Aivils Stoss wrote: > If You use Linux, then problem is kernel related. Almost Logitech > keyboards uses two USB interfaces : 1st as normal keyboard and 2nd as > multimedia keys. > > I think 2.4 ingnore multimedia keypress and do not send keycodes to TTY. You are correct indeed -- this is a Linux kernel problem. Thanks for pointing me in the right direction. I am going to test this keyboard on my FreeBSD machine later and see what happens. Also, my keyboard is not a USB/HID device -- it is a PS/2-style, cheap ($14) PS/2 Logitech keyboard. According to a few others, the keyboards work under Linux 2.4. I haven't tested this myself. Under the new 2.5/2.6 kernels (that I am using), it does not. Since I read your message I did some research on this; I didn't find too many other related hits on the web. That's alarming! I assume this means that few people are trying to map multimedia keys in Linux 2.5/2.6, or have given up trying... or are just happy with the keys that DO work, since 2.5/2.6 seem to see _some_ extra keys, but not all. However, I did find this message below which may help people: > From: Andries Brouwer (aebr (at) win.tue.nl) > Subject: Re: multimedia keys not working in 2.6.0-test6 > > Newsgroups: linux.kernel > Date: 2003-09-30 08:00:32 PST > > On Tue, Sep 30, 2003 at 01:54:59PM +0200, Pau Aliagas wrote: > > > These are the messages I get when pressing P1 and P2 in my laptop. > > > > kernel: atkbd.c: Unknown key pressed (translated set 2, code 0x153, data > > 0x74, on isa0060/serio0). > > kernel: atkbd.c: Unknown key released (translated set 2, code 0x153, > > data 0xf4, on isa0060/serio0). > > > > Email and browser keys report a correct code and I can bind thm to > > any app using xbindkeys, but with thes two there's no way. > > These keys produce scancode e0 74. Untranslated e0 53. > Entry 0x153 of atkbd_set2_keycode[] is 0, that is why > the key is called unknown. > > The normal way of assigning a keycode is by using setkeycodes. > This uses the KDSETKEYCODE ioctl, but it is broken at present. > > The reason is that it is written to use 0-127 for scancode xx > and 128-255 for scancode pair e0 xx. (Translated set2, of course.) > However, the current kernel untranslates what the keyboard sends > and then uses a scancode-to-keycode mapping for untranslated set 2. > That breaks this ioctl. > > Moreover, it uses a shift of 256 instead of 128 for e0. > That also breaks this ioctl. > > So, today the easiest way of getting these keys to work is to > edit kernel source: linux/drivers/input/keyboard/atkbd.c > and adapt atkbd_set2_keycode[0x153]. This is the line > 226, 0, 0, 0, 0, 0,153,140, 0,255, 96, 0, 0, 0,143, 0, > if I am not mistaken, of which you want to change the fourth > number, the third zero, to the desired keycode. > > In the meantime we can worry about the best way to fix this ioctl. > > Andries _______________________________________________ XFree86 mailing list XFree86@xxxxxxxxxxx http://XFree86.Org/mailman/listinfo/xfree86
