[BRLTTY] BrlAPI Raw key code mode?

[Mario Lang]

Shérab <Sebastien.Hinderer at ens-lyon.org> writes:

> Mario Lang (2017/07/23 11:54 +0200):
>> Oh!!!  Thanks for reminding me.  Indeed, now it dawns on me that there
>> is this driver-specific translation mechanism...  This sort of got lost
>> in the noise (for me) since we have introducted key tables.  I guess I
>> need to see if the HandyTech driver can be extended with these
>> translation functions.
>
> Yes. I expect this to be not too hard because the code that converts
> keycodes to commands is already there somehow, more or less explicitly.
> So, in my experience, such a change mostly consists in factorizing the
> driver code and making it cleaner.

Grepping for brl_keyToCommand and brl_readKey, I only find the Visio and
TTY drivers to have such a function.  Seems my original feeling is true, though for
different reasons: raw keycode mode isn't supported by a majority of the
drivers.  So it isn't really about just HandyTech, rather, the question
seems to be: do we still care for this feature?  If so, should we make
an effort to convert our drivers to support it?  Or is there a better
way, now that we have key name tables?

>>   if (Number == -1) throw std::system_error(brlapi_errno, std::generic_category());
>>   return { this, Number };
>> }
>
> With this code, will you get proper BrlAPI error messages?

std::error_code, which is what is being used under the hood here, allows
to pass low level error codes around.  And yes, indeed, this *will*
allow for proper BrlAPI error messages.  For now, I am just pretending
brlapi_errno contains standard errno values.  Once I get to it, it is
just a matter of implementing a BrlAPI::ErrorCategory and using it inside
of the throw instead of generic_category, and the exception message will
automatically contain the proper error message, and can also still be
handled programatically.

> In other words, does your code call brlapi_strerror or the like
> somewhere?

Not yet, but everything in place to do that soon.

> Just to be sure. Assuming the current code is made to work correctly,
> why wouldn't you be able to implement your tool with the code in its
> present state? Why do you need symbolic key names for that?

I would be able to do what I want with raw keycodes as well.  But not
needing to duplicate keycode decoding logic for every supported model in
the client would be convenient.  Symbolic was probably misleading.
While a function to retrieve the actual key name from the driver would
probably be a nice to have, what I am actually thinking about is an
interface to how most drivers tell the core that a key was pressed or
released these days.  Take the following example statement from the
HandyTech driver as an example:

    return enqueueKeyEvent(brl, HT_GRP_RoutingKeys, byte - HT_KEY_ROUTING, !release);

There is a key group, an actual key value, and the press/release status.
As the example nicely shows, the decoding of keycodes basically
happens before enqueueKeyEvent is finally called.  It are these, still
untranslated to commands, but already logically decoded key events that
I am interested in as a BrlAPI client.  If backwards compatibility is an
issue, just go for a new name like brlapi__readKeyEvent.  But since we
have the information on that level inside of the core since the key name
table rewrite, I think we should make it possible for BrlAPI clients to
make use of it.  Since all drivers that have been rewritten to use key
tables should actually call enqueueKeyEvent at some point, passing key
events to BrlAPI clients should also not need any driver change.
Contrary to enabling old keycode mode, which I don't really know how to
fit into the new callback way.

-- 
CYa,
  ⡍⠁⠗⠊⠕ | Blog: <https://blind.guru/>  GitHub: <https://github.com/mlang/>
  .''`. | Twitter: @blindbird23        FaceBook: disyled
 : :' : | SoundCloud: <soundcloud.com/mario-lang>
 `. `'  | YouTube: <youtube.com/user/mlang23>
   `-