[BRLTTY] Footsteps towards better accessibility in Linux

[Samuel Thibault]

Aura Kelloniemi, le mer. 07 mai 2025 22:30:29 +0300, a ecrit:
>  > Separating these means duplicating that code, thus
>  > more maintenance work long-term etc.
> 
> Or putting the code to a shared library and sharing it.

Maintaining a shared library (and thus documentation, backward
compatibility, etc.) is much more work than just sharing the code within
just one project.

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

Do you mean e.g. the management of combinations of key presses and
keytable definition? Such as

bind LeftJoystickLeft+RightJoystickPress TOP

?

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

Which is already the case. But apparently for the commands that you
don't want to handle, you want to receive the underlying raw keycodes,
instead of just drop them?

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

Again, taking the xkb example, it'd seem to me simpler to let the
application perform the translation by itself, possibly using a library
helper for this, rather than having to tell the server the translation,
only for the server to perform the translation on behalf of the client.

> This would allow BRLTTYs key press->command translation machinery to be reused
> by applications, would not require tremendous changes to BRLTTY

The difficult part is how to tell BRLTTY the desired translations. Which
essentially is the same kind of difficulty as defining a library helper
that does this. It's thus probably simpler to just do the translation on
the client side. That can e.g. make it simpler to have different binding
depending on application state etc.

For a start, the piece that is missing is the combination of receiving
the desired commands *and* receiving keycodes that are not bound to a
desired command. And application will already be able to use
BRLAPI_PARAM_DEFINED_DRIVER_KEYCODES and
BRLAPI_PARAM_DRIVER_KEYCODE_NAME to get the set of raw keycodes and
their names.

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

We are short in time in general, yes, that's why I'm very careful with
the management of development complexity.

Samuel