search

ValveSoftware / Proton

Compatibility tool for Steam Play based on Wine and additional components
Other
23.86k stars 1.04k forks source link

DiRT Rally 2.0 (690790) #2366

Open xpander69 opened 5 years ago

xpander69 commented 5 years ago

Compatibility Report

System Information

nyanloutre commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

@leillo1975 how much of a delay do you have ?

leillo1975 commented 5 years ago

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

gotzl commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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

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

NekoNoor commented 5 years ago

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 commented 5 years ago

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

NekoNoor commented 5 years ago

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

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

NekoNoor commented 5 years ago

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 commented 5 years ago

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

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

NekoNoor commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

@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 commented 5 years ago

@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 commented 5 years ago

@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 commented 5 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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:

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 commented 4 years ago

@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 commented 4 years ago

@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

mungewell commented 4 years ago

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

leillo1975 commented 4 years ago

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!

edwin-v commented 4 years ago

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?

leillo1975 commented 4 years ago

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.

edwin-v commented 4 years ago

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

mungewell commented 4 years ago

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

gotzl commented 4 years ago

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.

leillo1975 commented 4 years ago

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

leillo1975 commented 4 years ago

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)

edwin-v commented 4 years ago

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.

leillo1975 commented 4 years ago

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

edwin-v commented 4 years ago

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.

berarma commented 4 years ago

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.

jdinalt commented 4 years ago

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.

berarma commented 4 years ago

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?

mungewell commented 4 years ago

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

mungewell commented 4 years ago

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

mungewell commented 4 years ago

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 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 commented 4 years ago

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

mungewell commented 4 years ago

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