User-space Keyboard input?
Hi.
I'm working on BRLTTY[1], a user-space daemon which handles braille displays on UNIX platforms. One of our display drivers recently gained the ability to receive (set 2) scancodes from a keyboard connected directly to the display. This is a very cool feature, since the display in question has
a bluetooth interface, making it effectively into a complete wireless terminal (input and output through the same connection).
However, this creates some problems. First of all, we now have to deal with keyboard layouts. Additionally, since we currently insert via TIOCSTI I think this might get problematic as soon as one switches to an X Windows console and modifiers come into play.
Does anyone know (and can point me into the right direction) if Linux has some mechanism to allow for user-space keyboard data to be processed by the kernel as if it were received from the system keyboard? I.e., keyboard layout would be handled by the same mapping which is configured for the system.
Signature · 2 lines
Thanks, Mario
Hi Mario,
Quoted 6 lines
I'm working on BRLTTY[1], a user-space daemon which handles braille displays on UNIX platforms. One of our display drivers recently gained the ability to receive (set 2) scancodes from a keyboard connected directly to the display. This is a very cool feature, since the display in question has
a bluetooth interface, making it effectively into a complete wireless terminal (input and output through the same connection).
tell me more about this Bluetooth device.
Quoted 10 lines
However, this creates some problems. First of all, we now have to deal with keyboard layouts. Additionally, since we currently insert via TIOCSTI I think this might get problematic as soon as one switches to an X Windows console and modifiers come into play.
Does anyone know (and can point me into the right direction) if Linux has some mechanism to allow for user-space keyboard data to be processed by the kernel as if it were received from the system keyboard? I.e., keyboard layout would be handled by the same mapping which is configured for the system.
Take a look at the user level driver support (uinput).
Regards
Marcel
A message that is not in the archive (sent off-list or not yet received): [email protected]
Hi Mario,
Quoted 7 lines
Quoted 7 lines
Quoted 6 lines
I'm working on BRLTTY[1], a user-space daemon which handles braille displays on UNIX platforms. One of our display drivers recently gained the ability to receive (set 2) scancodes from a keyboard connected directly to the display. This is a very cool feature, since the display in question has
a bluetooth interface, making it effectively into a complete wireless terminal (input and output through the same connection).
Quoted 5 lines
Quoted 1 line
tell me more about this Bluetooth device.
Its a Braille Star 40 from HandyTech. Originally sold, the device had two alternative ports, serial or USB. They recently offered an additional bluetooth module. I don't really know what you want to know though :-).
what kind of profiles do this Bluetooth module support? Is it a HID compatible device or do it uses a vendor specific protocol? Do you tested it with Linux?
Quoted 11 lines
Quoted 11 lines
Quoted 10 lines
However, this creates some problems. First of all, we now have to deal with keyboard layouts. Additionally, since we currently insert via TIOCSTI I think this might get problematic as soon as one switches to an X Windows console and modifiers come into play.
Does anyone know (and can point me into the right direction) if Linux has some mechanism to allow for user-space keyboard data to be processed by the kernel as if it were received from the system keyboard? I.e., keyboard layout would be handled by the same mapping which is configured for the system.
Quoted 3 lines
Quoted 1 line
Take a look at the user level driver support (uinput).
Yup, thats it, thanks. Now I just need to find some example code on how to use it :-).
The BlueZ CVS repository utils2 contains the old bthid code that makes use of the uinput kernel module.
Regards
Marcel
Hi Mario,
About modifiers, I submitted a patch to Dave to handle them properly.
But ascii to scancode translation still depends on scancode to ascii translation performed by the kernel indeed and the question still applies. I'll have a look at uinput.
Regards,
Samuel
Quoted 6 lines · Samuel Thibault
About modifiers, I submitted a patch to Dave to handle them properly.
But ascii to scancode translation still depends on scancode to ascii translation performed by the kernel indeed and the question still applies. I'll have a look at uinput.
uinput support is now committed to scr_linux.c. I am using the exernal keyboard of my bluetooth capable braille display to type this email already via uinput :-). The same layout is used as is configured on the box. Our generic AT2 support maps to VAL_PASSKEY commands and
the AT2 support for Linux maps the AT2 scancode set to what Linux internally uses for scancodes (a sort of XT scancode set, but not really).
Signature · 2 lines
CYa, Mario