[BRLTTY] Footsteps towards better accessibility in Linux

[Samuel Thibault]

Hello,

Aura Kelloniemi, le mar. 13 mai 2025 18:27:07 +0300, a ecrit:
> 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.

This actually shows that it's a complex question, and thus questioning
to try to make this a protocol.

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

No, it doesn't need to. The client can tell the server which commands it
would like to see passed as commands (e.g. routing keys), and on
keypress the server can either send the already-translated command (if
that matches something that the client wanted to see), or the raw key
event (if that didn't match).

It's then up to the client to translate the raw key events in whatever
way it likes. It can use BRLAPI_PARAM_DRIVER_KEYCODE_NAME to let the
user dynamically define bindings. Or it could use a helper from the
brltty code to define this from binding files.

> It also cannot tell the user which key combination (on their specific
> display) triggers a particular command (like BRLTTY's help screen does).

It does not need to.

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

Sure, just like is done in X11 etc.

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

In my mind routing keys, touch sensors, etc. would be typically commands
that client would request.

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

How can they be used in binding tables if they don't have differing
names, or some differing parameter?

Samuel