No longer detected down to proton 5.13 about hid-tmff2

[kevenwyld]

I know we weren't having the same issues but I recently discovered that some changes to Steam Linux Runtime - Soldier was the cause for my pedals starting to work. While reading through their readme I noticed this quote:

The Steam Runtime is also used by the Proton Steam Play compatibility tools, which run Windows games on Linux systems. Older versions of Proton (5.0 or earlier) use the same 'scout' LD_LIBRARY_PATH runtime as most native Linux games. Newer versions of Proton (5.13 or newer) use a container runtime with newer library versions: this is Steam Runtime version 2, codenamed 'soldier'.

In the most recent version of Soldier my pedals no longer work anymore. Selecting the previous version from the beta menu resolves my pedal detection problem but I feel it's pretty likely that this is the place to look for wheel related input issues as well. And would explain why the steam client update did not coincide with your wheel breaking but the last release of soldier did (0.20230123.89).

Anyway I hope this helps somehow

EDIT: Link to response from valve ValveSoftware/steam-runtime#561 (comment)

[irseny]

you can modify protopedal.c and change usleep(1000) to 10 or 5

Thanks for letting me know again ;) I just replaced usleep() entirely for the next release.

Anyway I had some time to test and improve the workaround and so far it circumvents my original problem.
@Kimplul Since I do not require another solution I would not mind to have this issue closed.

[yacinbm]

There is an additional issue on the Steam Deck where the Steam Runtime seems to break support for steering wheels (and joystick devices in general I think). We found a workaround in the following thread that allows to run games without the Steam Runtime environment. I will report this to Valve and see what they can do.

Happy racing!

[Kimplul]

Hi, thanks for the report.

Do you see similar effects?

Unfortunately I can't see anything resembling what you're describing on my machine. A couple questions:

• Which distro and version are you using?
• Which games does this affect? Your post seems to imply all games, but could you provide some examples?
• Have you looked at dmesg when you start the game, or the debug log of proton?
• Have you checked that other controllers work? ValveSoftware/Proton#1549

Is there something that could be implemented on the driver side to prevent this behaviour?

I don't know, since I don't know what could be causing the issue.

[irseny]

Hi, thanks for the reply.

I am on debian 11.5
The behaviour does not seem to depend on games.

• My testing is mostly based on Assetto Corsa Competizione.
• The demo of Automobilista 2 did also stop to see the wheel.
• Today I installed Wreckfest which sees a Keyboard, my Pedals and an Xbox Controller (which I don't own) with Proton 7. Wreckfest refuses to run in lower versions.
• There are no issues using just the bundeled wine versions on Mafia
• There is nothing obviously going wrong looking at proton logs. I noticed one conspicuous difference comparing v5 vs v7:
  14923.038:006c:trace:hid:udev_driver_init UDEV input devices disabled in registry
  Could this be related to my issue?
• The dmesg output seems fine. What would I be looking for more specifically in there?

This sums up what I can test ATM. Since this is not reproducible for you may as well close this thread and I will report back once something major happens.
Bye and thank you for operating this project

[Kimplul]

I am on debian 11.5

I'm on Debian testing, though I doubt it makes a difference.

My testing is mostly based on Assetto Corsa Competizione.

I double checked ACC, the game's default wheel bindings are inverted but you say that the wheel is not at all detected, so again, unfortunately I can't reproduce. Automobilista 2 and Wreckfest both work for me.

There are no issues using just the bundeled wine versions on Mafia

I don't have Mafia, but if you mean the default Proton version for Mafia is lower than 5.10 then that matches what you've previously described.

There is nothing obviously going wrong looking at proton logs. I noticed one conspicuous difference comparing v5 vs v7:
14923.038:006c:trace:hid:udev_driver_init UDEV input devices disabled in registry
Could this be related to my issue?

Maybe? Apparently the wine registry key HKLM > System > CurrentControlSet > Services > WineBus > DisableInput is associated with that message. In the documentation this setting is described to turn off evdev for device discovery and communication, and it is set to enabled by default.

I couldn't get the message to show up in my logs, maybe your proton takes a different control path from mine because of some other root cause, not sure. Anycase, could you try setting the key to disabled and report back? You might have to create the key.

The dmesg output seems fine. What would I be looking for more specifically in there?

I was thinking that maybe there was something going catastrophically wrong and only the newer versions of proton on your system triggered it, in which case dmesg should've been filled with errors of some kind. Doesn't seem to be case.

This sums up what I can test ATM. Since this is not reproducible for you may as well close this thread and I will report back once something major happens.

I'd prefer keeping it open for now, if someone else runs into something similar it might be easier to spot while open.

[kevenwyld]

I'm also having this issue. Proton based games "detect" the wheel but no data seems to be sent to the game. It works fine on linux native games (BeamNG's linux binary launched outside of steam works fine for example).

After initial calibration the wheel goes into self center mode. Usually after launching a game self centering is no longer active, even after exiting the game, but now it seems it's just all the time. Even when in a game and no input is ever actually sent to the game despite the wheel being present in the controller section of all the games I've tried.

I've been running proton 6.3-8 for most things that require FFB and up until this issue that has been very reliable.

Things I've tried:

• Install from the git repo instead of the (orphaned) AUR package
• Various USB ports and cables
• Several steam proton games: AC, Dirt Rally 2.0, BeamNG
• jstest, which does work, though this isn't surprising since I think it's a proton related issue

OS: Arch Linux x86_64
Kernel: 6.1.8-arch1-1
WM: i3
CPU: AMD Ryzen 9 5950X (32) @ 3.400GHz
GPU: AMD ATI Radeon PRO W6800
Memory: 64194MiB

My Steam version according to the "About Steam" dialog is 1674871341. I am part of the steam beta update channel.

In dmesg when the wheel is connected I see:

[   30.027789] usb 3-2.2.2.2: new full-speed USB device number 9 using xhci_hcd
[   30.155177] usb 3-2.2.2.2: New USB device found, idVendor=044f, idProduct=b65d, bcdDevice= 1.00
[   30.155183] usb 3-2.2.2.2: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[   30.155184] usb 3-2.2.2.2: Product: Thrustmaster FFB Wheel
[   30.155186] usb 3-2.2.2.2: Manufacturer: Thrustmaster
[   30.274476] input: Thrustmaster Thrustmaster FFB Wheel as /devices/pci0000:00/0000:00:01.2/0000:02:00.0/0000:03:08.0/0000:07:00.3/usb3/3-2/3-2.2/3-2.2.2/3-2.2.2.2/3-2.2.2.2:1.0/0003:044F:B65D.000C/input/input21
[   30.274564] hid-tminit 0003:044F:B65D.000C: input,hidraw11: USB HID v1.00 Gamepad [Thrustmaster Thrustmaster FFB Wheel] on usb-0000:07:00.3-2.2.2.2/input0
[   30.295059] hid-tminit 0003:044F:B65D.000C: Wheel with model 0x2 is a Thrustmaster T300RS
[   30.297253] hid-tminit 0003:044F:B65D.000C: Success?! The wheel should have been initialized!
[   30.314672] usb 3-2.2.2.2: USB disconnect, device number 9
[   31.051469] usb 3-2.2.2.2: new full-speed USB device number 10 using xhci_hcd
[   31.181057] usb 3-2.2.2.2: New USB device found, idVendor=044f, idProduct=b66e, bcdDevice= 1.00
[   31.181062] usb 3-2.2.2.2: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[   31.181064] usb 3-2.2.2.2: Product: Thrustmaster T300RS Racing wheel
[   31.181065] usb 3-2.2.2.2: Manufacturer: Thrustmaster
[   31.279493] input: Thrustmaster Thrustmaster T300RS Racing wheel as /devices/pci0000:00/0000:00:01.2/0000:02:00.0/0000:03:08.0/0000:07:00.3/usb3/3-2/3-2.2/3-2.2.2/3-2.2.2.2/3-2.2.2.2:1.0/0003:044F:B66E.000D/input/input22
[   31.279616] hid-generic 0003:044F:B66E.000D: input,hidraw11: USB HID v1.11 Joystick [Thrustmaster Thrustmaster T300RS Racing wheel] on usb-0000:07:00.3-2.2.2.2/input0
[   31.347916] input: Thrustmaster Thrustmaster T300RS Racing wheel as /devices/pci0000:00/0000:00:01.2/0000:02:00.0/0000:03:08.0/0000:07:00.3/usb3/3-2/3-2.2/3-2.2.2/3-2.2.2.2/3-2.2.2.2:1.0/0003:044F:B66E.000D/input/input23
[   31.347975] tmff2 0003:044F:B66E.000D: input,hidraw11: USB HID v1.11 Joystick [Thrustmaster Thrustmaster T300RS Racing wheel] on usb-0000:07:00.3-2.2.2.2/input0
[   31.353068] tmff2 0003:044F:B66E.000D: force feedback for T300RS

I'm not sure if it's relevant however in the dmesg output above I see a disconnect and then a second successful connection which seems a bit odd. Again the wheel works fine in Linux native games though.

Sorry for all the edits, I kept thinking of things to add.

[Kimplul]

Thanks for chiming in, good to know it's not just a one-off. Maybe I'll try installing Arch and checking if that does anything.

I'm not sure if it's relevant however in the dmesg output above I see a disconnect and then a second successful connection which seems a bit odd.

That's expected. Thrustmaster's firmware starts the wheel in a kind of bootloader, and needs the computer to tell the wheel which model it is, after which it agressively restarts itself, disconnecting and reconnecting itself under a new USB product ID.

This is allegedly not allowed by the USB protocol, though I haven't really read into the spec enough to know for sure. At some point the disconnect caused my kernel to crash, but that seems to have been fixed.

[irseny]

At some point the disconnect caused my kernel to crash, but that seems to have been fixed.

I am pretty certain this fix did also apply to crashes that I saw some while ago. Before that disconnecting the T300 while still in use often lead to a kernel crash.

I don't have Mafia, but if you mean the default Proton version for Mafia is lower than 5.10 then that matches what you've previously described.

Not certain that I described my testing in enough detail. Mafia (and probably not limited to it) was able to see the wheel with the wine distributions of Proton 5.0, 5.10, 6.3 and 7.0 (all that I tested). Contrary to the Proton behaviour.

Apparently the wine registry key HKLM > System > CurrentControlSet > Services > WineBus > DisableInput is associated with that message.

It is, and it removed the message from the log but the outcome was the same. I also played around with other keys for winebus. I think it was worth a try.

BTW does your T300 appear in the steam controller configuration?
I started work on FFB passthrough for the aforementioned virtual device mimics. While playing around with it I saw it appearing in the steam controller config right away while the actual T300 does not. (It never was, not related to the actual problem)

[Kimplul]

Not certain that I described my testing in enough detail. Mafia (and probably not limited to it) was able to see the wheel with the wine distributions of Proton 5.0, 5.10, 6.3 and 7.0 (all that I tested). Contrary to the Proton behaviour.

Oh, so it might be game-dependent? Interesting. Have you tried installing steam in just basic Wine and playing some games through that? I'm wondering whether this is more a Proton or Wine thing.

It is, and it removed the message from the log but the outcome was the same. I also played around with other keys for winebus. I think it was worth a try.

Unfortunate, thanks for checking.

BTW does your T300 appear in the steam controller configuration?

No, it doesn't.

Maybe I'll try installing Arch and checking if that does anything.

I don't have any spare hardware to do a native install at the moment, so I spent some time yesterday setting up an Arch VM and compiling mesa's lavapipe for i686, and I'm honestly impressed that we can run (light) games through Proton on a virtual machine with a software renderer. Apparently there's even a vulkan protocol being worked on for virgl, so we might get hardware assisted vulkan rendering in virtual machines at some point, massively cool.

Anyway, all this to say that my wheel is still detected. To be fair, I only tested 'art of rally' and Broforce, since I can only run very light games in the VM, and if this detection issue might be game dependent, I could've missed games where it doesn't work.

[kevenwyld]

So this is still not working for me but I haven't had much more time to dig yet. I did notice today though that some things that didn't used to work in proton are now working, even in older versions, which seems to suggest a change was made, maybe to steam input?.

For example I have some Heusinkveld Ultimate+ pedals which previously required protopedal to work due to a limitation in proton which required all controllers to have at least 4 axis and 1 button. They are now detected in all the games I've tried without protopedal running (this is great btw!!!!!). And they are recognized correctly with only 3 axis. Even Dirt Rally 2.0 which had tons of issue with those pedals now can apply profiles to them as if it were on windows.

It might be worth opening an issue over in the proton github (if there isn't one already, I haven't looked yet). Or possibly the developer forum for steam, I'm not sure how that works exactly though. I wonder if steam is trying to do something clever with all the input devices it can find and this driver is not identified as input correctly.

EDIT: I tried opting out of steam beta but that didn't make a difference.

[Kimplul]

... I did notice today though that some things that didn't used to work in proton are now working, even in older versions, ...

Pretty cool, glad to see progress being made.

It might be worth opening an issue over in the proton github (if there isn't one already, I haven't looked yet).

I would've assumed the issue is related to ValveSoftware/Proton#1549 which I linked to earlier in the thread. But yeah, opening up a new issue or adding to that thread is advisable. I can't replicate and I don't know all the details of what you guys have tried, so I would appreciate it if you reported this to Valve yourselves so this doesn't turn into a weird game of telephone.

[kevenwyld]

I would've assumed the issue is related to ValveSoftware/Proton#1549

Oops, I missed that comment. Thanks.

so I would appreciate it if you reported this to Valve yourselves so this doesn't turn into a weird game of telephone.

Yeah you're probably right. I'll see about reporting it on the proton github page for the games I've tested.

[kevenwyld]

So I fixed it...

I noticed that /usr/lib/udev/rules.d/70-steam-input.rules has a lot of uaccess rules in it for various input devices. Most of the Thrustmaster range is missing though, and nothing matches the product IDs that the t300 uses.

So I created a new file /etc/udev/rules.d/99-thrustmaster.rules with the contents:

KERNEL=="hidraw*", ATTRS{idVendor}=="044f", ATTRS{idProduct}=="b66e", MODE="0660", TAG+="uaccess"

And that resolved the issue. Input works and FFB works.

I'm not sure how to proceed from here though. Clearly steam is shipping device specific udev configuration for devices they support, so how do we get on the list?

EDIT: Here's a somewhat concise explanation of what uaccess is used for from the archwiki in case anyone finds that useful.

[Kimplul]

Nice work! Interestingly I don't have 70-steam-input.rules, not really sure why not. Not really sure where that file comes from anyhow, searching for it on GitHub doesn't give any results. Moreover, I would've assumed if the issue was with uaccess that more than just Proton would refuse to acknowledge the wheel, but apparently I might've misunderstood something.

@irseny Does adding the udev rule work for you?

In any case, for now I can add a section to the README about this. Might be a good idea to figure out where 70-steam-input.rules comes from and see if we can send in a patch or something.

[kevenwyld]

70-steam-input.rules is owned by the steam package in arch. The OP of this issue said they were using debian 11.5 though so things may be different there. And this might not even be the same issue as I have. Weirdly coincident timing though...

] > pacman -Qo /usr/lib/udev/rules.d/70-steam-input.rules
/usr/lib/udev/rules.d/70-steam-input.rules is owned by steam 1.0.0.75-1

The file comes from the upstream tar.gz provided by valve but the PKGBUILD renames it for some reason from 60- to 70-:
https://github.com/archlinux/svntogit-community/blob/packages/steam/trunk/PKGBUILD#L57 . Do you have 60-steam-input.rules? Or any rules files provided by the steam package on Debian?

FWIW I did notice that oversteer provides some rules for devices they support. This makes me think of two things:

• Does having oversteer installed resolve this issue as well?
  • I tested this and it doesn't seem to make a difference (the udev rule above is still necessary to have any input in game) though I'm a bit unsure why since the two rules files seem to do nearly the same thing
• It would probably be OK to include your own rules file in this project if you wanted to that sets up uaccess for wheels this driver supports, but since this weirdly only impacts a really small number of people (1 or maybe 2) I think the readme is a great place for it.

As always thanks for all your help with this! I really appreciate all the work you have put into this project. And sorry for hijacking this issue since my problem might turn out to be totally different than OPs...

[berarma]

The file 70-steam-input.rules is in the package steam-devices for Debian.

The proposed solution would fix a permissions issue. I'm wondering if that's the original issue because OP says it stopped working. I don't get why would he need that rule now and not before. Also, it wouldn't affect only Proton, it would make the device not accessible from any application, including Oversteer.

In my system, I have access to the wheel because I'm in the input group and all input devices are by default owned by this group.

The steam file adds the tag uaccess that I think will grant access to the user in the current seat.

We could add this rule into Oversteer or even in our drivers, but why should we add it when distros (at least current Debian stable) don't? Even supported wheels as the Logitech ones don't have rules shipped with the distros and they have always worked.

I think we're in the midst of a transition in the use of systemd. But should we let distros handle the transition or do we start using this rule in case distros don't get it right at first? I think HID devices should be granted permissions by default, there are too many devices to make rules for all them one by one.

There's a request for documentation here: systemd/systemd#4288.

[irseny]

For example I have some Heusinkveld Ultimate+ pedals which previously required protopedal to work due to a limitation in proton which required all controllers to have at least 4 axis and 1 button. They are now detected in all the games I've tried

I can confirm that

So I created a new file /etc/udev/rules.d/99-thrustmaster.rules with the contents:

KERNEL=="hidraw*", ATTRS{idVendor}=="044f", ATTRS{idProduct}=="b66e", MODE="0660", TAG+="uaccess"

And that resolved the issue. Input works and FFB works.

Youre welcome. I am grateful this solved the issue for you. I did already have rules in place to give me rw access to the files. Tried it anyway but the proposed fix does not apply to my situation. The package steam-devices conflicts with steam-launcher and it probably has the same contents in 70-steam-input.rules as well so I skipped this hint for the time being. Still occupied with other stuff

I think HID devices should be granted permissions by default, there are too many devices to make rules for all them one by one.

Wouldn't an FFB upload result in a write to the device which would fail if it was not writable? (Maybe that's not done from user space so I might be wrong here.) If so there would be a mismatch between reported and actually supported/permitted capabilities. There is a chance applications do not properly handle such cases. At least for FFB capable devices it would not hurt to include the extra rules.

[irseny]

For testing this and a few other issues I did a reinstall of my system. Without hid-tmff2 the wheel detection seems fine. Playing around with runtimes broke the detection of my pedals again sustainably. Unfortunately it did not make a difference for the wheel. So back to protopedal.

Shameless plug

I added the aforementioned button and force feedback features to protopedal. It works on an acceptable level but I noticed maybe 10-30ms more input lag. That will require a bit more tuning (if it can ever be made unnoticable).

[fuzunspm]

I added the aforementioned button and force feedback features to protopedal. It works on an acceptable level but I noticed maybe 10-30ms more input lag. That will require a bit more tuning (if it can ever be made unnoticable).

you can modify protopedal.c and change usleep(1000) to 10 or 5

[fuzunspm]

you can modify protopedal.c and change usleep(1000) to 10 or 5

Thanks for letting me know again ;) I just replaced usleep() entirely for the next release.

Anyway I had some time to test and improve the workaround and so far it circumvents my original problem. @Kimplul Since I do not require another solution I would not mind to have this issue closed.

I didn't realize you were the protopedal maintainer :) BTW, i see that you released v2.0, should i update it? my current config would work without any editing?

[irseny]

@fuzunspm The main feature of 2.0 is force feedback. TBH it is a bit odd to get into details about my own stuff on a foreign project page. But since you asked: If 1.0 serves your needs the update is probably not worth it. I kept the earlier parameters but there is at least one detail where 100% compatibility was not feasible.

[yacinbm]

Hey, just thought I would chime in. I'm having a similar issue with my Steam Deck, where I can't get my T300RS to respond to any input. It seems like just as described earlier, my issue is caused by Proton. I installed Assetto Corsa with Proton GE-7-20, and upon running protontricks -c "wine control joy.cpl" 244210, the wheel is listed, but none of my inputs are recognized in the applet.

The interesting part is that, when running from Proton GE-7-20's wine binary, the wheel functions perfectly! (To do this, run <Your Steam Install Path>/compatibility.d/<Your Proton Version>/files/bin/wine control joy.cpl. I tried adding the udev rule described earlier by @kevenwyld, but it didn't change my issue. The wheel works as intended in Linux applications, such as oversteer and fftest. I also managed to get it working with AC with Proton 5.0-10.

If you guys have any idea as to what I could try next, or if you want me to post more logs, let me know!

[irseny]

@yacinbm
Running just wine control joy.cpl itself does at least not prepare the environment as proton / protontricks do, including the wine prefix and steam input.
Additionally some games expect the wheel to be the first controller, so it might not be possible to receive FFB depending on where/when the steam controller is added.
I have a Steam Deck available and will be able to play around with it somewhere within the next days. What do I need to install on the deck in order to compile tmff2?

[yacinbm]

@irseny
Hi, I don't think there were any extra steps to nstalling the hid-tmff2 driver on the Deck, except for disabling the read only file system (set a sudo password and run sudo steamos-readonly disable). Afterwards, I recommend you install the driver using dkms (see the tmff2 README), as compiling the driver from source requires you to install kernel drivers and multiple dependencies that aren't present by default on your deck.

Once installed, you can confirm the wheel is working by installing oversteer from the AUR (using yay for instance). If you need any pointers, let me know!

[yacinbm]

Ok some more findings! When using Proton 7, running protontricks -v -c "wine control" inputs would not showup in the applet. That being said, by checking the verbose logs, I saw that bubblewrap was being used by Steam Runtime.

I tried disabling it with the --no-bwrap proton tricks argument, and the wheel inputs are now being detected in control. Not too sure what this means, but thought I'd share my finding.

Now, I just need to find how to disable bubblewrap in my steam launch command, and I think I should be good.

[irseny]

@yacinbm
Thank you for reporting your findings. I have not come far yet on my steam deck because I fried the system prior to any tests. Though disabling the runtime with the method you linked above does make the wheel appear again on my main machine without any additional tools.