[BRLTTY] Linux console hacking (was: Re: Footsteps towards better accessibility in Linux)

[Aura Kelloniemi]

Hi,

On 2026-03-29 at 12:07 +0200, Sébastien Hinderer <sebastien.hinderer at ens-lyon.org> wrote:
 > Hi,

 > I very much share Aura's concerns.

 > Regarding re-using code, there already is ATK/AT-SPI, isn't that good
 > enough? And if it isn't, could it be improved to become good enough?

In my very much personal opinion AT-SPI2 is not suitable as a generic access
framework for terminal emulators, for at least the following reasons:

1. AT-SPI2 depends on D-Bus and is deeply integrated into the GNOME
accessibility stack. This is reasonable in a full desktop environment, but not
in lightweight scenarios (e.g. kmscon). Pulling in D-Bus and the GNOME
accessibility infrastructure purely to reach a terminal emulator is overkill
and most likely will not be an acceptable solution for kmscon or other
non-GNOME terminal emulators.

2. AT-SPI2 has no dedicated terminal interface; terminals are exposed as
generic text area widgets. That abstraction is too weak for BRLTTY’s needs
because it does not represent essential terminal concepts like screen size,
text/background colors, text attributes (bold, underline, reverse, faint,
etc.) and character widths.

3. AT-SPI2 does not provide a way for BRLTTY to inject input into the terminal
in a way comparable to writing to a Linux VT. In X, key events travel through
the generic desktop input stack and may be transformed, filtered, or blocked
by global shortcuts, window managers, etc. In Wayland, injecting key events is
not possible at all.

4. D-Bus is not well-suited to high-frequency updates at terminal speeds.
Terminals can update large portions of the screen many times per second.
Representing this as a stream of D-bus messages leads to high IPC overhead. -
This can introduce latency (and even lost updates).

Dave once proposed a possible solution using shared memory, and I believe that
this would be a good way to share screen contents between BRLTTY and the
termianl emulator. However, some bidirectional communication layer should
exist for passing input events to the terminal and for receiving screen size
and focus change events – maybe even supporting the GUI elements of the
terminal emulator itself (i.e. menus, settings controls, etc.).

Whatever the interface is, I believe that the terminal emulator side should be
implemented as a shared library so that the amount of code in every particular
emulator would be minimal. This would increase the chances for terminal
emulator authors to accept this and would minimize the effort to keeping this
code maintained. Also, it should not be a security threat, should not slow
down the emulator nor increase its memory usage (while not in use).

-- 
Aura