uinput was the thing, not udev.
kbdd, the buggy user level driver for nonHID BT keyboards, uses rfcomm to link with the keyboard and then the modules uinput and keybdev to inject the keystrokes.
Also, google reports on some old work of a guy creating the fake hid needed for some keyboards in 2.4 kernels,
http://klausler.com/msbtkb-linux.html
Quote:
|
I read the code in the kernel for USB keyboards and realized that I could exploit it. I wrote a small (100 lines) Linux device driver as a loadable module. All it does is register itself as a keyboard device, and then take any keyboard input events that are written into it and hand them off to the input core as keycode events. After remembering to load the "input" and "keybdev" modules, I loaded my new driver, and it worked the first time I tested it by creating a character device special file with "mknod" and writing some bytes into it. The keycodes that I sent were immediately echoed as if I had typed them on the keyboard. I was in business.
|
So once we have got, via kernel space modules, the BT signal, there are three ways:
- From the kernel space, via input and keybdev
- From user space, uinput and keybdev
- From user space having access to X, via the extension Xtest, which is told to be activated in the iRex (
Antartica suggested
xautomaton, and in fact design256 tested xte to work for mouse input at least)
xmodmap will be probably a must, later depending on the keyboard. I have a BT keyboard without the pipe symbol!