-
Notifications
You must be signed in to change notification settings - Fork 173
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Some HID devices make Big Picture unusable #3384
Comments
I have the same issue. I have A4Tech Bloody R7 wireless mouse. |
There were troubles when I tried to Start Closure Game with A4Tech USB |
I have the same issue using 045e:0768 Microsoft Corp. Sidewinder X4. |
Same problem with 045e:0800 Microsoft Corp. (MS All in one media keyboard) |
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 |
Relevant Kernel bug: |
Happens with the (wireless) Microsoft All-in-One Media Keyboard also. |
CM Storm Mizar mouse triggers this too. |
Merging bug #3943 with this one. |
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? |
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. |
Personally, I'd be more inclined to believe there is a bug in a common library, maybe libsdl2. |
Yep that could also be an explanation. Are you running libinput? |
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). |
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:
|
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. |
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. |
@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. |
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. |
@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. |
I've tried this again and it seems to work this time. thanks @denilsonsa |
I have a feeling this is libinput bugs? Are you using libinput? |
@alexhultman, nope, it is not. It is a bug in the Linux kernel itself because it creates joystick devices in |
Kk. I haven't figured libinput out lol |
With the latest rules Big Picture works for me. Edit: Metro 2033 Redux also works now. |
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. |
I can also confirm this happening with I get a constant scrolling in Big Picture and if I'm unlucky this will cause Steam to freeze or crash. Running 4.2.5-1 Arch |
@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. |
@cforain , thank you! |
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.
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 |
@hitokirihahn, by googling that model, it seems to have You should give us more details regarding your problem. What exactly are the vendor/model ids of your device? (Use |
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. |
@jcharaoui If you only unset the For my particular keyboard this means changing these two lines:
Into these:
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. |
@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 Thank you for your reply sir @denilsonsa |
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}="" Reattach mouse. This solved the phantom input problem. |
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. |
@vially I tested your suggestion with my keyboard. The multimedia keys are functional again, but the input problem in Big Picture mode returned. |
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. |
…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>
…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>
…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>
How to reproduce
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:
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:
The text was updated successfully, but these errors were encountered: