[BRLTTY] linux screen driver and commands

[Mario Lang]

Samuel Thibault <samuel.thibault at ens-lyon.org> writes:

>> 2) Is this switch-case dependent of the "local keyboard papping (such
>> as azerty, qwerty, and so on?) because it seems to be a qwerty map
>> into the screen.c file?
>
> Yes. This is a well-known default mapping.
>
>> And if so, what happens for accent - keys such as E acute, a grave; and so on ?
>
> They won't work that this function.
>
> But this doesn't pose problem: in XLATE or UNICODE mode (i.e. the usual
> mode), all textual keypresses are always emulated by the insertByte
> function (insertUinputKey() is only used for special key combination
> that can't be simulated by TIOCSTI). In RAW or MEDIUMRAW modes, this is
> not the case. In such case, the keyboard mapping will be qwerty ; but in
> practice, these modes are only used by X, for which xbrlapi is able to
> directly simulate correct keypresses in the X server.
>
> Nota: since evdev also provides KEY_* codes, you can simulate them back
> using the currently implemented uinput facility, you don't need to care
> about keyboard mapping.

Exactly, this grab-keys features does absolutely not present keyboard
mapping problems, since the kernel does the mapping of a keycode
to the actually used symbol *after* it receives the key via
uinput.  This is how the HandyTech Braille Star external keyboard
works, we receive AT2 keyboard scancodes from the braille display, map
them to uinput keys, and send them to the kernel via uinput.
The kernel maps the key to the symbol.  So I can use loadkeys to change
the mapping of my external keyboard.

The same would apply for this grab-key feature, since the key we receive
from the kernel input layer can be passed straght through to uinput
if we dont care about it, and will be mapped to the correct symbol
by the kernel later.

-- 
CYa,
  Mario