-
Notifications
You must be signed in to change notification settings - Fork 20
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
No longer detected down to proton 5.13 #54
Comments
Hi, thanks for the report.
Unfortunately I can't see anything resembling what you're describing on my machine. A couple questions:
I don't know, since I don't know what could be causing the issue. |
Hi, thanks for the reply. I am on debian 11.5
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'm on Debian testing, though I doubt it makes a difference.
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.
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.
Maybe? Apparently the wine registry key 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.
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
I'd prefer keeping it open for now, if someone else runs into something similar it might be easier to spot while open. |
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:
My Steam version according to the "About Steam" dialog is In dmesg when the wheel is connected I see:
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. |
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.
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. |
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.
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.
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? |
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.
Unfortunate, thanks for checking.
No, it doesn't.
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 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. |
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. |
Pretty cool, glad to see progress being made.
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. |
Oops, I missed that comment. Thanks.
Yeah you're probably right. I'll see about reporting it on the proton github page for the games I've tested. |
So I fixed it... I noticed that So I created a new file
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. |
Nice work! Interestingly I don't have @irseny Does adding the In any case, for now I can add a section to the README about this. Might be a good idea to figure out where |
The file comes from the upstream tar.gz provided by valve but the PKGBUILD renames it for some reason from FWIW I did notice that oversteer provides some rules for devices they support. This makes me think of two things:
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... |
The file 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 The steam file adds the tag 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. |
I can confirm that
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
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. |
I know we weren't having the same issues but I recently discovered that some changes to
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) |
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 plugI 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 |
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. |
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? |
@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. |
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 The interesting part is that, when running from Proton GE-7-20's wine binary, the wheel functions perfectly! (To do this, run 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! |
@yacinbm |
@irseny Once installed, you can confirm the wheel is working by installing oversteer from the AUR (using |
Ok some more findings! When using Proton 7, running I tried disabling it with the Now, I just need to find how to disable bubblewrap in my steam launch command, and I think I should be good. |
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! |
@yacinbm |
Thanks, needed this on manjaro too. |
Hello,
a few days ago my T300 stopped being available in games running in proton. This seems to suddenly effect all recent proton versions. 5.0-10 is the latest version that works as expected. Wine/Proton has a tool to test available controllers:
![image](https://user-images.githubusercontent.com/17438554/214967920-90a2bc78-2e27-4336-b10a-cae51c68c76f.png)
proton run control
(of course using the same wine prefix and so on)It looks like this:
In newer versions there is an additional middle panel titled "Connected (xinput)"
When the game is started "Thrustmaster T300 RS Racing Wheel" is moved into this panel. Testing the device under the "Test Joystick" tab indicates that no input is detected. The behaviour is reverted back to normal when the game stops.
Weird thing is that my pedals do not see this treatment (maybe it does not qualify as a controller without any buttons?)
Do you see similar effects? Is there something that could be implemented on the driver side to prevent this behaviour?
Other things I have tried:
When the game is running "Thrustmaster T300 RS Racing Wheel" is no longer detected, instead a device titled "xinput" appears. No input is detected from this device.
The same Proton versions worked before, it seems to be a combination of Proton+Steam+Runtime+Wizardry
The text was updated successfully, but these errors were encountered: