[Bug 48322] World of Warcraft Classic: Mouse movement can block keydown events from registering

[WineHQ Bugzilla]

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

--- Comment #20 from Luca Boccassi <luca.boccassi at gmail.com> ---
(In reply to Luca Boccassi from comment #19)
> (In reply to Sveinar Søpler from comment #18)
> > (In reply to Luca Boccassi from comment #17)
> > > Rather than bisecting the patchsets, I'm thinking it might be easier to
> > > bisect the staging git tree itself, with 4.17 being "good" and 4.18 being
> > > "bad"? In _theory_, unless intermittent breakages were added and then
> > > removed, it should be doable as both versions work with WoW.
> > 
> > I am not sure it is "as easy as that", but there was some strangeness that
> > started happening with 4.16 for some games aswell. I am sure this is not
> > ONLY WoW with this problem tho.
> > 
> > This is a bug posted, now marked as solved:
> > https://bugs.winehq.org/show_bug.cgi?id=47834
> > 
> > This is what i gather as something that caused problems aswell:
> > https://github.com/wine-staging/wine-staging/commit/
> > 0c7512f5f53deb168d3508bdd1f1107ecee774c6#comments
> > 
> > And it was disabled pre 4.18 launch:
> > https://github.com/wine-staging/wine-staging/commit/
> > 5b066d6aed7fd90c0be0a2a156b0e5c6cbb44bba
> > 
> > But i see no tests mentioning WoW in this particular context.
> > 
> > Maybe do some comparison of staging-4.17 vs. 4.17 with these patches
> > enabled/disabled? I think there was changes to the wine tree between 4.17
> > and 4.18 that prompted the need to update this user32-rawinput patchset tho,
> > but it is way beyond me to figure out the ins and outs of this.
> > 
> > We are playing the "blame-game" here: Is it wine, or is it staging :)
> 
> And the winner is... wine! :-)
> 
> I have bisected the wine-staging tree, and the first bad commit was the 4.19
> release. That didn't update any patch, but it changed wine's upstream commit
> from ccec532879ec14b2e79da08288152a69221ec4d1 to
> 6f2ef158b78f7d0a950c9398c26278d6523c112e.
> Sure enough, while keeping the wine-staging patches identical, switching the
> base wine tree between those two commits makes the issue appear/go away.
> 
> So I bisected that too, and the culprit is:
> 
> https://source.winehq.org/git/wine.git/commit/
> 413aad39135b0b0f8255500b85fcc05337a5f138
> https://github.com/wine-mirror/wine/commit/
> 413aad39135b0b0f8255500b85fcc05337a5f138
> https://bugs.winehq.org/show_bug.cgi?id=47821
> 
> With wine at wine-4.19 plus a revert of that commit, and wine-staging at
> v4.19, the bug is fixed. Without the revert, the bug is 100% reproducible.
> 
> So, what's next? I'm really not familiar with the codebase, so I can't see
> what the issue is.

While in works on 4.19, unfortunately reverting that commit on 5.4 breaks wine
completely, winecfg doesn't even start, fails with this error:

000b:err:winediag:nodrv_CreateWindow Application tried to create a window, but
no driver could be loaded.
000b:err:winediag:nodrv_CreateWindow The explorer process failed to start.

So I imagine that functionality is relied upon by something else.

-- 
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.