https://bugs.winehq.org/show_bug.cgi?id=51490 François Gouget <fgouget(a)codeweavers.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |FIXED Fixed by SHA1| |5cb70e73f070def227f47bb307c | |1d5a483fc898c Status|NEW |RESOLVED --- Comment #2 from François Gouget <fgouget(a)codeweavers.com> --- I think the issue was fixed by this commit: commit 5cb70e73f070def227f47bb307c1d5a483fc898c Author: Arkadiusz Hiler <ahiler(a)codeweavers.com> AuthorDate: Thu Aug 5 13:55:29 2021 +0300 dinput/tests: Make overlapped format tests more robust. Both Acquire() and event processing with DirectInput seem to be asynchronous. In most cases we can just keep hammering GetDeviceData() until the event gets processed. Things get pretty racy around Acquire() though. If we fire event right after the device is acquired we can find ourselves in one of the three situations: 1. Event happened after acquiring has completed - the wait will suffice. 2. Event happened before acquiring did any real work - the device will pick up the state as if the event was processed, but there's nothing in GetDeviceData(). Because of that we cannot fail on wait. 3. Event happened somewhere in the middle of acquiring - we ended up both missing the event for GetDeviceData() and we have outdated state. Sending event again will register as if the button was not already pressed. This change covers all three scenarios. Signed-off-by: Arkadiusz Hiler <ahiler(a)codeweavers.com> Signed-off-by: Rémi Bernon <rbernon(a)codeweavers.com> Signed-off-by: Alexandre Julliard <julliard(a)winehq.org> -- 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.