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

[Aura Kelloniemi]

Hi Nicolas and the list,

I finally have time to comment on this:

On 2026-03-30 at 01:16 -0400, Nicolas Pitre <nico at fluxnic.net> wrote:
 > Well... given the glutton for punishment that I am, I went ahead and 
 > looked at what BRLTTY+kmscon would entail. That resulted in the attached 
 > design document. The actual code implementing it would be quite simple 
 > and probably smaller than the document itself.

Thank you very much! This is a great proposal!

 > Comments welcome.

Regarding security, quoting your proposal:

 > This follows the same model BRLTTY already uses for access to
 > `/dev/input/*` devices and braille USB hardware, where udev rules assign
 > group ownership. BRLTTY runs as a system service (started at boot, before
 > any user logs in) with the appropriate group membership configured via its
 > systemd unit (`SupplementaryGroups=brl`)."

Nowadays, BRLTTY actually creates most of the required device nodes in its own private
mount namespace, eliminating the need to grant extra permissions on device
nodes.

Regarding the shared-library approach:

 > Implement the screen export and access protocol as a shared library that
 > any terminal emulator could link against (writer side) and any
 > accessibility tool could link against (reader side).

I still wonder whether the benefits would outweigh the drawbacks. One common
library might encourage other terminal emulators to adopt this system. The
adapter layer could be expanded each time we integrate a terminal emulator
with a different internal representation.

Reimplementing the same protocol (or, even worse, several similar protocols)
adds maintenance overhead for BRLTTY and could complicate the integration
process.

I'd like to see a solution that is very simple to plug into almost any
terminal emulator so that, after integration, BRLTTY would work with that
terminal emulator right away, without even needing to know which emulator it
is or what kind of internal representation it uses for screen contents.

If we implemented this protocol as a shared library, it could be designed so
that the library is easy to load dynamically (using dlopen). Some terminal
emulators may really want to avoid adding a new dependency, or even
accessibility code at all, because they may worry that the accessibility part
would slow the emulator down. If most of the accessibility code were loaded
only on demand, that concern would be mitigated.

 > - The tmux driver performs a full `capture-pane` on every update,
 >   transferring the entire screen content even when only one character
 >   changed and even when the braille display shows a different region.

Yes, and if we could get tmux to adopt our generic interface/protocol, it
would be an amazing step toward general terminal accessibility.

But I understand that tmux would probably prefer expanding its current socket
protocol, but the shared memory segment could still use the protocol from this
proposal.

 > - For a primary console, this inefficiency is significant.

Tmux is a primary console for many, like me. However, I don't use BRLTTY's
tmux driver.

I consider the tmux terminal driver to be broken at the moment for two reasons:

1) The inefficiency mentioned above, and
2) The lack of support for running BrlAPI applications inside tmux.

I use BrlAPI applications regularly and I need to open a separate VT for working with them.

 > The shm segments are created using `memfd_create()` rather than
 > `shm_open()`.

It seems that at least some BSDs support `memfd_create()`, so this is probably
portable enough.

You can see that I am trying to broaden the scope of your proposal. That is
because it is a very good proposal, and I really believe it could function as
a standard interface between terminal emulators and accessibility clients in
general. That is why I'd like to generalize it now and involve other terminal
emulator developers in the discussion, in addition to the kmscon developers.

-- 
Aura