[Bug 52714] New: Richard Burns Rally (RallySimFans): Logitech G29 Force Feedback doesn't work
https://bugs.winehq.org/show_bug.cgi?id=52714 Bug ID: 52714 Summary: Richard Burns Rally (RallySimFans): Logitech G29 Force Feedback doesn't work Product: Wine Version: 7.4 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: groovestomp+winehq(a)getgoogleoff.me Distribution: --- Install the RallySimFans distribution of Richard Burns Rally in a new wine prefix: https://rallysimfans.hu/rbr/index.php Run: "wine control" with the prefix and verify the racing wheel inputs all work correctly and force feedback works. Now go into the game, configure the wheel and notice force feedback does not work. Downgrading to Wine 5 (The latest previous version available before 7 on my system) works without issue. Here's a mention of this issue that led me to isolate that 7 is the problem: https://forum.winehq.org/viewtopic.php?t=36110 And that thread refers to another here: http://srmz.net/index.php?showtopic=14451#entry162706 Output of lshw -short: H/W path Device Class Description ============================================================= system Oryx Pro (Not Applicable) /0 bus Oryx Pro /0/0 memory 64KiB BIOS /0/1d memory 32GiB System Memory /0/1d/0 memory 16GiB SODIMM DDR4 Synchronous 2400 MHz (0.4 ns) /0/1d/1 memory [empty] /0/1d/2 memory 16GiB SODIMM DDR4 Synchronous 2400 MHz (0.4 ns) /0/1d/3 memory [empty] /0/23 memory 256KiB L1 cache /0/24 memory 1MiB L2 cache /0/25 memory 6MiB L3 cache /0/26 processor Intel(R) Core(TM) i7-7700HQ CPU @ 2.80GHz /0/100 bridge Xeon E3-1200 v6/7th Gen Core Processor Host Bridge/DRAM Registers /0/100/1 bridge 6th-10th Gen Core Processor PCIe Controller (x16) /0/100/1/0 display GP104BM [GeForce GTX 1070 Mobile] /0/100/1/0.1 multimedia GP104 High Definition Audio Controller /0/100/14 bus 100 Series/C230 Series Chipset Family USB 3.0 xHCI Controller /0/100/14/0 usb1 bus xHCI Host Controller /0/100/14/0/1 input G29 Driving Force Racing Wheel /0/100/14/0/4 multimedia Turtle Beach P11 Headset /0/100/14/0/5 communication Arduino Leonardo /0/100/14/0/7 generic EgisTec_ES603 /0/100/14/0/8 communication Bluetooth wireless interface /0/100/14/0/9 multimedia Chicony USB 2.0 Camera /0/100/14/1 usb2 bus xHCI Host Controller /0/100/14.2 generic 100 Series/C230 Series Chipset Family Thermal Subsystem /0/100/16 communication 100 Series/C230 Series Chipset Family MEI Controller #1 /0/100/17 storage HM170/QM170 Chipset SATA Controller [AHCI Mode] /0/100/1c bridge 100 Series/C230 Series Chipset Family PCI Express Root Port #1 /0/100/1c.4 bridge 100 Series/C230 Series Chipset Family PCI Express Root Port #5 /0/100/1c.4/0 generic RTL8411B PCI Express Card Reader /0/100/1c.4/0.1 enp109s0f1 network RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller /0/100/1c.6 bridge 100 Series/C230 Series Chipset Family PCI Express Root Port #7 /0/100/1c.6/0 wlp110s0 network Wireless 8265 / 8275 /0/100/1d bridge 100 Series/C230 Series Chipset Family PCI Express Root Port #9 /0/100/1d/0 storage NVMe SSD Controller SM961/PM961/SM963 /0/100/1d/0/0 /dev/nvme0 storage Samsung SSD 960 EVO 250GB /0/100/1d/0/0/1 /dev/nvme0n1 disk 250GB NVMe namespace /0/100/1d/0/0/1/1 /dev/nvme0n1p1 volume 497MiB Windows FAT volume /0/100/1d/0/0/1/2 /dev/nvme0n1p2 volume 4095MiB Windows FAT volume /0/100/1d/0/0/1/3 /dev/nvme0n1p3 volume 224GiB EFI partition /0/100/1d/0/0/1/4 /dev/nvme0n1p4 volume 4095MiB Linux swap volume /0/100/1f bridge HM175 Chipset LPC/eSPI Controller /0/100/1f.2 memory Memory controller /0/100/1f.3 multimedia CM238 HD Audio Controller /0/100/1f.4 bus 100 Series/C230 Series Chipset Family SMBus /0/1 input PnP device PNP0303 /0/2 generic PnP device SYN1219 /0/3 system PnP device PNP0c02 /0/4 system PnP device PNP0c02 /0/5 system PnP device PNP0b00 /0/6 generic PnP device INT3f0d /0/7 system PnP device PNP0c02 /0/8 system PnP device PNP0c02 /0/9 system PnP device PNP0c02 /0/a scsi3 storage /0/a/0.0.0 /dev/sda disk 1TB WDC WD10SPZX-00Z /0/a/0.0.0/0 /dev/sda volume 931GiB Linux Unified Key Setup volume -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=52714 --- Comment #1 from groovestomp+winehq(a)getgoogleoff.me --- By the way, I am a software developer and am happy to work on resolving this if someone can guide me. I am wholly unfamiliar with the wine codebase but welcome the opportunity to contribute. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=52714 groybe(a)gmail.com changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |groybe(a)gmail.com --- Comment #2 from groybe(a)gmail.com --- Can confirm this bug. No issues on wine 6. Fedit at least will let you send forces and they work but with this error. 00000005: Can't get force feedback axes! 00000006: hResult = 0x80070057 : Invalid parameters 00000007: SetUpFFDevice failed. 00000008: hResult = 0x80070057 : Invalid parameters Maybe the game can't see supported effects so it gives up? -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=52714 Sven Arvidsson <sa(a)whiz.se> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |sa(a)whiz.se --- Comment #3 from Sven Arvidsson <sa(a)whiz.se> --- I tried a bisect to see where it broke, but unsurprisingly it comes down to the big dinput rework some years ago: adfee25b45af8160848f94fdb24279d63d5f91f4 is the first bad commit commit adfee25b45af8160848f94fdb24279d63d5f91f4 Author: Rémi Bernon <rbernon(a)codeweavers.com> Date: Mon Oct 11 10:10:57 2021 +0200 dinput: Remove legacy joystick backends. Signed-off-by: Rémi Bernon <rbernon(a)codeweavers.com> Signed-off-by: Alexandre Julliard <julliard(a)winehq.org> The game does detect the wheel as force feedback capable and happily runs the feedback test in the settings, but nothing happens at the hardware end. Toggling autocenter does however work. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=52714 --- Comment #4 from groybe(a)gmail.com --- (In reply to Sven Arvidsson from comment #3)
I tried a bisect to see where it broke, but unsurprisingly it comes down to the big dinput rework some years ago:
adfee25b45af8160848f94fdb24279d63d5f91f4 is the first bad commit commit adfee25b45af8160848f94fdb24279d63d5f91f4 Author: Rémi Bernon <rbernon(a)codeweavers.com> Date: Mon Oct 11 10:10:57 2021 +0200
dinput: Remove legacy joystick backends.
Signed-off-by: Rémi Bernon <rbernon(a)codeweavers.com> Signed-off-by: Alexandre Julliard <julliard(a)winehq.org>
The game does detect the wheel as force feedback capable and happily runs the feedback test in the settings, but nothing happens at the hardware end.
Toggling autocenter does however work.
You might have more luck posting about this bug here https://bugs.winehq.org/show_bug.cgi?id=9221 It might be the same as that GPL bug and at least people are signed up to the cc list there. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=52714 --- Comment #5 from Sven Arvidsson <sa(a)whiz.se> --- Created attachment 76065 --> https://bugs.winehq.org/attachment.cgi?id=76065 Remove the axes check from dinput I think I figured out what's going on: The game creates single constant force with two axes. It then uses a SetParameters in a loop to update, download and run the effect. The calls to SetParameters also changes the number of axes to 1. This is the problem. According to the DirectInput API "The number of axes for an effect cannot be changed once it has been set*". Wine handles this by returning early from the method call with DIERR_INVALIDPARAM and never playing the effect. It seems Windows is more lenient, simply ignores the attempt to change the axes and plays the effect. My workaround (and the attached patch) simply removes the check for axes changes. I'm not sure if it's the correct way to handle this but force feedback works for me now. I tested the original game with and without the FixUp plugin (using a Logitech G29 and Wine 9.2). * https://learn.microsoft.com/en-us/previous-versions/windows/desktop/ee416616...) -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=52714 as400 <as400(a)smail.net.pl> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |as400(a)smail.net.pl --- Comment #6 from as400 <as400(a)smail.net.pl> --- Hey Sven, I can confirm your patch works also on Wine 9.7. I have Thrustmaster T150RS wheel. In-game "Force feedback test" sometimes doesn't work but when you go onto special stage all works as expected. I think including this patch into Wine would benefit not only this particular game. There are many games where force feedback is reported as not working for at least few versions of Wine. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=52714 leillo1975(a)gmail.com <leillo1975(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |leillo1975(a)gmail.com --- Comment #7 from leillo1975(a)gmail.com <leillo1975(a)gmail.com> --- I tried this patched wine 9.7 version build by @as400 and the game Force Feedback works great now: https://gitlab.com/as400l/wine-rbr Please include it on wine -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=52714 Ken Sharp <imwellcushtymelike(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |hardware --- Comment #8 from Ken Sharp <imwellcushtymelike(a)gmail.com> --- The source code isn't provided. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=52714 --- Comment #9 from groybe(a)gmail.com --- (In reply to Ken Sharp from comment #8)
The source code isn't provided.
It's in the patch. https://bugs.winehq.org/attachment.cgi?id=76065 -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=52714 Tomasz Pakuła <tomasz.pakula.oficjalny(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |tomasz.pakula.oficjalny(a)gma | |il.com --- Comment #10 from Tomasz Pakuła <tomasz.pakula.oficjalny(a)gmail.com> --- I've done extensive testing and debugging with Oleg Makarenko and this is an issue with the game, not wine. Wine works as expected and removing these checks would be in clear opposition to how directinput works. The same issue is present on windows. 1. The game creates FFB effects incorrectly. It includes ALL the FFB-enabled axes found on a device but then tries to change cAxes to 1, rgdwAxes to only contain the steering axis and rglDirection to only contain one entry. This is in clear violation of directinput which clearly states that cAxes, rgdwAxes and rglDirection can't be changed once they have been set during effect creation. https://learn.microsoft.com/en-us/previous-versions/windows/desktop/ee417536...) NOTE from linked documentation: The cAxes and rgdwAxes members cannot be modified once they have been set. An effect always has the same axis list. 2. The same issue (no FFB) is present on windows. A lof of PID wheelbases (Moza, VRS, Cammus etc) expose two possible FFB axes in their descriptors. The registry fix/hack from Moza (and later adapted by RSF for other manufacturers) overrides directinput and tells it that a specific device only has one FFB enabled axis. directinput in Wine doesn't have this functionality as it's pretty arcane. 3. Oleg created a small program to test effect creation and updates and we confirmed that there's no way to change cAxes once it has been set with the effect creation. In every possibility (changing direction types, supplying different axes etc) Wine behaves and returns the same errors as Windows AND works properly wit the same configs that work on Windows. Any change to cAxes will always return DIERR_INVALIDPARAM. The game worked previously as directinput emulation was very rudimentary. Now, that it's much, much closer to 100% replicating Windows, these game bugs are surfacing. Why would it not work with known working devices like Logitech G29? I'm trying to get a hold of data from one to confirm but Logitech does a lot of custom work in their windows drivers which expose different HID descriptors to what's actually found on the devices. They might actually expose two FFB axes. Maybe it's something in the driver/SDL/Wine handling of virtual joysticks that exposes more than the one FFB axis. I just want to emphasize that this is not the device's or Wine's issue/problem. A single-axis effect should be created with just one axis from the start. https://learn.microsoft.com/en-us/previous-versions/windows/desktop/ee417536... If possible, it would be best to fix game/rsf ngp FFB effect creation. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=52714 --- Comment #11 from Tomasz Pakuła <tomasz.pakula.oficjalny(a)gmail.com> --- Okay, I've done extensive modifications to SDL and especially to Wine to be able to create a variable number of axes in the virtual joystick's PID descriptor. I can confirm the "issue" goes away when a device only presents one FFB-enabled axis as this way, RBR creates an effect with one axis from the get-go and never triggers errer by changing cAxes. Logitech G29 and other wheels that should work don't, becasue Wine now hardcodes two FFB axes in the virtual PID descriptor. I already created a PR to SDL and will create MR to Wine as soon as I get my fork permissions. This should be classified as NOTOURBUG. While annoying, this works exactly like on windows. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=52714 fins.fire_0v@icloud.com changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |fins.fire_0v@icloud.com --- Comment #12 from fins.fire_0v@icloud.com --- (In reply to Tomasz Pakuła from comment #11)
I already created a PR to SDL and will create MR to Wine as soon as I get my fork permissions.
Hi, was it merged? Thanks! -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
participants (2)
-
WineHQ Bugzilla -
WineHQ Bugzilla