hid-tmff2: add combined pedals and centered clutch support for T300RS

[Eispala]

Hello,
since Need For Speed: Most Wanted 2005 needs combined pedals to work, i set out to implement this feature.

I am a software developer by trade, but not in C and i have no clue about driver development.
So, disclaimer: I used AI to implement this. - After i got it to work, i cleaned the code up (as good as i could at least)

It's only implemented for the t300rs, as i have that wheel.

Changes:

• Add combine_pedals module param to merge gas/brake into a single Z axis
• Expose both as sysfs attributes so we can enable/disable it. Also the sysfs file makes it compatible with Oversteer
• Add center_clutch module param to fix clutch at center (512) when combine_pedals is active (Also for NFS: MW 2005, otherwise the controls in the Menu always scroll down - you can ofc. press the clutch yourself, but it's nicer this way)
• Add t300rs_raw_event to rewrite pedal data
• Add t300rs_rdesc_nrm_combined HID descriptor for combined pedal mode

I tested it in NFS: MW 2005 and it works (Combining Pedals at least, it still has some other issues).
Also i did some form of regression testing if you can call it that - other games still work.

[Kimplul]

Hi, sorry for the delay, been kinda busy lately. Thanks for taking the time to share this, appreciate it.

So the approach here is to modify the packets that the wheel sends out and let the HID layer take care of the rest. I guess I'm not entirely opposed to the idea, but I dislike how this implementation is very wheel-specific and uses magic constants to reach into the bag of bits that is each event. I also don't quite understand why the rdesc has to be modified, do you have examples of other drivers that do something like this and how do they handle it?

I'm admittedly not super well versed in the input layer of the Linux kernel, so I'm not entirely sure if there are better approaches to take, just trying to learn by asking questions :)

[kakra]

As the maintainer of the xpadneo project, I think it makes sense to modify rdesc only if it reflects changes made to the rawhid output (otherwise apps parsing the descriptor to make sense of raw HID packets may become broken, although at least SDL doesn't really care and just looks at hard-coded offsets). If rawhid output/input has not been modified, rdesc should not be modified either. If rdesc has a broken structure or misleading input assignments (e.g. Rz instead of Z or something like that), it can be considered to be fixed but care has to be taken that user-space (SDL, Wine, Proton, Steam Input) still properly handle that. Especially for Proton gaming, it can be useful to modify HID (rdesc, rawhid) to align with what native Windows apps see: Proton wine provides a HID bus, and if such devices are used in Proton via HID bus, they should match Windows behavior as close as possible without interfering with SDL.

Given this specific change: The Windows Thrustmaster drivers provide a switch to combine pedals, so the same switch should probably exist in this driver, maybe generalized to all models, and be switchable at runtime via sysfs. Making it a runtime variable implies that rdesc and hidraw should not be changed.

OTOH, I'm not sure if oversteer should instead get such a switch and provide a virtual input device to be used by games. In that case, it would be purely a user-space change. But intercepting input devices and creating a new virtual device can be tricky: The original device must either become hidden or provide no output while the virtual device is used. Given that the input device must also handle force feedback, handling the pedal combining in the kernel driver might just be easier. Oversteer could be modified to access the sysfs parameter then.

Note: I didn't look at the code changes itself, I just wanted to add my knowledge I got from maintaining xpadneo and its various interactions with different user-space input layers.

[Kimplul]

I snooped around the kernel a bit and only found hid-lg4ff that allowed combining pedals, but it does seem to use the above method of tickling bits: https://elixir.bootlin.com/linux/v7.1.7/source/drivers/hid/hid-lg4ff.c#L326

However, I'm wondering if it might be better to hook into the event callback, by which time the raw bits have been cooked into separate axis events and the driver can filter for the generic AXIS_X etc. symbolic names. One potential issue that I can think of is that if the user presses both the brake and gas pedal at the same time, two events will be generated, one with a slight over- or undershoot and the second one being the correct value. Unsure how significant that might be, but I'm planning on trying it out soon-ish.