[BRLTTY] Footsteps towards better accessibility in Linux

[Samuel Thibault]

Aura Kelloniemi, le mer. 07 mai 2025 00:15:20 +0300, a ecrit:
> On 2025-05-06 at 22:31 +0200, Samuel Thibault <samuel.thibault at ens-lyon.org> wrote:
>  > Aura Kelloniemi, le mar. 06 mai 2025 23:11:47 +0300, a ecrit:
>  > > I think that we could discuss decopuling these activites – i.e. separating
>  > > BrlAPI server out of BRLTTY (possibly together with some additional features).
> 
>  > > BRLTTY would then always communicate with the display(s) through BrlAPI.
> 
>  > What would be the benefit, compared to the additional latency?
> 
> There are several. Most of them are related to usage scenarios where Linux
> virtual consoles are not the only environment where the user is working.
> 
> - Resource usage: if the user does not use VTs (or they are not available),
>   having a core BRLTTY that reads unused screens, parses configuration files,
>   manages braille tables, starts a speech driver, etc. is useless.

Nowadays the linux screen driver does almost nothing. And if opening
fails, it'll just report the failure to the core and not do anything
further. The rest of the core remains useful for braille rendering.

> All BRLTTY's screen reading features would be just extra bloat (and would also
>   be additional attack surface).

The linux screen would stay completely silent, without any attack way.

> - Multiple displays: if the user uses multiple displays (like I sometimes do),
>   they cannot connect them all to the same BRLTTY instance. Running a second
>   BRLTTY for the second display does not help, if the user wants to use
>   anything that relies on BrlAPI.

I don't understand: you can already set different BrlAPI server ports
for the different BRLTTY instances, and tell clients which one you can
to connect to.

> - Separation of roles/Unix philosophy: communicating with a braille display
>   and providing a user interface are different tasks and they naturally belong
>   to different programs once the user wants to use only one of these features.

Ok, but that's just a principle, not really a benefit.

> - Better support for BrlAPI-enabled applications: currently it is non-trivial
>   to write BrlAPI applications which don't utilize BRLTTY's command set in
>   their input handling.

? Either they know the braille device, and use raw keycodes as you wish,
or you don't know the braille device, but still can use raw keycodes
and let the user define bindings on the fly, or else you can rely on
something existing. That can be the brltty bindings, or something else
can be set up, but that can be built on *top* of the existing brlapi
rather than sticking it into the protocol. Similarly to X11's xkb which
sits in clients, not the server.

> - Resource usage again: if the user runs several BRLTTYs (e.g. one for
>   console, one for gnome-terminal, one for some other terminal emulator, etc.)
>   the BRLTTY binaries will all contain code for the BrlAPI server and this
>   code will be kept in memory,

No, it won't. The OS loads it on-demand. And it shares the physical
pages between all instances of it.

> - Device management: whether it is adding, removing or switching a braille
>   display from one connetion type to another, all device management could be
>   done by the core server. This would mean that all clients could fluently
>   switch from one display to another,

That is already supported.

>   or the user could configure the server to keep multiple displays
>   synced together, link different clients to control different
>   displays independently, or whateer.

That's an entirely different thing, which can be built independently
from the current brltty code: something that connects to existing
brlapi servers and opens a new brlapi server port, and provides the
user with ways to switch between the connections to the existing brlapi
servers. We had thought about it with Sebastien decades ago, we just
never took the time to implement something. Some parts of the brlapi
server code can probably be reused (e.g. the packetization, already
shared between the server and the client library), but not very much
more.

(I hope you'll admit that this isn't exactly the most common case to
have several displays, and nothing in the current code *prevents*
from achieving what you want, it's "just" more code that needs to be
written).

Samuel