Some HID devices make Big Picture unusable

[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]

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

[xDShot]

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.

[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]

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.

[flo-at]

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]

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

[aart3k]

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

[tjaart]

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

[tjaart]

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

[tjaart]

Relevant Kernel bug:

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

[tjaart]

Relevant Kernel bug:

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

[ernstp]

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

[ernstp]

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

[alexhultman]

CM Storm Mizar mouse triggers this too.

[alexhultman]

CM Storm Mizar mouse triggers this too.

[alexhultman]

Merging bug #3943 with this one.

[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]

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.

[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]

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

[Tele42]

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?

[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).

[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:

• https://bugzilla.kernel.org/show_bug.cgi?id=28912
• https://bugzilla.kernel.org/show_bug.cgi?id=37982
• https://bugs.launchpad.net/ubuntu/+source/linux/+bug/390959
• https://askubuntu.com/questions/173376/how-do-i-disable-joystick-input
• https://ryort.wordpress.com/2011/12/04/udev-and-the-microsoft-digital-media-keyboard-3000-wha/
• https://forum.manjaro.org/index.php?topic=15275.msg144519#msg144519
• https://bbs.archlinux.org/viewtopic.php?id=190485
• https://bbs.archlinux.org/viewtopic.php?id=142469
• https://forums.gentoo.org/viewtopic-t-362032.html
• https://bugs.winehq.org/show_bug.cgi?id=35954

[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:

• https://bugzilla.kernel.org/show_bug.cgi?id=28912
• https://bugzilla.kernel.org/show_bug.cgi?id=37982
• https://bugs.launchpad.net/ubuntu/+source/linux/+bug/390959
• https://askubuntu.com/questions/173376/how-do-i-disable-joystick-input
• https://ryort.wordpress.com/2011/12/04/udev-and-the-microsoft-digital-media-keyboard-3000-wha/
• https://forum.manjaro.org/index.php?topic=15275.msg144519#msg144519
• https://bbs.archlinux.org/viewtopic.php?id=190485
• https://bbs.archlinux.org/viewtopic.php?id=142469
• https://forums.gentoo.org/viewtopic-t-362032.html
• https://bugs.winehq.org/show_bug.cgi?id=35954

[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.

[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.

[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]

@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.

[tjaart]

@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.

[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.

[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.

[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

[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/

[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).

[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]

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.

[alexhultman]

With the latest rules Big Picture works for me.

Edit: Metro 2033 Redux also works now.

[cforain]

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.

[cforain]

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]

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

[slin31]

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]

@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]

@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]

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

[slin31]

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

[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

[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.

[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.

[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]

@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.

[vially]

@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

[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]

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.

[Kengur8]

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]

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.

[Ruedii]

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.

[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.

[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.