https://bugs.winehq.org/show_bug.cgi?id=46309
Bug ID: 46309 Summary: Winamp with Classic Skin "jumps randomly" when moved Product: Wine Version: 4.0-rc2 Hardware: x86 OS: Linux Status: NEW Severity: normal Priority: P2 Component: winex11.drv Assignee: wine-bugs@winehq.org Reporter: gabrielopcode@gmail.com Distribution: ---
Split from https://bugs.winehq.org/show_bug.cgi?id=15346
When you move Winamp with classic skin, it jumps around randomly. The faster you move it, the more pronounced this effect is. Eventually it will disappear because it will touch an edge of the screen (but that has more to do with the original bug which is a separate problem).
This is probably due to the fact that we use window-relative coordinates and then translate to screen coordinates ourselves, but those window-relative aren't synced perfectly with the cursor since Winamp chooses to reposition itself when moved.
This should be possible to fix by simply using the X-server-supplied root-relative coordinates and we can even get rid of the redundant transformations after that, as we have them already in screen coordinates (with slight translation), which should even simplify the code on top of it...
https://bugs.winehq.org/show_bug.cgi?id=46309
--- Comment #1 from Gabriel Ivăncescu gabrielopcode@gmail.com --- Created attachment 63071 --> https://bugs.winehq.org/attachment.cgi?id=63071 Use root-relative coordinates for events, if possible
Here's what I had in mind, which fixes the issue for me. Please feel free to test and report. It doesn't seem to break anything.
https://bugs.winehq.org/show_bug.cgi?id=46309
Felix Zielcke fzielcke@z-51.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |fzielcke@z-51.de
https://bugs.winehq.org/show_bug.cgi?id=46309
Alistair Leslie-Hughes leslie_alistair@hotmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |STAGED CC| |leslie_alistair@hotmail.com Staged patchset| |https://github.com/wine-sta | |ging/wine-staging/tree/mast | |er/patches/winex11.drv-mous | |e-coorrds
https://bugs.winehq.org/show_bug.cgi?id=46309
faalagorn@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |faalagorn@gmail.com
--- Comment #2 from faalagorn@gmail.com --- This patch breaks the mouse in first person mode in Escape from Tarkov (Unity 5 game) for me unfortunately – with this patch the mouse instantly drifs, but the second part from Bug 15346 that was recently included in wine-staging as well seems to work fine.
https://bugs.winehq.org/show_bug.cgi?id=46309
--- Comment #3 from Gabriel Ivăncescu gabrielopcode@gmail.com --- Can you please attach a (compressed) trace with +cursor by running:
export WINEDEBUG=+cursor
before launching the game in the terminal and reproducing the bug with and without the patch, if you can? (redirect the trace to somewhere like
/tmp/log 2>&1)
And I don't know if it will help, but just in case, does setting the string value "GrabFullscreen" to "Y" under [Software\Wine\X11 Driver] registry key help at all?
https://bugs.winehq.org/show_bug.cgi?id=46309
Gabriel Ivăncescu gabrielopcode@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #63071|0 |1 is obsolete| |
--- Comment #4 from Gabriel Ivăncescu gabrielopcode@gmail.com --- Created attachment 64359 --> https://bugs.winehq.org/attachment.cgi?id=64359 Be more conservative when using root relative coordinates.
Does this updated patch help? (replace the previous one)
It's more conservative now and should only use the root coordinates when it's hopefully safe to do so. It also works around vst-bridge's reparenting hack because the same workaround should also be safer on full-screen apps.
If you test it and it still doesn't work, please try to attach traces with +cursor as I mentioned if you can (ideally with and without the patch).
https://bugs.winehq.org/show_bug.cgi?id=46309
--- Comment #5 from faalagorn@gmail.com --- Thank you a lot for the help! Sorry for not replaying earlier – I wanted to provide log but didn't had the time before, but your updated patch seems to solve the issue for me :)!
I didn't test the "GrabFullscreen" to "Y" under [Software\Wine\X11 Driver] tip you provided before (I doesn't seem to have nothing set in that registry key, the only option Lutris sets is Mouse Warp Override on Default), but I guess it's not needed as of the most recent patch.
I also have a feeling that this patch might have helped prevent the issue with mouse drifting the same way when my game lost a focus sometimes (by "alt-tabing" out of it), though it's hard for me to tell when exactly did it happen, so I'm not 100% sure about that. Either way, it's definitely no worse than it was before the patch, which makes me very happy :).
I'll keep running this patch for now, but will this patch be updated in wine-staging soon as well? Or should I inform them about it too? It seems that staging patch caused some trouble for some with Valve's Proton fullscreen hack enabled, so it got disabled in wine-tkg builds in this commit: https://github.com/Tk-Glitch/PKGBUILDS/commit/1d98d5f33584f7fc2e5d60ed1c276b... so hopefully the newest version won't cause any issues there anymore as well. I didn't use that hack though, but I still was affected by this mouse drift/sync issue before the patch.
https://bugs.winehq.org/show_bug.cgi?id=46309
--- Comment #6 from Gabriel Ivăncescu gabrielopcode@gmail.com --- No problem, great to hear it works even better now!
Yes, I'm hoping it gets into the next wine-staging and perhaps back into Proton so it has more coverage. Feel free to inform them (I don't know their process for picking patches).
I think Alistair watches all the staging bugs so at least he should be aware of it before the next wine-staging release.
https://bugs.winehq.org/show_bug.cgi?id=46309
--- Comment #7 from faalagorn@gmail.com --- Thanks again for reply! I'll wait so hopefully staging will catch up then and continue using the patch in the meantime.
I also want to say that my bug when the game loses focus still occur still happens, but that might as well be game's issue. It's still good enough with the updated patch, so if it still solves winamp (and potentially other) issues it's fine as it didn't made any regression for me :)
https://bugs.winehq.org/show_bug.cgi?id=46309
GloriousEggroll@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |GloriousEggroll@gmail.com
--- Comment #8 from GloriousEggroll@gmail.com --- This is likely a far-fetch but I was wondering if we could a modified version of this patch thats compatible with valve's fullscreen hack:
https://github.com/GloriousEggroll/proton-ge-custom/blob/proton-ge-5/game-pa...
Specifically it seems to conflict with the changes made in dlls/winex11.drv/mouse.c
It would be awesome to have this patch compatible with proton, as many steam games are launched from Origin, which is affected by this bug.
https://bugs.winehq.org/show_bug.cgi?id=46309
--- Comment #9 from GloriousEggroll@gmail.com --- To further clarify, I apply staging like this:
../wine-staging/patches/patchinstall.sh DESTDIR="." --all \ -W server-Desktop_Refcount \ -W ws2_32-TransmitFile \ -W winex11.drv-mouse-coorrds \ -W winex11-MWM_Decorations \ -W winex11-_NET_ACTIVE_WINDOW \ -W winex11-WM_WINDOWPOSCHANGING \ -W user32-rawinput-mouse \ -W user32-rawinput-nolegacy \ -W user32-rawinput-mouse-experimental \ -W user32-rawinput-hid \ -W winex11-key_translation
Then the fullscreen hack patches:
echo "fullscreen hack" patch -Np1 < ../game-patches-testing/proton-valve-patches/proton-FS_bypass_compositor.patch patch -Np1 < ../game-patches-testing/proton-valve-patches/valve_proton_fullscreen_hack-staging.patch patch -Np1 < ../game-patches-testing/proton-valve-patches/proton-vk_bits_4.5+.patch patch -Np1 < ../game-patches-testing/proton-hotfixes/proton-integer_scaling.patch
After this is when I try to add the changes for winex11.drv-mouse-coorrds, and run into conflicts around send_mouse_input.
All attempts I've made have caused the window to open, then immediately close/wine crashes
https://bugs.winehq.org/show_bug.cgi?id=46309
--- Comment #10 from Gabriel Ivăncescu gabrielopcode@gmail.com --- Created attachment 66386 --> https://bugs.winehq.org/attachment.cgi?id=66386 Rebase for Proton
Does the attached patch help? I'm not familiar with the full-screen hack, so I'm not sure if I rebased it right (it might be that the full-screen hack itself causes issues), but I did follow along the logic and made sure it's aligned with the original intent of my patch.
Note that you apply this patch *instead* of the one from staging, not on top of it (since it doesn't apply anyway). The wine-staging patch will never be compatible with Proton's full-screen hack, but if this rebase works fine, I will try to get it into Proton so it uses it without hassle.
If it doesn't work, please provide steps to reproduce it easily in Proton, preferably with a smaller game download (even though, as I understand, it's an issue with the Origin launcher).
https://bugs.winehq.org/show_bug.cgi?id=46309
Gabriel Ivăncescu gabrielopcode@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #66386|0 |1 is obsolete| |
--- Comment #11 from Gabriel Ivăncescu gabrielopcode@gmail.com --- Created attachment 66387 --> https://bugs.winehq.org/attachment.cgi?id=66387 Rebase for Proton
Nevermind the previous patch, I bypassed the full screen hack and messed it up. Try this one instead. Sorry about that.
https://bugs.winehq.org/show_bug.cgi?id=46309
--- Comment #12 from GloriousEggroll@gmail.com --- (In reply to Gabriel Ivăncescu from comment #11)
Created attachment 66387 [details] Rebase for Proton
Nevermind the previous patch, I bypassed the full screen hack and messed it up. Try this one instead. Sorry about that.
This patch seems to work well here!
I had to modify the 4th hunk:
-------------- @@ -737,8 +754,6 @@ static void send_mouse_input( HWND hwnd, Window window, unsigned int state, INPU SERVER_END_REQ; }
- input->u.mi.dx = pt.x; - input->u.mi.dy = pt.y; __wine_send_input( hwnd, input, SEND_HWMSG_WINDOW ); }
--------------
Other than that it applies fine
Thanks!
https://bugs.winehq.org/show_bug.cgi?id=46309
winetest@luukku.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |winetest@luukku.com
--- Comment #13 from winetest@luukku.com --- still an issue when using wine 5.21.
https://bugs.winehq.org/show_bug.cgi?id=46309
Julian Rüger jr98@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |jr98@gmx.net
https://bugs.winehq.org/show_bug.cgi?id=46309
joaopa jeremielapuree@yahoo.fr changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |jeremielapuree@yahoo.fr
--- Comment #14 from joaopa jeremielapuree@yahoo.fr --- Should be fixed in current git. Can you give a try?
https://bugs.winehq.org/show_bug.cgi?id=46309
Dmitry Timoshkov dmitry@baikal.ru changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |regression CC| |zzhang@codeweavers.com Regression SHA1| |c5ec1585f6e5211a2b63e343574 | |8210552250534 Status|STAGED |NEW
--- Comment #15 from Dmitry Timoshkov dmitry@baikal.ru --- (In reply to joaopa from comment #14)
Should be fixed in current git. Can you give a try?
No it's not fixed. In fact, it's the same regression as indicated in the bug 50381. Reverting c5ec1585f6e5211a2b63e3435748210552250534 makes Winamp window moveable again.
https://bugs.winehq.org/show_bug.cgi?id=46309
Rémi Bernon rbernon@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |rbernon@codeweavers.com
--- Comment #16 from Rémi Bernon rbernon@codeweavers.com --- Well then it's a different problem.
Bug 50381 seems to be about the window going back to its original position on some desktop environment (which I cannot reproduce on GNOME), not jumping around randomly.
The issue here was that the window is slightly jumping around while moved was because of inconsistent window position between X11 and Wine, and that should be fixed now.
https://bugs.winehq.org/show_bug.cgi?id=46309
Gabriel Ivăncescu gabrielopcode@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Fixed by SHA1| |5a8bc554ef06c4a21d8b49ea8d9 | |36299f2cb2f34 Keywords|regression | Regression SHA1|c5ec1585f6e5211a2b63e343574 | |8210552250534 | Resolution|--- |FIXED Status|NEW |RESOLVED
--- Comment #17 from Gabriel Ivăncescu gabrielopcode@gmail.com --- Yeah, I can't reproduce that regression either, but I'm not sure Zhiyi's patch that causes it is entirely correct either, I remember it caused a regression with some full-screen applications that used multiple windows and dialogs (i.e. not games).
Anyway it's a completely separate bug. I confirm this bug is fixed by 5a8bc554ef06c4a21d8b49ea8d936299f2cb2f34, thank you Rémi.
Let's keep that other bug for the regression and close this one.
https://bugs.winehq.org/show_bug.cgi?id=46309
Dmitry Timoshkov dmitry@baikal.ru changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Regression SHA1| |c5ec1585f6e5211a2b63e343574 | |8210552250534 Resolution|FIXED |--- Keywords| |regression
--- Comment #18 from Dmitry Timoshkov dmitry@baikal.ru --- (In reply to Gabriel Ivăncescu from comment #17)
Yeah, I can't reproduce that regression either, but I'm not sure Zhiyi's patch that causes it is entirely correct either, I remember it caused a regression with some full-screen applications that used multiple windows and dialogs (i.e. not games).
Anyway it's a completely separate bug. I confirm this bug is fixed by 5a8bc554ef06c4a21d8b49ea8d936299f2cb2f34, thank you Rémi.
Let's keep that other bug for the regression and close this one.
This bug is not fixed. It could be easily tested and reproduced with Winamp under MATE. And this *is* a regression, reverting c5ec1585f6e5211a2b63e3435748210552250534 makes the Winamp window moveable again.
https://bugs.winehq.org/show_bug.cgi?id=46309
--- Comment #19 from Gabriel Ivăncescu gabrielopcode@gmail.com --- (In reply to Dmitry Timoshkov from comment #18)
(In reply to Gabriel Ivăncescu from comment #17)
Yeah, I can't reproduce that regression either, but I'm not sure Zhiyi's patch that causes it is entirely correct either, I remember it caused a regression with some full-screen applications that used multiple windows and dialogs (i.e. not games).
Anyway it's a completely separate bug. I confirm this bug is fixed by 5a8bc554ef06c4a21d8b49ea8d936299f2cb2f34, thank you Rémi.
Let's keep that other bug for the regression and close this one.
This bug is not fixed. It could be easily tested and reproduced with Winamp under MATE. And this *is* a regression, reverting c5ec1585f6e5211a2b63e3435748210552250534 makes the Winamp window moveable again.
I never said that regression is not real. But this bug is *not* about Winamp being unable to move, it's about it moving erratically when moved. We already have Bug 50381 about this regression, and I made a note about Winamp there with a download link.
Is there a reason you don't want to use Bug 50381 for this regression? If not, please close this bug because it's about an entirely different issue.
https://bugs.winehq.org/show_bug.cgi?id=46309
--- Comment #20 from Dmitry Timoshkov dmitry@baikal.ru --- (In reply to Gabriel Ivăncescu from comment #19)
I never said that regression is not real. But this bug is *not* about Winamp being unable to move, it's about it moving erratically when moved.
This is exactly what happens. Feel free to test it on your own.
We already have Bug 50381 about this regression, and I made a note about Winamp there with a download link.
Is there a reason you don't want to use Bug 50381 for this regression? If not, please close this bug because it's about an entirely different issue.
How would you propose resolving this bug? It's clearly not fixed, and this is a regression. So, it either needs to be marked as a duplicate, or the other bug should be marked as a duplicate of this one, sine this bug is older than the bug 50381. In any case the resolution as RESOLVED/FIXED is not appropriate here.
https://bugs.winehq.org/show_bug.cgi?id=46309
--- Comment #21 from Gabriel Ivăncescu gabrielopcode@gmail.com --- (In reply to Dmitry Timoshkov from comment #20)
(In reply to Gabriel Ivăncescu from comment #19)
I never said that regression is not real. But this bug is *not* about Winamp being unable to move, it's about it moving erratically when moved.
This is exactly what happens. Feel free to test it on your own.
We already have Bug 50381 about this regression, and I made a note about Winamp there with a download link.
Is there a reason you don't want to use Bug 50381 for this regression? If not, please close this bug because it's about an entirely different issue.
How would you propose resolving this bug? It's clearly not fixed, and this is a regression. So, it either needs to be marked as a duplicate, or the other bug should be marked as a duplicate of this one, sine this bug is older than the bug 50381. In any case the resolution as RESOLVED/FIXED is not appropriate here.
This bug was fixed only recently, the regression commit is far older, why would it be a regression of *this* bug in the first place? That's what I'm saying. It makes no sense. If there's a regression with the application itself it doesn't mean it goes into the same bug report. We separate bug reports for each specific problem, not per application.
Usually regressions have their own bug and in this case we have bug 50381 for that. It's not a duplicate because this bug is about it moving erratically *before* that regression commit. And that happens even on other WMs, like GNOME's Mutter, or Compiz. And that's exactly what the commit fixed and why this bug is fixed.
The regression is a *separate* bug and has nothing to do with it, even if the behavior is the same. As I said we already have a bug for the regression (bug 50381), please use that one for now. If it gets fixed and Winamp still has an issue on MATE, then please file a new regression bug because, as I said, it has nothing to do with this bug which existed before that commit, on other WMs, which *is* fixed.
https://bugs.winehq.org/show_bug.cgi?id=46309
--- Comment #22 from Dmitry Timoshkov dmitry@baikal.ru --- (In reply to Gabriel Ivăncescu from comment #21)
This bug was fixed only recently, the regression commit is far older, why would it be a regression of *this* bug in the first place? That's what I'm saying. It makes no sense. If there's a regression with the application itself it doesn't mean it goes into the same bug report. We separate bug reports for each specific problem, not per application.
Usually regressions have their own bug and in this case we have bug 50381 for that. It's not a duplicate because this bug is about it moving erratically *before* that regression commit. And that happens even on other WMs, like GNOME's Mutter, or Compiz. And that's exactly what the commit fixed and why this bug is fixed.
The regression is a *separate* bug and has nothing to do with it, even if the behavior is the same. As I said we already have a bug for the regression (bug 50381), please use that one for now. If it gets fixed and Winamp still has an issue on MATE, then please file a new regression bug because, as I said, it has nothing to do with this bug which existed before that commit, on other WMs, which *is* fixed.
I understand your reasoning, however with current wine.git (wine-6.5+) this bug is not fixed, behaviour of Winamp matches what is described in the first comment. Reverting c5ec1585f6e5211a2b63e3435748210552250534 does fix it. By all means this bug is not fixed, anyone is free to test it, and report back the results.
https://bugs.winehq.org/show_bug.cgi?id=46309
--- Comment #23 from Gabriel Ivăncescu gabrielopcode@gmail.com --- Well the bug itself is fixed. The application is not and has a regression; but like I said we separate bug reports per problem, not per application.
Obviously what the regression triggers is a completely separate thing from the fix in Rémi's commit. In short: it's a separate issue, and has its own bug report.
Just because the outcome is the same doesn't mean it's the same underlying problem.
For example an application could crash on launch due to many different issues. If one of them is fixed, the bug report gets resolved, even if it still crashes due to something else or a regression. Those go into a separate bug report.
In this case, Winamp's positioning is erratic due to different underlying issues. The one that this bug refers to is fixed.
But anyway, what good would it make to keep this bug open when we already have a bug tracking the regression?
You can't simply mark it as a duplicate, since the other bug is specifically about the regression, and *not* about the bug *before* that commit in the first place. Neither is it about other WMs. This bug *was* affecting other WMs as well. So it's obviously not a duplicate and it's about a different underlying cause/problem.
https://bugs.winehq.org/show_bug.cgi?id=46309
Zhiyi Zhang zzhang@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|REOPENED |RESOLVED Resolution|--- |FIXED
--- Comment #24 from Zhiyi Zhang zzhang@codeweavers.com --- Marking this one as resolved. Tracking the unmovable bug at https://bugs.winehq.org/show_bug.cgi?id=50381
https://bugs.winehq.org/show_bug.cgi?id=46309
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #25 from Alexandre Julliard julliard@winehq.org --- Closing bugs fixed in 6.7.
-
wine-bugs＠winehq.org -
WineHQ Bugzilla