[BRLTTY] Linux console hacking

[Lukáš Tyrychtr]

Hello.

Your DBus concerns are definitely valid.

However, AT-SPI2 actually can represent the terminal attributes you're 
talking about. The terminal size is a little tricky and you'd have to 
derive it by analyzing the screen content, or, we can of course have 
that information exposed through attributes of the terminal widget (the 
exposure to application programming toolkits is left as an excercise for 
the future).

Most of the text attributes is straightforwardly exposed through the 
text interface, maybe we have a few missing ones, but nothing stops 
standardizing new ones.

That's it for now,

L. T.

However,

Dne 29. 03. 26 v 16:59 Aura Kelloniemi napsal(a):
> 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).
>