[Bug 51824] New: TrueDrive, SimHub, Fanaleds,etc.: Non smooth movement tracking with severe skipping/jumping of the steering wheel/controller axis
https://bugs.winehq.org/show_bug.cgi?id=51824 Bug ID: 51824 Summary: TrueDrive, SimHub, Fanaleds,etc.: Non smooth movement tracking with severe skipping/jumping of the steering wheel/controller axis Product: Wine Version: 6.18 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: hid Assignee: wine-bugs(a)winehq.org Reporter: logos128(a)gmail.com CC: rbernon(a)codeweavers.com Regression SHA1: 325984ded50b354686e5a454aa5aca3aafa81432 Distribution: ArchLinux Created attachment 70711 --> https://bugs.winehq.org/attachment.cgi?id=70711 0001-hidclass.sys-Fix-writing-all-new-reports-at-the-last.patch All the mentioned applications use raw HID access (through HidD/HidP calls) to the devices they controll, so the movement tracking problems appear only there. DirectInput works well. After further investigation, found that the simpler ring buffer (hidclass.sys/device.c) introduced with the mentioned regression commit is causing the issues. Appeared that all new reports are pushed at the last available ring buffer slot, due to reaching the end of the buffer before the reading has started. Usually such devices as joysticks, controllers, steering wheels, etc., use constant stream of INPUT reports to report their axis movement, so any report skipping or change of the sequence, while the interested apps are reading, would lead to such issues. Attached a patch which fixes the issue (based on the current master aa629c4c7225166f4ee46476d98702df2e142711). -- 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=51824 --- Comment #1 from Ivo Ivanov <logos128(a)gmail.com> --- Created attachment 70712 --> https://bugs.winehq.org/attachment.cgi?id=70712 wine_6.18.log -- 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=51824 --- Comment #2 from Rémi Bernon <rbernon(a)codeweavers.com> --- Thanks! I sent an updated patch (https://source.winehq.org/patches/data/216077) that should fix that issue. I initially didn't bother too much with checking which strategy should be used here, as I know that there's another location in winebus.sys where the last report may be overwritten. It's much less likely to happen, as the reading thread is the one from hidclass.sys instead, which should only be busy reading, but it should probably be fixed as well at some point (more specifically it should probably queue the reports coming from the unix side instead of replacing the last report). -- 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=51824 Ivo Ivanov <logos128(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #3 from Ivo Ivanov <logos128(a)gmail.com> --- (In reply to Rémi Bernon from comment #2)
Thanks! I sent an updated patch (https://source.winehq.org/patches/data/216077) that should fix that issue.
Tested with 5a8dcb062793fbb68997e1b54ebc2666a2b2834d from yesterday, and can confirm that the issue is resolved now. The movement tracking of the steering axis is smooth again.
I initially didn't bother too much with checking which strategy should be used here, as I know that there's another location in winebus.sys where the last report may be overwritten.
Related to this, there is another issue with crashing bus_main_thread() (winebus.sys), which I experience in 6.18 and probably earlier. I have managed to get a debug log with hid, hidp, hid_report and plugplay turned on. Unfortunately there is no backtrace after the crash, just this "Unhandled page fault on write access to 0000000000000000 at address 00000001C8E14369 (thread 0088), starting debugger...". The TrueDrive software continues working, showing a "disconnected" message on top of the window. It's pretty random, so it'll be much harder to bisect. I'll fill a separate bug report for this, but do you have any suggestions for additional parameters or a procedure I should follow to find the issue faster? I've added ntoskrnl, but the output was too verbose, and I couldn't provoke the bug.
It's much less likely to happen, as the reading thread is the one from hidclass.sys instead, which should only be busy reading, but it should probably be fixed as well at some point (more specifically it should probably queue the reports coming from the unix side instead of replacing the last report).
I've looked at the HIDRAW code in the Linux kernel, and while the write sends the raw output reports without any buffering, the read buffers up-to 64 reports in the hidraw layer itself. So IMO this also should be considered. -- 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=51824 Ivo Ivanov <logos128(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Fixed by SHA1| |51ae926240f05ac6fe3538728ae | |c1e65ad7abf2c -- 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=51824 --- Comment #4 from Rémi Bernon <rbernon(a)codeweavers.com> --- Regarding the crash you should be able to attach gdb to the winedevice.exe processes (usually there's two of them an no real way to tell which one is running winebus.sys), and maybe get a stacktrace from there. This gdb python script can get you symbols after gdb is attached: https://www.winehq.org/pipermail/wine-devel/2021-June/189134.html -- 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=51824 --- Comment #5 from Ivo Ivanov <logos128(a)gmail.com> --- Created attachment 70746 --> https://bugs.winehq.org/attachment.cgi?id=70746 0001-winebus.sys-Fix-possible-memory-leak-in-various-bus_.patch -- 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=51824 --- Comment #6 from Ivo Ivanov <logos128(a)gmail.com> --- Created attachment 70747 --> https://bugs.winehq.org/attachment.cgi?id=70747 0001-winebus.sys-Fix-insufficient-number-of-chars-being-c.patch -- 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=51824 --- Comment #7 from Ivo Ivanov <logos128(a)gmail.com> --- (In reply to Rémi Bernon from comment #4)
Regarding the crash you should be able to attach gdb to the winedevice.exe processes (usually there's two of them an no real way to tell which one is running winebus.sys), and maybe get a stacktrace from there.
This gdb python script can get you symbols after gdb is attached: https://www.winehq.org/pipermail/wine-devel/2021-June/189134.html
Thanks! The script works great. IMO they should consider adding it to the tools dir. It's really helpful. I still cannot reproduce the crash. This weekend will test it with longer game playing sessions, while TrueDrive being launched in the background. The issue was always present (TrueDrive disconnected from the wheel) while switching between games lately. Since it's just controlling software, there's no problem to just relaunch it. But with the new joystick_hid everything will go through this path, so it's important to find it. Also while searching for possible issues in winebus.sys, have found few possible memory leaks in unixlib.c, and an insufficient number of chars being compared for HID_NAME in get_device_subsystem_info (bus_udev.c). Nothing that is causing this crash, but still worth fixing :) I've attached the two patches here, since the issues are too small for an additional bug report IMO. The patches are based on 5636088871714f2a2de9e543eb66f944ce188edc. -- 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=51824 --- Comment #8 from Rémi Bernon <rbernon(a)codeweavers.com> --- I've sent your patches, nice catch.(In reply to Ivo Ivanov from comment #7)
(In reply to Rémi Bernon from comment #4)
Regarding the crash you should be able to attach gdb to the winedevice.exe processes (usually there's two of them an no real way to tell which one is running winebus.sys), and maybe get a stacktrace from there.
This gdb python script can get you symbols after gdb is attached: https://www.winehq.org/pipermail/wine-devel/2021-June/189134.html
Thanks! The script works great. IMO they should consider adding it to the tools dir. It's really helpful.
Yeah it's not perfect though, and it would be better if we could find a way to tell gdb about the loaded modules dynamically. It only hooks dlopen, although maybe there's some way, using systemtap probes.
I still cannot reproduce the crash. This weekend will test it with longer game playing sessions, while TrueDrive being launched in the background. The issue was always present (TrueDrive disconnected from the wheel) while switching between games lately. Since it's just controlling software, there's no problem to just relaunch it. But with the new joystick_hid everything will go through this path, so it's important to find it.
I'm not sure to understand where it crashes but I've found places where I misused CancelIoEx, in xinput but also in dinput, and which could cause client applications to crash after unacquiring dinput devices. Maybe it's something else, but I've sent some patches to fix those today nonetheless.
Also while searching for possible issues in winebus.sys, have found few possible memory leaks in unixlib.c, and an insufficient number of chars being compared for HID_NAME in get_device_subsystem_info (bus_udev.c). Nothing that is causing this crash, but still worth fixing :) I've attached the two patches here, since the issues are too small for an additional bug report IMO. The patches are based on 5636088871714f2a2de9e543eb66f944ce188edc.
Nice catch, 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.
https://bugs.winehq.org/show_bug.cgi?id=51824 Alexandre Julliard <julliard(a)winehq.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED --- Comment #9 from Alexandre Julliard <julliard(a)winehq.org> --- Closing bugs fixed in 6.19. -- 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=51824 Gijs Vermeulen <gijsvrm(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |regression -- 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 (1)
-
WineHQ Bugzilla