Windows drivers inside prefix

[Raboebie]

I know this will sounds a bit strange but I have been able to reproduce this on multiple occasions.

I recently acquired F1 22 and it did not recognize my wheel no matter what I did. Eventually I gave up assuming it was a game issue.

A few days later I noticed a post on vales proton bug tracker about someone who installed the windows drivers inside the prefix and then the wheel was detected and mapped correctly on startup. I was pretty sure it won’t do anything, knowing wine has massive limitation when it comes to driver support, but it did. The wheel is detected and works perfectly.

I then decided to test other titles such as ams2 and acc. With both titles the games did not recognize my previous configuration and I had to recalibrate everything. What really surprised me is that the feel of the wheel and especially the pedals changed a lot after installing the drivers. I race daily and I have very fine settings I always keep, but this changed it quite significantly. Can’t really say if it’s for better or worse but the pedals do provide more depth or range of motion for sure.

Could you shed some light on this perhaps? I honestly feel like this should not have done anything yet it made a big difference.

[Kimplul]

I wouldn't be surprised if the driver also installs some registry keys or something along those lines at the same time, and the games check for their existence and change their behaviour based on it. This is actually something that was brought up earlier this summer and I'm intending to take a look at it, but haven't managed to do so yet.

Interesting that the driver even installs under Wine though, but pretty cool. I might add a note about it in the README.

EDIT: Just to clarify, I don't think the Windows driver itself works under Wine, rather that games detect a device that might be a T300 RS, but there's no registry key for it so its ignored. After the driver is installed, the registry key exists, and the game starts working. The Linux driver is most likely still needed.

Maybe, as I said I haven't looked into it but this is my working theory.

[Raboebie]

t looked into it but this is my working theory.

Thanks for the inputs. That is what I thought may be happening but it's cool that it works non the less.

[Raboebie]

Did some quick digging and found these reg keys that the driver creates. Interesting that it says T500RS there. I obviously have a T300RS. I don't know what that binary data means but I think the directory ones it creates may be what makes it tick.

[Kimplul]

Could be worth trying to write a script that automatically inserts those keys into a prefix and checking if that has an effect on games?

[Raboebie]

That's a good idea. I'll give that a go a bit later.

…

On Fri, Jul 29, 2022 at 8:48 AM Kimplul ***@***.***> wrote: Could be worth trying to write a script that automatically inserts those keys into a prefix and checking if that has an effect on games? — Reply to this email directly, view it on GitHub <#46 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABGCYYWPZYEE2DN4QHG4XJDVWN5ELANCNFSM546ANIZQ> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[Raboebie]

@Kimplul So before I tried scripting anything I figured I needed to figure out if it actually uses the files in the Thrustmaster folder and turns out, if I remove/move the drivers folder inside Thrustmaster (in Program Files) the wheel is no longer detected. So it's actually using something in the drivers folder to make the wheel work. This is the contents of the folder. I have no idea how to check what files wine is using when running.

[Kimplul]

Good thinking. I'm guessing .inf could be the main point of interest here, but try removing stuff individually until something breaks. The binary data in the regkey could also be a hash of some kind of the folder, and anything missing could trigger an error state.

[Raboebie]

I see, I'll give that a go. I did find this in the logs

11041.496:0150:01c4:trace:unwind:RtlCaptureStackBackTrace captured 1 frames
11041.505:0150:0384:fixme:dinput:dinput_device_Escape iface 0000000013AD0050, escape 000000004BA4EB60 stub!
11041.516:0150:01c4:trace:loaddll:free_modref Unloaded module L"C:\windows\system32\XInput9_1_0.dll" : builtin
11041.516:0150:01c4:trace:loaddll:free_modref Unloaded module L"C:\Program Files\Thrustmaster\FFB Racing wheel\tmsdk\tm_api_lib_x64.dll" : native
11041.517:0150:01c4:trace:seh:sigsys_handler SIGSYS, rax 0x8d, rip 0x1459a0e66.
11041.517:0150:01c4:trace:seh:sigsys_handler SIGSYS, rax 0x8d, rip 0x14bd6c90c.
11041.517:0150:01c4:err:ole:CoUninitialize Mismatched CoUninitialize
11041.517:0150:01c4:trace:loaddll:free_modref Unloaded module L"Z:\home\dihank\RAID\SteamLibrary\steamapps\common\F1 22\CM.Windows.Gaming.Input.dll" : native

Seems like it's directly loading tm_api_lib_x64.dll

trace:loaddll:build_module Loaded L"C:\Program Files\Thrustmaster\FFB Racing wheel\drivers\amd64\tmInstall.EXE" at 0000000100000000: native

UPDATE: It loads both the libraries every time the game is started. Switching the wheel to PS4 mode it's not detected by oversteer or Linux in general but when I start the game it detects it as a Xbox controller. Very odd

[Kimplul]

Interesting, we ran into tm_api_lib_x64.dll before as well:
#37

I didn't know it was a generic library, I thought it was just related to Automobilista but if several games use it then it might be best to just add a note to the README about installing the Thrustmaster drivers in prefixes. I'm not a lawyer, but I'm fairly certain redistributing a binary is a no-no.

Or just reverse-engineer it and add in stub functions, but I suspect that might be a bit excessive.

[Kimplul]

UPDATE: It loads both the libraries every time the game is started. Switching the wheel to PS4 mode it's not detected by oversteer or Linux in general but when I start the game it detects it as a Xbox controller. Very odd

I suspect that's because the Linux driver supports PS4 mode, and Proton just passes it through to the games. Windows has no support for PS4 mode at all, from what I can remember, so I suspect the games/libraries don't really know what to do with it. PS4 is detected under a separate USB ID from the PS3 version, so it's essentially a completely 'different' product.

EDIT: Missed the parts about Linux and Oversteer. PS4 mode seems to be missing from wheel_ids.py in Oversteer so it isn't detected, but the Linux bit is weird.

[Raboebie]

Yeah agreed.

So as a final test I decided to remove your driver completely so its detected by the built in driver with no FFB. When running the game the weel is still detected correctly and all my mappings are still present but there is no FFB. So this confirms that it's looking for something to load which identifies the wheel rather than using the windows driver itself.

tm_api_lib_x64.dll can be found in the root directory of F1 22 as well. Plenty of games seem to ship this as default.

[Raboebie]

d add in stub functions, but I suspect that might be a bit excessive.

I think it could be fair to add something in the readme that some games require you to have to Windows drivers install in the prefix for it to be detected I guess. Yeah I don't think we need a lawyer for that one.

[Kimplul]

Added a note about it in the README. I might add some instructions for the driver installation later.

Really glad you brought this up, but sort of unfortunate that people will potentially have to run a driver installer in each prefix separately. I wonder if there's some way to automate the setup?

[Raboebie]

I'm not a copy write expert but the driver can be silently installed and pulled with wget perhaps but since every stream game gets it's own prefix this may be a bit tricky. Perhaps a proton fix for a custom version of proton could be the answer for steam titles at least.

Or perhaps it can be added to protontricks as a select-able option. Not perfect but could be a lot easier

[Raboebie]

Adding on here. I've had time to test all my sims now and in all of them installing the driver in the prefix makes noticeable changes to the calibration of the wheel. It really does feel like I'm playing on windows after installing windows driver.

AMS2
AC
ACC
rFactor 2
PC2
Dirt Rally 4
WRC9
F1 22 and 2021
BeamNG

So I think it's worth installing them even if it works out of the box. Allows the game to correctly calibrate everything. Most notable are the pedals with some improvements to FFB.

[fuzunspm]

could you please guide me on how to install windows driver in the prefix?

[Kimplul]

Added a wiki section about it: https://github.com/Kimplul/hid-tmff2/wiki

Feel free to request clarifications etc. if it's not clear enough.

[fuzunspm]

I missed that sorry and thank you

[fuzunspm]

out of context but I saw your old message on github about you don't own AC. I can't code for hardwares or in C (only in python and nodejs) but I want to contribute this project so please let me know your missing games and I will gift them.

[Kimplul]

Thank you, that's very kind. I somewhat recently actually bought AC and ACC on Humble Bundle, so that's not an issue anymore.
I'll keep your offer in mind for the future, though :)

[fuzunspm]

yes please do it, thank you

[Raboebie]

Hi Peter, You should use something like protontricks to set the windows version to 10. Proton experimental may have problems so I recommend using something a bit older.

…

On Tue, Oct 4, 2022 at 8:37 PM peterlopen ***@***.***> wrote: @Raboebie <https://github.com/Raboebie> hi, pls, how did you manage to install drivers? I am getting: [image: image] <https://user-images.githubusercontent.com/19715361/193896681-ea6eb7c9-10a2-425b-aad9-e860963f9882.png> and there is nothing pointing to a problem in wine log :( I have set Proton experimental in properties for F1 2019. [image: image] <https://user-images.githubusercontent.com/19715361/193898416-a1827299-fda2-4a63-9107-bc39f8a10c06.png> thank you. peter — Reply to this email directly, view it on GitHub <#46 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABGCYYQWBPLET7PE6QOIRZTWBR2QDANCNFSM546ANIZQ> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[peterlopen]

@Raboebie it was proton version. I tried Proton 7 and it worked. thanks a lot for this information about drivers installation in wine prefix, I tested F1 2019 and now it feels (almost) the same as in Windows.

thank you all, finally I can play with wheel in linux :)

[Raboebie]

I'm glad my nerdiness helped you out!

…

On Wed, Oct 5, 2022 at 7:58 AM peterlopen ***@***.***> wrote: @Raboebie <https://github.com/Raboebie> it was proton version. I tried Proton 7 and it worked. thanks a lot for this information about drivers installation in wine prefix, I tested F1 2019 and now it feels (almost) the same as in Windows. thank you all, finally I can play with wheel in linux :) — Reply to this email directly, view it on GitHub <#46 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABGCYYXFLHLYEJXPQLQC5FTWBUKGZANCNFSM546ANIZQ> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[nkay08]

I tested installing the windows driver in my Assetto Corsa prefix and, indeed, it works great.
I had some doubts about how good it will be on Linux since in Oversteer there's a massive Deadzone on the pedals.
With the windows drivers there are no such problems, everything seems to be working fine. (I have also added deadzone settings in /etc/udev/rules.d/99-joydev.rules, though)

I want to tune the wheel settings, has anyone tried starting the Thrustmaster Control Panel?
I tried launching it within the prefix, but it does not seem to start.

[peterlopen]

hi @nkay08 , I tried to find exe for TM control panel, but seems like there is just some configuration (.inf file) for "generic" windows control panel and I was not able to run that :(
anyway, looking forward to try AC :)

[nkay08]

hi @nkay08 , I tried to find exe for TM control panel, but seems like there is just some configuration (.inf file) for "generic" windows control panel and I was not able to run that :( anyway, looking forward to try AC :)

I checked it on windows, and there a custom Thrustmaster menu opens from the gamepad settings for the wheel properties.
In wine this obviously doesn't work. We have wine control where we can see connected game devices, but we cannot launch that Thrustmaster menu...

AC is abit tricky to set up. I recommend following this link Asseto Corsa on Linux Updated Gist to prepare the wine prefix.
After you are done, you can use a much more recent wine version to launch the game with better performance (I'm using Proton GE 7.37).

[peterlopen]

thanks for info 👍

[peterlopen]

so I tried AC with this oversteer settings

and it actually felt pretty good :)
thanks once again

[nkay08]

I played around a bit and it seems on Windows the settings from the Thrustmaster Control Panel are saved in the Registry.

The keys on my system seem to be saved in HKEY_CURRENT_USER\System\CurrentControlSet\Control\MediaProperties\PrivateProperties\Joystick\OEM\VID_044F&PID_B66E\OEM\JoystickSettings\0x28B3B24F.

Some possible Keys are the following for which hex values are set:

• DefaultWheelAngle
• OverallGain
• DamperGain
• SpringGain
• PeriodicGain
• ConstantForceGain
• DefaultSpringStiffness
• DefaultSpringIsPersistent 00 00 00 00 is off, 01 00 00 00 is on

For example, for DefaultWheelAngle a value of 84 03 00 00 is 900, 38 04 00 00 is 1080.

I exported the keys, with Steering Angle set to 900, Gain set to 70% and Damper set to 30%.

Windows Registry Editor Version 5.00

[HKEY_CURRENT_USER\System\CurrentControlSet\Control\MediaProperties\PrivateProperties\Joystick\OEM\VID_044F&PID_B66E\OEM\JoystickSettings\0x28B3B24F]
"DefaultWheelAngle"=hex:84,03,00,00
"OverallGain"=hex:58,1b,00,00
"DamperGain"=hex:b8,0b,00,00

[HKEY_CURRENT_USER\System\CurrentControlSet\Control\MediaProperties\PrivateProperties\Joystick\OEM\VID_044F&PID_B66E\OEM\JoystickSettings\0x28B3B24F\0]

[HKEY_CURRENT_USER\System\CurrentControlSet\Control\MediaProperties\PrivateProperties\Joystick\OEM\VID_044F&PID_B66E\OEM\JoystickSettings\0x28B3B24F\1]

I can successfully import the .reg file using wine regedit.

Does anybody know if the driver installed in the prefix can see these values? (I could maybe test by setting gain very low for example)

What I don't know is what the 0x28B3B24Fkey is? Is it device specific or is it a general key for the T300?

EDIT:
Unfortunately, it does not seem to have an effect.

[peterlopen]

hi @nkay08, do you use oversteer? my understanding is oversteer will set those values when run. Same as TM control panel is doing in windows - from registry values in this case. I assume those value are set only "once" - when oversteer/control panel is running. So I assume to get registry values to wheel TM control panel would need to be run in wine prefix. However, I am not sure if it would be even able to talk to wheel hardware.

[nkay08]

hi @nkay08, do you use oversteer? my understanding is oversteer will set those values when run. Same as TM control panel is doing in windows - from registry values in this case. I assume those value are set only "once" - when oversteer/control panel is running. So I assume to get registry values to wheel TM control panel would need to be run in wine prefix. However, I am not sure if it would be even able to talk to wheel hardware.

Kind of. Oversteer is a utility on the Linux host itself, which can modify the device settings.
This device on the host system is passed through to wine/proton so the game can see it.

I thought, perhaps installing the driver in the prefix would allow the original thrustmaster driver to be loaded for the game.
But I now doubt that that is the behavior. From my understanding the windows driver loads the registry keys I mentioned above.
But perhaps installing the driver is not doing very much inside the prefix, aside from installing some registry Keys so that some games can detect the wheel.

[peterlopen]

makes sense. thanks for explanation

[berarma]

I've followed this thread because I find interesting that Windows drivers can have an influence on the hardware under Wine/Proton. That was unexpected for me.

There's not many ways this can happen I guess. The drivers might be registering some library so that DirectInput calls are redirected through them and then modify the parameters before they reach the Linux API or they're sending messages to the wheel to change its behavior using raw USB messaging. Have you done some testing to guess which one is the case?

Using ffbwrap logs it should be possible to compare the Linux API calls and see if there's different parameters sent. Maybe some transformations of the parameter values when the Windows driver is installed.

For the other option, I don't know if that's possible, and it's probably impossible if Wine/Proton is running from Flatpak. If in doubt, Wireshark could be used to search for USB messages sent by the Windows software that might change the wheel behavior.

I guess the first option is more easy to test and also more likely to be true.

[nkay08]

Using ffbwrap logs it should be possible to compare the Linux API calls and see if there's different parameters sent. Maybe some transformations of the parameter values when the Windows driver is installed.

Do you maybe have an idea how to trace a reproducible scenario?
I guess, it would be difficult to analyze and compare the logs if I just recorded two random scenarios.

I have a backup of my wine prefix before and after installing the driver, so I could make some tests.

[berarma]

Using ffbwrap logs it should be possible to compare the Linux API calls and see if there's different parameters sent. Maybe some transformations of the parameter values when the Windows driver is installed.

Do you maybe have an idea how to trace a reproducible scenario? I guess, it would be difficult to analyze and compare the logs if I just recorded two random scenarios.

I have a backup of my wine prefix before and after installing the driver, so I could make some tests.

True. I guess some FFB tool for Windows that can replay effects would work best. There was a FFB editor that came with DirectX, I think. Or maybe some game where it's easy to reproduce a similar scenario that has very different outcomes depending on the driver being present or not.

[Lightning-Smith]

hey,
I was wondering if anyone could help because I'm unable to install t248 ps version drivers in the prefix. Granted I don't completely understand what I'm doing. So I was wondering if anyone knows what I'm doing wrong.

For clarifications:
My steamlibrary is on my mass storage which is not the drive with nobara installed.
I've tried to do it on both drives and it doesn't work for me. It is able to find the game, nomatter through which drive I look for it with protontricks. But the moment I try to add the driver, it is unable to find the steamlibrary.

If I have missed some info, just ask me and I'll clarify that which I have forgotten to mention.

[Kimplul]

@Lightning-Smith did you try without the sudo? It could be messing up your $PATH.

[Lightning-Smith]

Thank you for your reply

I just tried it, but I get a warning

as you can see, it warns me for an unknown option -c

does that mean I still need to install something?

[Kimplul]

I'm pretty sure you just have the arguments in the wrong order, try

protontricks -c 'wine ./2023_TTRS_1.exe' 690790

By the by, I'm also pretty sure you have the dot on the wrong side of the slash.

[Lightning-Smith]

I see, you are correct. I definitly put the dot on the wrong side of the slash.

And now I have different result

It seems I have hit some sort of limit within wine and it is unable to open the driver.
I just looked up the error and apparently it means that the executable doesn't exist? even though I copied and pasted the file name directly

[Lightning-Smith]

I do have to add that I the driver both on the main ssd and the second one

[Kimplul]

I just looked up the error and apparently it means that the executable doesn't exist?

Yep, wine can't find the installer. Maybe try double checking that you're in the right directory, or that you didn't accidentally rename the file or something like that. Any number of things could've occurred.

I do have to add that I the driver both on the main ssd and the second one

You don't actually need to do that. Protontricks will install the driver into the game's wine prefix, so you can use the same installer for multiple games on multiple drives.

I'm guessing you're somewhat new to working on the command line? Small tip, you can usually just copy the error messages directly into GitHub comments. Just add three backticks (```) before and after to get nicer formatting. That way you don't have to mess around with screenshots, saves on bandwidth and is generally a bit easier in my opinion.

[Lightning-Smith]

thx for the advice:)

so I tried it in 2 different ways and they both got the same results.
This time I typed out the name of the driver.

so here is what I tried first ():

[lightningsmith@lightningsmith-pc Downloads]$ protontricks -c 'wine ./2023_TTRS_1' 690790
/bin/bash: /usr/lib/pressure-vessel/overrides/lib/x86_64-linux-gnu/libtinfo.so.6: no version information available (required by /bin/bash)
fsync: up and running.
wine: RLIMIT_NICE is <= 20, unable to use setpriority safely
wine: failed to open "./2023_TTRS_1": c0000135

And the second try:

[lightningsmith@lightningsmith-pc Downloads]$ protontricks -c 'wine ./2023_TTRS_1.exe' 690790
/bin/bash: /usr/lib/pressure-vessel/overrides/lib/x86_64-linux-gnu/libtinfo.so.6: no version information available (required by /bin/bash)
fsync: up and running.
wine: RLIMIT_NICE is <= 20, unable to use setpriority safely
wine: failed to open "./2023_TTRS_1.exe": c0000135

And this time I am in the downloads folder where the driver resides
And I deleted the duplicate on the other drive, so there is only 1 driver

[Kimplul]

Oh, right, I completely missed that you will have to specify a full path to the installer. Looks like your installer is in ~/Downloads, so your full command should look like

protontricks -c 'wine ~/Downloads/2023_TTRS_1.exe' 690790

Protontricks changes the working directory to the game's directory before executing the command, so the relative path will not point to where you think it's pointing.

[Lightning-Smith]

hmm, weird.

so to clarify, the wheel worked fine without the driver. Except for force feedback. so that is why I wanted to install the driver.
so I added the drivers to acc, dirt rally 2.0 and raceroom.

dirt rally 2.0 acts like nothing happened and there is no force feedback.
the other 2 just crash and wont start anymore. And they did work before as I tried them out before installing the driver.
but in a way it is weird that the driver would make the games crash, because they rely on the driver to send the force feedback to the wheel.

[Kimplul]

but in a way it is weird that the driver would make the games crash, because they rely on the driver to send the force feedback to the wheel.

Not exactly. I touched on this earlier in this thread: #46 (comment)

To recap, on Windows you will need the driver, yes. However, Proton only passes the force feedback effect requests directly to hid-tmff2, this driver. The Windows driver likely provides some files or metadata that games that seems to improve the force feedback, but generally speaking the Windows driver isn't required for Linux/Proton.

The bit about crashing and no FFB is weird enough that I opened up a new issue about it, let's continue this discussion over in #59.

[Urth]

Protontricks changes the working directory to the game's directory before executing the command, so the relative path will not point to where you think it's pointing.

Could this be added to the wiki? I've forgotten and have been bitten twice by this 😞
https://github.com/Kimplul/hid-tmff2/wiki#installing-the-windows-drivers-inside-a-proton-prefix

[Kimplul]

@Urth Great suggestion, apologies for the oversight on my part. I added a bit about absolute paths and changed the examples, is the wording ok?

[Urth]

@Kimplul yeah that is great 👍