Report a non-zero value in dwFFDriverVersion for haptic devices (fixes force feedback effects in WRC8)

[whizse]

Hi,

The first patch fixes one of the issues with the game WRC 8 (tracked in #4567). It seems that the game assumes no force feedback enabled driver is loaded if dwFFDriverVersion is zero, and refuses to enable any force feedback effects. Settings this to a non-zero value enables the effects.

I'm not sure if any game check the actual driver version. If so I assume this needs to be revisited and report a device specific value matching the Windows driver?

The game WRC 9 have the same problem and fix. This game will release on Steam next month. Confirmed the fix with a copy of the game from another store.

---

The second patch removes a seemingly superfluous call to set the DIDC_FORCEFEEDBACK flag a second time. I'm less sure about this one, but the final dwFlags value seems unchanged for the games I tried with and without this change.

[ivyl]

Hey. Thanks for the report and the patches. They look fine to me other than the mixup of spaces and tabs, but that's trivial to fix when applying them.

The tricky part is that WRC8 doesn't work with Proton, so it's hard to test the changes. I see that you have attributed that to winehq#44650 in the other Proton issue and that it is solved by the staging patches. I assume you were testing with GE's Proton? It would be nice if you would mention that's the case in the future, it would spare me some confusion :-)

Sadly the crash here doesn't seem to be related to the gaps between ELF segments. Either this is another problem covered by some other patches or staging solves that by accident - the ELF hole patch alone is not enough to fix this.

On my system the segfault happens on this access:

0114:0118:trace:virtual:virtual_handle_fault addr 0x540090 err 00000000 stack 0x63c030

which is the PAGE_NOACCESS area at the very start of the stack allocation for that thread:

0114:0118:trace:virtual:RtlCreateUserStack commit 0, reserve 0, zero_bits 0, commit_align 0x10000, reserve_align 0x10000, stack 00007FFED36A6680
0114:0118:trace:virtual:NtAllocateVirtualMemory 0xffffffffffffffff (nil) 00100000 2000 00000004
0114:0118:trace:virtual:alloc_free_area limit 0x7fffffff0000, size 0x100000, top_down 0.
0114:0118:trace:virtual:alloc_free_area range (nil)-0x10000.
0114:0118:trace:virtual:alloc_free_area_in_range range 0x10000-0x10000.
0114:0118:trace:virtual:alloc_free_area range 0x540000-0x7b000000.
0114:0118:trace:virtual:alloc_free_area_in_range range 0x540000-0x7b000000.
0114:0118:trace:virtual:dump_view View: 0x540000 - 0x63ffff (valloc)
0114:0118:trace:virtual:dump_view       0x540000 - 0x63ffff --rw-
0114:0118:trace:virtual:NtAllocateVirtualMemory 0xffffffffffffffff 0x540000 00001000 1000 00000001
0114:0118:trace:virtual:dump_view View: 0x540000 - 0x63ffff (valloc)
0114:0118:trace:virtual:dump_view       0x540000 - 0x540fff c----
0114:0118:trace:virtual:dump_view       0x541000 - 0x63ffff --rw-
0114:0118:trace:virtual:NtAllocateVirtualMemory 0xffffffffffffffff 0x541000 00001000 1000 00000104
0114:0118:trace:virtual:dump_view View: 0x540000 - 0x63ffff (valloc)
0114:0118:trace:virtual:dump_view       0x540000 - 0x540fff c----
0114:0118:trace:virtual:dump_view       0x541000 - 0x541fff cgrw-
0114:0118:trace:virtual:dump_view       0x542000 - 0x63ffff --rw-
0114:0118:trace:virtual:NtAllocateVirtualMemory 0xffffffffffffffff 0x542000 000fe000 1000 00000004
0114:0118:trace:virtual:dump_view View: 0x540000 - 0x63ffff (valloc)
0114:0118:trace:virtual:dump_view       0x540000 - 0x540fff c----
0114:0118:trace:virtual:dump_view       0x541000 - 0x541fff cgrw-
0114:0118:trace:virtual:dump_view       0x542000 - 0x63ffff c-rw-

Unless there's another game that works and requires non-zero dwFFDriverVersion we need to look at this crash first - what the game tries to do here? What part of staging actually fixes it? Is this an acceptable fix or is staging allowing the process access to the stack guard by accident?

I have few other things to attend to before I can look more into this.

[zfigura]

wine-staging used to have some patches that deal with thread stacks; it doesn't anymore. But if this is wine-staging 6.3 patches applied to proton 6.3 they might be relevant.

[whizse]

Hi,

Thank you for taking the time to review! First PR I ever done :)

The game and patchset was tested with Proton 6.3-5 (built in vagrant). The only source changes were these patches and the 0001-ntdll-Fix-holes-in-ELF-mappings.patch from staging. I noticed the game did start with GE, so I made a reverse bisect of staging to find what exact patchset fixed it.

I used a Logitech G29 wheel for testing, using the new-lg4ff driver. While force feedback works in-game with this change, the "Test Vibration" button in the settings does not. Some Windows users have reported the same thing so I guess that's a game bug.

The segfault you're hitting might be because the game requires setting Windows version to 7 (to work around an issue tracked in Wine bugzilla #51643). If that doesn't fix it, you might have found yet another issue. This game seems to have quite a few. For the Windows version issue, I'd be happy to do another PR to add an override to wine.inf.

Apologies for these omissions and any confusion I might have caused. I'll try to be clearer the next time around.

...and a second apology for the tabs/spaces mixup, I'll fix my editor. For future reference, what would be the preferable way to amend the PR?

[ivyl]

The game and patchset was tested with Proton 6.3-5 (built in vagrant). The only source changes were these patches and the 0001-ntdll-Fix-holes-in-ELF-mappings.patch from staging. I noticed the game did start with GE, so I made a reverse bisect of staging to find what exact patchset fixed it.

Now I know what to do to get the game running, and I don't have to do the digging myself. Thanks! I'll give it another look soon.

I used a Logitech G29 wheel for testing, using the new-lg4ff driver. While force feedback works in-game with this change, the "Test Vibration" button in the settings does not. Some Windows users have reported the same thing so I guess that's a game bug.

That's good intel. I'll know to not worry too much about that button. I'll be testing things with G290 using the hid_logitech_hidpp driver, I can also compare the behavior against Windows.

Apologies for these omissions and any confusion I might have caused. I'll try to be clearer the next time around.

No worries, just be sure that you have included any extra patches / steps required to run the game. This will help with testing and may even end up in Proton, so the game will run out of the box :-)

For future reference, what would be the preferable way to amend the PR?

You can just (force) push to the branch you have used to create the PR. This will update the PR.

[ivyl]

Those changes will make the game playable and should end up in the next experimental: https://github.com/ivyl/wine/commits/wrc8

When WRC9 will release on Steam we will probably need to add something like https://github.com/ivyl/wine/commit/6233cec1c23c69e40f8fbc68c62df43ef656cbdd for it as well.

[whizse]

Awesome! Thank you!

[ivyl]

This is now in experimental (20210830) and will "graduate" to the release branch if there are no problems caused by the changes. I'll keep an eye on this. I've also commented on the win7 prefix / possible controller problems in the Proton issue dedicated to the game.

I think we can close this PR now. Thanks for your contribution!

[kisak-valve]

Closing per the last comment.

(https://github.com/ValveSoftware/wine/compare/657daf49680e03e8b0310ee5a9d8860e1e7b5f07..f7c7d4ab2fc1e94125d0f78dd644ccdd3fd96f0c)