[BRLTTY] Footsteps towards better accessibility in Linux

[Samuel Thibault]

Aura Kelloniemi, le lun. 12 mai 2025 12:58:32 +0300, a ecrit:
> It chould be done with new brlapi commands or using parameters.

I'm not questioning what would be the conveyer, but the format of the
data to be conveyed.

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

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

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

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

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

Samuel