Scroll wheel on BTC 8193 keyboard is not working in Linux. On another keyboard (Genius SlimStar Pro) and the scroll wheel works there. When I rotate or click the wheel, nothing happens, nothing is appearing in the relevant /dev/input/eventNN file, nothing bad in dmesg. Here's the hardware info I was able to collect: # dmesg | tail -n 6 usb 1-6.1.2: new low speed USB device using ehci_hcd and address 16 usb 1-6.1.2: configuration #1 chosen from 1 choice input: USB-compliant keyboard as /class/input/input18 input: USB HID v1.10 Keyboard [USB-compliant keyboard] on usb-0000:00:1a.7-6.1.2 input: USB-compliant keyboard as /class/input/input19 input: USB HID v1.10 Device [USB-compliant keyboard] on usb-0000:00:1a.7-6.1.2 # /sbin/lsusb | grep KEY Bus 001 Device 016: ID 0518:0002 EzKEY Corp. # /sbin/lsusb -d 0518:0002 -v Bus 001 Device 016: ID 0518:0002 EzKEY Corp. Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 1.10 bDeviceClass 0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize0 8 idVendor 0x0518 EzKEY Corp. idProduct 0x0002 bcdDevice 1.00 iManufacturer 0 iProduct 1 USB-compliant keyboard iSerial 0 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 59 bNumInterfaces 2 bConfigurationValue 1 iConfiguration 0 bmAttributes 0xa0 Remote Wakeup MaxPower 100mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 0 bAlternateSetting 0 bNumEndpoints 1 bInterfaceClass 3 Human Interface Devices bInterfaceSubClass 1 Boot Interface Subclass bInterfaceProtocol 1 Keyboard iInterface 0 HID Device Descriptor: bLength 9 bDescriptorType 33 bcdHID 1.10 bCountryCode 0 Not supported bNumDescriptors 1 bDescriptorType 34 Report wDescriptorLength 65 Report Descriptors: ** UNAVAILABLE ** Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes 3 Transfer Type Interrupt Synch Type None Usage Type Data wMaxPacketSize 0x0008 1x 8 bytes bInterval 10 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 1 bAlternateSetting 0 bNumEndpoints 1 bInterfaceClass 3 Human Interface Devices bInterfaceSubClass 1 Boot Interface Subclass bInterfaceProtocol 2 Mouse iInterface 0 HID Device Descriptor: bLength 9 bDescriptorType 33 bcdHID 1.10 bCountryCode 0 Not supported bNumDescriptors 1 bDescriptorType 34 Report wDescriptorLength 50 Report Descriptors: ** UNAVAILABLE ** Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x82 EP 2 IN bmAttributes 3 Transfer Type Interrupt Synch Type None Usage Type Data wMaxPacketSize 0x0003 1x 3 bytes bInterval 10 If there is anything else I should report here -- please ask.
It looks like there are 2 interfaces on it, with the scroll wheen reported via the 2nd mouse-like device. How is you mouse set up?
(In reply to comment #1) > It looks like there are 2 interfaces on it, with the scroll wheen reported > via > the 2nd mouse-like device. Agree. > How is you mouse set up? If you mean X.org configuration, it reads from /dev/input/mice. The two specific problems I see is 1. I get nothing from cat /dev/input/event18 (which I presume is that "mouse"). $ pwd /dev/input $ ls -l by-id/ total 0 lrwxrwxrwx 1 root root 10 2007-11-15 13:58 usb-0518_USB-compliant_keyboard-event-kbd -> ../event17 lrwxrwxrwx 1 root root 10 2007-11-15 13:58 usb-0518_USB-compliant_keyboard-event-mouse -> ../event18 lrwxrwxrwx 1 root root 9 2007-11-14 18:20 usb-Logitech_USB_Receiver-event-mouse -> ../event1 lrwxrwxrwx 1 root root 9 2007-11-14 18:20 usb-Logitech_USB_Receiver-mouse -> ../mouse1 # cat /dev/input/event18 (I scroll and click -- nothing here) 2. There is no mouseX file in neither /sys/class/input/input18 nor input19 dir. Both looks like a keyboard: $ cat input18/uevent PHYSDEVPATH=/devices/pci0000:00/0000:00:1a.7/usb1/1-6/1-6.1/1-6.1.2/1-6.1.2:1.0 PHYSDEVBUS=usb PHYSDEVDRIVER=usbhid PRODUCT=3/518/2/110 NAME="USB-compliant keyboard" PHYS="usb-0000:00:1a.7-6.1.2/input0" UNIQ="" EV=120003 KEY=1000000000007 ff87207ac14057ff febeffdfffefffff fffffffffffffffe LED=7 MODALIAS=input:b0003v0518p0002e0110-e0,1,11,14,k71,72,73,74,75,77,79,7A,7B,7C,7D,7E,7F,80,81,82,83,84,85,86,87,88,89,8A,8C,8E,96,98,9E,9F,A1,A3,A4,A5,A6,AD,B0,B1,B2,B7,B8,B9,BA,BB,BC,BD,BE,BF,C0,C1,C2,F0,raml0,1,2,sfw $ cat input19/uevent PHYSDEVPATH=/devices/pci0000:00/0000:00:1a.7/usb1/1-6/1-6.1/1-6.1.2/1-6.1.2:1.1 PHYSDEVBUS=usb PHYSDEVDRIVER=usbhid PRODUCT=3/518/2/110 NAME="USB-compliant keyboard" PHYS="usb-0000:00:1a.7-6.1.2/input1" UNIQ="" EV=f KEY=7fff00ac3027 bf00444400000000 1 c000a37c000 267bfad941dfed 9e000000000000 0 REL=40 ABS=100000000 MODALIAS=input:b0003v0518p0002e0110-e0,1,2,3,k71,72,73,74,77,80,82,83,85,86,87,88,89,8A,8B,8C,8E,8F,90,96,98,9B,9C,9E,9F,A1,A3,A4,A5,A6,A7,A8,A9,AB,AC,AD,AE,B1,B2,B5,CE,CF,D0,D1,D2,D4,D5,D9,DB,EA,EB,100,162,166,16A,16E,178,179,17A,17B,17C,17D,17F,180,181,182,185,18C,18D,192,193,195,197,1A0,1A1,1A2,1A3,1A4,1A5,1A6,1A7,1A8,1A9,1AA,1AB,1AC,1AD,1AE,r6,a20,mlsfw # for f in input*; do echo === $f; cat $f/uevent; done === input0 PRODUCT=17/1/1/100 NAME="Macintosh mouse button emulation" EV=7 KEY=70000 0 0 0 0 REL=3 MODALIAS=input:b0017v0001p0001e0100-e0,1,2,k110,111,112,r0,1,amlsfw === input18 PHYSDEVPATH=/devices/pci0000:00/0000:00:1a.7/usb1/1-6/1-6.1/1-6.1.2/1-6.1.2:1.0 PHYSDEVBUS=usb PHYSDEVDRIVER=usbhid PRODUCT=3/518/2/110 NAME="USB-compliant keyboard" PHYS="usb-0000:00:1a.7-6.1.2/input0" UNIQ="" EV=120003 KEY=1000000000007 ff87207ac14057ff febeffdfffefffff fffffffffffffffe LED=7 MODALIAS=input:b0003v0518p0002e0110-e0,1,11,14,k71,72,73,74,75,77,79,7A,7B,7C,7D,7E,7F,80,81,82,83,84,85,86,87,88,89,8A,8C,8E,96,98,9E,9F,A1,A3,A4,A5,A6,AD,B0,B1,B2,B7,B8,B9,BA,BB,BC,BD,BE,BF,C0,C1,C2,F0,raml0,1,2,sfw === input19 PHYSDEVPATH=/devices/pci0000:00/0000:00:1a.7/usb1/1-6/1-6.1/1-6.1.2/1-6.1.2:1.1 PHYSDEVBUS=usb PHYSDEVDRIVER=usbhid PRODUCT=3/518/2/110 NAME="USB-compliant keyboard" PHYS="usb-0000:00:1a.7-6.1.2/input1" UNIQ="" EV=f KEY=7fff00ac3027 bf00444400000000 1 c000a37c000 267bfad941dfed 9e000000000000 0 REL=40 ABS=100000000 MODALIAS=input:b0003v0518p0002e0110-e0,1,2,3,k71,72,73,74,77,80,82,83,85,86,87,88,89,8A,8B,8C,8E,8F,90,96,98,9B,9C,9E,9F,A1,A3,A4,A5,A6,A7,A8,A9,AB,AC,AD,AE,B1,B2,B5,CE,CF,D0,D1,D2,D4,D5,D9,DB,EA,EB,100,162,166,16A,16E,178,179,17A,17B,17C,17D,17F,180,181,182,185,18C,18D,192,193,195,197,1A0,1A1,1A2,1A3,1A4,1A5,1A6,1A7,1A8,1A9,1AA,1AB,1AC,1AD,1AE,r6,a20,mlsfw === input4 PHYSDEVPATH=/devices/platform/pcspkr PHYSDEVBUS=platform PHYSDEVDRIVER=pcspkr PRODUCT=10/1f/1/100 NAME="PC Speaker" PHYS="isa0061/input0" EV=40001 SND=6 MODALIAS=input:b0010v001Fp0001e0100-e0,12,kramls1,2,fw === input5 PRODUCT=19/0/2/0 NAME="Power Button (FF)" PHYS="LNXPWRBN/button/input0" EV=3 KEY=10000000000000 0 MODALIAS=input:b0019v0000p0002e0000-e0,1,k74,ramlsfw === input6 PRODUCT=19/0/3/0 NAME="Sleep Button (CM)" PHYS="PNP0C0E/button/input0" EV=3 KEY=4000 0 0 MODALIAS=input:b0019v0000p0003e0000-e0,1,k8E,ramlsfw === input7 PHYSDEVPATH=/devices/pci0000:00/0000:00:1a.7/usb1/1-6/1-6.2/1-6.2:1.0 PHYSDEVBUS=usb PHYSDEVDRIVER=usbhid PRODUCT=3/46d/c501/110 NAME="Logitech USB Receiver" PHYS="usb-0000:00:1a.7-6.2/input0" UNIQ="" EV=20007 KEY=1f0000 0 0 0 0 REL=103 LED=ff00 MODALIAS=input:b0003v046DpC501e0110-e0,1,2,11,k110,111,112,113,114,r0,1,8,aml8,9,A,B,C,D,E,sfw
I see at least one problem: EV=f KEY=7fff00ac3027 bf00444400000000 1 c000a37c000 267bfad941dfed 9e000000000000 0 REL=40 REL=40 means that it seel REL_WHEEL but EV=f means that hid driver did not set EV_REL in dev->evbit so it is not passed to handlers by input core. Jiri, could you please take a look why HID would not set up evbit properly?
Kir, could you please compile your kernel with CONFIG_HID_DEBUG (if you already don't have it), and modprobe the 'hid' module with 'debug=1' parameter. This will give us additional output in the kernel log when you connect the device, and also when you move and click the wheel. Could you please send me this log? Thanks.
(In reply to comment #4) > Kir, > > could you please compile your kernel with CONFIG_HID_DEBUG (if you already > don't have it), and modprobe the 'hid' module with 'debug=1' parameter. OK, done that. Kernel is vanilla 2.6.23.8 (it was F8's 2.6.23 before). > This > will give us additional output in the kernel log when you connect the device, This is dmesg after unplugging/plugging the keyboard: usb 1-6.1.2: USB disconnect, address 6 usb 1-6.1.2: new low speed USB device using ehci_hcd and address 7 usb 1-6.1.2: configuration #1 chosen from 1 choice input: USB-compliant keyboard as /class/input/input6 input: USB-compliant keyboard as /class/input/input7 > and also when you move and click the wheel. WOW! Now when I rotate (any direction) or click the wheel, my X mouse pointer moves about 100px left. Finally I have something... It looks like it is now shown as a mouse, and I get some events from it: [kir@dhcp0-6 input7]$ sudo cat /dev/input/mouse2 )2�)2�)2�)1�)1�)1�)2�)2�)0�)0�)0�)1�)1�)1�)1�)1�)2�)2�)2�)0�)0�)0�)1�)1�)1�)2�)2�)2�)0� 1s are for wheel up, 2s are for wheel down, 0s are for click. So it does not look like a normal wheel...
Also, uevent is different now. [kir@dhcp0-6 input19]$ pwd /sys/class/input/input19 [kir@dhcp0-6 input19]$ cat uevent PHYSDEVPATH=/devices/pci0000:00/0000:00:1a.7/usb1/1-6/1-6.1/1-6.1.3/1-6.1.3:1.1 PHYSDEVBUS=usb PHYSDEVDRIVER=usbmouse PRODUCT=3/518/2/100 NAME="USB-compliant keyboard" PHYS="usb-0000:00:1a.7-6.1.3/input0" EV=7 KEY=1f0000 0 0 0 0 REL=103 MODALIAS=input:b0003v0518p0002e0100-e0,1,2,k110,111,112,113,114,r0,1,8,amlsfw
That's because you loaded usbmouse driver instea dof hid. Kill it (usbmouse).
(In reply to comment #7) > That's because you loaded usbmouse driver instea dof hid. Kill it (usbmouse). Oh. I had some success with the following sequence: # echo "options hid debug=1" >> /etc/modprobe.conf # modprobe -r usbmouse FATAL: Module hid is in use. (Still, usbmouse is now removed, mouse is unusable) # modprobe -r usbkbd usbhid hid (Keyboard is also unusable, using ssh from the other box for the next commands) # modprobe hid (Kbd/mouse not working) # modprobe usbhid Now keyboard starts to work, there are lot of messages from kernel -- see attachment #1 [details]. I try to use the wheel and see these messages (see attachment #2 [details]). I see that 231 is for scroll up, 232 for scroll down, 230 for clicking the wheel. Hope that helps.
Created attachment 13645 [details] kernel messages after loading hid debug=1 and usbhid
Created attachment 13646 [details] kernel messages when I use the scroll wheel
Sorry, I specified wrong attachment IDs in comment #8. Below are correct links to attachments. Now keyboard starts to work, there are lot of messages from kernel -- see attachment #13645 [details]. I try to use the wheel and see these messages (see attachment #13646 [details]). I see that 231 is for scroll up, 232 for scroll down, 230 for clicking the wheel.
Created attachment 13665 [details] 8193 scrollwheel testing patch Thanks a lot for providing the logs. The scrollwheel on your keyboard is not in fact behaving like a proper scrollwheel. It is emitting "Full Screen" (for clicking), "Normal View" (for scrolling-up) and "Toggle View" (for scrolling-down) events. These are currently not supported in Linux. Could you please try the attached patch and let me know whether the things got improved? This is definitely not the version I would want for mainline, but it will help to see whether another additional quirky handling would be needed or not. Thanks.
(In reply to comment #12) > Created an attachment (id=13665) [details] > 8193 scrollwheel testing patch > > Could you please try the attached patch and let me know whether the things > got > improved? Unfortunately it changes nothing for me, i.e. behavior is the same -- scrolling and clicking moves mouse pointer 100 px right. Yes I have checked that the patch is applied, that it's a new kernel wit and a new module. I can redo the logging part if you want.
(In reply to comment #13) > Unfortunately it changes nothing for me, i.e. behavior is the same -- > scrolling > and clicking moves mouse pointer 100 px right. Yes I have checked that the > patch is applied, that it's a new kernel wit and a new module. > > I can redo the logging part if you want. Hmm, strange. Did you also make sure not to use usbmouse and usbkbd modules, but usbhid and hid isntead?
Also, the logs should contain lines similar to drivers/hid/hid-input.c: Mapping: Button.0001 ---> Key.LeftBtn etc. but I don't seem to see them in the logs you provided. Could you please double-check that? Thanks.
(In reply to comment #14) > Hmm, strange. Did you also make sure not to use usbmouse and usbkbd modules, > but usbhid and hid isntead? Sorry. I have removed usbmouse, usbkbd, usbhid and hid modules, and then modprobe'd usbhid. That way there is neither usbmouse not usbkbd, and keyboard works, but mouse doesn't. I was not able to get the mouse working w/o loading usbmouse driver. Maybe my .config is wrong? Now when I only have usbhid and hid (not usbmouse/usbkbd) I can use keyboard (but not mouse) and kernel prints the same 230, 231, 232 codes when I use the wheel on the keyboard.
(In reply to comment #15) > Also, the logs should contain lines similar to > > drivers/hid/hid-input.c: Mapping: Button.0001 ---> Key.LeftBtn > > etc. but I don't seem to see them in the logs you provided. Could you please > double-check that? There are no such messages. Is something wrong with my .config?
Created attachment 13667 [details] my current kernel .config Attaching the .config in case you want to take a look.
Maybe this is totally unrelated, but when I unload usbmouse and then physically detach/attach mouse receiver to USB port, usbmouse module is loaded. Same with the keyboard -- when I rmmod usbkbd and reattach the keyboard, usbkbd is loaded.
Kir, to avoid further confusion, please disable both usbkbd and usbmouse in your .config. The driver that should control both USM keyboards and mice is usbhid. Jiri, in your patch you are mapping BTN_1, not BTN_LEFT. Was it intentional?
OK, recompiled with # CONFIG_USB_KBD is not set # CONFIG_USB_MOUSE is not set Now both keyboard and mouse work fine, no usbkbd/usbmouse modules loading, still scroll wheel doesn't work even with the patch. I will reload hid with debug=1 and attach the logs shortly.
Created attachment 13669 [details] kernel messages after loading hid debug=1 and usbhid I load hid with debug=1, when usbhid, then plugged in the keyboard and tried to use the scroll wheel. Mouse is unplugged to make the output shorter. I still don't have any "Mapping:" messages.
Actually the debug output is missing also other information, like report descriptor dump, etc. Where do you get this output from? If from syslog logs, doesn't syslog filter it somehow? Isn't 'dmesg' output more verbose?
(In reply to comment #23) > Actually the debug output is missing also other information, like report > descriptor dump, etc. Where do you get this output from? If from syslog logs, > doesn't syslog filter it somehow? Isn't 'dmesg' output more verbose? Right. Sorry for that. I will be able to attach proper output in about 12 hours.
Created attachment 13692 [details] full kernel messages after loading hid debug=1 and usbhid and using scroll wheel OK, I modified my sysctl.conf, and here are the full logs.
Thanks, this looks correct. What does evtest report now, when you use the wheel?
Created attachment 13696 [details] evtest output log (In reply to comment #26) > Thanks, this looks correct. What does evtest report now, when you use the > wheel? > I was not able to find evtest in my distro (F8), so I get one from a random place (http://aehallh.com/~warp/olpc/evtest.c) and compiled it. I ran it, then did scroll up, scroll down and click. Scroll up and scroll down events looks consistent with what I do. Output is attached.
Created attachment 13701 [details] btc 8193 hack #2 Hm, this device's handling of wheel is really badly broken. Could you please test the attached testing patch and report back to me whether this makes your wheel behave? Thanks for your cooperation.
Scroll wheel works! Two problems though: 1. When I scroll the wheel up, text scrolls down, and vise versa. 2. Typing "5" on the keyboard leads to "75". When I type Shift+5 I get "&%". It's 100&% reproducible. "5" on a numeric pad is not affected.
Created attachment 13706 [details] brac 8193 hack #3 (In reply to comment #29) > Scroll wheel works! Two problems though: Great, thanks a lot for testing. It's really messed up piece of hardware :) > 1. When I scroll the wheel up, text scrolls down, and vise versa. Yes, I did a small bug in the patch. The one attached is the correct one. Does also clicking work? > 2. Typing "5" on the keyboard leads to "75". When I type Shift+5 I get "&%". > It's 100&% reproducible. "5" on a numeric pad is not affected. Confusing. Did this started to happen when you applied my patch to fix the wheel, or did it happen also before? In any case, I would appreciate the hid debug logs from pressing this badly working key. Thanks.
Created attachment 13707 [details] btc 8193 hack #4 Or even better, please try this one.
Created attachment 13708 [details] btc 8193 hack #5 Sorry, I definitely don't have my day today. This one is the one that should be tested, sorry for the noise.
OK, hack 5 works better for me, scrolling direction is fine, wheel click is now sending left click (was right click before if I'm not mistaken), and instead of "75" the key "5" now emits just "7"... I will attach a log shortly
Created attachment 13711 [details] kernel debug log after hack#5 Removed the mouse to keep the log shorter, modprobed hid debug=1 and usbhid. Typed 4 5 6, then 4 5 6 again with Shift pressed. I get 7 instead of 5 and & instead of per cent sign (which I can not input now).
Created attachment 13713 [details] hack #5 applied; evtest output log when I use numbers on the keyboard Hack #5 applied; I run evtest and type 1 2 3 4 5 6 7 8. Instead of 5 I get 7.
Created attachment 13715 [details] btc 8193 hack #6 I really suck badly today :( Sorry. This one should fix your issues. Please let me know.
(In reply to comment #36) > Created an attachment (id=13715) [details] > btc 8193 hack #6 This one works flawlessly for me, thanks a lot! :) Could I suggest to unify "if (usage->type == EV_REL)" checks into a separate "if" statement?
(In reply to comment #37) > > Created an attachment (id=13715) [details] [details] > > btc 8193 hack #6 > This one works flawlessly for me, thanks a lot! :) Thanks a lot for testing. > Could I suggest to unify "if (usage->type == EV_REL)" checks into a separate > "if" statement? This patch was just for testing what is needed, I am going to merge a completely different one, as I have changed the way hid-input quirks are handled in recent kernels. You will be automatically CCed when the patch is added to my tree. Thanks.
BTW strange thing is that I don't seem to be able to close this bug as resolved, the only option I see is "Leave as REOPENED". If bugzilla allows you to close the bug, could you please do so? Thanks.
Fixed by the following commit in hid.git repository, branch hid-input-quirks: http://git.kernel.org/?p=linux/kernel/git/jikos/hid.git;a=commit;h=23bef39e61823111de6cff108773a0ff00388d9e
Fixed in vanilla, to be available in 2.6.25: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=36ccaad640737899b069a9a93a82765f0e675a20