Joystick regression since SDL 2.0.16, Windows 11

[KingOfIce77]

Some time after SDL 2.0.16, some game devices disappeared (pedals and 2 of my 3 button boxes).

Here are the results for the pygame code :

pygame.joystick.init()
ljoysticks = [pygame.joystick.Joystick(x) for x in range(pygame.joystick.get_count())]
print([j.get_name() for j in ljoysticks])

SDL 2.0.16 with pygame 2.4.0 result :

• ['FANATEC Podium Wheel Base DD2', 'DSD CSW Panel', 'DSD CSW Panel', 'FANATEC ClubSport Pedals V3', 'DSD uBox Type One', 'FANATEC Podium Wheel Base DD2']

SDL 2.28.0 with pygame 2.5.1 result :

• ['FANATEC Podium Wheel Base DD2', 'FANATEC Podium Wheel Base DD2']

pygame issue here : [https://github.com/pygame/pygame/issues/3942]

[Starbuck5]

Pygame on Windows 2.4.0 uses SDL 2.26.4, pygame 2.5.1 uses SDL 2.28.2, and pygame 2.5.0 uses SDL 2.28.0. Tested by installing those versions and checking the support prompt.

So as far as I can tell this issue should read joystick regression between 2.26.4 and 2.28.0.

[Starbuck5]

Looks like it could be this commit on SDL's end: d42c303

[IOBYTE]

This commit d42c303 also breaks my pedals on Windows 10 and linux because they have axes but no buttons. Button boxes will also break because they have buttons but no axes. The right way to fix the problem this commit is trying to fix is to add the problem device to the black list. This commit should be reverted.

[IOBYTE]

Linux is broken for my pedals but that must be a different problem.

[IOBYTE]

The linux problem is similar. SDL_EVDEV_GuessDeviceClass assumes a joystick with 3 axes but no buttons is an accelerometer. My pedals have 3 axes and no buttons so it's ignored.

[TheFloatingWidget]

Also seeing this problem with 2.28.3, don't think we had it when using 2.24.1 (which easily pre-dates the suspicious commit you've called out). Is it worth putting up a merge request that reverts that commit?

[slouken]

@smcv, thoughts?

[IOBYTE]

I think d42c303 should be reverted. There is code elsewhere that already solves the same problem.

The linux problem is more complicated. One way would be to add a PEDALS joystick type and add a whitelist for known devices or add a blacklist for known accelerometers. Both are maintenance nightmares keeping the lists up to date.

[TheFloatingWidget]

I've rolled back to v2.26.5 and all controllers are working again (Windows test environment).

[smcv]

The linux problem is more complicated. One way would be to add a PEDALS joystick type and add a whitelist for known devices or add a blacklist for known accelerometers. Both are maintenance nightmares keeping the lists up to date.

Right, there's really no good answer to this: evdev doesn't tell us what a device is, only what capabilities it has, but evdev capabilities are not enough to distinguish between a 3-axis accelerometer and 3-axis pedals because both are simply reported as (X, Y, Z).

I think the best long term answer would be for the kernel (which has better information) to report what a device is. There is already a way for it to report that a device is definitely an accelerometer, by setting INPUT_PROP_ACCELEROMETER, but there is currently no way for it to report that a device is definitely a joystick; and even if there was, SDL would need to do something (a heuristic involving axes, buttons, and a denylist or allowlist) for ambiguous devices that have neither property.

[smcv]

This commit d42c303 also breaks my pedals on Windows 10 and linux

That commit should only affect Windows, and Windows games running on Linux via a compatibility layer like Wine/Proton. It should have no effect on native Linux versions of SDL. Is that what you mean?

[IOBYTE]

Yes. There are 2 separate bugs. One is in Windows and one is in linux specific code. They both make assumptions for the joystick type using the number of buttons and axes that are wrong. The result is the same for windows and linux. The same problem probably exists in other interface code. Extending the existing platform independent whitelist/blacklist code to handle this problem is probably the correct way to fix this. Adding the ability for the application to add to the device lists would help work around bugs like this for unknown hardware.

[IOBYTE]

I reverted d42c303 locally and my pedals were recognized and worked on Windows 10.

[slouken]

Reverted, thanks!

[IOBYTE]

I managed to get my pedals working on linux by adding a udev rule that set the permissions properly and changed the device type from ACCELEROMETER to JOYSTICK.

[KingOfIce77]

Why reopen and reapply the bug?

[slouken]

Because this fix caused a bunch of other bugs. As noted in the commit, we need to find a better way to distinguish between gaming mice and pedals.

[KingOfIce77]

Ah ok... I guess it's a matter of point of view because for me everything worked perfectly before this modification (and I have a lot of "game components" as simracer)

[slouken]

Yep, I have the Pugio mouse ordered, so I'll see if there's a better fix. If nothing else then we can create a list of game components and explicitly allow them (which would work for Linux as well)

[KingOfIce77]

mouse is a game component !?

[IOBYTE]

You need to add the devices to ignore to SDL_ShouldIgnoreJoystick. Hard coded lists are not future proof but that's a whole other issue. You could add more hard coded lists for pedals and button boxes.

You shouldn't be making assumptions like this in driver/os dependent code so reverting the revert is wrong no matter how it eventually gets fixed.

The hard coded lists should be moved to a file in the future to fix this problem.