[BRLTTY] BrlAPI Raw key code mode?

[Shérab]

Aura Kelloniemi (2017/07/31 01:25 +0300):
> 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.

Orca for instance.

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

I share Samuel's fear that is will be difficult to design something
which is generic enough. What can we do beyond returning the keycodes
themselves or brltty commands, as we currently do?

> 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 find all this very interesting. I am pretty sure a lot of research and
experimenting remains to be done regarding the way to most effectively
use a braille terminal.

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

I think the key code as returned now does reflect all this, at least as
faithfully as brltty does in its braille tables, no?

Perhaps there is some decoding to do which we could make easier, but I
think the information is pretty much there already.

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

Couldn't the client get this by parsing the keytable for the device?

Shérab.