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.

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.

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 Thank you!

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

@nightsky30 Why the close on the pull request?

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

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

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

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

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.

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

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

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.

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 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}=""

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

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

Actually I think this can be closed.