Bug 37982

Created attachment 62952 [details]
rdesc output of the first entry

Created attachment 62962 [details]
rdesc output of the second entry

Comment on attachment 62962 [details]
rdesc output of the second entry

Oups this got altered while I trying to understand how hid worked

Created attachment 62972 [details]
rdesc output of the second entry

This is still happening with Kernel 3.7.8 and udev-197 in a Gentoo Linux. If you have access to joystick tools you can calibrate this /dev/input/js0 with jscal -c /dev/input/js0, and at least it won't interfere with the programs, also plug first your gamepad so /dev/input/js0 get's assigned to it first.

It's a very annoying bug if you want to use wine or other programs.

Any ideas on how to fix it?.

Also other keyboard and mouse devices from microsoft suffer the same problem like can be seen on the following links:

https://bugs.launchpad.net/ubuntu/+source/linux/+bug/987622
https://bbs.archlinux.org/viewtopic.php?id=142469
http://ryort.wordpress.com/2011/12/04/udev-and-the-microsoft-digital-media-keyboard-3000-wha/
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/390959

lsusb -v:

Bus 002 Device 005: ID 045e:0750 Microsoft Corp. Wired Keyboard 600
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 Wired Keyboard 600
  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)

Seems to be a problem in the hid parser, that default some inputs to a joystick if it miss interpret some of the values (for some good or wrong reasons). But last time I check was when I created the bug report.

If this is still present in modern kernels please update the bug

Still valid as of kernel-3.10

Seems to still be valid as of 3.18.2

And still in 3.19.2

Relevant: https://bugzilla.kernel.org/show_bug.cgi?id=28912

Relevant (2009): https://bugs.launchpad.net/ubuntu/+source/linux/+bug/390959

Can I get output of /proc/bus/input/devices for that mouse please?

For my keybord it exposes the following (kernel 3.14.x but I guess it 
doesn't mater):

I: Bus=0003 Vendor=045e Product=0750 Version=0111
N: Name="Microsoft Wired Keyboard 600"
P: Phys=usb-0000:00:1d.0-1.6/input0
S: 
Sysfs=/devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.6/2-1.6:1.0/0003:045E:0750.0003/input/input20
U: Uniq=
H: Handlers=kbd event17
B: PROP=0
B: EV=120013
B: KEY=1000000000007 ff9f207ac14057ff febeffdfffefffff fffffffffffffffe
B: MSC=10
B: LED=7

I: Bus=0003 Vendor=045e Product=0750 Version=0111
N: Name="Microsoft Wired Keyboard 600"
P: Phys=usb-0000:00:1d.0-1.6/input1
S: 
Sysfs=/devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.6/2-1.6:1.1/0003:045E:0750.0004/input/input21
U: Uniq=
H: Handlers=kbd event18 js0
B: PROP=0
B: EV=10001f
B: KEY=4c37fff072ff32d bf54445600000000 c00000000000001 30f908b17c007 
ffff7bfad951dfff febeffdfffefffff fffffffffffffffe
B: REL=40
B: ABS=ffffff01000701ff
B: MSC=10

 From my understanding it was due to a default behaviour of the 
descriptor parser. It is falling back to a dummy joystik input in case 
of error, and the keyboard device descriptor has a constructor private 
interface, for the multimedia keys, that was wrongly parsed leading to 
the creation of the dummy joystick device.

Has there been any progress on this Dmitry?

This issue still occurs on 4.6 series.

Any advise on where to starting look to fix this issue?

I think there was an udev rule that banned the device creation on some 
distribution for these kind of devices. So it maybe be the wiser 
temporary solution, without touching the kernel code.

Yes, there is udev rules.

Since I have one of the keyboards that causes the issue.  I thought I might have a go at fixing it but would like some advise on a good place to start.

Ahh, ok I thought you meant a quick fix.
I looked at the code again, and I don't seems to find the place I was 
thinking was causing the issue.
 From my memory, the place I had find was a bug in the hid descriptor 
parser, that was miss interpreting some vendor private range field, 
making the device mutate to a joystick. So if I remember well, it was in 
interaction between drivers/hid/hid-{core,input}.c and 
drivers/input/input.c.

Created attachment 221851 [details]
First attempt to patch the issue and uniformise fixes.

The attached patch tries to uniformise the patching of microsoft keyboard.
I add Microsoft media 600 (that I own) and 7k (that Alistair Leslie-Hughes owns) that were tested with the patch.
The only small deviation I made from original code is that Microsoft Wireless Receiver Model 1028 check is now stronger (I was not able to test it or find a copy of the report descriptor to ensure it is correct)

Created attachment 222351 [details]
Patch V2, add Microsoft Digital Media 3KV1 workaround.

Created attachment 233381 [details]
Proposed upstream patch

This is the patch I sent upstream which should solve all Microsoft devices.

Reference: https://patchwork.kernel.org/patch/9328671/

I took the time to update my kernel with the patch, and so far everything is good. I successfully tried various multimedia keys (using hid-microsoft since my keybord was not work-arounded). And /dev/input/js0 is gone.

So the new patch seems good for me and should be good for almost all Microsoft Digital Media Keyboard series (since they seems to share the same report descriptors).

Will see with a bit longer testing but ok for me.

Fixed a while ago. Forgot it was still open.