[BRLTTY] BrlAPI Raw key code mode?

[Shérab]

Hi,

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.

> > What I find strange, though, is that you do not get a proper error from
> > BrlAPI. Normally, if you try to enter in raw keycode mode with a driver
> > that does not support it, you should get an oeration not supported
> > error, I think.
> 
> I just checked, and no, I didn't miss error handling:
> 
> BrlAPI::TTY BrlAPI::Connection::tty(int TTY, bool Raw) {
>   auto Number = brlapi__enterTtyMode(BrlAPI->handle(), TTY, Raw?
>   "HandyTech" : "");

Unrelated note: I would rather not use "Raw" as the name of the boolean
parameter because this can be confusing in the context of BrlAPI. Raw is
indeed used to mean a mode where you get packets directly from the
driver, so you are at a lower level than when you receive keycodes. So
I'd rather call this argument keyCodes or something like that. Just to
improve clarity, that would indeed change nothing to the behaviour of
the code, of course.

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

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

> It reports an error (no device or address) if I pass an invalid driver
> name string.  Maybe it should report a similar error if the driver
> string is correct, but the driver doesn't have the translation
> functions?

That is indeed what is supposed to happen, see the isKeyCapable function
in Programs/api_servec.c.

I have to say, though, I do not understand how the code is actually
supposed to work for now. First? I don't understand why the previously
mentionned funciton refers to the disp variable. Second, I was not able
to find the code that performs the delivery of key codes.

Mario, if you feel like experimenting, you could comment what appears
after the or in the isKeyCapable function and then my guess is that you
should get a proper error when trying to enter in tty mode.

> >> Also, now that we have symbolic key names, I wonder, is there any
> >> possibility to create some sort of "hybrid" raw mode for BrlAPI, which
> >> would return key names and press/release status?
> >
> > Samuel and I should probably think about it, indeed.
> 
> Please do.  I have an actual use case herre, which I'd like to implement
> in the upcoming months.  I'd like to build a musical instrument (a
> control voltage sequencer) out of a Braille display as main (and only) interface.  For
> that, having to deal with BRLTTY commands is not very convenient since
> what I am building is not a screen reader, rather, it is a native
> braille based hardware/software sequencer.  Here is a repository
> already, but it only contains binding code for now.  Maybe another
> result of this will be modern C++ BrlAPI bindings:
> https://github.com/mlang/brlcv

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?

In keycodes mode, the driver and the client program simply have to agree
on the meaning of the numbers and then they can exchange pretty much
whatever they like.

Cheers,

Shérab.