Bug 9396

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.