I'm a Logitech Desktop LX-710 owner, one of the newest cordless desktop kits from Logitech. It comes with a unique USB receiver for both mouse and keyboard, and it's pretty similar to the Logitech Desktop S510, sharing the same keyboard layout and extra/multimedia keys (and the probabily the same receiver - S510 with media remote only). Trying to make all the extra keyboard keys work, I've found this about S510: http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.21.y.git;a=commit;h=b55fd23ccdf32f969a7b4180c6e52d62d8e99972 Now, taking a look at the code added in hid-core.c we can see: #define USB_VENDOR_ID_LOGITECH 0x046d #define USB_DEVICE_ID_LOGITECH_USB_RECEIVER 0xc101 +#define USB_DEVICE_ID_LOGITECH_USB_RECEIVER_2 0xc517 and here is a lsusb: marco@alfa:~$ lsusb | grep Logitech Bus 001 Device 002: ID 046d:c517 Logitech, Inc. Infact, in dmesg: [ 24.773558] input: Logitech USB Receiver as /class/input/input1 [ 24.773584] input: USB HID v1.10 Keyboard [Logitech USB Receiver] on usb-0000:00:02.0-1 [ 24.783244] /build/buildd/linux-source-2.6.22-2.6.22/drivers/hid/usbhid/hid-core.c: Fixing up Logitech keyboard report descriptor So it seems to be the same hardware (keys and receiver), but I don't know if they share the same scancodes (they probably do). However I'm still unable to get some of the extra keys working, but I'm not sure whether is a scancodes/keycodes mapping problem or a xorg problem (xev can't see them and running a 2.6.20, prior to that patch, means no extra keys working except multimedia keys). Using the 2.6.22 or the lastest 2.6.23.1 kernel and this configuration in xorg.conf: Section "InputDevice" Identifier "Generic Keyboard" Driver "kbd" Option "CoreKeyboard" Option "XkbRules" "xorg" Option "XkbModel" "pc105" Option "XkbLayout" "it" EndSection almost all the extra keys are working except: Fn + F2 Fn + F3 Picture button Rotate button Zoom+ Zoom- Zoom100% Voip button Shuffle button Fn + Stamp Fn + Break Doing cat /dev/input/event1 reports all the standard 105 keyboard events while cat /dev/input/event2 reports both the extra keyboard keys and mouse events. As soon as possible I'll try to use evrouter to make that keys work but I don't thinks this is the solution and probably a kernel hack is needed.
Marco, could you please - send output of 'evtest' (part of input-utils package) when you press the non-working keys? This way we can know whether they are passed through evdev and only your X are ignoring them, or if they don't even make it from HID code to input - if the keys are not seen in output of evtes, please compile your kernel with CONFIG_HID_DEBUG, modprobe the 'hid' module with 'debug=1' parameter, and send me the output from the moment you connect the receiver, and also from the moment you press the non-working keys. Thanks.
Created attachment 13588 [details] debug logs First of all taking a closer look at some S510 photos on the web I noticed a few minor differences in some extra keys functions (nothing really important) and one major difference: in the S510 there's no Fn+Stamp (menu - right mouse button) and no Fn+Break (scroll lock button). I run into the suggested test and collected the results in the tarball attached, which has two dirs containing system/debug logs, one reporting information about all the extra keys and the other one containing information about the device and the non-working keys only. Ok, let's say that using evtest all the keys are reported except the Fn+Stamp and Fn+Break combos (the evtest output is included in the tarball and the keys pressing order too, if needed). So I connected the receiver and pressed this two combos and then I pressed and logged every single key. I don't know if can be usefull but you can find a detailed photo of the keyboad and its functions/shortcuts/keys here: http://www.absence.it/img/DSC05045.JPG So, the S510 patch seem to work fine for the LX710 too (Fn+Stamp and Fn+Break excluded) but I still don't know how to make this extra keys work, since some of them have a code above the 255 limit. Is X capable of reading those keys, or is it possible a specific mapping in the kernel? getkeycodes shows me an empty table. Thanks
Created attachment 13630 [details] keycodes list I'm back with further news. Well, I'll be a little verbose but I think it's necessary for you to understand clearly what I did and what I got. A few days ago I tried changing my xorg.conf to make the extra keys work by adding a third "Input Section" (a second keyboard) using the evdev driver. Unfortunately it didn't worked (that time), maybe for a stupid configuration error or an oversight. Then tomorrow searching for a solution I found this howto: http://gentoo-wiki.com/HOWTO_Microsoft_Natural_Ergonomic_Keyboard_4000 It deals with the Microsoft Natural Keyboard 4000 but it suffers similar problems about keycodes above the 255 limit. I tried once again changing my xorg.conf into: Section "InputDevice" Identifier "Generic Keyboard" Driver "evdev" # Option "Phys" "usb-0000:00:02.0-1/input0" Option "CoreKeyboard" Option "XkbModel" "evdev" Option "XkbLayout" "it" EndSection Section "InputDevice" Identifier "Extra Keyboard" Driver "evdev" Option "Phys" "usb-0000:00:02.0-1/input1" Option "SendCoreEvents" Option "XkbModel" "evdev" Option "XkbLayout" "it" EndSection and.. it worked! The standard keyboard (with boot capabilities) is fine and all the extra keys are reported by xev. But there is a problem, some of them share the same keycode. This is due to the fact that keycodes > 255 are lowered down into an 1-255 range by the X evdev driver, as esplained in the url above, in this way: X keycode = ((kernel keycode + 8) mod 256). Infact in the file attached you can see, in the next to last column, how X keycodes are calculated and generated (where the original keycode is obtained through evtest). Keycodes collision are numbered from 1 to 5. So I thought: is it possible to avoid keycodes collision configuring the main keyboard as a standard keyboard throught the xorg driver (not the evdev one) that was able to manage both the usual 105 keys and the extra keys with keycodes < 255 and then configuring a second special keyboard using the evdev driver for keycodes > 255? Unfortunately with this solution collisions (from 7 to 9) still persist as you can see in the last colomn of the attached file, although they are a little bit better. But I can't get this configuration working. In conclusion, since this keyboards are usefull only in a graphical environment it's just a X problem, using 1 byte for keycodes and so lacking support for keycodes > 255. I know. But I don't think that the xorg developers team are going to remove this limitation soon, although they should (without waiting for X12). Do you think is possible a kernel workaround similar to that used for the MS Natural Ergonomic Keyboard 4000 (as explained in the HOWTO) to make no more collision happen?
Marco, first, sorry for the delay in reply, I have been quite busy with a lot of different things lately. Regarding the evdev keycode limit -- keycodes up to 2^16 can be passed through the event interface. You need to specify "evdev" as the keyboard driver in the xorg.conf input device section and the correct input device for your keyboard. Then you can get all the keys working correctly in X.Org. Thanks a lot for providing the logs. I am a little bit confused with them though -- could you please be more specific which keypresses are not working (i.e. do not produce anything in evtest), and what lines in the logs correspond to them? As long as you can see keys properly reported in the evtest output, the kernel part is OK and if it's not working in X for you, it is very probably something in the X configuration. Thanks a lot.
Created attachment 13668 [details] non-working keys kernel logs Hi Jiri, thanks for your reply and please there's no need for you to apologise! Well, as I explained I do use the evdev driver in my xorg.conf but problems still persist. I don't think it's an evdev kernel driver problem (as you say it supports 2^16 keycodes, infact my evtest reports keycodes > 255 as well) but it's an xorg evdev module problem (evdev_drv.so / xserver-xorg-input-evdev package). To tell the truth it's not even an evdev module defect, it's rather an xorg limitation (it don't support keycodes > 255, maybe due to the PS2 standard?) and to accomplish this limit the xorg evdev module truncates kernel keycodes with this formula: X keycode = ((kernel_keycode + 8) mod 256). But using this trick causes different keys to share the same keycode under X. For example: KeyboadKey keycode X_keycode [Vol_+] = 115 + 8 = 123 [Rotate] = 371 + 8 - 256 = 123 So here is the problem, every single key is working but some of them are still unusable. Since it's a xorg problem I wrote to the xorg developers but I'm still waiting for a reply. However, if I'm not wrong, for the MS Natural Ergonomic Keyboard 4000 which suffers the same problem, someone wrote a kernel patch to change the scancode/keycode mapping for the "colliding" keys. Do you think it would be possible a temporary patch of this kind as a workaround? I know, it's not the right solution but if it can make them work correctly... Sorry for the confusion, I thought it was better not to taint kernel logs, new detailed logs are attached, reporting just the two extra keys (Fn+Stamp and Fn+Break combos) not seen by evtest. Evtest output for the working keys is included too. By the way, for the "Find" key I get, on my laptop running linux 2.6.23.1, keycode #217, while keycode #136 on my desktop running 2.6.22.9. Thanks for paying attention. Regars
Hi, in the recent kernels, you can change the mapping from userspace "on the fly", HID layer now supports getkeycode()/setkeycode() methods. There are some software packages (for example google for KeyTouch) which make this task quite user friendly thing to do. Regarding Fn+Stamp and Fn+Break, I'd definitely like to fix it so that it makes its way to evdev. I unfortunately don't have the hardware, so I'd need a hint from you -- what would be the correct mapping for these events? I.e. what is the expected functionality, when you press these keys? Regarding the X issues, I am afraid you'll really have to consult them with X developer, sorry. Thanks.
Hi Jiri thanks for all this information, all this input devices stuff is something new for me. As far as I know USB keyboards don't generate scancodes so I don't really know which program should be used (KeyTouch didn't work for me). However, this is not a kernel issue, so it doesn't matter here... About the extra keys don't worry, I'm here to help you and to provide all the information you need. The Fn+Stamp combo should open the right mouse click menù. Pressing Fn+Break once should activate the Scroll Lock funcion, while pressing it again should obviously deactivate the Scroll Lock. Some keys and shortcuts (Fn+FX) are a little bit different from the S510 model, so here is a list of all the extra keys, their keycode (read from evtest) and functionality. Key Keycode Function ------------------------------------------- Picture 392 Image Editor Rotate 371 Rotate Image Zoom+ 419 Zoom In Zoom- 418 Zoom Out 100% 420 Reset Zoom Vol- 114 Lower Volume Vol+ 115 Raise Volume VolMute 113 Mute Audio Find 217 File Search Mail 155 Mail Client VoIP 430 VoIP Client Music 171 Audio Player Shuffle 410 Next Track - Shuffle Mode >>| Track 163 Next Track |<< Track 165 Previous Track Play/Pause 164 Play/Pause Fn+F1 236 Word Processor Fn+F2 421 Excel / Spreadsheet Fn+F3 423 Calendar Fn+F4 140 Calculator Fn+F5 131 Documents Fn+F6 182 New Folder Fn+F7 210 Print Fn+F8 234 Save Fn+F9 148 User Defined Shortcut A Fn+F10 149 User Defined Shortcut B Fn+F11 202 User Defined Shortcut C Fn+F12 203 User Defined Shortcut D Fn+Stamp --- Right Mouse Button Menù Fn+Breack --- Scroll Lock Sleep don't know the keycode but works Let me know if you need more informations. Thanks
Any news?
(In reply to comment #7) > As far as I know USB keyboards don't generate scancodes so I don't really > know > which program should be used (KeyTouch didn't work for me). However, this is > not a kernel issue, so it doesn't matter here... Yes, they don't generate scancodes, but HID usage codes. Recently autor of KeyTouch made me write a patch to kernel, that would allow KeyTouch to be used even for USB keyboards. Please ask him what is the current status of this support in KeyTouch. > Pressing Fn+Break once should activate the Scroll Lock funcion, while > pressing > it again should obviously deactivate the Scroll Lock. > Some keys and shortcuts (Fn+FX) are a little bit different from the S510 > model, > so here is a list of all the extra keys, their keycode (read from evtest) and > functionality. Thanks. I I'll do a patch for Fn+Break and Fn+Stamp and will ask you to test it.
Did that happen ?
I have never seen a patch so I had no opportunity to test it. However, using evtest right now those two combo seem to work. marco@etna:~$ ll /dev/input/by-id/ totale 0 lrwxrwxrwx 1 root root 9 2008-09-27 21:22 usb-Logitech_USB_Receiver-event-kbd -> ../event4 lrwxrwxrwx 1 root root 9 2008-09-27 21:22 usb-Logitech_USB_Receiver-event-mouse -> ../event5 lrwxrwxrwx 1 root root 9 2008-09-27 21:22 usb-Logitech_USB_Receiver-mouse -> ../mouse1 Now with "evtest /dev/input/event4" I can see every single keyboard key exept the extra keys. With "evtest /dev/input/event5" I can see both the keyboard extra keys and the mouse keys/movements. So it seems fully working now, I think we can close this bug.