Yeah, seems there is some regression between Wine 7.17 and 7.18. Tried it with my own build of Wine-staging 7.18 + patches, and it crashes in the online paddock part. While with Wine 7.17 (from Arch Linux) it works properly. Will have to update and try with Wine 7.18 from Arch.
The utility above looks handy.
This is one of the disadvantages of using a separate wineprefix per game. For this reason, and for easier development, I have installed Steam for Windows in a single wineprefix. Not all games work with standard Wine/Wine-staging though. But after porting some of the needed patches from proton, itās OK. And I can use CrewChief, SimHub, JoyToKey, etc. in one install.
I know this evdev bug, since I reported it about ~8 months ago + a patch to fix it. The sdl backend is default, so it mitigates the problem. But after that backend is disabled, the next is hidraw and then evdev, which crashes while parsing a keyboard report descriptor. The Wine devs probably overlooked the issue, since it doesnāt happen in normal prefixes.
However, they wonāt accept disabling the sdl backend as this is the most compatible solution. IMO what is needed is to reverse the order of running with hidraw first (evdev disabled) and then sdl for compatibility. Itās not trivial to do, though.
May rise the issue again and discuss with them, if time permits.
I tested TrueDrive in Wine 7.18 and it works as expected incl. the online part. Tried searching for profiles, applying profiles, etc., all seems to work properly. So the crash Iām experiencing is not related to Wine (standard). Probably some of the staging patches or my backported proton patches.
@S.R.Lemke, try Wine (standard) if you are using staging. The problem might be in staging. Also make sure it is not running in some kind of sandbox (flatpak, snap, firejail, etc.), that is denying network access. I have the same behavior with TrueDrive on Windows, when I block outgoing network connections with Windows Firewall.
I also tested R3RE with Proton 7/Experimental, and you are right that there is some problem with it. In my case it is crashing when getting into a car. The issue also exists on my custom staging build, so itās most likely the SDL backend, since hidraw works perfectly. Iāll look into that.
With proton6, when I click ādriveā on R3, after some 1/2 seconds I see I quick micro-freeze, but it works normally, when I noticed that I decided to keep a terminal open with a dmesg -w and a kernel crash happens and prints a stacktrace, but with proton6 no problem, game continues to work, with proton7 it crashes, I think it is the same kernel crash, itās just that proton6 can deal with it while proton 7 not.
For the wine / truedrive I did not invest time investigating it, I think internet in the wine/prefix that runs truedrive is fine, but have to dig more.
Yeah, itās a warning for an out of bounds value - 16bit to 8bit in hid-core - which just prints a call stack for easier tracking of the issue, I guess. It is one of the fields (loop_count) of the HID report that starts ffb effect. SDL sends 0xFFFF (16bit) while the HID report requires 8bit - ie. 0xFF. Itās harmless. Eventually they crop it to 8bit and send it that way to the device.
The problem is that thousands such messages are logged per gaming session. I already have a fix for this, which will submit to winehq next week. Hopefully theyāll accept it and then backport to Proton also.
For Proton 7, the issue is somewhere in Wineās SDL backend, since hidraw works and probably evdev as well.
I saw these once, but couldnāt provoke them again. None of the sims with high ffb rate (BeamNG, rF2, AMS2, ACC, etc.) cause such warnings with the Linux PID driver. I think they are related to one of the out of bounds warnings (value 302) caused by Proton 6.3. This warning is not raised when Proton 7 is running.
Thatās the usual raceroom with proton6, like I said, a lot of those I can see on dmesg but the game works normally (I think a small stutter when the kernel crash happens).
Dunno if that would be something to report upstream as my system is quite āspecificā and with workarounds.
Itās not a crash, just a warning with a call trace. The relevant part should be slightly above the first line of the quote. Iāve fixed the issue with Wine/Proton 7ās SDL backend (the 32bit out of bounds issue). There seems to be another issue with Proton 6, something like: value 302 out of 8bit bounds, etc. This probably wonāt be fixed, since itās a legacy version.
Anyway, once they accept a patch that enables the hidraw backend for SC devices, all these issues will disappear. This is also the only way for R3E to work on Proton 7, since the Sector 3 devs set the SC2ās rotation angle programmatically through direct access to the device. So it crashes in hidapi.dll, if there is no such access. (Proton 6 has this enabled by default, while itās dinput implementation relies on SDL - a completely different winebus architecture from Proton/Wine 7.)
Hello!
Do you have the MR of that patch? I would like to follow up and try R3E with Proton7 when that gets merged/accepted/released. Or just update this thread when/if that happens.
Well done for getting it merged!
I also have confirmed already that it works fine(proton experimental -> betas/bleeding edge beta), experimenal proton also got the DXVK2 release which fixes a lot of problems on raceroom, like the quite common shadow glitch.