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.

[potjesoep]

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)

[potjesoep]

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

[potjesoep]

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...

[potjesoep]

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.

[berarma]

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.

Hi.

I've been trying to figure out what's wrong with FFB on Logitech wheels. Take everything I say with a grain of salt since I don't have any technical background on the subject.

It seems that although G29 and G920 are mechanically the same, the former seems to use a memless controller. After some random code reading, I guess this means that the G29 can't run complex effects by itself, while the G920 might be able to save complex effects on internal controller memory to be run later.

This would explain why they use different FFB drivers. It seems Michal Malý did an effort to update the G29 driver to support more complex FFB effects. This effort would have been useful for older Logitech wheels too.

There are other issues that might still not be fixed in the driver that might block these enhancements. Like being able to query the driver for the status of the effects (playing/finished), or managing queue overruns (when the driver receives more effects that it can play or queue).

I've tried to find out why the Michal patches didn't get merged in the kernel. No one has answered.

I have some doubts whether this kind of features should go in a kernel driver or instead go to a user-space API like libSDL. I guess it would be ideal if game devs had a standard multiplatform API to access FFB.

Currently, the issues Wine might be facing is:

• Translating whatever API is used in Windows to Linux device commands.
• Dealing with incomplete/heterogeneous Linux driver device commands.

It seems no one is working or caring about this. The ones who have worked on it or have the knowledge seem not to care or are too busy.

I'd like to get things moving but I don't know how or where to start. I found this wiki from someone trying to create documentation: https://github.com/Eliasvan/Linux-Force-Feedback/wiki

@leillo1975's links are the most important source of information I know, besides the Linux source code.

Maybe if we could get everyone interested together we could gather enough information and attention to get things moving.

Ideas welcomed.

[berarma]

@jdinalt, I have just seen your libSDL patches. Wine might be already doing it right and the problem might lie in the libSDL or Linux drivers domain. The G29 driver doesn't support some effects and libSDL isn't implementing them either.

[mungewell]

@berarma is correct. Although the 920 looks (and is marketed) as similar to G29, it is significantly different internally (wrt code/electronics). It is a much more capable in terms of ForceFeedback.

I haven't done any wheel stuff for a few years, but from memory the G29 kernel driver only implements ConstantForce. The wheel is physically capable of a couple more effects (spring, inertia) but these were not implement in the kernel. Logitech has a document on the capabilities/programming of the wheels. https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/hid/hid-lg4ff.c?h=v5.3-rc8#n431

G27/G29: Effects can be loaded into 4 different slots, plus there is a strength for 'auto-center' spring force.

I believe that the SDL driver asks kernel drivers for capabilities, I am not sure (foggy memory) on whether it emulates the missing effects....

Looks like I played with TestHaptic (in Python, but SDL C code has equivalent) on the G27 (same driver as G29) gives this: https://github.com/marcusva/py-sdl2/issues/62

simon@bigbox:~/PySDL2-0.9.2/examples$ python testhaptic.py
Trying to find haptics
Found 0 : G27 Racing Wheel
Found 1 : Sony Computer Entertainment Wireless Controller
Using device 0
   effect 0 Sine Wave
   effect 1 Triangle
   effect 2 Sawtooth Up
   effect 3 Sawtooth Down
   effect 4 Ramp
   effect 5 Constant Force
   effect 6 Left/Right
      Bug 'leftright' not defined
Now playing effects for 5 seconds each with 1 second delay between
   Playing effect 0
   Playing effect 1
   Playing effect 2
   Playing effect 3
   Playing effect 4
   Playing effect 5
   Playing effect 6

Probably helpful to confirm whether that it still the case for G27, G29, or G920. :-)

If the kernel is loosing/forgetting effects, you need to look at FFMEMLESS to see how it keeps track of the 'fake' effects that it renders via the Wheel's ConstantForce effect.

With even foggier memory - there is/was a way in DirectX to sent a 'pre-scripted' force feedback sequence to a device, rather than adjusting the FFB in real time. "FEdit" rings a few bells, and "Wooden Bridge" effect.... It's possible games are using this sort of thing. https://www.desktopsimulators.com/forum/showthread.php?tid=378 https://lkml.org/lkml/2014/5/21/325

Edit: 'FFE' parser/player written with a very old version of Construct: ffe_parse.zip