[BRLTTY] BrlAPI Raw key code mode?

[Aura Kelloniemi]

Hello list,

Shérab <Sebastien.Hinderer at ens-lyon.org> writes:
 > Mario Lang (2017/07/24 00:30 +0200):
 > > 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.

I also need this feature, please consider implementing it.

My experience with BrlAPI suggests that the current interface based on BRLTTY
commands is useful if and only if one's application is very similar to BRLTTY
itself. However, I don't know of a single application that uses BrlAPI and is
very similar to BRLTTY. Most applications don't have use for most of the
commands understood by BRLTTY, but instead would benefit from their own
command set in order to make the braille display interface as intuitive as
possible.

What I have wanted to implement for a long time is an interface to the text
editor Emacs (yes, I hear you saying that it is accessible already - you are
right, but read on). Emacs can be made much easier to use by allowing the user
to do basic editing with their braille display such that they don't need to
move their hands to the computer keyboard in order to copy/paste, to activate
buttons, to switch buffers and windows, etc. A special braille interface to
Emacs could also communicate to the user about different Faces used by Emacs
(by using special marker dots or symbols as configured by the user) - and it
would allow the user to use their braille display's routing keys in a similar
fashion a sighted person would use a mouse. Note also that Emacs is not
accessible to BRLTTY users when it is run in an X Windows mode (which is very
useful for having full keyboard input support in Emacs).

I would like the keys to be categorized in a simple fashion. It would be ideal
if BrlAPI could return (in addition to the key press status) the name of the
key (as defined by the display manufacturer) plus the category information.

Categories could be something like Routing key / Braille keyboard key / Touch
/ Wheel / Normal key.

A function that would return a list of all the keys on the braille display
(along with their category information) would be of use to applications which
allow the BrlAPI input interface to eb configured inside the app. I don't know
though if it is possible to write this kind of a function such that it would
provide accurate information.

-- 
Aura