Issues on many games, how to debug and contrib

[snorkellingcactus]

Issues on many games, how to debug and contrib

[Kimplul]

Hello, thanks for the report. Quite a lot to chew through, apologies if I miss anything. First of all, could you just confirm that you have working FFB in some games?

I had issues with the wheel on many games (all with thrustmaster driver installed on prefix) with T300RS:
Game: WRC 8
Proton: 8-11
Status: Works all except force feedback
[...]
I added WINEDLLOVERRIDES="xinput1_3=n,b" steam launch option for some games to work, like wrc generations

What does WRC 8 do without WINEDLLOVERRIDES=...?

I also turned off the thrustmaster api in flavour to dinput on wrc generations and everything went fine

I don't own the game, do you mean there's a setting in the game for this and with input set to dinput the game works with input and FFB?

I wonder where i should look at to debug it

General thoughts: Some input/FFB issues could be attributed to stuff similar to #38, i.e. games having an internal database of wheels, and Linux for some reason or other not fulfilling the requirements the game sets to recognise a wheel. Some games use xml files, some might have them built into source code or a library, some might use SDL (or rely on Wine which in turn relies on SDL), or potentially even tm_api_lib_x64.dll (though I'm still not entirely sure what functionality the library actually has).

Still, each game might have its own issues, so the approach unfortunately might have to differ from game to game.

Should i monitor like man in the middle ? Would virtualbox serve for this ? or some wine tracing ? or rebuild the module with some debug info added ?

Man in the middle works pretty well for monitoring FFB, could maybe also work for monitoring input though I'm not entirely sure how that would be useful. The thing is that this driver doesn't actually handle input, that job is delegated to the HID subsystem in Linux. Frankly I'm fairly confident the input is handled correctly by the Linux kernel, and I would suspect these issues exists outside of it, either in Wine/Proton or the games themselves (or any combination of both). Wine tracing might also give some insight into what a game is doing, or at least what services its requesting from Wine, which might be helpful, though very context sensitive.

I had other input issues unrelated to this driver too that somehow i think they may be related to elogind and seats

Entirely possible that some subsystem steps in and tweaks inputs between the kernel and whatever game you're trying to play, always something to keep in mind. Also note that there are at least two subsystems for joysticks, joydev and evdev, and some games might use one over the other. Generally speaking evdev is the default these days and it's the one Wine uses (I believe), but you might find some games that still use joydev in which case modifications done with evdev might not show up. Something to be wary of.

Should i see the ts300 as an xinput device on wine control ?
I see it as a dinput device

Dinput for me as well, couldn't get FFB effects to work in the control panel but they work in games so not sure what that's about. Maybe something worth looking into.

(unrelated too) I also have the always left issue when i plug a custom handbrake

I'm guessing the handbrake shows up as a separate controller with one axis. If you know which axis the handbrake shows up as, you should be able to remap it on a system level to some other axis to avoid games interpreting the handbrake as a 'normal' input. Alternatively, maybe calibrate the device to a range so that the axis doesn't register left input when not being touched.