Some HID devices make Big Picture unusable #3384

Open
valentindavid opened this Issue Jun 28, 2014 · 38 comments

Projects

None yet
@valentindavid
How to reproduce
  1. Plug one of those devices: Microsoft Wired Keyboard 600 (045e:0750) or A4Tech mouse G7 750 (09da:054f).
  2. Start Big Picture.
  3. Go in a vertical list (like in the options) and go anywhere but the top.
  4. Wait for a second. Then the cursor will by itself go up.

Tried on both release and beta. On a 64 bits Gentoo. Tested with 3.14.9-gentoo and 3.12.13-gentoo kernels.

It is very difficult to do anything because every time you wait for a second, then Steam goes cuckoo.

The likely root of the problem

It seems that some HID devices provide spurious joystick devices. I do not know if this is a bug in the kernel that it shows up as joystick, but at least there is a useless device on the hardware, and this is not a bug from the kernel.

Workarounds

The only two workarounds I have found are:

  • Unplugging both devices when I am in Big Picture. This is extremely annoying since I need to have a hub to be able to access the usb plugs.
  • Filter the spurious input devices in the kernel based on vendor id, product id AND interface number.

Removing device files (both the event and the js one) did not work I am guessing that showing up in sysfs is enough for the problem to happen. Doing some udev tricks is likely not to work.

It could be argued that the Linux kernel should have the correct quirks for those devices. But there might be a lot more of those devices. Steam should be more tolerant to this. Enabling all the controllers found on the machine even if it cannot open the device file is a bad idea in my opinion. For the moment I have not seen any game having problems with this devices, they show up as detected, but they do not use them. Only the Steam Big Picture fails miserably on it.

Here is the ugly work-around for people who happen to have the same bug:

diff -ur linux-3.14.9-gentoo.old/drivers/hid/usbhid/hid-core.c linux-3.14.9-gentoo/drivers/hid/usbhid/hid-core.c
--- linux-3.14.9-gentoo.old/drivers/hid/usbhid/hid-core.c   2014-06-29 00:44:10.830712842 +0200
+++ linux-3.14.9-gentoo/drivers/hid/usbhid/hid-core.c   2014-06-29 00:30:13.043473836 +0200
@@ -1239,6 +1239,20 @@
    dbg_hid("HID probe called for ifnum %d\n",
            intf->altsetting->desc.bInterfaceNumber);

+   if ((dev->descriptor.idVendor == 0x09da)
+       && (dev->descriptor.idProduct == 0x054f)) {
+     if (intf->altsetting->desc.bInterfaceNumber != 1) {
+       return -ENODEV;
+     }
+   }
+
+   if ((dev->descriptor.idVendor == 0x045e)
+       && (dev->descriptor.idProduct == 0x0750)) {
+     if (intf->altsetting->desc.bInterfaceNumber != 0) {
+       return -ENODEV;
+     }
+   }
+
    for (n = 0; n < interface->desc.bNumEndpoints; n++)
        if (usb_endpoint_is_int_in(&interface->endpoint[n].desc))
            has_in++;
@xDShot
xDShot commented Dec 3, 2014

I have the same issue. I have A4Tech Bloody R7 wireless mouse.

@Plaque-fcc

There were troubles when I tried to Start Closure Game with A4Tech USB
HID G10 compound device's USB Dongle plugged in. Guess it's related.

@flo-at
flo-at commented Jan 6, 2015

I have the same issue using 045e:0768 Microsoft Corp. Sidewinder X4.
Sometimes it keeps going left, other times it goes up.
Makes Big Picture Mode unusable while the Keyboard is plugged in.

@aart3k
aart3k commented Apr 19, 2015

Same problem with 045e:0800 Microsoft Corp. (MS All in one media keyboard)

@tjaart
tjaart commented Sep 25, 2015

Also having the same issue. I linked it here. This is the device I have

input: Microsoft Wired Keyboard 600 as /devices/pci0000:00/0000:00:13.0/usb9/9-5/9-5:1.1/0003:045E:0750.0006/input/input20

@ernstp
ernstp commented Oct 14, 2015

Happens with the (wireless) Microsoft All-in-One Media Keyboard also.

@alexhultman

CM Storm Mizar mouse triggers this too.

@alexhultman

Merging bug #3943 with this one.

@alexhultman

Do you know if this is a thing in SteamOS or if they did fix the kernel / underlying issue? Maybe Valve isn't interested in fixing distro specific issues before launch? I have Fedora and you have Gentoo so did anyone test with SteamOS?

@alexhultman

Because like I wrote in my bug report: it's not only Big Picture - it's also some games. For me I cannot play Metro 2033 Redux because my Mizar mouse is making me turn left for ever. So If the issue is also in SteamOS then it is pretty much critical stuff.

@Tele42
Tele42 commented Oct 22, 2015

Personally, I'd be more inclined to believe there is a bug in a common library, maybe libsdl2.

@alexhultman

Yep that could also be an explanation. Are you running libinput?

@nortexoid

It's definitely a bug that is not confined solely to Big Picture mode. E.g., spurious input occurs in FEZ, too. In Kubuntu 14.10 using kernel 3.19, my Microsoft all-in-one media keyboard connected via the nano tranceiver v.20 (that came with the keyboard) also showed up as a joystick (in the Joystick KDE Control Module). But this bug with spurious input never showed up. So some update in the Steam client for linux introduced this bug (which may ultimately be the fault of a kernel bug, but one that didn't affect prior client versions).

@denilsonsa

I am not running Steam Big Picture, so I have not experienced the exact bug described here. However, I have experienced very similar issues with some devices, and they are most likely caused by the same root cause: a bug in the Linux kernel.

I have created a workaround file here: https://gist.github.com/denilsonsa/978f1d842cf5430f57f6

That file contains udev rules that work as a "blacklist", preventing spurious joystick devices from being available. People seem to report success on using those rules.

Again, it is a workaround, the actual solution would be to fix the actual kernel bug. Although those rules are "safe", there is no warranty implied in any form. Use at your own risk.


Related reports on other projects:

@ghallberg

I'm having this issue on Arch Linux, and apart from sending bogus inputs, the /dev/input/js0 device makes my wireless XBOX360 controllers confused, causing them to number from 2 instead of 1, so I can never get a "first" controller. This happens even if I use the above udev rule to prevent inputs from the bogus js0 device.

@alexhultman

This might be my own fault since I provided the rule, but installing the rules by running:

sudo curl -o /etc/udev/rules.d/51-these-are-not-joysticks.rules https://gist.githubusercontent.com/denilsonsa/978f1d842cf5430f57f6/raw

Doesn't solve the problem for me. I used the same formatting as everyone else.

@tjaart
tjaart commented Oct 25, 2015

@denilsonsa I have a version of the udev rules and my keyboard doesn't show up as a joystick any more, however the bug still surfaces in Steam Big Picture. The only way to fix it is to unplug my keyboard.

I'm curious whether the same bug will be present in SteamOS. Maybe Valve will take a bug in SteamOS more seriously.

@denilsonsa denilsonsa referenced this issue in denilsonsa/udev-joystick-blacklist Oct 25, 2015
Closed

ENV{ID_INPUT_JOYSTICK}=="1" does not correctly match all devices #2

@alexhultman

How do you see if it shows up as a joystick? I agree we should test SteamOS. That would be an absolute blocker bug if some common devices won't work out of the box.

@denilsonsa

@ghallberg, @alexhultman, @tjaart, and anyone else who used the workaround posted above: I've moved those udev rules to a full GitHub repository. I've also fixed an important issue, so it is worth trying again with the latest version. It is now located at: https://github.com/denilsonsa/udev-joystick-blacklist

Issues with those rules should be discussed in that repository, not here. However, if those rules help solving the issue listed here, I believe it is on-topic to mention it here.

@ghallberg

I've tried this again and it seems to work this time. thanks @denilsonsa

@alexhultman

I have a feeling this is libinput bugs? Are you using libinput?

http://www.freedesktop.org/wiki/Software/libinput/

@denilsonsa

@alexhultman, nope, it is not. It is a bug in the Linux kernel itself because it creates joystick devices in /dev/input/ for devices that are not joysticks. Look at the links I have provided. This bug can also be seen in jstest-gtk, which accesses /dev/input/js* devices directly, without any library. When using USB devices, run udevadm monitor -p to see the kernel and udev events (and to see the joystick devices being created).

@alexhultman

Kk. I haven't figured libinput out lol

@alexhultman

With the latest rules Big Picture works for me.

Edit: Metro 2033 Redux also works now.

@cforain
cforain commented Oct 30, 2015

I can confirm this. I'm running Gentoo with kernel 4.0.5 and Microsoft Keyboard and mouse with usb receiver:

Bus 005 Device 005: ID 045e:0745 Microsoft Corp. Nano Transceiver v1.0 for Bluetooth

As @denilsonsa pointed out, it does generate a node on /dev/input/js0, but even if I cat it, no input is generated there, only in /dev/input/event2 (keyboard) and /dev/input/mouse0 (mouse), so I don't believe that's the reason Steam in big picture goes all left and/or up. Further, this bugs is extended to (some?) games, as in Dust Elysian Tale I cannot navigate through the menus, as it goes indefinetly up and/or left, even if I launched it from standard steam mode (not big picture).

It's also worth mentioning that the mouse and keyboard work flawlessly whatsoever besides Steam. I also installed jstest-gtk just to further confirm that there are no "ghost" inputs on js0, which was confirmed.

I hope for a solution.

@slin31
slin31 commented Nov 11, 2015

I can also confirm this happening with
045e:0745 Microsoft Corp. Nano Transceiver v1.0 for Bluetooth

I get a constant scrolling in Big Picture and if I'm unlucky this will cause Steam to freeze or crash.
The issue starts as soon as I plug the Microsoft USB dongle in.
I get no interference in normal desktop mode.

Running 4.2.5-1 Arch

@cforain
cforain commented Nov 11, 2015

@slin31 , check this:

https://github.com/denilsonsa/udev-joystick-blacklist

It solved for me. If you don't want to have all those rules, you can use lsusb to see the id of your adapter and have only that one. Thats what I did.

@slin31
slin31 commented Nov 12, 2015

@cforain , thank you!
One simple udev rule and no more strange scrolling issues.

@scaronni scaronni added a commit to scaronni/shield-controller-config that referenced this issue Feb 1, 2016
@scaronni scaronni Make sure the controller is not seen as a mouse and is accessible.
When an input device is seen as a mouse or keyboard and at the same time is
seen as a joystick, the input gets weird in most programs trying to access the
joystick part (ghost touches, etc.).

It is actually the opposite of this:
- ValveSoftware/steam-for-linux#3384
- https://github.com/denilsonsa/udev-joystick-blacklist

Make sure the mouse part is disabled when plugging the controller in the system
and make sure it is accessible for games like in the Steam Controller rules.

With this patch, the controller works fine in Steam.
49025d8
@hitokirihahn

i have this big picture problem always goes to left, when i use the rules you made, my keyboard not working, my keyboard is detected but i cant type none of its button works, my keyboard is A4tech G800V, OS Linux Manjaro

@denilsonsa

@hitokirihahn, by googling that model, it seems to have 09da:90c0 vendor:model ids. However, such model is not listed in the udev-joystick-blacklist repository.

You should give us more details regarding your problem. What exactly are the vendor/model ids of your device? (Use lsusb.) What have you done? Have you written the rule by yourself? Also, I don't have such keyboard and I cannot have all the models, so I cannot test for every hardware. Finally, depending on what you have tried, maybe you should open an issue at udev-joystick-blacklist instead of commenting on this one.

@jcharaoui

I have the same keyboard as the OP (045e:0750). Please consider udev-joystick-blacklist as nothing more than a workaround, because it makes the keyboard's multimedia keys unusable.

@vially
vially commented Mar 15, 2016

@jcharaoui If you only unset the ID_INPUT_JOYSTICK env var from the /dev/input/event* device and keep the device active (instead of removing or disabling it) the big picture issues will get fixed while the multimedia keys will still work.

For my particular keyboard this means changing these two lines:

SUBSYSTEM=="input", ATTRS{idVendor}=="045e", ATTRS{idProduct}=="0745", ENV{ID_INPUT_JOYSTICK}=="?*", RUN+="/bin/rm %E{DEVNAME}", ENV{ID_INPUT_JOYSTICK}=""
SUBSYSTEM=="input", ATTRS{idVendor}=="045e", ATTRS{idProduct}=="0745", KERNEL=="js[0-9]*", RUN+="/bin/rm %E{DEVNAME}", ENV{ID_INPUT_JOYSTICK}=""

Into these:

SUBSYSTEM=="input", ATTRS{idVendor}=="045e", ATTRS{idProduct}=="0745", ENV{ID_INPUT_JOYSTICK}=="?*", ENV{ID_INPUT_JOYSTICK}=""
SUBSYSTEM=="input", ATTRS{idVendor}=="045e", ATTRS{idProduct}=="0745", KERNEL=="js[0-9]*", RUN+="/bin/rm %E{DEVNAME}", ENV{ID_INPUT_JOYSTICK}=""

Note: Only the first line requires changes so the second line is kept unchanged.

Edit: I've only tested it on my keyboard but if someones else finds this fix useful for other keyboard models maybe it would be a good idea for someone to create a pull request for udev-joystick-blacklist with these changes.

@hitokirihahn

@denilsonsa the vendor:model is excatly as you mentioned. Here is the details of what happened, at first my keyboard detected but not working after fresh installation of Manjaro, if id o lsusb i can see my keyboard with vendor:model 09da:90c0, i cant type but when i add your rules, my keyboard is working but alaways goes left if i start steam with big picture, then i took the initiative to manually insert rules for my keyboard
SUBSYSTEM=="input", ATTRS{idVendor}=="09da", ATTRS{idProduct}=="90c0", ENV{ID_INPUT_JOYSTICK}=="?*", ENV{ID_INPUT_JOYSTICK}="" SUBSYSTEM=="input", ATTRS{idVendor}=="09da", ATTRS{idProduct}=="90c0", KERNEL=="js[0-9]*", RUN+="/bin/rm %E{DEVNAME}", ENV{ID_INPUT_JOYSTICK}=""
and i came back to the start where my keyboard detected but not functioning, so i delete the rules for my keyboard and it works again, i'm really confused.

Thank you for your reply sir @denilsonsa

@Kengur8
Kengur8 commented Apr 16, 2016

You need to find out the offending device first. For example I got V8 Bloody. When I check (after installing joystick-support) that there's a bogus /dev/input/js0 (with 37 axis lel) I did this

udevadm info --query=property --name=/dev/input/js0

created additional /etc/udev/rules.d/ like this

SUBSYSTEM=="input", ATTRS{idVendor}=="09da", ATTRS{idProduct}=="3f8b", ENV{ID_INPUT_JOYSTICK}=="?", RUN+="/bin/rm %E{DEVNAME}", ENV{ID_INPUT_JOYSTICK}=""
SUBSYSTEM=="input", ATTRS{idVendor}=="09da", ATTRS{idProduct}=="3f8b", KERNEL=="js[0-9]
", RUN+="/bin/rm %E{DEVNAME}", ENV{ID_INPUT_JOYSTICK}=""

Reattach mouse. This solved the phantom input problem.

@Ruedii
Ruedii commented Apr 16, 2016

There are utilities to set the kernel joystick calibrations and mappings. You an either unmap the problem axis or remove the devices altogether. you can also change the ordering of the devices so the spurious devices are labeled as a high numbered joystick such as js7 instead of js0, and thus will be ignored by most software.

You can use those to filter the device.

Valve needs to add a feature to interface with these.

Honestly, I think a kernel interface needs to be added to bridge between rjs (raw joystick) and vjs (virtual mapped Joystick) devices. This would solve all these problems, since the standard config utilities would identify virtual mappings by DeviceID, you could simply turn off those mappings, or move them to something other than the primary joystick.

@jcharaoui

@vially I tested your suggestion with my keyboard. The multimedia keys are functional again, but the input problem in Big Picture mode returned.

@scaronni

Red Hat has provided a patch for Wacom and Microsoft input devices. At least in my case the issue with the ghost inputs in Big Picture is solved with the patched kernel:

https://bugzilla.redhat.com/show_bug.cgi?id=1325354#c8

I will remove the extra UDev rules from the Fedora 25 build of Steam.

@0day-ci 0day-ci pushed a commit to 0day-ci/linux that referenced this issue Sep 13, 2016
@fengguang Benjamin Tissoires + fengguang HID: input: ignore System Control application usages if not System Co…
…ntrols

Microsoft is reusing its report descriptor again and again, and part of it
looks like this:

0x05, 0x01,                    // Usage Page (Generic Desktop)        299
0x09, 0x80,                    // Usage (System Control)              301
0xa1, 0x01,                    // Collection (Application)            303
0x85, 0x03,                    //  Report ID (3)                      305
0x19, 0x00,                    //  Usage Minimum (0)                  307
0x29, 0xff,                    //  Usage Maximum (255)                309
0x15, 0x00,                    //  Logical Minimum (0)                311
0x26, 0xff, 0x00,              //  Logical Maximum (255)              313
0x81, 0x00,                    //  Input (Data,Arr,Abs)               316
0xc0,                          // End Collection                      318

While there is nothing wrong in term of processing, we do however blindly
map the full usage range (it's an array) from 0x00 to 0xff, which creates
some interesting axis, like ABS_X|Y, and a bunch of ABS_MISC + n.

While libinput and other stacks don't care that much (we can detect them),
joydev is very happy and attaches itself to the mouse or keyboard.

The problem is that joydev now handles the device as a joystick, but given
that we have a HID array, it sets all the ABS_* values to 0. And in its
world, 0 means -32767 (minimum value), which sends spurious events to games
(think Steam).

It looks like hid-microsoft tries to tackle the very same problem with its
.report_fixup callback. But fixing the report descriptor is an endless task
and is quite obfuscated.

So take the hammer, and decide that if the application is meant to be
System Control, any other usage not in the System Control range should
be ignored.

Link: https://bugzilla.redhat.com/show_bug.cgi?id=1325354
Link: https://bugzilla.kernel.org/show_bug.cgi?id=28912
Link: ValveSoftware/steam-for-linux#3384
Link: https://bugzilla.redhat.com/show_bug.cgi?id=1325354
Link: https://bugzilla.kernel.org/show_bug.cgi?id=37982

Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
8dd8d3a
@sudipm-mukherjee sudipm-mukherjee pushed a commit to sudipm-mukherjee/parport that referenced this issue Sep 20, 2016
Benjamin Tissoires + Jiri Kosina HID: input: ignore System Control application usages if not System Co…
…ntrols

Microsoft is reusing its report descriptor again and again, and part of it
looks like this:

0x05, 0x01,                    // Usage Page (Generic Desktop)        299
0x09, 0x80,                    // Usage (System Control)              301
0xa1, 0x01,                    // Collection (Application)            303
0x85, 0x03,                    //  Report ID (3)                      305
0x19, 0x00,                    //  Usage Minimum (0)                  307
0x29, 0xff,                    //  Usage Maximum (255)                309
0x15, 0x00,                    //  Logical Minimum (0)                311
0x26, 0xff, 0x00,              //  Logical Maximum (255)              313
0x81, 0x00,                    //  Input (Data,Arr,Abs)               316
0xc0,                          // End Collection                      318

While there is nothing wrong in term of processing, we do however blindly
map the full usage range (it's an array) from 0x00 to 0xff, which creates
some interesting axis, like ABS_X|Y, and a bunch of ABS_MISC + n.

While libinput and other stacks don't care that much (we can detect them),
joydev is very happy and attaches itself to the mouse or keyboard.

The problem is that joydev now handles the device as a joystick, but given
that we have a HID array, it sets all the ABS_* values to 0. And in its
world, 0 means -32767 (minimum value), which sends spurious events to games
(think Steam).

It looks like hid-microsoft tries to tackle the very same problem with its
.report_fixup callback. But fixing the report descriptor is an endless task
and is quite obfuscated.

So take the hammer, and decide that if the application is meant to be
System Control, any other usage not in the System Control range should
be ignored.

Link: https://bugzilla.redhat.com/show_bug.cgi?id=1325354
Link: https://bugzilla.kernel.org/show_bug.cgi?id=28912
Link: ValveSoftware/steam-for-linux#3384
Link: https://bugzilla.redhat.com/show_bug.cgi?id=1325354
Link: https://bugzilla.kernel.org/show_bug.cgi?id=37982

Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
1989dad
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment