[BRLTTY] Footsteps towards better accessibility in Linux

[Aura Kelloniemi]

Hi,

On 2025-05-07 at 13:45 +0200, Samuel Thibault <samuel.thibault at ens-lyon.org> wrote:
 > Aura Kelloniemi, le mer. 07 mai 2025 12:23:59 +0300, a ecrit:
 > 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.

Sorry, I don't know BRLTTYarchitecture so well. The extent of how BRLTTY uses
dynamically loaded libraries is new information to me and I did not take that
into account when making my list or suggesting the split. I have a bit more of
an end-user view here. For me it just seems clearer to have separate client
and server processes, not processes which sometimes act as clients, sometimes
as servers.

 > Where would you want to split?

That is a good question. Read on.

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

It seems to me that BRLTTYcodebase has already been organized very wisely – in
a way that is not immediately clear to someone who mostly has not read the
code.

 > Separating these means duplicating that code, thus
 > more maintenance work long-term etc.

Or putting the code to a shared library and sharing it.

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

I think you have demonstrated to me that my suggestion related to splitting
BrlAPI out of BRLTTY is not a good idea, and does not provide lots of value to
BRLTTY or braille accessibility in general. I pull that idea back.

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

Yes kind of, but Iexpected the splitting side to be trivial, so I saw this
more like an opportunity than as redundant work.

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

I mean the logic of mapping a (possibly very complex) combination of keycodes
to commands. BRLTTYdoes it very well and it is far from simple to duplicate.

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

Or allow the application to tell BRLTTYwhich BRLTTY commands it wants to handle
– commands like LNUP, FWINRT, HOME, etc.

Additionally the application could supply BRLTTY a model-specific key table
with application specific commands.

This would allow BRLTTYs key press->command translation machinery to be reused
by applications, would not require tremendous changes to BRLTTY and would be
the most convenient way for applications to extend BRLTTY's command set.

For example my e-book reader could tell BRLTTY that it understands general
movement commands, and BRLTTY would use its own key table to translate key
presses to these commands. In addition to these general commands, my
application could tell BRLTTY that it has commands named Accept and Cancel and
supply a binding for those commands. If the application does not have a
built-in mapping for the user's braille display, and the user does not provide
the binding, then BRLTTY cannot help and the application needs to find some way
to work around it, or report an error.

 > > 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"?

The later. So I want BrlAPI applications to be able to add new local commands,
and new local (application-specific) contexts as well.

 > > 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 ;)

I'm afraid I don't have the time. This would be very interesting though.

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

Oh, I did not know. It does not seem to work on my system. I need to look at
this.

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

Definitely not.

-- 
Aura