I recently replaced my old PS/2 keyboard with a new Microsoft-branded USB one and it's exposed a weird problem with Linux's USBHID device detection. As far as I can tell, the keyboard has 2 'interfaces', the first one is the actual HID Keyboard, the second one is a dead device (I think it might be a placeholder for the keyboard models with USB Hubs built-in). Linux detects the first input as a keyboard and registers it correctly but it detects the second as a generic "HID Device" then proceeds to register it as /dev/input/js0 for some reason. After googling for a while, I did find a few other cases where this seems to be a relatively common problem with the Microsoft keyboards but the device doesn't seem to be doing anything non-standard. Reproducible: Always Steps to Reproduce: 1. Connect a Microsoft-branded keyboard 2. Look at dmesg and /dev/input/ uname -a: Linux andre 2.6.28-gentoo-r5 #8 SMP PREEMPT Tue May 5 21:10:53 EST 2009 x86_64 AMD Phenom(tm) 9850 Quad-Core Processor AuthenticAMD GNU/Linux [Current AMD64 Stable gentoo-sources] Relevant part of dmesg: <snip> usb 4-1: new low speed USB device using ohci_hcd and address 2 usb 4-1: configuration #1 chosen from 1 choice input: Microsoft Wired Keyboard 600 as /devices/pci0000:00/0000:00:13.2/usb4/4-1/4-1:1.0/input/input2 generic-usb 0003:045E:0750.0001: input: USB HID v1.11 Keyboard [Microsoft Wired Keyboard 600] on usb-0000:00:13.2-1/input0 input: Microsoft Wired Keyboard 600 as /devices/pci0000:00/0000:00:13.2/usb4/4-1/4-1:1.1/input/input3 generic-usb 0003:045E:0750.0002: input: USB HID v1.11 Device [Microsoft Wired Keyboard 600] on usb-0000:00:13.2-1/input1 usb 4-1: New USB device found, idVendor=045e, idProduct=0750 usb 4-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0 usb 4-1: Product: Wired Keyboard 600 usb 4-1: Manufacturer: Microsoft <snip> Relevant part of lsusb -v: <snip> Bus 004 Device 002: ID 045e:0750 Microsoft Corp. Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 1.10 bDeviceClass 0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize0 8 idVendor 0x045e Microsoft Corp. idProduct 0x0750 bcdDevice 1.10 iManufacturer 1 Microsoft iProduct 2 Wired Keyboard 600 iSerial 0 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 59 bNumInterfaces 2 bConfigurationValue 1 iConfiguration 0 bmAttributes 0xa0 (Bus Powered) Remote Wakeup MaxPower 100mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 0 bAlternateSetting 0 bNumEndpoints 1 bInterfaceClass 3 Human Interface Device bInterfaceSubClass 1 Boot Interface Subclass bInterfaceProtocol 1 Keyboard iInterface 0 HID Device Descriptor: bLength 9 bDescriptorType 33 bcdHID 1.11 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 Device bInterfaceSubClass 0 No Subclass bInterfaceProtocol 0 None iInterface 0 HID Device Descriptor: bLength 9 bDescriptorType 33 bcdHID 1.11 bCountryCode 0 Not supported bNumDescriptors 1 bDescriptorType 34 Report wDescriptorLength 106 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 0x0008 1x 8 bytes bInterval 10 Device Status: 0x0000 (Bus Powered) <snip> I'm not familiar with the contents of the USB/USBHID specs but I would expect that something with "No Subclass" and an interface protocol of "None" should be ignored. The Kernel has PS/2 Keyboard and mouse still enabled, the HID subsystem and USB OHCI+EHCI but I don't see what difference that should make.
Created attachment 191472 [details, diff] Patch to fix joydev module in kernel After fiddling around with the Kernel sources for a while, I tried to modify the USBHID subsystem (hid-core.c) to ignore devices that have no sub class and protocol which did seem to fix the joystick issue at first but I then discovered that the interface does have an actual purpose - to provide the Multimedia keys on the keyboard (play, volume up/down/mute) so that didn't help as much I'd have liked. The real problem ultimately comes down to the joydev module being a little overenthusiastic about what constitutes a joystick, I added a new blacklist entry that seems to have done the trick (My xpad360 still works at least), patch is attached.
(In reply to comment #1) > Created an attachment (id=191472) [edit] > Patch to fix joydev module in kernel > > After fiddling around with the Kernel sources for a while, I tried to modify > the USBHID subsystem (hid-core.c) to ignore devices that have no sub class and > protocol which did seem to fix the joystick issue at first but I then > discovered that the interface does have an actual purpose - to provide the > Multimedia keys on the keyboard (play, volume up/down/mute) so that didn't help > as much I'd have liked. > > The real problem ultimately comes down to the joydev module being a little > overenthusiastic about what constitutes a joystick, I added a new blacklist > entry that seems to have done the trick (My xpad360 still works at least), > patch is attached. > We don't usually accept user-made patches that were not accepted upstream, so you will have to take this to the linux-input mailing list: http://vger.kernel.org/vger-lists.html#linux-input Thank you!
Yep, please get this accepted upstream... Sounds like a purely cosmetic issue if no problems are actually being caused?
