add an option to invert pedals axis values ?

[aderumier]

Hi,

I have problems with some games or emulator with a g29 pedals, where the game is seeing the pedal full pressed when unpressed, and unpressed when full pressed.

I have checked with evtest, the values are 255 unpressed (max value) and 0 pressed (min values).

That seem to be wrong, if I compare with my logitech G pro pedals, where values are

0 (unpressed) ---> 65536 (pressed)

or my xbox260 && ps5 controllers, where trigger values are

0 (unpressed) ---> 256 (pressed)

Some games seem to handle this correctly, but wine for example, to do xinput|dinput translation, is really seeing the values reverted. and if the game if don't have an option to invert the axe, they are not way to inverse them. (SDL mapping can't revert value too).

On linux, Supermodel emulator (model3 arcade) is also seeing the values reverted.

It could be fantastic to have a sysfs knob to dynamically invert the pedals value

[aderumier]

I have made a patch : #120

[JacKeTUs]

Hi, how are you connecting your g29 pedals to the PC? May be adapter is inverted somehow?

[berarma]

@JacKeTUs The values are correct, but those values have worked well in the past. It's also the same values you get with only the HID driver or the in-kernel driver.

@aderumier, can you give more details about what's not working? Wine/Proton version, games tested,...

We can add an option to invert the pedals but first I'd like to know why this is happening now.

[aderumier]

Hi, how are you connecting your g29 pedals to the PC? May be adapter is inverted somehow?

no, tested with 2 friends with 2 differents and 2 differents g29 wheel without modification

[aderumier]

@JacKeTUs The values are correct, but those values have worked well in the past. It's also the same values you get with only the HID driver or the in-kernel driver.

@aderumier, can you give more details about what's not working? Wine/Proton version, games tested,...

We can add an option to invert the pedals but first I'd like to know why this is happening now.

Currently I have problem with supermodel (model3 emulator) on linux.
https://github.com/trzy/Supermodel

On wine, I'm mostly testing "modern" arcade games, with teknoparrot/jconfig, directinput or xinput with wine sdl backend. (mario kart arcade dx for example).

But you can try with wine with a simple "control.exe" (tested on wine 9.17 && wine 10.1), with sdl mapping,, they are an xinput test, and the pedals are seeing as full pressed (when physically unpressed).

[aderumier]

Note that I have other emulator, retroarch,pcsx2 for example, which are able to handle values in both directions.
(so maybe it's just a game engine limitation, I don't known enough how SDL is working)

[berarma]

The pedals are recognized as joystick axes. Unlike buttons, there's no pressed or unpressed state for axes. SDL shouldn't make assumptions either about what axis values mean. Games shouldn't just assume 0 is unpressed and 255 is pressed. Games normally use calibration to adjust their inputs. Arcade machines usually have calibration settings too to correct differences in the hardware, or due to wear and tear. I would strongly recommend this route to avoid more complexity in this already complicated niche of input devices.

Can you please check with those projects if there's a calibration procedure or if there could be one?

There's jscal/jstest-gtk for the old joystick API that allows calibrating the inputs. But it might only work for old games. I don't know if there's something similar for evdev or SDL.

[aderumier]

Hi,

some game have calibration , but some other games not. Some games only implement the gamepad api from sdl. (or like wine, xinput is mapped to sdl gamepad, and some game have only xinput support without calibration)

I'm going to fix it at sdl level, they are a knob ~ on sdl mapping to invert value, it's working for all axes excluding the l2|r2 trigger currently.

note that the sdl3 gamepad documentation have been updated recently, to specify that unpressed is expected to be 0 and pressed 255.
https://wiki.libsdl.org/SDL3/SDL_GamepadAxis
"Trigger axis values range from 0 (released) to SDL_JOYSTICK_AXIS_MAX (fully pressed) when reported by SDL_GetGamepadAxis()."

[berarma]

Hi,

some game have calibration , but some other games not. Some games only implement the gamepad api from sdl. (or like wine, xinput is mapped to sdl gamepad, and some game have only xinput support without calibration)

I'm going to fix it at sdl level, they are a knob ~ on sdl mapping to invert value, it's working for all axes excluding the l2|r2 trigger currently.

note that the sdl3 gamepad documentation have been updated recently, to specify that unpressed is expected to be 0 and pressed 255.
https://wiki.libsdl.org/SDL3/SDL_GamepadAxis
"Trigger axis values range from 0 (released) to SDL_JOYSTICK_AXIS_MAX (fully pressed) when reported by SDL_GetGamepadAxis()."

If they want to treat wheels the same as gamepads, then they should fix it in their API. Since they have already defined it, I think making it configurable will only complicate matters. They will have to maintain a database of devices that need their values inverted.

[Lawstorant]

I do feel like SDL tries to do a little too much with it's device handling. I don't really like the long lists they have defined for what devices are what because of their heuristics which often break.

[berarma]

I do feel like SDL tries to do a little too much with it's device handling. I don't really like the long lists they have defined for what devices are what because of their heuristics which often break.

SDL is the glue between several systems and the apps. In this case, between a static and close to the hardware layer (the kernel), and the apps. The more the SDL API abstraction departs from the underlying standards used (HID in this case), the more it has to do. But I don't see anything wrong with this, I think it's by design.

I don't think we should embed any abstractions needed by applications into the kernel drivers. If there are things SDL isn't doing well we should fix it there. Heuristics should be definitely improved for wheels, and I think that there should be a way for apps/SDL to request device descriptor information and use it for its heuristics.

Also, I would avoid having different input maps depending on whether the wheel is using just the HID driver or some other driver that tries to follow the SDL or any other API. What would happen if they decide to change their abstractions for SDL4 or it's superseded by another different high-level API? I'm thinking generically here.

If we were talking about features created in the driver it would be different, there's more freedom. But I'd still would advocate not to invest too much in following any current high-level API and instead try to be neutral.

My opinion.

[aderumier]

I have fixed it at sdl level, I don't have pushed the patch upstream yet.
Currently, the x && y axis in sdl have a '~' mapping knob to reverse min/max.
it was not existing for z axis.

If somebody is interested:
https://github.com/batocera-linux/batocera.linux/pull/13521/files

(I'm working on batocera emulator distro to implement wheels on different emulators)

[Lawstorant]

If you'd want to push to upstream, it would be best to do it in both SDL2 and SDL3