[BRLTTY] BrlAPI Raw key code mode?

[Shérab]

Hi,

Mario Lang (2017/07/24 00:30 +0200):
> 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.

Well, in the "isKeyCapable" function, there is this bit of code:

  ... || (disp && disp->keyNames!=NULL

So I'm not sure, perhaps something has been implemented based on
keyNames, I can't remember and was not able to find anything in the
code.

> So it isn't really about just HandyTech, rather, the question
> seems to be: do we still care for this feature?

The idea that was behind it initially was to allow one to write
device-specific software, e.g. re-implement under Linux
manufacturer-provided software one was used to under DOS/Windows.

> If so, should we make an effort to convert our drivers to support it?

I'd say yes, it's worth the effort, both for the feature and for what it
brings in terms of code improvement.

> Or is there a better way, now that we have key name tables?

I don't know.

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

Okay. But you know that is not actually true, I guess.

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

Good.

> > In other words, does your code call brlapi_strerror or the like
> > somewhere?
> 
> Not yet, but everything in place to do that soon.

Good, again.

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

Okay, I get your point. Will talk about it with Samuel.

Shérab.