https://bugs.winehq.org/show_bug.cgi?id=47104
Bug ID: 47104 Summary: Cannot click anywhere on VST plugins Product: Wine-staging Version: 4.7 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: blocker Priority: P2 Component: -unknown Assignee: wine-bugs@winehq.org Reporter: paulalbertdev@gmail.com CC: leslie_alistair@hotmail.com, z.figura12@gmail.com Distribution: ---
Hi ! Just wanted you to know that 10mins ago everything was working fine but then I upgraded the staging version of wine and, since that, when I'm using windows VSTs plugins through vst-bridge and wine, clicks on the interface are not taken into account... So I cannot use no win VST anymore. Gonna downgrade to dev version but got other problems (less disturbing) with it. Good luck for fixing the bug ! Cheers
https://bugs.winehq.org/show_bug.cgi?id=47104
--- Comment #1 from Alistair Leslie-Hughes leslie_alistair@hotmail.com --- Did it work in wine-staging 4.6?
Can you please please provide a download link?
https://bugs.winehq.org/show_bug.cgi?id=47104
--- Comment #2 from Paul paulalbertdev@gmail.com --- Yes, as I said 10mins before everything was working fine (since months). I even tried to reboot (unsuccessfully). And I don't see what kind of link I could give you since it's for VST plugins through "vst-bridge" in Bitwig Studio... Maybe you can DL Bitwig Studio demo, compile vst-bridge from "abique" GitHub repo, and test it with a free windows VST plugin, but it's a bit fastidious isn't it ?
https://bugs.winehq.org/show_bug.cgi?id=47104
Zebediah Figura z.figura12@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |gabrielopcode@gmail.com
--- Comment #3 from Zebediah Figura z.figura12@gmail.com --- Most likely culprit seems to me to be recent patches to winex11. Gabriel, can you please take a look at this?
https://bugs.winehq.org/show_bug.cgi?id=47104
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Severity|blocker |normal
https://bugs.winehq.org/show_bug.cgi?id=47104
--- Comment #4 from Gabriel Ivăncescu gabrielopcode@gmail.com --- Sorry for the late response. I wasn't able to look much into this due to national holiday today, but from the limited testing I did I wasn't able to reproduce it, yet.
If you can, please try to answer or perform the following:
1) Does this happen with other DAWs like Cockos Reaper? It would make it much easier to test. 2) Can you please give an example of a free VST (you can pick one randomly) that exhibits this behavior in the bridge? 3) What Window Manager (or distro) are you using?
And finally, please do a +cursor debug trace log by launching wine-staging like this in the DAW's directory (replace DAW.exe with the executable):
WINEDEBUG=+cursor /opt/wine-staging/bin/wine DAW.exe >/tmp/winelog 2>&1
Then try to click on the VST window that exhibits this behavior and quit. Then compress the file /tmp/winelog to .gz or anything else and attach it here on your reply.
Thanks.
https://bugs.winehq.org/show_bug.cgi?id=47104
Gabriel Ivăncescu gabrielopcode@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Assignee|wine-bugs@winehq.org |gabrielopcode@gmail.com Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED
--- Comment #5 from Gabriel Ivăncescu gabrielopcode@gmail.com --- Ok, I've managed to reproduce it. The problem is this 'vst-bridge' from: https://github.com/abique/vst-bridge
Note that it's actually a Linux native app that hosts Windows plugins via Wine.
It uses a hack to get the whole window from Wine, using GetPropA(g_host.hwnd, "__wine_x11_whole_window"); and then the plugin calls XReparentWindow on it. This messes it up on the Wine side because root_window is not updated when that happens so it becomes out of sync with Wine's expectations.
The coordinates sent now (with x_root and y_root) are correct for the entire screen, but because of the hack, Wine believes they are in a completely different spot. It believes the plugin itself is at the top-left on the desktop. The (0,0) for Wine's root is now not the screen's top-left but rather where the Window was reparented to by vst-bridge.
For example, its (0,0) coord is (0,0) after MapWindowPoints to the desktop, so MapWindowPoints actually does nothing. This is obviously out of sync with event->x_root which has the proper full-screen coordinate, because root_window doesn't get updated by vst-bridge (it can't since it's internal).
I don't know how to fix this cleanly and honestly I don't know if it's Wine's fault to begin with. I expected __wine stuff to be for internal-use only.
A somewhat ugly workaround for vst-bridge would be to do the MapWindowPoints and check whether the result is identical to what was put in. If so, use that instead of x_root. This would help with this particular hack, and of course we'll have to document it why. It still fixes the original bug with Winamp so it's still good.
I tested this workaround crudely, but I'd like to know if it's a good idea before I factor it properly.
Thoughts?
https://bugs.winehq.org/show_bug.cgi?id=47104
--- Comment #6 from Paul paulalbertdev@gmail.com --- Wow, that's very nice you found out the origin of the problem, thanks a lot ! I don't know if there is a link but I've already seen with previous version of wine that the tooltips were not shown at the right place... May I add, as a simple enduser, that this project vst-bridge is not updated anymore but is very convenient for me cause some other VST plugins don't run with the other bridges systems I tried...
https://bugs.winehq.org/show_bug.cgi?id=47104
--- Comment #7 from Paul paulalbertdev@gmail.com --- Woops, my bad, there seems to be still some activity on the master branch
https://bugs.winehq.org/show_bug.cgi?id=47104
Alistair Leslie-Hughes leslie_alistair@hotmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |RESOLVED Resolution|--- |NOTOURBUG
--- Comment #8 from Alistair Leslie-Hughes leslie_alistair@hotmail.com --- (In reply to Gabriel Ivăncescu from comment #5)
It uses a hack to get the whole window from Wine, using GetPropA(g_host.hwnd, "__wine_x11_whole_window"); and then the plugin calls XReparentWindow on it. This messes it up on the Wine side because root_window is not updated when that happens so it becomes out of sync with Wine's expectations.
This is bypassing the normal windows behaviour and there isn't anything we can do to fix it. Marking as NOTOURBUG.
Reporting the bug upstream could help.
https://bugs.winehq.org/show_bug.cgi?id=47104
--- Comment #9 from Zebediah Figura z.figura12@gmail.com --- To be fair, in my opinion they're trying to do a reasonable thing by reparenting the native window under the X window. It would be nice if we can provide a stable external interface to make this work.
https://bugs.winehq.org/show_bug.cgi?id=47104
--- Comment #10 from Gabriel Ivăncescu gabrielopcode@gmail.com --- (In reply to Zebediah Figura from comment #9)
To be fair, in my opinion they're trying to do a reasonable thing by reparenting the native window under the X window. It would be nice if we can provide a stable external interface to make this work.
Yeah, I'm open to suggestions, but I don't know if the vst-bridge dev is still working on it, hence why I tried a workaround as a hack.
An issue was raised already on it yesterday, but no reply so far: https://github.com/abique/vst-bridge/issues/21
Perhaps it would be good to suggest the interface there, to see if it meets his needs. (either way, he'll have to update vst-bridge to use it, though)
https://bugs.winehq.org/show_bug.cgi?id=47104
--- Comment #11 from Gabriel Ivăncescu gabrielopcode@gmail.com --- Ok, I've updated the patch in the original bug report, it now works around vst-bridge as well (the same workaround also works on full-screen apps, so it's a bit safer anyway).
I think it's a good idea to keep this workaround so people can still use vst-bridge for now, at least until we find a way to reparent it properly.
Note that the reparenting is already buggy. For example with Synth1 VST, turning knobs is bugged and the mouse snaps to the position Wine thinks it is at (i.e. near top-left). Clicking, however, works fine. This happens even in vanilla Wine so it has nothing to do with the staging patch, just a thing to keep in mind. The reparenting is still an issue but it already existed before to begin with.
https://bugs.winehq.org/show_bug.cgi?id=47104
--- Comment #12 from Paul paulalbertdev@gmail.com --- Thank you Gabriel Ivăncescu !
https://bugs.winehq.org/show_bug.cgi?id=47104
xfxphil83@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |xfxphil83@gmail.com
-
wine-bugs＠winehq.org -
WineHQ Bugzilla