Linux - HardwareThis forum is for Hardware issues.
Having trouble installing a piece of hardware? Want to know if that peripheral is compatible with Linux?
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
I have a Hauppauge WinTV-HVR110 TV-Card, and that infrared remote control that came along with it.
Now I'd like to use that remote as pseudo-keyboard for my desktop.
I learned, that there are many ways how to make that remote usable in linux.
First thing I tried, was assigning Keysymbols. This works semi-well, some keycodes are the same keycodes that my normal keybord sends. This isn't that much of a problem, since they match pretty well (Numpad on remote sends numbers, Media-key match the Media-keys on my keyboard). But some keys simply don't work.
xev doesn't get any readings from the device on those buttons, so my first thought was, that they're non-functional.
However, when I tried the remote under a text-terminal (no X), I discovered something rather interesting:
when I run showkey -k (keycodes output), I get Keycodes fore _every_ key. This leads to the conclusion, that every key on the remote actually _IS_ functional.
But when I run showkey -s (scancodes) I only get codes for the same keys, that I get keycodes under X with.
But how is this possible? I get Keycodes, for nonexistent scancodes?
The Keycodes for the scancode-less keys are strangely high: Ranging from 353 to 412.
Since I couldn't fix that problem in two days of work, I followed the advice of a friend of mine, and tried LIRC.
But this turned out not to be satisfactory as well.
Passing commands to irexec works well, however this is not really handy, when it comes to things like passing a "volume_up" event to the desktop environment.
I can send key-events to applications with irxevent, when I assign the proper keysymbol to be passed to that application.
This works well for some applications - like XINE - but I'd like to pass certain events so my KDesktop-Environment, "volupe_up" for instance. Sending XF86... keys seems to be a general problem for irxevent, though. I'd like them to have the functionality, the media key on my keyboard have, sending XF86... keycodes to the desktop.
The keycodes come from my keyboards extra keys, so you of course have to modify them.
Then depending on your Desktop Environment or Window Manager you should use the specific way to assign shortcuts I guess. I am running IceWM and use aumix to deal with audio volume, but I think in KDE's control center you should find a way to assign shortcuts.
I have an interesting new piece of information: I have another Linux box (older), I plugged my apple keyboard on it, then I turned it on.
The keyboard didn't work until the SO start (seems the BIOS is not able to manage the USB keyboard) but after, the keyboard works with a wrong mapping but the F3 works.
After my reaserch (several hours) I conclude: "when no scancode but keycode in showkey() and no info in dmess is driver issue"
Next step: check the drivers in both computers.
I had this problem too with my hp pavilion, i had some mediakeys (dvd key) and some ir remote keys mapped to a keycode but no scancode!!
Problem is X reads only the first 255 keycodes, so you have to remap the key u wish to use to a lower keycode. However not having a scancode makes this impossible to do!
The fact is showkey -s does not get real scancode but a re-interpretation of the scancode! This happens with kernel 2.6, while in 2.4 this was not true!
However, as pointed out by Coacher on archlinux bbs, 2.6.9 and above kernels support atkbd.softraw=0 boot parameter.
All you have to do is boot with this parameter, use showkey -s to get the scancode and map it to a free keycode UNDER 255 (dumpkeys helps a lot here)!!
Oh i forgot: if no scancode is visible even with that kernel parameter then the driver is the problem!