[BRLTTY] BrlAPI Raw key code mode?

[Shérab]

Hi Aura,

Aura Kelloniemi (2017/09/01 08:01 +0300):
> Samuel Thibault <samuel.thibault at ens-lyon.org> writes:
> 
>  > Dave Mielke, on ven. 25 août 2017 17:27:45 -0400, wrote:
>  > > [quoted lines by Shérab on 2017/08/25 at 22:47 +0200]
>  > > 
>  > > >> Each client specifies which key ranges it'll handle. Those key ranges are for 
>  > > >> values derived from key table processing. In other words, key table processing 
>  > > >> occurs before determining which client should get any given key code, so key 
>  > > >> table processing is common to all clients. Perhaps I'm missing something, but, 
>  > > >> to me, that gets in the way of clients defining their own commands.
>  > > >
>  > > >Indeed. That's why I suggested to provide the keybindigns processing
>  > > >code as a library. That way this could be done by each client and the
>  > > >code would still be shared.
>  > > 
>  > > I don't see how that'd work. If a client specifies raw key codes then it gets 
>  > > everything. That only allows for one client at a time. It also doesn't allow 
>  > > for xbrlapi to be running in order to handle input.
> 
>  > AIUI, an application which would use a different binding than the brltty
>  > commands would have to be responsible. I.e. if it only supports a set of
>  > key events, it should only request the brltty daemon to send these, and
>  > let the daemon send others to other clients, if any, such as xbrlapi.
> 
> I would prefer the interface to be such that BRLTTY sends the raw key codes
> (or commands, or maybe even both) to a client. Then the client responds to
> BRLTTY whether it actually consumed the key or not so that BRLTTY can pass the
> same code to another client.

For a key which is not consumed by the client, that may make its
processing very slow, even from a user experience perspective, IMO.

Shérab.