DiRT Rally 2.0 (690790)

[xpander69]

Compatibility Report

• Game: DiRT Rally 2.0
• App ID: 690790

System Information

• GPU: GTX 1080 Ti

• Driver version: nvidia 418.43

• Kernel version: 4.20

• System info: https://pastebin.com/wHH2qhNY

• Proton version: 3.16-7 Beta

• Proton log: <!-- steam-690790.log

• Problem: Force Feedback doesn't work with the Logitech G920 Wheel
  With wine-staging 4.2 Force Feedback works fine.

[nyanloutre]

Is there currently a way to use wine 4.2 with Proton ?

I found https://github.com/kakra/wine-proton but it doesn't seem to work with Dirt Rally 2.0

This issue aside, the game is working well for me with a GTX 1070

EDIT: I am running wine 4.2 staging and wine for Windows as a workaround. force feedback is working well.

[leillo1975]

In addition to the absence of feedback I notice that my G29 steering wheel has a delay in movement. I don't know if this can be configured in game. Is important to say that my wheel is not detected as predefined G29 and is necessary to assign the bottons and axis. Do you have the same problem?

[nyanloutre]

@leillo1975 how much of a delay do you have ?

[leillo1975]

split-second.... but enough to appreciate it on screen, and of course driving worse . Compared to DIRT Rally 1 it is very noticeable

[gotzl]

For me, the game runs fine with wine-4.2 and Windows-Steam, apart from occasional sound issues.
I've also build a local proton with this this version of wine, but FFB does not work with that.
Can it be that some patch included in proton breaks FFB?

[xpander69]

Yeah i think some of the proton Contoller patches might do this... Not 100% sure but few unity (the Forest and Lacuna Passage for example) games also have issues with mouse dragging into bottom of the screen, while working perfectly fine with controller or using wine-staging they work fine with keyboard/mouse also. So i think there are some controller hacks in proton that might break other things

[gotzl]

I've dumped the dinput winedebug, maybe s.o. is able to find s.t. in there.
The log with proton-3.16-8 Beta where FFB is not working is here.
The log with wine-4.1 where FFB is working is here.

My input-setup is a Logitech Driving Force GT wheel and Fanatac CSL pedals (split from the wheel).
The dumps correspond to the early startup of the game. In case of wine-4.1, one recognizes a short application of force at some point, which indicates that the FFB of the wheel gets somehow initiated. This doesn't happen with proton.

[xpander69]

No go with proton 4.2 for me either and no go with custom proton-tkg 4.4.r8 either. Something with native steam client killing the FFB? as the FFB works fine with regular wine 4.1 to 4.4

[nyanloutre]

Wine and steam-windows are causing frequent crash for me (full system freeze with audio looping). It never happens with Steam and Proton 4.2.

[nyanloutre]

I might have an idea by changing this file

In dlls/dinput/dinput_main.c there is a dinput_devices struct and each element is a type of device. The patch above is adding SDL support and a new type of device, but it is inserted at the top of the struct (and is used first when entering the EnumDevices loop). So if it's moved to the bottom, find_joydevs (the one working included in joystick_linuxinput_device) will be used instead of find_sdldevs (the one not working from the SDL Proton patch included in joystick_sdl_device)

Also this is a complete guess that I didn't test, but if someone want to give it a try here is my Proton fork with the patch applied

But this may be an ugly fix, the SDL/dinput compatibility layer is missing something (the force feedback should work), but my knowledge in the SDL library is limited so I wouldn't know what to look for in the patch.

[nyanloutre]

Even by disable the SDL patch completely Force Feedback is not working, but the wheel is detected more correctly (button pictures in menu are accurate)

[tipe84]

I was able to get Dirt 2.0 to recognize my G27 wheel correctly using proton-tkg 4.4.r9. Earlier builds that I tried didn’t work and after the next proton update (in early April) it stopped working. I have been using that build and updating only dxvk. If the game recognizes the wheel correctly all I had to do is replug my wheel in the game and force feedback works.

When the wheel is recognized as "Logitech® G27" force feedback will work. If it is recognized as "G27 Racing Wheel" it will not work.

[NekoNoor]

not sure if this is what the disable sdl patch does, but the /dev/input/event* device for wheels is the only one that supports force feedback, so if proton only detects the /dev/input/js* device somehow, force feedback won't work

[nyanloutre]

@NekoNoor no for this I still needed to disable the js device using the wine controller panel (also needed when using steam in wine without Proton)

[NekoNoor]

I saw this in the patch notes of a recent steam client update:

• Added support for rumble pass-through for virtual controllers. This fixes missing rumble support for any controllers opted into Steam Input, and rumble emulation support for the Steam controller.

I was hoping this would fix this issue but it still seems to be present in proton 4.2-7 with the latest client

[NekoNoor]

I got it to work! using proton-tkg 4.11r6 with sdl support disabled in the config when compiling. then disabling the js joystick in wine control and when the wheel is recognized as "Logitech® G29" I replug in my wheel and force feedback fully works

[leillo1975]

with proton 4.11-1 the game seems to detect my wheel (@Logitech G29) correctly (I can see the button icons correctly), but Force Feedback continues without work
steam-690790.log

I think that if with Wine 4.10, the FFB works, with Proton 4.11-1 would be the same...

[NekoNoor]

i tried using proton 4.11 and force feedback doesn't work and replugging makes the input not work so i can't test force feedback after replugging

[nyanloutre]

I recently tried with wine 4.13 and the force feedback didn't work either. Tried with stable 4.0.1 and it worked (but got a crash after an hour of playing)

[jdinalt]

I have identified the source of the problem and have a patch for making FFB work on the G29

You can find my debug notes here, which includes instructions for applying the patch:
https://gist.github.com/jdinalt/278d752ab3c898090b109b2297d82379

The actual patch is here:
https://gist.github.com/jdinalt/0616d7b4c4f509a443e85ecee201e12f

[xpander69]

@jdinalt Thank you for this amazing work, but sadly it doesnt seem to work for me with a G920. Patched the SDL2 with it, tried steam-runtime and steam-native, LD_PRELOADed the correct SDL .so file, but still no go for me. FFB works fine with wine-staging 4.11 to 4.14 with the windows steam client for me though, so i dunno how the SDL patch could change things for proton really.

Maybe you have more information to share about it?

[jdinalt]

@xpander69 Thanks for the feedback.

The G920 is nearly identical to the G29 and is handled by the same Linux kernel driver. While it is possible that the issue is G920 specific, it is more likely that there is some other difference.

I have updated the debug notes to include information on how to use my SDL tracing patch for diagnostics, as well as having written a bit more background on the situation with Proton/Wine/Raw HID, as the latter may be relevant to your question.

https://gist.github.com/jdinalt/278d752ab3c898090b109b2297d82379

The gist of the situation is that Proton has been patched to use the native SDL2 library for its direct input calls.

See: https://git.froggi.es/tkg/PKGBUILDS/blob/2b563056f83e555bef56616a9a48578b1ea0758c/wine-tkg-git/wine-tkg-patches/proton-sdl-joy.patch

[xpander69]

@jdinalt Thanks for this. I verified everything. Followed your guide with the symlinking, verified the file is correctly symlinked and so on. Still doesnn't work for me. AFAIK G920 is the only wheel that supports every Force, not only the Constant Force. Might be theres some other bugs then. Doesn't really help that recent kernels regressed G920 driver ( https://bugzilla.kernel.org/show_bug.cgi?id=204191 ) so i have to switch back to 4.19 LTS kernel in order for it to work at all. Didn't have time to test your diagnostics patch yet, need some more time for it. But seems G920 and G29 are quite different enough to make a difference with this.

[jdinalt]

Interesting...
The G29 and G920 do not have much in the way of technical differences, but they are not using the same kernel driver.

Tracing the path from ff_input_upload(), which is shared, as it is part of the common FFB framework.
https://elixir.bootlin.com/linux/v4.18/source/drivers/input/ff-core.c#L104

Eventually, it hand the request off to the hardware specific code at this line:
165: ret = ff->upload(dev, effect, old);

The G29 driver delegates this call to a generic "memless" entry implementation:

477: static int ml_ff_upload(struct input_dev *dev,
struct ff_effect *effect, struct ff_effect *old)

https://elixir.bootlin.com/linux/v4.18/source/drivers/input/ff-memless.c#L477

This defers the actual work, using a timer, and this eventually leads to the following being called:
https://elixir.bootlin.com/linux/v4.18/source/drivers/input/ff-memless.c#L402

410: ml->play_effect(ml->dev, ml->private, &effect);

This call enters the lg4ff driver at:
402: static int lg4ff_play(struct input_dev *dev, void *data, struct ff_effect *effect)
https://elixir.bootlin.com/linux/v4.18/source/drivers/hid/hid-lg4ff.c#L412

The driver then generates a 7-byte RAP message and sends it to the device.

Contrast this with the code path for the G920. It still starts with the generic code path:
ff-core.c:165: ret = ff->upload(dev, effect, old);

But this is dispatched directly to the logitech-hidpp driver here:
static int hidpp_ff_upload_effect(struct input_dev *dev, struct ff_effect *effect, struct ff_effect *old)
https://elixir.bootlin.com/linux/v4.18/source/drivers/hid/hid-logitech-hidpp.c#L1611

This code generates the longer 20-byte FAP message, which is the newer of the two protocols.
For HID protocol background, see:
https://elixir.bootlin.com/linux/v4.18/source/drivers/hid/hid-logitech-hidpp.c#L76

This is a completely different codepath, driver, and HID protocol.

I have not been able to find much in the way of documentation on either of these wheels from Logitech, but devices supporting 20-byte FAP messages also support 7-byte RAP messages. It may be possible to just change the driver binding to the other driver -- this would require a few minor code changes.

In any case, please get a sample with SDL2 tracing enabled. It is pretty well instrumented and should provide clues as to what is going wrong with the other driver. From there, it is possible that there may be a quick fix for it.

[leillo1975]

Like you say @jdinalt , @Logitech G29 and G920 use two different drivers. Take a look to this post in GOL:
https://www.gamingonlinux.com/articles/pylinuxwheel-and-oversteer-two-open-source-tools-for-managing-steering-wheels-on-linux.14796/comment_id=162306

There was a project, ff-memless-next, to add this effects to the driver on G29, G27 or DFGT. In this Project was involved Simon Wood, the same person that include the ffb support for logitech wheels in kernel, and one of the original devs of the Simracing Open Source game Speed Dreams . This Project seems to be neglected unfortunately :
https://lkml.org/lkml/2014/4/26/115
I hope in a close future someone will retake it and finish this work.

I don't know if this project by Edwin ( @edwin-v ) is the same project or another different thing:

https://github.com/edwin-v/linux-hid-lg4ff-next

[jdinalt]

Thanks for the background and links. This could be a fun project to work on and the current driver could definitely use work. I'll take a look at the details when I'm home from work... assuming I'm up to it -- I work on Linux kernel stuff for a living, so I'm not always up to working on more of it after work :-P

If you know of any more resources, let me know.

[leillo1975]

Perhaps this another "last effort" from edwin in a Steam Group:

https://steamcommunity.com/groups/linuxff/discussions/0/405692224235574471/

I think that this dev and Simon Wood (@mungewell) could give a lot of information about this. I also think that @ValveSoftware could help to support this type of controllers, because for example, Thrustmaster users have hardly any support ( https://github.com/her001/tmdrv ) .

I don't know if it will be useful, but this user, @simon50keda , managed to activate Feedback in Euro Truck Simulator 2 on Logitech steering wheels. I don't know if the code will be useful:
https://forum.scssoft.com/viewtopic.php?f=109&t=249622

I'm sorry I can't give you more information. I'm just a user, I don't have programming experience.

[Zuikkis]

Oh, that is odd. I have a different wheel, though. But for me, when I plug it in during game, game notices it and says "new steering device added" and after that it appears correctly in the config. And also it remembers the settings for it.

Hmm, I did the cert trick described in Protondb to get multiplayer working. Maybe I'll try removing that, if it fixes the startup crash. I'm mostly playing single player too.

[Samsagax]

Just tested this game with Proton 5.13-6 and it works out of the box.
Proton Experimental doesn't work even disabling futex2. It won't launch.

[Samsagax]

New Proton 6.3 will work but won't connect with error "Server unavailable". But then Proton Experimental works with online login and all (thanks for online single player).

[kisak-valve]

Hello @Samsagax, just to confirm, Proton 5.13-6 and Experimental currently work as expected and Proton 6.3-2 has a regression?

Please add PROTON_LOG=1 %command% to the game's launch options, reproduce the regression, and attach the generated $HOME/steam-$APPID.log to this issue report as a file. (Proton logs compress well if needed.) Also, please copy your system information from Steam (Steam -> Help -> System Information) and put it in a gist, then include a link to the gist in this issue report.

[Samsagax]

Hello @Samsagax, just to confirm, Proton 5.13-6 and Experimental currently work as expected and Proton 6.3-2 has a regression?

Please add PROTON_LOG=1 %command% to the game's launch options, reproduce the regression, and attach the generated $HOME/steam-$APPID.log to this issue report as a file. (Proton logs compress well if needed.) Also, please copy your system information from Steam (Steam -> Help -> System Information) and put it in a gist, then include a link to the gist in this issue report.

I could not reproduce the error, but here are the steam logs for the three cases if it's of any help. Maybe the error only appears when first logging in? Or maybe it was the server really not being available but is really annoying as I tested a few times with the same result and when changed proton versions it suddenly worked.
Anyway, disregard the report if it's not helpful.

steam-690790.6.3.log
steam-690790.experimental.log
steam-690790.5.13.log

[writequit]

Anyone having wheel issues since the recent update? I have a G29 and it worked perfectly since I bought the game in December.

With proton 7 the wheel works but there is no FFB, I also can't play career or the dailies etc as is there is it can't talk to the server.

With proton 6.3 the wheel is not detected at all but comms with the server seem ok.

I'm using the new-lg4f driver. The wheel works normally in ATS native version. In wreckfest the wheel works normally using proton 6.3 but no FFB under proton 7. Same with mudrunner, FFB only with proton 6.3.

Also steam seems to have decided I have an xbox 360 controller, I've never had a game controller.

Not sure if this is a steam or proton issue...

[kevenwyld]

@writequit yes I'm having issues as well with my thrustmaster t300 wheel and some other devices (arduino handbrake) not being detected in proton 7.x and experimental. Also online content is broken as well in 7.x. Someone commented on protondb too: https://www.protondb.com/app/690790 .

[kisak-valve]

Hello @writequit, @kevenwyld, can you share the information requested at #245 (comment) (adjusted for this game's appid)?

[kevenwyld]

@kisak-valve sure, here's a launch using proton experimental with all my devices listed below connected via USB:

ThrustMaster, Inc. Thrustmaster T300RS Racing wheel, using the hid-tmff2 driver (https://github.com/Kimplul/hid-tmff2)
ThrustMaster, Inc. T500 RS Gear Shift
Arduino SA HAND BRAKE (some cheapo thing from ebay)

File:
steam-690790.log.tar.gz

Thanks!

EDIT: In this case none of the devices appear available in game, only the keyboard is preset as a control device.

EDIT2: Also the online features of the game do not work, for example clicking on "Events" produces this error:

Text copied here so that people can search:

CONNECTION FAILED
The server is not available. Please try again later.
Error Code: 3fa463f5d4b51e7-9000d351-3c-58

[writequit]

I'm getting that same server error on 7.0. I also have an Arduino device which is just 3 switches for ATS range/splitter/jake but proton has never detected it afaict and disconnecting it first makes no difference.
Logs:
steam-690790-7.0-1.log.zip
steam-690790-6.3-8.log.zip

[writequit]

Ok, now everything to do with the wheel is working on both 6.3 and 7.0. I still have the network issue in this game in 7.0.

Not sure what to conclude as I had to re-install the OS and restore data from backups so I don't know if Proton or steam got an update or if there was some problem on my side.

Let me know if logs would be useful.

[Samsagax]

Just tested with proton 7.0-1 and back to 6.3-8 and the game shows the network error in 7.0-1 and not in 6.3-8. Both test were made with clean prefixes.

[Nisse43]

With proton experimental I have to reconnect my wheel G29 to get force feedback and pedals working(wrong inversion or something).
In proton experimental there is also a new stiffness or break on the wheal making it more heavy to turn that was not there in 6.3. I can not tell if that is a feature or not since I have not tried dirt 2 on windows

Worked really well on 6.3

I am using the new-lg4ff driver and arch linux on latest kernel

[gotzl]

I've found a workaround to get FFB with proton 7.0-1 (here with a Fanatec CSL Elite)

protontricks -c "wine reg add 'HKLM\System\CurrentControlSet\Services\winebus' /v DisableHidraw /t REG_DWORD /d 0x1" 690790

This works also with other games (I also tested ACC and Automobilista) and should work for other wheels as well.

Note: I don't know the drawbacks of this setting ... One should definitely remember doing it to undo it at some point ...

protontricks -c "wine reg delete  'HKLM\System\CurrentControlSet\Services\winebus' /v DisableHidraw /f" 690790

And another side note: I always select "Disable Steam Input" in steams Controller config for games where I want to use the wheel ...

[writequit]

Nice, can confirm this works with a G29 and enables FFB for Wreckfest and also for ATS under proton 7.

[zuavra]

Online play not working under any version of Proton 7, even with the CodeMasters certificate added.

[writequit]

Online is working again in Proton experimental. Still need the protontricks registry setting to get FFB on the G29.

[andrebrait]

I can confirm career/online play/events work fine on both 6.3-8 and Experimental, but not on 7.0-1. Unfortunately, 7.0-1 is what Steam uses by default, at least on the Deck.

[Samsagax]

I confirm online works with proton 7.release candidate 7.0-2

[solgzr]

Proton Experimental seems to have a regression compared to 6.3-8. After playing for a while and switching location/stage the GPU utilization jumps to 99% and framerate dips below 20fps, Only restarting the game restores the framerate to playable state. With 6.3-8, I can play with 60fps locked and it stays there regardles of playtime and switching locations. RX 6500 XT, Mesa 22.1, openSUSE Tumbleweed.

System summary

steam-690790.log

[andrebrait]

Replying to #2366 (comment)

@solargazr what about 7.0-2?

[solgzr]

@solargazr what about 7.0-2?

The regression seems to be in 7.0-2 too.

The difference between the 6 and 7 series I noticed was (assuming mangohud reports these things correctly), 6.3 does not free VRAM when switching between stages through main menu. 7.0 and Exp both free VRAM when exiting to menu, but when it gets populated again when loading a new stage, the GPU utilization jumps and performance suffers.

[poVoq]

Steam controller not recognized in 7.04, but seems to be fixed in Proton Next 7.05.

[polluxau]

decided buy this game as its on sale to see how it would work under amd

using latest experimental(bleeding edge), arch linux, mesa 24.0.6, kernel 6.8.9, plasma 6.0.4 under wayland the game will freeze when being launched

also happens under proton9-1, proton-ge-9-4,
steam-690790.log

reading through where it froze it shows this.

builtin
124.527:012c:01f8:err:kerberos:kerberos_LsaApInitializePackage no Kerberos support, expect problems
124.527:012c:01f8:trace:loaddll:free_modref Unloaded module L"C:\windows\system32\Kerberos.dll" : builtin
124.530:012c:01f8:trace:loaddll:build_module Loaded L"C:\windows\system32\netapi32.dll" at 00006FFFFC6F0000: builtin
124.530:012c:01f8:trace:loaddll:build_module Loaded L"C:\windows\system32\MSV1_0.dll" at 00006FFFFC730000: builtin
124.530:012c:01f8:err:ntlm:ntlm_LsaApInitializePackage no NTLM support, expect problems
124.530:012c:01f8:trace:loaddll:free_modref Unloaded module L"C:\windows\system32\MSV1_0.dll" : builtin
124.531:012c:01f8:trace:loaddll:free_modref Unloaded module L"C:\windows\system32\netapi32.dll" : builtin
124.531:012c:01f8:trace:loaddll:build_module Loaded L"C:\windows\system32\schannel.dll" at 00006FFFFC740000: builtin
125.306:012c:01f8:trace:loaddll:build_module Loaded L"C:\windows\system32\cryptnet.dll" at 00006FFFFC710000: builtin

edit: works under proton 8.0-5

[kisak-valve]

Hello @polluxau, can you check if https://gitlab.freedesktop.org/drm/amd/-/issues/3343 is relevant to your system? A quick test would be to reboot into an older kernel and see how the game behaves.

[polluxau]

Hello @polluxau, can you check if https://gitlab.freedesktop.org/drm/amd/-/issues/3343 is relevant to your system? A quick test would be to reboot into an older kernel and see how the game behaves.

i dont think so, i have rebar and 4g decoding both enabled in my bios, but proton 8 seems to be running fine

[polluxau]

Using either Proton 9 or experimental the game is working now, the only issue is my cursor doesn't go away in game and the cursor flickers a little in the menu and in game

The steam overlay takes a while to appear in this game also

The cursor flicker is not a vrr or screen tearing issue so must be something happening in the game or kde is doing something weird with it

EDIT: I actually had feedback problems like with Forza horizon 5 so I needed to throttle it again so the wheel was doing the feedback correctly

I would rlly like to see this get fixed by valve at some point as I didn't know about the tool that solves this problem

No performance issues either or crashing as other users have said in the past atleast on my amd system so far