Just upgraded to a new PC with a motherboard that has an integrated RGB controller. Upon starting VO, the cursor immediately starts going diagonally bottom-left. Moving the mouse creates two ghost instances of the cursor between the actual location and the incessantly moving bottom-left cursor. I discovered later that this is caused by the game detecting the RGB controller as a joystick. I attempted setting all controls to "none" for their binds, this did not change the behavior, nor did a 100%, -100% dead zone. Disabled in config.ini via enabled=0 as a workaround.

https://discord.com/channels/466329329073389568/466329329073389571/1165429018401718303 Image in #general

Strangely enough, after setting the enabled=0 flag under the config.ini entry for the AsRock LED Controller, my Xbox controller is not being detected at all in the joystick list. The left joystick controls ship acceleration but that is all I've noticed.

Permanent workaround for this is to disable the LED controller via udev. Would be a nice addition if the game could filter it out but understandable if not.

Is the LED controller showing up in /dev as a joystick device?

Like this discussion implies that LED controllers are showing up as actual joystick devices.

I wouldn't consider that a "game bug" if the game is legitimately trying to detect joysticks, and some weird device is inappropriately using that device type, and wrongly showing up as a joystick.

But, I do acknowledge that we need to do "something", because the default behaviour of the game can't be "broken" on any linux-gamer PC who has a weird motherboard LED controller.

I imagine there's some kind of linux-kernel discussion about why this was chosen, somewhere (unless it's purely some binary-blob thing), but I haven't looked around to understand why this was done.

Anyway, I'm not exactly sure what we should be doing differently. Like, maybe we should stop trying to detect joysticks on Linux at all, unless someone "forces" it?

It gets pretty annoying if we have to try and hunt around through hwinfo data, which may-or-may-not continue to be available to us as a userspace app, to try and figure out "what joysticks are actual joysticks, and which joysticks are weird hardware interfaces being exposed by someone lazy".

I definitely wouldn't consider it a bug in the sense that the game is doing precisely what it's told to do, look for joysticks in /dev/js. It does show up globally as a joystick.

When you guys run detection, is there a possibility of filtering by vendor ID or detection naming? Only theory I can think of to bypass it.

When you guys run detection, is there a possibility of filtering by vendor ID or detection naming? Only theory I can think of to bypass it.

Well, that's what I was referencing when I said it would become more annoying. The problem is, there's no standard for any of this. We could make some guesses on vendor IDs or names, but inevitably someone is going to show up with some random (but suddenly-popular) Chinese gamepad that happens to have some horrible mangled "name" that then appears like it's one of these LED controllers.

Or, some RGB controller person is going to name their thing differently.

The trouble with being a game developer is you're always pressed for time. So many things that need maintenance, or changes being forced on you by platforms (Android "forced" billing API changes, Linux dropping GTK2, Windows code-signing strangeness, etc).. without even getting into the forward-looking development you want to do..

So, whenever we encounter something like this, we want to fix it robustly, once, so we never have to come back and look at this particular issue again. It's less appealing to "fix" in some hacky way that simply ends up requiring more visits and changes in the future.

Anyway, thanks for the report, we'll take a look.

Ages ago, I had a similar problem to this with Xorg itself using my old laptop's drop-detection accelerometer, which presents itself as a 3-axis joystick, as an absolute pointer device.

The only real way to fix it was like you did with udev rules or configuring xinput/libinput to ignore it.

Sometimes drivers are weird and do stupid things. At least this OS gives us tools to work around them.