[BRLTTY] Footsteps towards better accessibility in Linux

[Aura Kelloniemi]

Hello,

On 2025-05-13 at 01:34 +0200, Samuel Thibault <samuel.thibault at ens-lyon.org> wrote:
 > Aura Kelloniemi, le lun. 12 mai 2025 12:58:32 +0300, a ecrit:
 > > We would need to export BRLTTY's key table management data structures to
 > > client applications, and there would need to be a brlapi call for transferring
 > > key tables from the client to the server and the other way around.

 > But what form would that be? a binary format? a text format to be parsed
 > by brltty? Security questions raise quite quickly...

Depends on what BrlAPI already is, but don't ask me, I have never designed a
network protocol from a security viewpoint.

 > > But if the client does the translation, all the same problems need to be
 > > solved.

 > Except that all the interface questions are not cast in stone into
 > the protocol (which is way more problematic to upgrade than a library
 > interface). And security questions do not raise.

Hmm, are we talking about the same thing? If the key event handling is done on
the client side in a way that I see it, BRLTTY needs to send its current key
tables to the client through BrlAPI. The client may then us ethem to provide
basic key bindings and as basis for more complete display model specific key
bindings.

This requires that we have a protocol for sending the bindings data.

Of course BRLTTY can just send both raw keycodes and the commands it
interpreted from them, and refrain from sending the whole key binding tables,
but then the client application cannot reliably extend the command set
provided by BRLTTY, because it cannot know which key bindings are already
taken. It also cannot tell the user which key combination (on their specific
display) triggers a particular command (like BRLTTY's help screen does).

 > > the client might need to run another thread to do the translation.

 > The current key event does not provide timing information but that would
 > be easy to add, avoiding the client to have to use threads etc. only to
 > get the event timing.

Then the server would need to send key repeat events as well, because long key
presses can trigger actions based on timeouts (compare to BRLTTY's own command
repetition handling). But yes, this is quite simple.

 > >  > 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.
 > > 
 > > BRLAPI_PARAM_DRIVER_KEYCODE_NAME cannot tell anything more about the key than
 > > its name.

 > What would you expect more than that?

Routing key index would be a very useful piece of information. It would also
be great to know if the pressed key is such that the display has a big number
of them (like routing keys, touch sensors, etc.).

 > > if I remember correctly, it does not work for routing keys at all –
 > > for the first routing key it says the name is is "routing key" or
 > > similar, and for all the rest it gives no name.

 > That'd just be a bug to be fixed.

Kind of, but BRLTTY does not itself have a separate name for different routing
keys. They are all called simply a "RoutingKey" or "NavrowKey". These names
are used in key binding tables. THe problem is that BRLTTY is able to detect
which of the routing keys was pressed, but the applications cannot do this
without specializing to a particular display model.

-- 
Aura