[BRLTTY] Footsteps towards better accessibility in Linux

[Samuel Thibault]

Hello,

Aura Kelloniemi, le mer. 07 mai 2025 12:23:59 +0300, a ecrit:
> On 2025-05-07 at 00:05 +0200, Sébastien Hinderer <Sebastien.Hinderer at ens-lyon.org> wrote:
>  > Aura Kelloniemi (2025/05/07 00:15 +0300):
>  > > - 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. All
>  > >   BRLTTY's screen reading features would be just extra bloat (and would also
>  > >   be additional attack surface).
> 
>  > It's possible to make BRLTTY rather minimal, e.g. by compiling it with
>  > the no screen driver.
> 
> This is why I expected that it would not require a lot of work to separate
> BrlAPI and BRLTTY from each other,

But what do you aim for exactly? The brltty infrastructure already
provides the plugging between a real-braille-driver and the brlapi
server, and between a brlapi-braille-driver and a screen driver.

Where would you want to split?

I'm really seeing this as "let's try to split because it looks nice on
the board". But if you look at the code, there's the module loading
infrastructure and all asynchronous management infrastructure that is
used in both case. Separating these means duplicating that code, thus
more maintenance work long-term etc.

> because it is almost doable already just by building BRLTTY twice with
> different configure options.

Yes, and why isn't it fine to just do this? Or just not compile it
twice, and instead just not load a screen driver in the braille-driver
brltty instance?

>  > > - 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.
> 
>  > Well in text mode having two instances of BRLTTY works, a bunch of times
>  > I hacked with blind friends and we did manage to do that. It's true that
>  > it's not yet well supported at the BrlAPI client leel, but it's not
>  > inconceivable that clients connect to several instances of BrlAPI at the
>  > same time.
> 
> Yes, but it is not easy. I don't need to use multiple displays, just one
> display is enough, if I normally use it with bluetooth and then plug it into
> USB port for charging. Then a new BRLTTY is launched for the "new" display,

So that's what needs to be disabled: you just need to run brltty only
once (not auto-started by udev) and let it see devices one after the
other. And brlapi will follow, and Orca as well. That will already
work. That's actually the default configuration on debian for instance.

> The point of this complaint is that BrlAPI is not a first-class citizen in
> BRLTTY world,

Ok, I think I see your point.

To put it another way, what I understand from it is that by forcing
ourself to split everything, we will *have* to improve the "BRLTTY as a
BrlAPI client" case.  To my eyes, that mostly looks like a management
strategy which mostly adds yet more work to something that could be done
as well without that additional work (and incrementally).

>  > Also, the only thing you have to do if you do not
>  > want BRLTTY commands is to ask for key codes whenyou enter in tty mode.
> 
> Yes, but BRLTTY already provides a lot of machinery to handle driver-specific
> key codes and reimplementing this logic to every BrlAAPI application that
> requires a different command set form BRLTTY is tedious, errorprone and wasted
> time.

You mean the logic of managing a table between a keycode and some
application-specific command? This does really not seem to me like a lot
of work (it's essentially a hash table), I don't think it's really worth
trying to bend models just to be able to share this.

> Currently BrlAPI's support for describing raw keycodes is incomplete, BRLTTY
> cannot for example tell the client that the pressed key is a routing key – it
> just sends a code.

Ok, I agree that we could define an intermediate between raw keycodes
and brl commands, that provides some well-known key types, along other
device-specific key types (whatever buttons happens to be on the
device), and those will necessarily need application-specific bindings
to be defined by the user or gathered by the community in the software.

> BrlAPI applications would benefit a lot from a setup where they can ask for
> some BRLTTY commands and allow the user to configure the rest of the key codes
> how they wish.

But by "commands", do you mean only braille commands without any brltty
notion (e.g. routing keys), or also some commonly-used meaning of some
buttons, such as what brltty calls "next window" but essentially means
"next"?

>  > And finally, I am skeptical about thae fact that splitting BRLTTY from
>  > BrlAPI would lead to progress in this direction. Well even if it would,
>  > that progress would have to outweight the manpower necessary to do that
>  > split and which is scarce and may be better used on a different front.
> 
> Assuming the split is quite simple, adding the new features (for command
> handling, device management, etc.) would certainly take the most manpower.

I believe it'd be the contrary. Splitting would *not* be simple (but
again, maybe I'm misinterpreting what kind of split you are talking
about). And again, I'm really afraid of the maintenance cost if we are
to duplicate the pieces of code.

On the other side, changing the key command management does not seem a
large task, and I don't think any kind of splitting would help in any
way here actually.

> At this point even BRLTTY as a BrlAPI client is not fully functional. For
> example it cannot produce speech, control status cells (on display which have
> them) and it cannot recover from situations such as crash (or restart) of the
> core BRLTTY.

Contribution welcome ;)

Again, that's completely independent from any kind of split.

> and if the separation itself causes resistance (as it seems to)

We are not resisting it. We are saying that it's work that can be
avoided. We are *already* overloaded, we cannot just add to ourself yet
more work just for the sake of beauty.

> Let me describe one possible idea on how braille accessibility could work in
> Linuxafter the rearrangement:

All you describe is *already* possible, except:

> Applications would sit on top of these [...] maybe by passing brailled
> a key bindings table (or by pointing brailled to such table on the
> disk).

Taking the X & Wayland as examples, that would rather be done at the
client level. That could be an addition to libbrlapi, like libxkb is an
addition to libX11/wayland.

> There would be a library for doing braille rendering (based on braille
> tables) – liblouis already does this, I suppose,

It does.

> but it could be extended to support global user-defined representations for
> widgets.

It could.

> In case brailled crashes, the clients would keep on trying to connect to it,
> and the system service manager would try to restart brailled.

That's already what happens with xbrlapi and Orca, for instance.

The fact that some pieces of the picture you describe are not exactly
there (like x11-brltty coping with root-brltty restarting), does not
mean that we should spend a lot of time just revamping everything only
to force ourself to fix the few things that are missing...

Samuel