No Input with T300RS in Steam Games #100
Comments
|
Hi, thanks for the detailed report. This sounds a lot like #56, unfortunately that one still hasn't really been resolved. Looks like the driver is correctly installed and responds like it should to I would recommend trying out different Proton versions, would be cool if some newer version of Proton fixed things but I wouldn't hold my breath. Unfortunately I just went on holiday and can't really test anything on my end for a bit over a week, but I'd be happy to try and help otherwise.
Whoops, wrong command in the README, good thing you pointed it out. Should be Fixed it in the README. |
|
Thanks for the reply! Do you know how I can test if the windows drivers are working correctly in the proton prefix? |
|
You could check that registry keys associated with Thrustmaster show up, like here: #46 (comment) Though, that's just checking that the driver installed, not necessarily if it is having any effect. Here's a list of some games that seem to benefit from the driver being installed, you could maybe do an A/B test, before vs after installing the driver: #46 (comment) |
|
I had absolutely no luck testing today. I tried Dirt 4 and my wheel didn't show up before or after installing the windows drivers. Or rather, it showed up as an Xbox Controller and none of the input worked. I was unsure before if the driver installed correctly for ACC, but I was able to uninstall it with the installer, so that seemed to work. In #46 (comment) it sounds like both Dirt 4 and ACC should work as well as on Windows. As for Proton versions, I didn't try a lot of different ones today because I was busy getting steam installed correctly and installing a up to date version of protontricks, that didn't have an effect on wheel functionality though. I tried Experimental, 9-0-1, 8-0-5, and Proton-GE 9-7. None of them made a difference for me for ACC or Dirt, maybe I'll try going further back tomorrow. tbh I'm pretty discouraged right now and I feel like there's something more basic wrong apart from individual games. |
That is pretty weird, does not match my experience with DiRT 4. It does have its own problems, mentioned in #38, but no input at all is rather strange.
Really very frustrating having nonworking hardware for mysterious reasons, totally get it.
There have been some reports of Steam itself sometimes being an issue, effectively because of some sandboxing it tries to do in some circumstances, though so far I've only received reports of it happening on the SteamDeck, but it might be a good idea to read #54 (comment) and the rest of the thread. |
|
No good news again, unfortunately. I read through #54 and tried some stuff, but none of it worked for me. I followed yacinbm's experiment of running I tried adding a udev rule for the wheel, but it didn't help. I tried running the protontricks wine control command without the Steam runtime like described here, but the run script didn't generate for me, so I don't know if the Steam runtime is the problem (but it seems pretty likely at this point. like, what else is there?). I tried older proton versions and went as far back as 4.11-13 because I read somewhere that someone had problems starting with 5-something, but nothing. I was using the Steam .deb version from Steam's website and tried using the flatpak instead, but no change. |
|
What does Steam's game controller input menu say about the wheel? Try disabling Steam Input if it isn't already. If that doesn't work, it really does seem like some bug in the Steam runtime. May or may not be related to ValveSoftware/Proton#6674. |
OH. MY GODI mistyped the file name of the udev rule. I had Can I send you a few bucks or gift you a game for your awesome work on the driver and your time? Edit: Okay, I still have problems in ETS2. I can't use the native version, because the graphics are glitchy and I'm getting no input with the proton version, but the game sees the wheel. I have the Windows driver installed and tried disabling Steam Input. |
Hah, good catch. Seems to be a common enough issue that I might add it to the list of common issues. Might also be a good idea to set up some database of which games are expected to work and how well and workarounds, most of the opened issues tend to be about game support these days.
Interesting, ETS2 has showed some other issues before but not missing input completely. I can't remember if I tested ETS2 via Proton or natively, but I believe it might've been natively. I should check that when I get back, it's also been a while since I last played it and I believe it's gotten some updates to how input is handled, could've introduced some new issues.
Assuming ETS2 hasn't soured your mood too badly, I would be happier if you used that money to make a donation to your charity/software project/whatever of choice :) |
Agree. To be specific, I was talking about the udev rule to give read/write access to the wheel #54 (comment):
That's a really good call. I imagine it to be pretty difficult to keep that organized well, but it would be incredibly helpful.
I can live with that, at least I know things are mostly working. The graphical glitching I have in the native version is probably because I'm using the Nvidia 555 beta driver. I'd still love to hear from you when you get around to testing the proton version :)
Will do, thank you SO much for your help and have a great rest of your holiday :) |
roomfullofcommits
changed the title
|
Alright, ETS2 worked fine for me both natively and under Proton 9.0.2. Just a sanity check, you did run the input wizard after selecting the wheel as the input device? |
|
For what it's worth since a lot of these issues seem to be reported by those on SteamDeck, I am now also seeing this behavior after upgrading from Ubuntu 20.04/kernel 5.15 to Ubuntu 24.04/kernel 6.8 (and kernel 6.12). Before upgrading, I had hid-tmff2/0.81 installed through DKMS (though I can't remember when I pulled, so don't know the commit). Now I have hid-tmff2/0.82 (commit a3e70e7) also through dkms. Previously, most proton games I had to run with the Native games work fine, oversteer detects input, but no games running under Proton receive input (but do detect the wheel). The same behavior exists both before and after installing the windows driver in the prefix. Running I didn't want to create a new issue since the behavior I am seeing is (more or less, I don't think there's one that is exactly the same other than this issue) also reported in #119, #118, #114, #112, #106, #54, #90, #138, #61. Other issues outside of this repo are ValveSoftware/Proton#6674, Matoking/protontricks#216, ValveSoftware/Proton#6323. Similar to #114, the wheel no longer seems to re-initialize on reboot (no calibration spinning at least). dmesg output mostly looks fine to me, but there is one line that none of the other reports seem to have: In the linked issues, I'm not seeing much reported about versions of proton, kernel, or OS. This feels like probably a wine/proton issue, but I'm really not sure how to verify that. |
|
Hi @NickChiapputo, thanks for the report. Just to add to your impressive list of references, there's also #132, where we found out that the udev TL:DR; SDL, which Steam/Wine/Proton uses, has a feature where it prefers its own userspace HID drivers for some common devices. To use these drivers, the I somewhat recently added the
Interesting flow, seems pretty annoying. Seems like something that would be worth opening up an issue for :) Wonder if Steam messes with library loading, for example it could come with a 'broken' version of SDL and you running the command manually would load another, 'working' SDL library? Not sure.
Sure, this is fine. I wouldn't have minded a new issue either, but there's value to adding more context to an existing discussion as well.
That's (unfortunately) kind of expected, when the wheel restarts itself it does so very aggressively and kind of breaks the USB protocol while doing so, which causes the USB subsystem to report an error (even though everything is 'fine'). This error, however, seems to vary quite a lot, you can see in https://github.com/Kimplul/hid-tminit/blob/eebcfce75900bb793f32ccd463367c46567eed8d/tminit.c#L152 that a few known error values are checked but every now and then a new one pops up. Might be worth just ignoring the errors outright, but that's not exactly good practice either (what if a real error happens?). |
Yep, I was looking at #132 but didn't see any change with, without, or modifying the udev rules so I didn't include that with my report.
That seems to be it! Ubuntu 24 noble came with 2.30.0 so I removed that and built 2.30.11. That didn't work either, so I went back to 2.0.20 which I (probably) had before the distro upgrade and it works exactly as before! I started making a table to list what versions were working to hopefully help you pin down what versions are happier...but nothing past 2.24.2 works for me (at least in Proton 8.0-5 which is the only version I can get to work with the wheel). It's possible there is something else on my system that is not particularly up to date that interacts poorly with the newer versions. But here's the table anyway:
Thank you for pointing me in the right direction!
It is certainly not ideal and the option to generate that executable is gone in proton 9+, so I have to stay back on 8. I just move the executable to under my user directory and use that as a launcher instead. Fairly painless, fortunately. There is an open issue on this here: ValveSoftware/Proton#6674, but I am not sure how actively anybody is searching for a solution/cause. |
|
Thanks for the list of SDL versions, greatly appreciated. I'm somewhat surprised 2.30.11 doesn't work, either there was some flaw in my testing setup or there's some third, as of yet unknown variable that's different between Ubuntu and Debian. Still, very useful information. I suppose the next step would be to start digging into why the wheel is being treated as if it should be accessed from userspace. I might also go ahead and revert my |
|
I opened up a PR in SDL with what I believe is a fix, seemed to work on my machine at least, let's see what the maintainers think of it. I also separated out the |
I'm on PopOS, trying to run my T300RS in Assetto Corsa Competizione.
I installed the dependencies and then the driver with DKMS, then booted into Windows to update my firmware to v34, I was on v29 before.
I tried it in ACC on pop and I'm pretty sure the game already recognized the wheel at that point and loaded the correct profile. However, none of my buttons and pedals worked and I got no input with the wheel. The wheel also always tried to center itself like it does by default, not sure if that is how it's supposed to behave in menus.
I then tried installing the windows drivers in the proton prefix and I think they installed correctly, but I'm not sure. Is there a way to check that?
After that I had no change in behavior in ACC. I did notice though that in PS4 mode at least my buttons worked, but not my wheel and pedals.
The blacklisting thing didn't work for me, it says
bash: /etc/modprobe.d/hid_thrustmaster.conf: Permission denied.During that whole process I rebooted multiple times and nothing changed.
sudo dmesg -wlogs this:Log
Full log in pastebin
And I feel the effects with
fftest.Let me know I there's more info I can provide, I think in the meantime I'll try using the wheel in other games and see how that goes.
The text was updated successfully, but these errors were encountered: