[Bug 51824] TrueDrive, SimHub, Fanaleds,etc.: Non smooth movement tracking with severe skipping/jumping of the steering wheel/controller axis

[WineHQ Bugzilla]

https://bugs.winehq.org/show_bug.cgi?id=51824

Ivo Ivanov <logos128 at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |FIXED
             Status|UNCONFIRMED                 |RESOLVED

--- Comment #3 from Ivo Ivanov <logos128 at 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.