Mouse detected as controller causing many games to crash on startup

[viggy96]

Your system information

• Steam client version (build number or date): 16 Apr 2019
• Distribution (e.g. Ubuntu): Ubuntu 18.04.2 LTS, kernel 5.0.10
• Opted into Steam client beta?: Yes
• Have you checked for system updates?: Yes

Please describe your issue in as much detail as possible:

The Steam client detects the Corsair M65 Pro RGB gaming mouse as a joystick/gamepad device, causing a variety of games to fail.

Steps for reproducing this issue:

1. Plug in Corsair gaming mouse
2. Start game (like Project Cars 2, or even native games like Dirt Rally)
3. Game will fail to start. Proton games will show segfault on libSDL2

@kisak-valve My Corsair mouse is being recognised by Steam as some sort of controller, you can see in the terminal output:

Local Device Found
  type: 1b1c 1b2e
  path: sdl://1
  serial_number:  - 0
  Manufacturer: 
  Product:      ckb1: Corsair Gaming M65 Pro RGB Mouse vKB
  Release:      306
  Interface:    -1

Local Device Found
  type: 1b1c 1b2e
  path: sdl://2
  serial_number:  - 0
  Manufacturer: 
  Product:      ckb1: Corsair Gaming M65 Pro RGB Mouse vM
  Release:      306
  Interface:    -1

When I don't have my Corsair gaming mouse plugged in, and just use a regular mouse, this game runs fine. It appears that we may need to blacklist some devices from being detected as "controllers" and being passed to the game as such. I suspect that this issue causes games that utilise controllers to fail to start. I have confirmed, as previously mentioned that games run just fine when the gaming mouse is disconnected, and instead a regular mouse is used, including both Proton titles, and native titles.

I have mentioned this on ValveSoftware/Proton#908. I have previously noted that other games like Lego Harry Potter (1 and 2), Ni no Kuni 2, also exhibit this issue. I suspect this affects many other titles as well, though I haven't taken the time to test every single title in my library to confirm this.

[ghost]

Personally, I'm confused by the definition of mouse being applied here. A gaming mouse is still a normal mouse - they're all mice. My $150 gaming mouse works fine by comparison https://www.logitechg.com/en-us/products/gaming-mice/pro-wireless-mouse.html so by all means your cheap one should as well.

I don't know if this is a system problem or a Steam one based on the above info.

[ghost]

Product: _**ckb1:**_ Corsair Gaming M65 Pro RGB Mouse vM

I'm wondering is ckb1 in reference to https://github.com/ccMSC/ckb ?

If so, I would say that's your problem, not Steam.

[nightsky30]

Seems the same issue some are referencing here, here, and here. One of them even using a Corsair keyboard!

@viggy96 Some claim using the -nojoy option fixes the issue for them while others say it does not help. Maybe try it?

@kisak-valve Is the -nojoy option available in all games through Steam or just available in CSGO?

[kisak-valve]

-nojoy is a Goldsource/Source engine option.

In general, these devices the extra joystick interface should get added to a blacklist and distributed in distro packaging because it's outside the scope of Steam.

[nightsky30]

@kisak-valve Thank you!

Edit: I've resubmitted a pull request for blacklisting the two Corsair devices.

[viggy96]

@nightsky30 Why the close on the pull request?

[nightsky30]

Sorry, I realized there were more files to edit. 🙄 I've submitted a new pull request here.

[viggy96]

@nightsky30 I have tried your branch and it didn't work. I tried both the permissions and rm versions... 😢

[nightsky30]

I just added the device IDs in all files using the copied lines from the initial Corsair device that was listed. Thought that would suffice. Maybe there is something different in the 5.0.x kernel that has changed things? Not sure what the after_kernel_4_9 stuff is about. I'm assuming you tried those files.

Ahh...

What's different in after_kernel_4_9/?
A patch has been accepted into Linux kernel 4.9, so that Microsoft devices will not be detected as joysticks anymore. Thus, those devices are not included in after_kernel_4_9/*. Read issue #20 for details.

So any of those should have worked 😞

[nightsky30]

I did some digging and found this. Seems they are matching devices in their udev rules differently with the use of the ckb daemon.

ACTION=="add|change", SUBSYSTEM=="input", ATTRS{name}=="ckb[0-9]: [A-Za-z0-9]*", ENV{ID_INPUT_JOYSTICK}=""

VS

SUBSYSTEM=="input", ATTRS{idVendor}=="1b1c", ATTRS{idProduct}=="1b2e", ENV{ID_INPUT_JOYSTICK}=="?*", ENV{ID_INPUT_JOYSTICK}=""
SUBSYSTEM=="input", ATTRS{idVendor}=="1b1c", ATTRS{idProduct}=="1b2e", KERNEL=="js[0-9]*", MODE="0000", ENV{ID_INPUT_JOYSTICK}=""

I don't use ckb daemon as I use Razer devs and openrazer's daemon. Does the ckb daemon add its own udev rules files? If so, what order are the files processed? Alphanumerically I would guess? Perhaps they get in each other's way. Or maybe try modifying the udev joystick blacklist rules' regex to match your devices better as named by the daemon?

ATTRS{name}=="ckb[0-9]: [A-Za-z0-9]*"

After all, your product showed as:

Product: ckb1: Corsair Gaming M65 Pro RGB Mouse vKB
Product: ckb1: Corsair Gaming M65 Pro RGB Mouse vM

[viggy96]

Yeah, I've tried that udev rule now, and it doesn't work either. I've reported this on ckb-next as well here: ckb-next/ckb-next#410.

[viggy96]

@nightsky30 Removing the device via udev rules works, but then the mouse is unusable. But setting the mode to "0000" doesn't work either, as steam still picks up the mouse as a controller as before.

[ghost]

@nightsky30 Removing the device via udev rules works, but then the mouse is unusable. But setting the mode to "0000" doesn't work either, as steam still picks up the mouse as a controller as before.

Your mouse should work without the need for that to even be installed. You may loose functionality if not stored into mouse hardware memory but the pointer, left & right, middle click should all work at the very least. I have yet to see a mouse that didn't.

Similar to what they said on your opened bug post, they are another area where problems surface, and now you're reaping the effects of that.

Also if it is partially caused by libinput that means it was borked for an entire year and not long after their "fix". Stuff happens though so maybe you want to keep living with the extra borking.

[tatokis]

Your mouse should work without the need for that to even be installed. You may loose functionality if not stored into mouse hardware memory but the pointer, left & right, middle click should all work at the very least. I have yet to see a mouse that didn't.

I should point out that the M65 has an hid descriptor that shows up as a joystick without ckb-next, so you need a udev rule anyway.

As a sidenote, this issue does not occur with evdev.

As far as uinput is concerned, I don't think there is a way to mark a device as a mouse or as a keyboard only.

[nightsky30]

Also the owner and curator of udev-joystick-blacklist seems to indicate it is a kernel bug.

Ideally, the bug in the Linux kernel should be fixed, so that this repository (which is essentially just a workaround) wouldn't be needed anymore.

If that is the case, then is it really an issue with any of the above mentioned libraries/frameworks/daemons/applications? Perhaps they are also victims.

Edit: The linked kernel bug.

[nightsky30]

@nightsky30 Removing the device via udev rules works, but then the mouse is unusable. But setting the mode to "0000" doesn't work either, as steam still picks up the mouse as a controller as before.

If the removal rule does what it is supposed to do and removes the device it matches with regex, then the other rule type which sets permissions as "0000" should be working as well. As I tried to explain before (maybe not very well), and @tatokis has mentioned in the linked ckb thread, if you have multiple udev rules they can get in each others' ways. One rules file can undo what the prior rules file applied.

• If the udev-joystick-blacklist rule removes the device, and then the ckb udev rules file is applied afterwards this would cause no effect as the device was completely removed. The second ckb udev rule set has nothing to act upon.

• If the udev-joystick-blacklist rule sets permissions to "0000" and then the ckb udev rules file is applied afterwards this could be causing the device to still be seen as a joystick. And this makes sense as you mention the removal of ckb while using the udev-joystick-blacklist rules fixes your issue.

I believe the files are applied in alphanumeric order. So, the files beginning with 51 would be applied before the file starting with 99...

udev/51-these-are-not-joysticks-rm.rules
or...
udev/51-these-are-not-joysticks.rules
then...
udev/99-ckb-daemon.rules

If you want ckb then try modifying the ckb udev rules and don't use the other udev files. Maybe add MODE="0000" to the ckb rules, i.e.

ACTION=="add|change", SUBSYSTEM=="input", ATTRS{name}=="ckb[0-9]: [A-Za-z0-9]*", MODE="0000", ENV{ID_INPUT_JOYSTICK}=""

[viggy96]

@tatokis My Corsair Mouse does not appear as a joystick under '/dev/input', and it does not appear in jstest-gtk.

[viggy96]

@tatokis I've fixed the issue by moving the rule that ckb-next installs from its default install location '/usr/lib/udev/rules.d' to '/etc/udev/rules.d'.

[kisak-valve]

Hello @viggy96, is there any particular reason to continue tracking this issue here? It's fairly clear this is either a udev or kernel issue instead of a Steam client issue.

[viggy96]

Actually I think this can be closed.