Trigger execution of scripts in response to keys on braille displays

[jteh]

Braille display drivers call methods on braille.handler to scroll the display and perform cursor routing. However, no other keys are supported. Keys on braille displays should be able to trigger scripts in NVDA; e.g. previous line, next line, toggle tether, etc.

[jteh]

This raises some issues with regard to keyboard layouts:

• In which keyboard map should the braille display keys be placed?
  • They certainly aren't specific to desktop or laptop layouts.
  • One option is to place them in their own "braille" map. This requires that multiple key maps be loaded simultaneously.
• Should there be a different keyboard map for each display?
  • This probably makes sense, as each display is essentially a different keyboard layout.
  • However, the keys would still need to be differentiated; e.g. brltty_windn, not just windn. This is necessary so that they can be differentiated from other keys.

We probably need to refactor our keyboard layout system to take this into account. There is also other dissatisfaction with the current system, so a refactor should take all of this into account.

[SamuelThibault]

Note: the brlapi.KEY_CMD_* commands should already be generic. Of
course not all devices support them all, but a generic keymap should
already be quite fine. We could make a survey of which devices provide
which in brltty. Now, you can also use the driver parameter of
enterTtyMode to get raw keycodes as read by brltty from the device, to
define device-specific keymaps. These could be shared with other
drivers' keymaps.

[jteh]

Replying to SamuelThibault:

Note: the brlapi.KEY_CMD_* commands should already be generic. Of
course not all devices support them all, but a generic keymap should
already be quite fine.

It is my attention to use this generic mapping for the BRLTTY driver. These still need to bind to scripts in NVDA, so the mechanism still needs to be developed.

Now, you can also use the driver parameter of
enterTtyMode to get raw keycodes as read by brltty from the device, to
define device-specific keymaps.

I think that those using BRLTTY may already be familiar with BRLTTY key bindings, so it would be best to use those (generic) keys. Of course, some of these don't map so well to a Windows GUI screen reader and we may have to fudge this a little.