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

[Nicolas Pitre]

On Wed, 8 Apr 2026, Aura Kelloniemi wrote:

> 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!

Thanks.

I actuallystarted implementing this into kmscon. And obviously reality 
checks and practicalities came in the way. So I'm revising the document 
as I go.

> 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.

It still needs a high degree of privileges to create those device nodes 
in the first place.

But the need for access control remains. The terminal must make its 
shared memory segment accessible but we don't want any random process 
being able to snoop the console and log keypresses.

> 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.

At the moment I have a sharable header file defining structures and 
protocol values. The adapter layer consists in converting the internal 
representation into the shared memory format and this is highly terminal 
specific. Once this is done there is so far simply nothing left worth 
factoring out into a shared library.

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

In theory. I'll reconsider my position once I have something actually 
working.

> 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.

Sure. But the "very simple to plug into almost any terminal emulator" 
won't hold up in reality. There is always complexity to contend with.
I'm looking at only one terminal emulator right now and this makes me 
scratch my head already.

> 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.

You still need some intrusive hooks deep inside the emulator core to 
intercept data flows. That's unavoidable if you want to have an 
efficient system that is not constantly polling memory content for 
changes. That can't be created on demand with a loadable library.

So I'm going with the functionality-first approach in this kmscon proof 
of concept, and the form it takes is a consequence of that, not a design 
requirement.

> 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.

Sure. It still needs to prove itself though.


Nicolas