[BRLTTY] [Feature request] Improved raw key codes API

[Samuel Thibault]

Aura Kelloniemi, le sam. 05 déc. 2020 14:25:51 +0200, a ecrit:
> As this information can be decoded from the raw key code, a new function to
> BrlAPI could be added.

Just one thing here: I don't think we want to embed the decoding
knowlege in libbrlapi itself, but keep it in the driver or key table.
I.e. when decoding a key event, you'd request the server to do the
decoding. We can however try to cache the result in libbrlapi, to avoid
requesting it every time.

> /// Stores information about a single raw key press/release event.
> typedef struct {
>     // Key codes
>     uint32_t key_group;
>     uint32_t key;
> 
>     bool pressed; // 1 if pressed, 0 if released
> } brlapi_raw_key_event_t;

uint32_t could seem more than enough, but you never know, Dave what do
you think?

What'd we need first is something in the core that provides the
information: from a raw key code construct fill such a structure.

> typedef struct {
>     uint32_t key_group; // The same value as in brlapi_raw_key_event_t
>     char *key_group_name; // Human- and machine readable/comparable name of this group – e.g. "RoutingKey"
>     int key_count; // Total number of keys in this group
> } brlapi_raw_key_group_description_t;
> 
> Now there should be a function which provides the caller a list of
> brlapi_raw_key_group_description_t instances.

protocol-wise I'd say it'd be first getting the list of key_group
values, then query the information for each group, but that can be done
by libbrlapi, yes.

Then the question is to which extend we'd standardize group names.
There will be some groups we'd want to standardize such as routing keys,
more precisely to say that "key" in that case is the routing key number.
Ditto for dot key. Possibly for some other kinds of keys?

Samuel