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.

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?

@leillo1975 how much of a delay do you have ?

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

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?

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

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.

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

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.

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.

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)

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.

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

@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)

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

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

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

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

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)

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

@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?

@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

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

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.

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

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.

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.

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.

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

@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

Also for the G29 double check what the Kernel logs when it is plugged in.
There is a little switch which changes it's behaviour. IIRC one way is a simple wheel, handled by a generic joystick driver and the other way is using 'hid-logitech'....

As I said before I'm just a simple user and I don't have idea in programming, so most of what you say here I don't understand, but I want to take the opportunity to thank you publicly, @mungewell , all the work you have done in favor of free software, especially your contribution to the driver of Logitech steering wheels and the great Open Source simulator "Speed Dreams".

Cheers!

Haven't read the entire thing in detail. But I always assumed that Proton not working with force feedback was caused by them changing the input code is some way. Basic Wine always worked normally (with a few exceptions). Have things gotten problematic with recent versions of Wine?

Hello @edwin-v , welcome to this conversation. In principle, specifically in this game the FFB works well with Wine, but not with Proton. It's strange because many other games work correctly, such as Project Cars 1 or Assetto Corsa Competizione.

At first the conversation was about Dirt Rally 2, but @jdinalt created a patch that managed to make the game work with Proton on the @Logitech G29. Then @xpander69 commented that it didn't work with the G920, and this is because it uses a different and more complete driver.

Then I mentioned that there had been an attempt to implement more effects (spring, damper, friction...), as the G920 has them, and that's where I mentioned you, @edwin-v, and @mungewell.

Out of curiosity, what finally happened to this project to include these effects in the kernel controller? Considering how long it's been, I guess it's abandoned. It would be a great thing to take it up again.

There are lots of car games that work well with Proton and Wine, but don't have FFB, which prevents you from enjoying them 100%. In many of these games this feature is tremendously important as they are simulators. Games like rFactor 2, Automobilista, Project Cars 2, RACE 07 and many more works really well with Wine/Proton, but they have this problem.

Out of curiosity, what finally happened to this project to include these effects in the kernel controller? Considering how long it's been, I guess it's abandoned. It would be a great thing to take it up again.

Long story. The ff-memless-next was a thing when I first poked my nose into the FF corner. This was an attempt to add effect emulation (mainly periodics) and other effects to the FF drivers. This works well in theory, but it has some timing related problems. To account for that, a new system (KLGD) was designed to make everything completely asynchronous and generic. Most of it was implemented (and can be found in the steam group), but not entirely stable. Unfortunately the person that wrote it can't put much time into it for now. I'm also not so sure if the kernel maintainers would be at all open to accepting a system like that in kernel space. The G920 was a bit of a surprise addition because it was wildly different and actually forced an asynchronous approach on the driver. I wrote two versions, one using KLGD and one without. The one without is currently in the kernel.

Interesting is that while quite a bit of work was done to support the functionality, ETS2 and ATS remain the only games I know of that actually use the extra effects. Others calculate everything themselves and only use a single constant force effect.

There are lots of car games that work well with Proton and Wine, but don't have FFB, which prevents you from enjoying them 100%. In many of these games this feature is tremendously important as they are simulators. Games like rFactor 2, Automobilista, Project Cars 2, RACE 07 and many more works really well with Wine/Proton, but they have this problem.

I agree. But last time I checked (which was a while ago), everything worked fine in Wine. Which was not so surprising since the Linux FF API is a complete mirror of the Windows FF API. There is no technical reason why it shouldn't work in default Wine unless something broke along the way. Proton might be different since I have no idea if they changed something critical.

While the FF drivers all have some issues, it shouldn't prevent them from working. I expect you have no problem with native games. Next would be to test plain Wine versions and see where things might have stopped working.

If you have specific questions about how the FF system or Logitch drivers work than I can look into them. I don't have any non-Logitech devices though. If I did, I would have made a driver for them already. ;)

In summary "we" don't really know where the problem lies, I would again suggest falling back to the simplest system and confirm that it works... then progress to test with the full set up.
It appears (from comments here) that Proton uses SDL to drive effects to the wheel - therefore use TestHaptic (C, or Python via PySDL) from SDL to see if it works

Just to add a success story, for me and my LG Driving Force GT, the hack proposed by @jdinalt works. Thanks for that! So this fix at least indicates where the problem lies for the combination of 'standard' logitech drivers and DR2... But in general, it seems to be pretty messed up with different drivers and different games all having their own issues... For instance, FF in PC2 still doesn't work.

In Project Cars 2, the feedback worked before the 2018 October game update. If you downgrade the game the FFB works again.

I agree. But last time I checked (which was a while ago), everything worked fine in Wine. Which was not so surprising since the Linux FF API is a complete mirror of the Windows FF API. There is no technical reason why it shouldn't work in default Wine unless something broke along the way. Proton might be different since I have no idea if they changed something critical.

What Games you test with Wine? Most of the ones I tried are Simracing games. Maybe these games have more complex effects.

This are some issues about FFB with Proton/Wine:
https://github.com/ValveSoftware/Proton/issues/245
https://github.com/ValveSoftware/Proton/issues/246
https://github.com/ValveSoftware/Proton/issues/2728
https://github.com/ValveSoftware/Proton/issues/1212
https://github.com/ValveSoftware/Proton/issues/908 (FFB this game worked in past, broken after game update)
https://github.com/ValveSoftware/Proton/issues/2886 (FFB this game worked in past, broken after game update)

My old tests were the demos for Live For Speed and ETS2 I think. That was Wine 2.x though. Of the other games listed I only own Project Cars 2.

And again, it's essential to know whether it's a Wine or a Proton problem. Curious that the version of PC2 makes a difference. Makes me wonder if Windows changed something along the way.

My old tests were the demos for Live For Speed and ETS2 I think. That was Wine 2.x though. Of the other games listed I only own Project Cars 2.

In the games I listed, I tried it with Wine and Proton with the same results. Only Dirt Rally 2 works with Wine and don't with Proton

And again, it's essential to know whether it's a Wine or a Proton problem. Curious that the version of PC2 makes a difference. Makes me wonder if Windows changed something along the way.

Is not a Windows problem. The change is in the game, through an update. After it the FFB stopped working definitively

If you have any of the older games (I think rFactor has worked for quite while), try older versions of Wine.

With Windows changing something I mean that they introduced a new API that PC2 started using. Could even be something from Logitech. Anyway, PC2 I can test myself and see how/if proton interacts with the FF API. The others I don't have.

Sorry, I answered mainly to @jdinalt comment and unintentionally started an offtopic conversation. In this issues's case it's a problem with Proton it seems.

Anyway, it's good we're talking about the subject since there's not much people with knowledge. There are pieces missing but we aren't even sure which pieces and how important are they.

We know the G29 driver is missing some effects. We don't know whether SDL implements them as a fallback, but since ETS2 and ATS don't have FFB on their native port I'm guessing it's not implemented in SDL either. I've tried the "fftest" but it links to SDL1.2, a bit old. I'll try to compile SDL/testhaptic and test.

The games not working on G29 might be using the extra effects, but we should confirm they work on the G920 or it might be some other problem.

I'd like to gather information and suggestions to improve FFB support on Logitech wheels and maybe others. Testing SDL support and creating issues in the SDL project could be a good first approach. I'd like anyone interested or able to help to collaborate.

Thanks everyone for contributing info.

I think a little background on this may help.

The USB specification defines what are referred to as "Human Interface Devices" and the standard defines a way to discover what the capabilities of a given device are provides an abstraction for communicating with these devices. Steering wheels with FFB are part of the standard and the G29 / G920 are not exceptions.

The idea was that software would not require proprietary drivers to communicate with these devices and that new devices could be supported without having to install any new drivers.

The modern Windows APIs for wheels with FFB, the Linux Kernel APIs for the same, and the SDL2 APIs all more-or-less are directly mapable to the HID abstraction.

https://www.usb.org/hid
https://eleccelerator.com/tutorial-about-usb-hid-report-descriptors/
https://www.usb.org/sites/default/files/hutrr63b_-_haptics_page_redline_0.pdf

Both Windows and Linux provide a "raw" HID API, which allows applications to directly query a devices capabilities and to communicate with it directly, without needing any specialized kernel support for the device.

https://docs.microsoft.com/en-us/windows-hardware/drivers/hid/introduction-to-hid-concepts
https://www.kernel.org/doc/Documentation/hid/hidraw.txt

Traditionally, Wine directly mapped the Windows raw HID APIs to the native Linux kernel raw HID API's. If a Windows game, say DiRT Rally 2.0, were to use these API's, there would be no need for any Linux kernel driver support, assuming that the application was properly written --and I think it is a safe bet to assume that DiRT 2.0 is one of these apps.

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

Proton has patched some of this functionality and it appears to have broken things for DiRT. The Proton patch redirects the Direct Input API's to calls into SDL2, which makes use of "cooked" HID kernel drivers, rather than raw HID drivers.

This would explain why the normal version of Wine actually works properly for DiRT 2.0, with respect to driving wheels.

The patch I provided is essentially a "work-around," rather than a "fix," for what appears to be a bug in the lg4ff driver. A proper fix would involve either a patch to Proton or a patch to the broken kernel driver -- neither of these options are easy for your average user and a quick and dirty work-around patch to SDL2 was more expedient than anything.

A better solution would be to figure out how they have borked up Wine, as to break the raw HID support. If we can get DiRT to talk directly to the hardware, and there is not reason to believe that it does not support this, then we should have feature (and bug) parity with Windows on both the control and FFB front.

There was a question about emulating unsupported effects in the driver or SDL2 and a few mentions of a prior attempt to add this to the Linux kernel.

First, SDL2 makes no attempts to emulate effects. It reports what the device driver says that it can do and just translates the abstract API into the proper kernel calls.

Second, emulating effects is really not a great idea... especially in the kernel. I fully support the call to not include this, as this does not belong in the kernel or even in SDL2 -- if this is to be done at a library level, it should be above SDL2.

Given what I mentioned above about HID, I'm a bit surprised that we even have these specialized drivers in the Linux kernel at all, rather than a more generic HID driver.

Linux supports user-land "cooked" HID drivers. That is to say, a user-space program can publish a "virtual" input device, which can be constructed using raw HID or other "cooked" input devices. At least for development, this would be the most practical place to implement a "driver" for the G29/G920/.

Before acquiring the dedicated H-shifter for my G29, I wrote a quick and dirty H-shifter emulator using this interface. I took a USB numeric key-pad as the data-source and provided a virtual device for shifting -- you can't just use your numeric keypad as-is, unless you like the idea of holding the keys down to stay in gear.

https://gist.github.com/jdinalt/f0ade7e8123d574e7d7c59e2efc9cd65

If I were to eventually create a proper kernel driver, the best way to do this would be to provide a core abstraction, which allows the same code to run in both the kernel and in a user-space server.

Thanks @jdinalt, that's the most comprehensive explanation I've read about the subject. Do you know or anyone else know what DirectInput does on Windows? ETS2 and ATS seem to ignore any device that doesn't support the effects they're using, that's not how it's supposed to work. My guess is that DirectInput implements the missing effects. If we want game developers to have a straight path to port to Linux we should provide something similar.

@mungewell, you mentioned that Logitech has a document on the capabilities/programming of the wheels but you linked to the kernel sources. Can we have access to that document or did you mean the kernel sources as the documentation?

@berarma Roland from Logitech, sent us this link
https://opensource.logitech.com/opensource/index.php/Technical_Information

@jdinalt You are mostly right about HID, however the contents of the HID report really only tells the system how to read the bits of information in the periodic blocks of data that the device sends.
Generally the HID classes don't define the manufacturer protocols which are used to send Force-Feedback information. There is no way that a generalized driver could know that (for example) the LG wheel needs which bytes set for controlling the FF.
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/hid/hid-lg4ff.c?h=v5.3-rc8#n430

Plus many HID descriptors are wrong/broken, or only parse correctly on Windows. There are many examples of the Linux kernel drivers patching (or replacing outright) to get the devices working with the 'standard' HID-Class drivers it uses....

If the games (running under Wine/Proton) are using 'hidraw' then, as you say, the kernel driver will not be used. In fact you might be able to check this with 'lsof' (list of open files) or by blacklisting the kernel driver.

If Wine/Proton are using 'hidraw' then they are presumably relying on FF to be hard coded into the games, or ignoring it completely.

wrt SDL2 - I am not 100% convinced that 'it' does not emulate missing effects. My early comment seems to suggest that 'it' did (at least a few years ago it did). Though 'it' that might have been FFMemless doing the emulation....

PS. which bug in lg4ff.... there are likely many! ;-)

OK I stand corrected, tested today SDL's 'testhaptic' only shows one effect on the G29 and many on G920.

simon@thevoid:~/SDL2-2.0.10/test$ uname -a
Linux thevoid 4.17.0-rc5+ [#11](/issue/ValveSoftware/Proton/11) SMP Sat May 19 11:08:23 MDT 2018 x86_64 x86_64 x86_64 GNU/Linux
simon@thevoid:~/SDL2-2.0.10/test$ ./testhaptic 
INFO: 1 Haptic devices detected.
INFO: Device: Logitech G29 Driving Force Racing Wheel
INFO:    Supported effects [16 effects, 16 playing]:
INFO:       constant
INFO:    Supported capabilities:
INFO:       gain
INFO:       autocenter
INFO: 
Uploading effects
INFO:    effect 0: Constant Force
INFO: 
Now playing effects for 5 seconds each with 1 second delay between
INFO:    Playing effect 0

simon@thevoid:~/SDL2-2.0.10/test$ ./testhaptic 
INFO: 1 Haptic devices detected.
INFO: Device: Logitech G920 Driving Force Racing Wheel
INFO:    Supported effects [63 effects, 63 playing]:
INFO:       constant
INFO:       sine
INFO:       triangle
INFO:       sawtoothup
INFO:       sawtoothdown
INFO:       ramp
INFO:       friction
INFO:       spring
INFO:       damper
INFO:       inertia
INFO:       left/right
INFO:    Supported capabilities:
INFO:       gain
INFO:       autocenter
INFO: 
Uploading effects
INFO:    effect 0: Sine Wave
INFO:    effect 1: Sawtooth Up
INFO:    effect 2: Constant Force
INFO:    effect 3: Condition Spring
INFO:    effect 4: Condition Damper
INFO:    effect 5: Condition Inertia
INFO:    effect 6: Condition Friction
INFO:    effect 7: Ramp
INFO:    effect 8: Left/Right
INFO: 
Now playing effects for 5 seconds each with 1 second delay between
INFO:    Playing effect 0
INFO:    Playing effect 1
INFO:    Playing effect 2
INFO:    Playing effect 3
INFO:    Playing effect 4
INFO:    Playing effect 5
INFO:    Playing effect 6
INFO:    Playing effect 7
INFO:    Playing effect 8

@berarma Roland from Logitech, sent us this link
https://opensource.logitech.com/opensource/index.php/Technical_Information

Thanks @mungewell. This document seems to imply that all the effects (conditional and periodic) are available in all the wheels, even the older ones. It's just that the G920 uses a different protocol.

Am i understanding it correctly? Would these effects work when added to the kernel driver?

@berarma Yes, the lg4ff wheels could support more than just CONSTANT.

However, the upper FF-memless framework is intended to drive 'dumb' devices and would also need to be adjust. FF-memless-2 was going to take some of that work... but that project was abandoned. The main problem is that the wheels support 6 (IIRC) different effects, but can only play 4 of them at any one time.

It would be a really good way for someone to earn their "kernel developer" badge. :-)

@berarma Yes, the lg4ff wheels could support more than just CONSTANT.

However, the upper FF-memless framework is intended to drive 'dumb' devices and would also need to be adjust. FF-memless-2 was going to take some of that work... but that project was abandoned. The main problem is that the wheels support 6 (IIRC) different effects, but can only play 4 of them at any one time.

I thought we were talking amount emulating other effects using the constant force effect. Even if the wheels support 6 different effects, being able to play only 4 at any one time is much better than having just constant force. I think I should read again the source code to ff-memless and ff-memless-next with more detail and maybe I'll understand it a bit better. Anyway, am i missing something obvious here?

I don't understand what you mean by "dumb" devices. Wouldn't it be possible sending a spring force effect to the device just the same way we're sending a constant force effect?

It would be a really good way for someone to earn their "kernel developer" badge. :-)

I don't aspire to become a kernel developer, although it's a great skill to have, sure. But I'd like to have better support for our wheels. I don't have much free time now but I'd like to pave the way for anyone able to do it, or even me sometime in the near future with the help from others that know better than me. :-)

I've been thinking that maybe the people at @FeralInteractive know something about it. They ported a lot of Codemasters games (GRID Autosport, F1 2015, DIRT Rally, F1 2017 and DIRT 4), and all of them with Force Feedback, even with light leds on the wheels. I have no idea which of their developers will take care of this part, but it would be nice to have their help.

@berarma It's even worse. I'm sure I have a modified lg4ff laying around somewhere that supports more. It can't be submitted though because the lg4ff has one fundamental flaw, it's blocking on the USB communication. It's been a while since I worked on it, but I remember ETS2 getting a serious fps hit from all the waiting. So big changes are needed in addition to emulation of the periodic effects.

@leillo1975 The most interesting thing that Feral has is support for some wheels that have no kernel driver. At some point I considered faking a device and see what it was trying to send. But since I don't even have time for other things I need to do, I'll leave that. :) Also, as far as I know all leds are supported already.

I'm almost late for the party :)

Well I would say that feral takes and emulates everything via constant force. That is only logical explanation to me how they got working different wheels, even Fanatec ones!

Also as @leillo1975 mentioned I did port plugin to ETS2 for linux however I using only constant force sending it to the wheels via ioctl and low level linux/input.h structs, in which I see the solution. But maybe my vision is to short sighted as I ain't no kernel dev nor have much experience with input devices yet.

PS: I'm really happy that this topic is being brought up lately as we really need to do sth about proper support of FFB on linux :)

I'm almost late for the party :)

Well I would say that feral takes and emulates everything via constant force. That is only logical explanation to me how they got working different wheels, even Fanatec ones!

I also have this feeling. It would be great if they participated in this conversation.

Also as @leillo1975 mentioned I did port plugin to ETS2 for linux however I using only constant force sending it to the wheels via ioctl and low level linux/input.h structs, in which I see the solution. But maybe my vision is to short sighted as I ain't no kernel dev nor have much experience with input devices yet.

Very interesting, I would like to understand how you convert this effects, but I'm only a user/gamer I don't have idea of programming. A question: Is your ETS2 plugin code Open Source/Public?

PS: I'm really happy that this topic is being brought up lately as we really need to do sth about proper support of FFB on linux :)

Certainly many of us need a decent FFB support on Linux. It would be nice if you all worked together in that direction.

In case anyone with G920 is having issues, there was just/recently a patch posted to the kernel dev list:
https://patchwork.kernel.org/patch/11176765/

Hi again.

I've started a project where we can hopefully help each other work through the issues of FFB on Linux. I'm probably not the most qualified to talk about the subject but I've been spending some time learning about the status of FFB on Linux and I'm willing to spend more time to help those more qualified than me, or even learn from you to get more things done.

I'd like to join everyone interested, specially all of you that have worked on this area. We could greatly benefit from your knowledge and experiences, @mungewell, @edwin-v, @jdinalt, @Eliasvan, @simon50keda, and everyone else. Any user can help by creating FFB reports.

https://github.com/berarma/ffbtools

Very good initiative, I hope people respond and help in whatever way they can. It would be good if @Logitech , @ValveSoftware or even @FeralInteractive could also lend a hand.

Hi again.

I've started a project where we can hopefully help each other work through the issues of FFB on Linux. I'm probably not the most qualified to talk about the subject but I've been spending some time learning about the status of FFB on Linux and I'm willing to spend more time to help those more qualified than me, or even learn from you to get more things done.

I'd like to join everyone interested, specially all of you that have worked on this area. We could greatly benefit from your knowledge and experiences, @mungewell, @edwin-v, @jdinalt, @simon50keda, and everyone else. Any user can help by creating FFB reports.

https://github.com/berarma/ffbtools

Congratulations, @berarma , with your FfbFixUpdate.sh tool, now I have Force Feedback in DIRT Rally 2. I use it with the following Launch Parameter in the settings of the game on Steam:
/home/user/ffbtools/bin/FfbFixUpdate.sh /dev/input/eventX -- %command%
eventX is the event assigned to your wheel. You can know what's your wheel event using ls -la /dev/input/by-id/ and seeing where event is linked.

This solution is more easy to apply than @jdinalt patch, but it's fair to thank him for his work, because this solution is based on it.

You can colaborate with this project sending FFB Logs using FfbLogIoCalls.sh
( /home/user/ffbtools/bin/FfbLogIoCalls.sh /dev/input/eventX /home/user/FFBLog -- %command% )

You can know what's your wheel event using ls -la /dev/input/by-id/ and seeing where event is linked.

That's not needed anymore. You can now use the device entries in /dev/input/by-id/ and the script will resolve the link. Thanks @leillo1975 for the testing.

For me the G920 only shows up as Xbox 360 gamepad in dr2. How do you guys even get the wheel working? Maybe it's a flatpak specific problem again.

Do you used FfbFixUpdate?
can you give your ffb logs with FfbLogIoCalls?
We are very interested in G920 logs

At the moment I'm only interested in getting the wheel to work with or without ffb.

In the control options, in advanced settings, you can change the type of controller to a Wheel. Take a look in this video:
https://youtu.be/twNHoNVN3Qc?t=240 (min 4:00). In video you can read "Tipo de Dispositivo > Volante", in English I suppose that you can see something like "Controller type > Wheel"
The video is in spanish, but you can see where that option is by the position in the menus. A few seconds before, you can see how to find it.

https://imgur.com/a/5wZCp0r

Proton 4.11-7, Steam Input Forced Off. When Steam Input is on only the keyboard shows up. evtest shows everything is working properly:

/dev/input/event22:	Logitech G920 Driving Force Racing Wheel for Xbox One

The device node is available in the flatpak and producing events

flatpak run --command=bash com.valvesoftware.Steam
cat /dev/input/event22

You can use the other @berarma tool, Oversteer, and emulate a G29, G27 or DFGT:
https://github.com/berarma/oversteer

Perhaps following this way, your controller is recogniced as a Wheel

The device doesn't have any alternative modes or any of the files referenced in the code. Applying any changes doesn't seem to do anything.

Can you try to record a FFB log with FfbLogIoCalls?
https://github.com/berarma/ffbtools

You only have to download the release and compile it doing "make"

You can use it on DR2 Steam Launch Properties like here:
/home/user/ffbtools/bin/FfbLogIoCalls.sh /dev/input/eventX /home/user/FFBLog -- %command%

@swick, I guess the wheel is working elsewhere.This is an unrelated issue to this one. I think it would be better to create a new issue with all the information.

@leillo1975

000000000000: > IOCTL: Query force feedback features.
000000000092: < 16, 
000000019720: > IOCTL: Query force feedback features.
000000019739: < 16, 
000000019873: > IOCTL: Query force feedback features.
000000019881: < 16, 

Is the wheel working out of the box for everyone else?

@xpander69 uses a G920 wheel that works with Wine/DXVK. Perhaps you can try it.

@swick I don't know what's wrong, the ffbtools log shows as if your wheel supported no FFB effects. I think running Steam from Flatpak might be the reason your wheel isn't properly detected. It can also interfere with the ffbtools. Please, open an issue at https://github.com/berarma/ffbtools if you want to keep looking for solutions. My bet is that running ffbtools outside of any Flatpak application will probably work. We need reports from G920 users so please consider joining us.

I've updated ffbtools. Look at the docs in the project to see the new simplified syntax. The --update-fix option is what's needed for DR2 on Proton.

Please, understand that ffbtools isn't a proper fix for this or any issue. We should continue debugging and working on a definitive fix. The ffbtools project aims to work on fully understanding the underlying issues so we can propose the right solutions. We need help from anyone that knows about FFB or wants to learn.

Ok finally managed to test this and seems to be working fine, except 1 really odd issue. The RSB Button on my Wheel now lower system sound volume somehow. I used this button for the handbreak in the game and every time i take corners with this it will slowly decrease the sound volume :D bizarre.

command i use to launch with proton 4.11-7: /home/xpander/Build_Projects/ffbtools-master/bin/ffbwrap --update-fix /dev/input/by-id/usb-Logitech_G920_Driving_Force_Racing_Wheel_for_Xbox_One_0000c58d7f6b6a4c-event-joystick -- %command%

Thank you @berarma for this amazing tool!

@xpander69, can you try it without the --update-fix and see if it still confuses the RSB button with the volume key?

Please, subscribe to the ffbtools project since we will need more testing before getting the fixes to where they should be. This isn't a permanent nor convenient solution by any means. Thanks.

so just for reference, the behavior I observed was a kernel driver regression which will be fixed in kernel 5.4 (https://lore.kernel.org/patchwork/cover/1141425/)

@berarma without --update-fix FFB doesn't work and the button acts still same. this is what i see in the steam log when i press that button:

Loaded Config for Local Override Path for App ID 413080, Controller 0: /home/xpander/.local/share/Steam//controller_base/empty.vdf
Controller 0 mapping uses xinput : false
OnFocusWindowChanged to window type: k_nGameIDControllerConfigs_Desktop, AppID 413080
Controller 0 mapping uses xinput : false

edit: i removed the mediakey shortcuts for volume and now it doesnt change the volume (but it brings up the mouse cursor in the game when i press that button)
i also binded some other button combinations to the volume up and down for a workaround for now.

By using /FFBWRAP_PATH/bin/ffbwrap --update-fix /dev/input/event3 -- %command% and disabling Steam Input my G920 is working

@jaspi72 I guess you miss the codemasters certificate. Check this link, couldn't find a resource in english... Also, at your own risk ;) And you might need to adapt the commands to your distro...

Thanks for use my post as tutorial

Today a new driver for Logitech Wheels has been released and enables a lot effects (spring, damper, friction ... and more) than with the driver included in the Kernel. Its creator is @berarma. You can find more information on this reddit post:
https://www.reddit.com/r/linux_gaming/comments/dypf2q/newlg4ff_a_much_more_complete_new_driver_for_our/

Of course you can visit the Project web on github:
https://github.com/berarma/new-lg4ff

With this new driver you also can feel easily Spring and Damper effects.
Take a note that ffbtools with update-fix is also needed

I suspect this is what happens. It seems like the device file handle used to create the effects is closed then reoponed again. The kernel tracks effects ownership by the file handle used, and when the file handle is closed all effects created with it are erased.

Now, why the device file handle is closed? Is it the game or Wine/Proton?

@kisak-valve The sound of this game is stutter, how to fix it?
The discontinuous sound is so annoying.
Proton 4.11-9

Thanks for use my post as tutorial

It doesn't work.

Its working on me so..

Its working on me so..

By the way, how do you resolve the sound stutter issue? It is really unacceptable.

I have found where the issue is, I need to disable the default-sample-format = s32le which I have enabled in /etc/pulse/daemon.conf for pulseaudio

Its working on me so..

I have found a better way from ProtonDB to do it for Manjaro.

1. Download the codemasters.pem.
   https://www.upload.ee/files/9626680/codemasters.pem.html

2. Convert it to crt.
   Run openssl x509 -in codemasters.pem -inform PEM -out codemasters.crt.

3. Run sudo trust anchor --store codemasters.crt.

On Arch you don't even need to convert it.

just copy to:
/etc/ca-certificates/trust-source/anchors
and run:
update-ca-trust

On Arch you don't even need to convert it.

just copy to:
/etc/ca-certificates/trust-source/anchors
and run:
update-ca-trust

What! Why don't they teach us this way? It's much more easy.

On Arch you don't even need to convert it.
just copy to:
/etc/ca-certificates/trust-source/anchors
and run:
update-ca-trust

What! Why don't they teach us this way? It's much more easy.

its too offtopic for this issue, this issue is about forcefeedback not working by default.

but why dont they teach us this way? my reports on proton.db have always had this way. Just that doesn't work in Ubuntu iirc.

edit: ahh no its not about missing ffb only anymore, its generic DR2.0 issue reporting it seems, my bad

Any performance tips? I'm getting frequent stutters even on very low preset. The higher the preset the longer the stutters. I don't think I have a bad hardware.

OS: Linux Mint 19.2 Tina
KERNEL: 5.3.0-24-generic
CPU: Intel Core i7-6700K @ 4.00GHz
GPU: NVIDIA GeForce GTX 1070
GPU DRIVER: NVIDIA 435.21
RAM: 16 GB

Any performance tips? I'm getting frequent stutters even on very low preset. The higher the preset the longer the stutters. I don't think I have a bad hardware.

OS: Linux Mint 19.2 Tina
KERNEL: 5.3.0-24-generic
CPU: Intel Core i7-6700K @ 4.00GHz
GPU: NVIDIA GeForce GTX 1070
GPU DRIVER: NVIDIA 435.21
RAM: 16 GB

I need to enable Vsync to fix it.
I also install gamemode and add gamemoderun %command% for the game.

@laichiaheng I won't check Vsync since I have FreeSync enabled but gamemode helped me, thanks!

P.S. Do you know how to use this mode Steam-wide (without specifying the parameter for each game at a time)?

@laichiaheng I won't check Vsync since I have FreeSync enabled but gamemode helped me, thanks!

P.S. Do you know how to use this mode Steam-wide (without specifying the parameter for each game at a time)?

I don't know, either.
@kisak-valve Is there any way to do that?

With the last version of Proton (4.11-10), the game stills without FFB. It still needs ffbtools with "--update-fix"

Anyone else having issues getting ffb to work on Mint 19.3 Cinnamon with the lg4ff-driver-0.2b? I've tried to use the "ffbwrap -- update-fix" tool at the command line but no joy so I added the command to the game's "Set Launch Options" as described in other posts but nothing happens. I made sure the full path was in the command and used "%command%".
Linux Mint 19.3 Cinnamon
kernel: 5.3.0-26-generic (just updated from 5.0.0 - no change)
Latest version of Steam
Proton 4.2-9
Lsmod shows the new driver is loaded.

Any advice would be appreciated.

I don't understand why this was closed. As listed in my post above, I am using Proton 4.2-9, I followed all the instructions carefully, then suddenly the issue is closed and I'm told to upgrade Proton when I'm already using the latest version? Why?

My apologies for making such a silly mistake on the Proton version numbering. I was elated when I saw this thinking that I only had to switch to the newer (4.11) version of Proton to get things to work. Alas, it still doesn't work. here is the exact text in DR2's "Set Launch Options..." /home/curt/Documents/Logitech_G29_Driver/ffbtools-master/bin/ffbwrap --update-fix /dev/input/by-id/usb-Logitech_G29_Driving_Force_Racing_Wheel-event-joystick -- %command%

I guess the next step is to reinstall Steam.

Ffbwrap still doesn't work on my system, even when using Proton 4.11-12 but it looks like it's a Proton issue. Under Proton 4.2-9 the wheel (G-29) works fine (just no ffb) and all the inputs map and bind properly. Under 4.11-12 the inputs are scrambled and some things are completely not recognized and will not bind. If I try to bind steering, the wheel-to-the-right is recognized but not wheel to the left. Neither throttle nor brake is recognized at all. The "Input" selection in "Advanced Settings" where the wheel tuning parameters are found is grayed out and blank. Very weird.

Digging around more on the internet turned up a Debian package in the repositories called "joystick". This has a command called "ffset" that enables force feedback on a wheel and allows for adjustment of gain and centering force. I installed it and sure enough, it enables force feedback in DR2 even with Proton 4.2-9.

If anyone has a suggestion to try I would appreciate hearing it. It looks like at this point I'll have to start over with Steam if I want to get Proton 4.11 working and get the new wheel driver functional.

Many thanks to berarma for trying to help me out.

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

Hello! The FFB does not work for my G29, but I can't open the link of your patch. Can you help??

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

I read through the debug document and did notice that it refers to replacing SDL2.0-2.0.9.0 with -2.0.10 from the patch. There's already a -2.0.10 in Steam in the path indicated by the notes. I'm running a newer kernel (5.3) and Proton 4.11-12 so I'm not sure if the patch may have been superseded?

Also, I first have to figure out why the G29 doesn't work properly at all with Proton 4.11-12 but does with 4.2-9 as I described in my earlier post. I'm going to attempt a full reinstall of everything but I don't have time to do this right now - maybe in a few days.

UPDATE: Reinstalled everything including the new-lg4ff driver with a fresh copy from Github. Everything now works as advertised with Proton 4.11-12. There are a couple of minor weird things with the wheel such as having to hold the clutch all the way to the floor during playback to get it to play forward but they're not ffb driver related (at least I don't think they are). The ffb elements in the game are really slick! They really add to the experience.

Many thanks to berarma for your gracious and patient assistance to a newbie.

I still got freeze every couple hours of gameplay with Proton 5.0-5
But compared to the last time I reported this issue my system is still usable so I can kill the game properly, still annoying as it will make me loose online races.
Also the audio isn't looping anymore, only the video is freezing.

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

I've found the root cause of this bug (symptoms were no FF effects and lines like err:dinput:effect_SetParameters SDL_HapticUpdateEffect failed: Haptic: Error updating the effect: Invalid argument in logs): it's a kernel bug!

The kernel would flush all FF effects for a device when any FD for the device was closed (could be caused by a call to system(), a fork(), or a dup()/close() of the FD).
I had seen it sporadically with DiRT Rally 2, but it was consistently happening with WRC 7.

The fix is in kernel 5.8 and all the stable kernels (5.6.16, 5.4.44, 4.19.126, 4.14.183, 4.9.226, 4.4.226):
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/input/evdev.c?id=09264098ff153f60866039d60b31d39b66f55a31

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

I've found the root cause of this bug (symptoms were no FF effects and lines like err:dinput:effect_SetParameters SDL_HapticUpdateEffect failed: Haptic: Error updating the effect: Invalid argument in logs): it's a kernel bug!

The kernel would flush all FF effects for a device when any FD for the device was closed (could be caused by a call to system(), a fork(), or a dup()/close() of the FD).
I had seen it sporadically with DiRT Rally 2, but it was consistently happening with WRC 7.

The fix has been accepted in the kernel and is working its way upstream, it should be in 5.8.
https://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git/commit/?h=for-linus&id=09264098ff153f60866039d60b31d39b66f55a31

Awesome! Thank you! I hink this was the last FFB related issue we had pending.

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

I've found the root cause of this bug (symptoms were no FF effects and lines like err:dinput:effect_SetParameters SDL_HapticUpdateEffect failed: Haptic: Error updating the effect: Invalid argument in logs): it's a kernel bug!

The kernel would flush all FF effects for a device when any FD for the device was closed (could be caused by a call to system(), a fork(), or a dup()/close() of the FD).
I had seen it sporadically with DiRT Rally 2, but it was consistently happening with WRC 7.

The fix has been accepted in the kernel and is working its way upstream, it should be in 5.8.
https://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git/commit/?h=for-linus&id=09264098ff153f60866039d60b31d39b66f55a31

Really, really awesome....
I wish there is some way I could patch up my current Kernel. About WRC 7, I see that it is also affected by this problem. In my case the game closes when I plug my wheel.

I just tested the patch with my G920 and can confirm it's working great !
Thanks for the work @mrpippy !

Confirming. this patch applied to kernel 5.6 makes the DR2.0 work with FFB on G920 without the need of the ffbtools. Works great with proton 5.0-6. Thank you @mrpippy

@xpander69 and @nyanloutre , I suppose you compiled the kernel with the patch applied

@xpander69 and @nyanloutre , I suppose you compiled the kernel with the patch applied

yes, thats what i wrote also.

I'm pretty clumsy with those things, what steps did you take? I'm interested in see if this patch solves the problem when I connect the Wheel on WRC7

I'm pretty clumsy with those things, what steps did you take? I'm interested in see if this patch solves the problem when I connect the Wheel on WRC7

Don't own WRC7. Sorry. I just added the patch to the PGKBUILD and compiled the kernel with it. I don't really know how to do that on non-Arch distros though.

I'm pretty clumsy with those things, what steps did you take? I'm interested in see if this patch solves the problem when I connect the Wheel on WRC7

These are the easy steps for Ubuntu:
https://wiki.ubuntu.com/Kernel/BuildYourOwnKernel

Just apply the patch before the build step. You can use the patchcommand with the diff in the commit above.

@leillo1975 I use NixOS and just added this to my config

  boot.kernelPatches = [
    { name = "dirt_rally_2_ffb_fix";
      patch = pkgs.fetchpatch {
        url = "https://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git/patch/?id=09264098ff153f60866039d60b31d39b66f55a31";
        sha256 = "17g7zvn46b9252qk4sqd3j73989lr0hkd86zz4bq1c4dhziy219w";
      };
    }
  ];

@atommaki I also have a G25, just tried it with DiRT Rally 2, 5.0-7, and a fresh prefix and it shows up fine for me. I also get force feedback (with the kernel patch I posted above). Can you post a log with +timestamp,+pid,+tid,+seh,+debugstr,+loaddll,+dinput?

Did you use new-lg4ff?:
https://github.com/berarma/new-lg4ff

It really works well

No, I haven't used new-lg4ff but I want to give it a try

You must do it, it activates a lof of effects that the kernel driver don't use. With this driver a lot of games that don't have FFB support adquire this feature. Games like rFactor2 , Automobilista or RACE 07 works with feedback.
I think this driver must replace the one included in kernel because is much more advanced and complete.

Great news for solution but how i can patch my kernel? Im total newbie in linux and pretty old fart so cant understand too :) Im using kubuntu 20.04. If someone could to this to me clear.. ;)

I just found this solution on reddit and it works copy/paste:

I've also managed to get G29 FFB working in Dirt Rally 2.0, and without patching anything. The following works with or without new-lg4ff (but it's a much better experience with):

The wheel needs to be plugged in when starting steam, unplugged when launching the game, and then plugged back in, but only after getting past the racenet login.

I don't know why that works, but for me this works consistently. It's a mild bit of faff, but so minor it's basically a non-issue.

Has anyone been able to get VR support working with Dirt Rally 2 via Proton? The game starts, I hear sound (e.g. menu music, etc.) but there is no image in the HMD. I've tried many different tweaks and changes to the config files, but I've had zero luck getting the image to display on the HMD.

I'm currently using a Valve Index. Many other VR games work very well via Proton (Boneworks, Pistol Whip, etc.).

@kisak-valve
Can we get an official response for the racenet issue on steam play? (see: https://github.com/ValveSoftware/Proton/issues/3177)

I have seen multiple posts here and on protondb linking to a certificate (see: https://github.com/ValveSoftware/Proton/issues/2366#issuecomment-559925141)

I don't like to install root CA on my machine from random links, it would've been nice to get this directly from codemasters or valve. It's just a certificate, how hard can it be?

@kisak-valve
Can we get an official response for the racenet issue on steam play? (see: #3177)

I have seen multiple posts here and on protondb linking to a certificate (see: [#2366 (comment)](https://github.com/ValveSoftware/Proton/issues/2366#issuecomment-559925141))

I don't like to install root CA on my machine from random links, it would've been nice to get this directly from codemasters or valve. It's just a certificate, how hard can it be?

This has been fixed upstream and should be fixed in the next Proton release.

@kisak-valve
Can we get an official response for the racenet issue on steam play? (see: #3177)
I have seen multiple posts here and on protondb linking to a certificate (see: [#2366 (comment)](https://github.com/ValveSoftware/Proton/issues/2366#issuecomment-559925141))
I don't like to install root CA on my machine from random links, it would've been nice to get this directly from codemasters or valve. It's just a certificate, how hard can it be?

This has been fixed upstream and should be fixed in the next Proton release.

That's great, thanks for the update. Can you point to the commit which fixed this?

https://bugs.winehq.org/show_bug.cgi?id=46726 -> https://source.winehq.org/git/wine.git/?a=commit;h=aa80ef20504660fa55914d40fb4bb296eef94c59

Awesome, thanks for fixing this

Hi I'm getting access violation error since a couple of weeks ago, should I post the logs? seems to me it's a dependency problem because with the steam flatpak version it doesn't happen, this is on Focal Fossa 20.04.1. apparently someone else got the same issue on protondb.com.
also it doesn't matter which version of proton I use.

https://bugs.winehq.org/show_bug.cgi?id=46726 -> https://source.winehq.org/git/wine.git/?a=commit;h=aa80ef20504660fa55914d40fb4bb296eef94c59

@kisak-valve This is blocking a big chunk of the game which otherwise works flawlessly now. Can the patch be pulled in a proton update?

It could be applied on https://github.com/ValveSoftware/Proton/issues/4070

Has anyone been able to get VR support working with Dirt Rally 2 via Proton? The game starts, I hear sound (e.g. menu music, etc.) but there is no image in the HMD. I've tried many different tweaks and changes to the config files, but I've had zero luck getting the image to display on the HMD.

I have the same problem. There are some complaints on forums https://steamcommunity.com/app/690790/discussions/0/1643170903487960968/ that might be related, but no specific information.
And the gameplay actually works OK if I blindly click through menu, it's just menu that's broken.

The game is locking up my system completely when I try to start a rally stage. I'm running Manjaro GNOME, stable branch, with AMD Radeon VII graphics.
steam-690790.log

Hi I'm getting access violation error since a couple of weeks ago, should I post the logs? seems to me it's a dependency problem because with the steam flatpak version it doesn't happen, this is on Focal Fossa 20.04.1. apparently someone else got the same issue on protondb.com.
also it doesn't matter which version of proton I use.

Same issue here, I solved this by using https://github.com/GloriousEggroll/proton-ge-custom/releases/tag/5.9-GE-6-ST

Compatibility Report

Name of the game with compatibility issues: Dirt Rally 2.0
Steam AppID of the game: 690790

System Information

GPU: GeForce GTX 1060 6GB
Driver/LLVM version: 4.6.0 NVIDIA 450.66
Kernel version: GeForce GTX 1060 6GB
Proton version: 5.0-9

I confirm:

that I haven't found an existing compatibility report for this game.
that I have checked whether there are updates for my system available.

Symptoms

Upon quitting from a race to the main menu the game crashes, with an Error Report that states "Access violation at address 0x9f4e4936 in module " + 0x9f4e4936" this address changes with each crash.
##Reproduction
Load any race, attempt to return to the main menu.
This does not occur in Proton 4.2-9, nor in https://github.com/GloriousEggroll/proton-ge-custom/releases/tag/5.9-GE-6-ST

I also can confirm that I solve the access violation using https://github.com/GloriousEggroll/proton-ge-custom/releases/tag/5.9-GE-7-ST.

Thanks for the tip

On Arch you don't even need to convert it.

just copy to:
/etc/ca-certificates/trust-source/anchors
and run:
update-ca-trust

I guess removing it then, is simply deleting the file in /etc/ca-certificates/trust-source/anchors and running update-ca-trust again, right?

https://bugs.winehq.org/show_bug.cgi?id=46726 -> https://source.winehq.org/git/wine.git/?a=commit;h=aa80ef20504660fa55914d40fb4bb296eef94c59

The online play fix should be in Proton 5.13, no need to mess with certificates

Has anyone been able to get VR support working with Dirt Rally 2 via Proton? The game starts, I hear sound (e.g. menu music, etc.) but there is no image in the HMD. I've tried many different tweaks and changes to the config files, but I've had zero luck getting the image to display on the HMD.

I have the same problem. There are some complaints on forums https://steamcommunity.com/app/690790/discussions/0/1643170903487960968/ that might be related, but no specific information.
And the gameplay actually works OK if I blindly click through menu, it's just menu that's broken.

Coming back to this question, has anybody tried VR support in this game recently? Using SteamVR in combination with a Valve Index (either via the Steam Launch Menu or maually by setting '-vr open' in Launch Settings) seems to boot the game in normal, i.e. non-VR, mode.
Using the same hardware and SteamVR version in Windows 10 starts the VR mode as expected.
I suspect the game itself is unable to recognize the connected SteamVR hardware or maybe it is unable to initialize the OpenVR subsystem.

Things which I tried so far:

• replacing the openvr_api.dll shipped by the game with the up-to-date version from the OpenVR Repository (so it matches the current SteamVR version) does not seem to make a difference.
• all previously mentioned fixes which consist of enabling windowed mode or borderless windowed mode do not seem to make a difference either

These tests have been performed on ArchLinux with mesa 20.2.1 (vulkan-radeon), Kernel 5.9.3, SteamVR 1.14.15 and Vanilla Proton 5.13.
Any further ideas for debugging directions are also appreciated ;)

@herrju I also tried VR with a HTC Vive and got the same issue as you, a blank screen and no menu

The access violation crash is fixed for me in 5.13-RC2.

@berarma @mungewell I just bought a G920, but unfortunately, it doesn't work at all with dirt rally 2.0 (It works OOTB with native feral titles like DIRT 4 and F1 2017). the fact is that the steering wheel is not recognized at all and not misrecognized (like say, a keyboard or an alternative xbox gamepad) by this game.

reading the thread i've seen that some people were only lacking FFB, but the wheel at least was recognized. I'm using proton 5.13-2 on (vanilla) ubuntu 20.04. what sort of checks and workarounds should i have to try?

i have G920 and it works perfectly fine in DR2.0 i think you need kernel 5.8 at least, there was a regression with its FFB on older kernels and then Steam was saying its generic Xbox360 controller.

edit: you also need steam --reset after you installed kernel that doesnt have the regression, cause steam stores it as xbox controller for some reason.
maybe someone knows a better way to clean it up ofc.

@dragonfly-lover , you have two options:
FIRST:

Hi again.
I've started a project where we can hopefully help each other work through the issues of FFB on Linux. I'm probably not the most qualified to talk about the subject but I've been spending some time learning about the status of FFB on Linux and I'm willing to spend more time to help those more qualified than me, or even learn from you to get more things done.
I'd like to join everyone interested, specially all of you that have worked on this area. We could greatly benefit from your knowledge and experiences, @mungewell, @edwin-v, @jdinalt, @simon50keda, and everyone else. Any user can help by creating FFB reports.
https://github.com/berarma/ffbtools

Congratulations, @berarma , with your FfbFixUpdate.sh tool, now I have Force Feedback in DIRT Rally 2. I use it with the following Launch Parameter in the settings of the game on Steam:
/home/user/ffbtools/bin/FfbFixUpdate.sh /dev/input/eventX -- %command%
eventX is the event assigned to your wheel. You can know what's your wheel event using ls -la /dev/input/by-id/ and seeing where event is linked.

This solution is more easy to apply than @jdinalt patch, but it's fair to thank him for his work, because this solution is based on it.

You can colaborate with this project sending FFB Logs using FfbLogIoCalls.sh
( /home/user/ffbtools/bin/FfbLogIoCalls.sh /dev/input/eventX /home/user/FFBLog -- %command% )

SECOND:

I just found this solution on reddit and it works copy/paste:

I've also managed to get G29 FFB working in Dirt Rally 2.0, and without patching anything. The following works with or without new-lg4ff (but it's a much better experience with):
The wheel needs to be plugged in when starting steam, unplugged when launching the game, and then plugged back in, but only after getting past the racenet login.
I don't know why that works, but for me this works consistently. It's a mild bit of faff, but so minor it's basically a non-issue.

berarmas tool isnt needed quite some time.. Works out of Box with kernel driver quite some time. Also new-lg4ff is for all wheels prior G920 afaik. G920 has all the stuff in kernel. Its all about the kernel regression with the Hid++ FFB driver, which started with kernel 5.1 iirc, and was finally fixed in 5.8

I'm talking about ffbtools, not new-lg4ff

I'm talking about ffbtools, not new-lg4ff

your second option was with new-lg4ff

thatwhy i jumpled in. Anyway ffbtools are not needed with G920 (at least not for this game). All he needs is to update his kernel and do a steam --reset to get rid of steam detecting it as generic xbox controller.. i think stable 5.4 has the backports of this also, but im nost sure what versions. 5.8 surely has the fix for it. No need for any black magic. Out of box experience with this wheel.

@xpander69 i upgraded to ubuntu 20.10 as you suggested which has kernel 5.8, but still no luck to have the G920 operative under proton. as i mentioned, it's fully working (FFB included) with native games.

Is there something in proton configuration or udev rules or somewhere else i can do to make it work with it? Probably i have a different configuration in respect to other users that prevent me to "see" the wheel under proton.

Can't run previous protons because it crashes at start.

@dragonfly-lover Can you modify the launch option to 'PRESSURE_VESSEL_SHELL=instead %command%', then start the game. Instead of the game you'll get a shell. In that shell, enter 'echo $@'. Take the output but replace the game .exe with 'control', so you get s.t. like .../proton waitforexitandrun control. Double click 'Game Controllers' and check the names in the 'Connected' panel, also check if you device is listed in 'Test Force Feedback'.

My suspicion is that the steam controller config replaced your device with xbox controller or s.t. like that. In this case, your device will have a different name in the above GUI, or it will not have its FFB capabilities and it will not be listed in the FFB panel.
In my case, I had to check all options in 'Steam -> Settings -> Controller -> General Controller Settings', and in the Game Properties I changed the Input Per-Game/BPM to 'Forced Off'. (You may have to restart steam when changing these settings, and you may have to delete the 'SDL_GamepadBind' entry in .steam/steam/config/config.vdf before restarting steam).

@gotzl you are my hero! i just had to set the steam input settings for Dirt rally 2 to "Forced off" and magically i had the wheel and force feedback in proper place. i can't vaguely imaging which is the reason, but that's it!

thank you soooo much!

P.S. the solution covers also F1 2019. wonderful!

I have a Wingman Force GP wheel (in Momo disguise, but that's another story). It works fine in most games I have tried, including force feedback. With new-lg4ff it can do all the "new" style force effects that modern wheels have.

I have blacklisted the wheel in Steam settings. Steam ignores it. Still games find it properly. I guess blacklisting prevents the issue @dragonfly-lover was having?

Back to the subject. :) In Dirt Rally 2.0 the wheel was detected OK, but there was no force feedback. But this trick fixes it for me:

I've also managed to get G29 FFB working in Dirt Rally 2.0, and without patching anything. The following works with or without new-lg4ff (but it's a much better experience with):

The wheel needs to be plugged in when starting steam, unplugged when launching the game, and then plugged back in, but only after getting past the racenet login.

I don't know why that works, but for me this works consistently. It's a mild bit of faff, but so minor it's basically a non-issue.

I actually don't even have to have wheel plugged in when starting Steam. I can start the game without wheel.

This method is very simple for me as the wheel is normally put aside. I just start DR2 and while it's launching, I bring the wheel in place and adjust driving position etc. When DR2 is at main screen, plug USB in and the wheel works perfectly.

I have used Proton versions 5.0 and 5.21-GE. Proton 5.13 usually crashes at the initial "Connecting" screen. Except that maybe 20% of time it works. :) With 5.0 I have had some random crashes when at end of a race, 5.13 and 5.21-GE don't have that.

Another thing, I can't get multichannel audio to work in this game with any Proton version. Winecfg shows windows is configured for 5.1, yet there is sound only on front left+right.

Game doesn't launch since yesterdays proton-experimental update. previous experimental worked fine. 5.13-4 works great also

Log from latest proton-experimental:
steam-690790.log

This thread has been really helpful for me; thank you to all involved.

I have a Logitech Driving Force Pro. It is not detected by Dirt Rally 2.0 at all if I use Proton 5.0-10, and I can't even start the game with Proton 5.13-5, but it is detected with Proton 4.2-9 . Almost everything works, including wheel, pedals, buttons, and shifter. However, there is no force feedback, whether I change the FFB settings in the game to "Device Driver" or "Enabled".

I have installed and loaded hid_logitech_new from https://github.com/berarma/new-lg4ff . I also installed https://github.com/berarma/oversteer , though that didn't seem to help with the FFB problem.

I have tried using ffbwrap (https://github.com/berarma/ffbtools/blob/master/docs/ffbwrap.md) with arguments --update-fix /dev/input/by-id/usb-Logitech_Logitech_Driving_Force_Pro-event-joystick -- %command% and the game starts up fine, but it doesn't make the FFB work.

When I test with bin/ffbplay -d /dev/input/by-id/usb-Logitech_Logitech_Driving_Force_Pro-event-joystick tests/conditional.ffb, I can feel each of the SPRING, DAMPER, and FRICTION effects when I move the wheel with my hand. So all of that seems to be working perfectly. (https://github.com/berarma/ffbtools/blob/master/docs/ffbplay.md)

Any suggestions for getting FFB in DR2 with the Logitech Driving Force Pro?

@TakahashiRyos-ke did you try the simple trick, leave the wheel unconnected until game has started to main menu. Then plug in USB. This is the only way I get working FFB..

Bigger issue for me currently is that the game crashes often at startup, when connecting to server. Proton version doesn't seem to make a difference. Sometimes needs 5 tries to get through.

@Zuikkis Thanks for your response.

1. If I leave it disconnected until I get to main menu, then when I plug it in and it does its spinning calibration, when I go to the options, it does not show it in the device list.
2. If I leave it connected when I start up DR2, then it appears in the device list, but has no FFB. When I disconnected it in the middle of driving, then reconnect it, then it seems totally uncalibrated, acting like all pedals are down, etc. and it's just unusable.

For me, I always get the common error message when it tries to connect online. For now, I'm okay with that, as I'd be content to play in just single player for a long time, though I'd probably like to try online play at some point in the future.

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.

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.

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

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

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

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

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

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.

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.

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

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

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

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

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

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.

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

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

Replying to https://github.com/ValveSoftware/Proton/issues/2366#issuecomment-1140418351

@solargazr what about 7.0-2?

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

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

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

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

EDIT: today there is no problems on either nvidia or amd, my wheel works properly also without needing ffbtools to delay the feedback

Crashes my whole desktop environment on X or wayland, doesn't matter which is used.

In proton experimental, crashes on launch
In proton 8, crashes when loading into a race

kernel 6.12, pop os 22.04, mesa 25.0.5

CPU: 9800X3d
GPU: 6900XT

Crashes my whole desktop environment on X or wayland, doesn't matter which is used.

In proton experimental, crashes on launch In proton 8, crashes when loading into a race

kernel 6.12, pop os 22.04, mesa 25.0.5

CPU: 9800X3d GPU: 6900XT

how long does it take and can you provide a crash log possibly of some kind either it be PROTON_LOG=1 %command% for the launch command, it will make a log in the home folder, or a systemlog by doing journalctl -k -b in your terminal

steam-690790.log
Please see above log from proton experimental

The dirt rally 2.0 logo appears in the middle of the screen. Then it moves half way towards the bottom right corner, my top gnome task bar disappears and the freeze occurs. I waited a little bit and then forcefully turned off my system.

I see a gpu crash in my journalctl logs:
journalctl -k -b -1 | grep amdgpu > amdgpu.log

amdgpu.log

I also see this 3 seconds before the amdgpu crash

May 04 13:51:14 pop-offs kernel: steam[20226]: segfault at 5fd7bac0 ip 000000005fd7bac0 sp 00000000fff3ab3c error 15 likely on CPU 9 (core 1, socket 0)
May 04 13:51:14 pop-offs kernel: Code: 00 00 01 00 00 00 01 00 00 00 01 00 00 00 01 00 00 00 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 71 00 00 00 <30> bb d7 5f 1c 00 00 00 fa 00 00 00 00 00 00 00 00 a8 09 5f 1e 00

I'm having the same problem as ryannathans, if I try to start the game on proton experimental my system crashes. I switched to Proton 9.0-4 and it seems to be working fine. Ubuntu 25.04 with an amd 7900 xt.

on replay mode the steering wheel(g29) input is broken, it will always play in reverse unless the wheel is fully turned to the right (proton 10.0-1-beta)

Same issue as @ryannathans

Gamescope fixes the issue

I've recently re-installed DiRT Rally 2.0 and found it crash on startup. Log file from Proton attached below:

steam-690790.log

This game hangs the entire desktop/machine with Proton versions above 9.0-4 (tested up to Experimental 2025-12-23). Got similar behavior to what others have described (logo appears, desktop hangs, sometimes it recovers whereas others I have to force the machine's power off button... another tty session not possible).

I was able to get some Proton 10 logs: steam-690790.tar.gz

Specs:

• OS: Arch
• Kernel: 6.12.61
• GPU: RX 6700 XT (Mesa 25.2.7)
• CPU: Ryzen 7 5700G (8c/16t)
• DE: Plasma 6.5.3 (wayland)

Hi @kisak-valve ... I'll try to catch something from the system logs... I had to manually kill the game process, that's probably why there is nothing on the Proton logs.

@kisak-valve I was able to dig and discover the problem. So firstly, the issue was just happening on the Plasma Wayland session for Proton versions > 9.0-4 (I had forgotten to test on X11). No issues when I tested on X11, and I was able to check the game's resolution was set to 1080p (my old display device). So I set the resolution to 1440p and retried on the Wayland session, and finally got no issues. I'm not an expert, but this might be an issue with the XWayland window resizing behavior (deadlock, perhaps ?) Any way, sorry for the late response..