[BRLTTY] FreedomScientific raw key codes

[Aura Kelloniemi]

Hello

I have been experimenting with the new API which can converts the raw key codes
returned by the braille driver to their respective key names. For this I wrote
a simple Python program which I include at the end of this message. I have
used BRLTTY's development code from Saturday.

I have some questions about the results that I got. I am using a
FreedomScientific Focus Blue display (newer model which does not have the
wheel keys, but nav keys instead).

First a normal case, where everything works as expected. Here is the output of
atest run of my program, where I press a few keys:

<clip>
[2.5291862] RightSelector press (0x11)
[3.1254345] RightSelector release (0x11)
[3.6691326] Dot1 press (0x0)
[4.5242367] Dot1 release (0x0)
[14.541956] LeftNavPress press (0x8)
[14.739393] LeftNavPress release (0x8)
</clip>

Then another run where I once press the LeftNavUp key and release it, then I
press the RightNavDown key and release it respectively. These keys probably
send periodic press/release events while the key is held down, but not a
single press/release event per a key press. However, you can see, that the
release events are a bit odd:

<clip>
[2.2287493] LeftNavUp press (0x20)
[2.229068] Dot1 release (0x0)
[2.7348714] LeftNavUp press (0x20)
[2.7351442] Dot1 release (0x0)
[3.0898827] LeftNavUp press (0x20)
[3.0901469] Dot1 release (0x0)
[4.1273401] RightNavDown press (0x22)
[4.1275699] Dot1 release (0x0)
[4.6337695] RightNavDown press (0x22)
[4.6340487] Dot1 release (0x0)
[4.9898944] RightNavDown press (0x22)
[4.9901697] Dot1 release (0x0)
</clip>

This makes it impossible for an application to keep track of whether the Nav
keys or the Dot1 key are being pressed at the same time. However, I noticed,
that BRLTTY itself is able to detect this. I tested this by pressing down the
Dot1 key, and then quickly pressing one of the Nav keys (which is supposed to
send the Dot1 release event). I then (without releasing the Dot1 key) pressed
the Dot2 key, and BRLTTY outputted the letter B (dots 1 and 2) to the
terminal. This confirms, that for some reason BRLTTY does not mix the release
events. Is this a bug in the raw key codes API?

Thirdly, I tested using the Routing keys. According to BrlAPI there is a
single key called Routing which has the raw key code 0x1FF. Here are the
results for the test run:

<clip>
[1.6521713]  press (0x100)
[2.728411]  release (0x100)
[3.6034265]  press (0x101)
[4.7098149]  release (0x101)
[6.568527]  press (0x127)
[7.5384698]  release (0x127)
</clip>

Here the name of the key is an empty string. Could there be a way in which
applications using raw key codes could detect that a routing key is pressed
(and which one)? I mean, without resorting to driver/device-specific
information. And would it be feasible, that if an unknown key code is sent to
PARAM_KEY_SHORT_NAME it would return NULL instead of an empty string (maybe it
does so in C)?

The Python program which I used is this:

<clip brlapitest.py>
import brlapi
import time

press_flag = 0x8000000000000000

clock_start = time.monotonic ()
ba = brlapi.Connection ()

try:
    ba.enterTtyMode (brlapi.TTY_DEFAULT, ba.driverName)
    while True:
        key = ba.readKey ()
        clock = time.monotonic () - clock_start
        pressed = bool (key & press_flag)
        press = "press" if pressed else "release"
        key &= ~press_flag
        key_name= ba.getParameter (brlapi.PARAM_KEY_SHORT_NAME, key, brlapi.PARAMF_GLOBAL)
        message = f"{key_name} {press} (0x{key:x})"
        ba.writeText (message)
        print (f"[{clock:.8}] {message}")
finally:
    ba.leaveTtyMode ()
</clip>

Thanks for any comments!

-- 
Aura