https://bugs.winehq.org/show_bug.cgi?id=57603
Bug ID: 57603 Summary: Interacting with yabridge plugins after moving the window broken Product: Wine Version: 9.22 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: major Priority: P2 Component: -unknown Assignee: wine-bugs@winehq.org Reporter: mbarriolinares@gmail.com Distribution: ---
Issue:
When opening a plugin window via yabridge in carla patchbay or ardour8, the mouse input is registered at an incorrect position. After moving the plugin window, mouse interaction stops working entirely, making the interface unusable.
Steps to Reproduce: 1. Open a yabridge plugin window in carla patchbay or ardour. 2. Attempt to interact with the plugin using the mouse. 3. Observe that clicks and movements are registered at incorrect positions. 4. Move the plugin window. 5. Try interacting with the plugin again. 6. Observe that the mouse no longer interacts with the plugin.
Additional info: wine version: 9.22-1 yabridge version: 5.1.1-1 xorg-server version: 21.1.15-1 ardour 8.10 carla 2.5.9-1
---
Dwngrading to wine 9.21 fixed the issue
https://bugs.winehq.org/show_bug.cgi?id=57603
Robbert van der Helm mail@robbertvanderhelm.nl changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |mail@robbertvanderhelm.nl
https://bugs.winehq.org/show_bug.cgi?id=57603
ben@zeiss.net changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |ben@zeiss.net
https://bugs.winehq.org/show_bug.cgi?id=57603
--- Comment #1 from Manuel Barrio Linares mbarriolinares@gmail.com --- Test with https://www.bluecataudio.com/Products/Bundle_AllPluginsPack/
https://bugs.winehq.org/show_bug.cgi?id=57603
Craig Dunford craig@dunford.dev changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |craig@dunford.dev
--- Comment #2 from Craig Dunford craig@dunford.dev --- Lots of discussion on this issue: - https://github.com/robbert-vdh/yabridge/issues/382 - https://gitlab.winehq.org/wine/wine/-/merge_requests/6569#note_89380
https://bugs.winehq.org/show_bug.cgi?id=57603
schroedingerscat@disroot.org changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |schroedingerscat@disroot.or | |g
https://bugs.winehq.org/show_bug.cgi?id=57603
PennRobotics irischer.posaunist@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |irischer.posaunist@gmail.co | |m
--- Comment #3 from PennRobotics irischer.posaunist@gmail.com --- Created attachment 78043 --> https://bugs.winehq.org/attachment.cgi?id=78043 debug output while testing mouse inputs with yabridge
WINEDEBUG=+timestamp,+pid,+loaddll,+x11drv,+event,+cursor,+win,+msg,+message,+hid
Using REAPER and yabridge: 1. Clicked near upper left corner of plugin window 2. Clicked near lower right corner 3. Clicked near the middle 4. Moved the containing window (up and left) 5. Clicked upper left 6. Clicked lower right 7. Clicked middle 8. Exit
https://bugs.winehq.org/show_bug.cgi?id=57603
--- Comment #4 from Nikolay Sivov bunglehead@gmail.com --- (In reply to PennRobotics from comment #3)
Created attachment 78043 [details] debug output while testing mouse inputs with yabridge
If Direct2D is the problem, the log should be using WINEDEBUG=+d2d,+seh. There are no d2d err/fixme traces in the current log. According to loaddll traces it's not even loaded.
https://bugs.winehq.org/show_bug.cgi?id=57603
--- Comment #5 from PennRobotics irischer.posaunist@gmail.com --- I just added those flags and did not find d2d in the updated log, although there are some seh traces.
https://bugs.winehq.org/show_bug.cgi?id=57603
PennRobotics irischer.posaunist@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #78043|0 |1 is obsolete| |
--- Comment #6 from PennRobotics irischer.posaunist@gmail.com --- Created attachment 78044 --> https://bugs.winehq.org/attachment.cgi?id=78044 debug output (new flags added) testing mouse inputs with yabridge
WINEDEBUG=+timestamp,+pid,+loaddll,+x11drv,+event,+cursor,+win,+msg,+message,+hid,+d2d,+seh
https://bugs.winehq.org/show_bug.cgi?id=57603
--- Comment #7 from PennRobotics irischer.posaunist@gmail.com --- A few remarks---prefaced that I don't know much about Wine or Windows:
* There is no WindowPosChanging in the middle (at or around 13:34:50), and this is expected as AFAIK the plugin window doesn't change its origin; only the parent window, owned by REAPER, moves. I see there's a window for the whole screen (10072h) and for the plugin (2000003h) and I don't see anything about parent position in the debug log: all of the GetWindowRect lines start with (0,0). However, the offset used by map_event_coords changes from 13:34:49 to 13:34:51, so this is when I moved the window.
* There are only two MouseEvent pairs where there should be six (if those are, indeed, the mouse clicks) and they are both occur higher than (100, 100) where the first one should be closer to (0,0). These clicks would have been after I moved the parent window (up and left).
https://bugs.winehq.org/show_bug.cgi?id=57603
--- Comment #8 from PennRobotics irischer.posaunist@gmail.com --- X11DRV_MotionNotify (uses A coords), map_event_coords (A to B), NtUserTrackMouseEvent (uses B coords), and then window_from_point (uses A coords)
The B coord numbers are always higher than the A coord's.
X11DRV_MotionNotify refers to 0x10072/2000003 NtUserTrackMouseEvent uses 0x10076
They both seem to be the plugin window (rect 0,0 to 805,460), so I'd expect them to use the same coords or same handle, but I guess that's the purpose of the comparison near line 500 in dlls/winex11.drv/mouse.c
That's about the extent of my mental energy today.
There should be enough there to figure out if yabridge needs to give Wine more information or if the mapping is happening improperly in this case.
https://bugs.winehq.org/show_bug.cgi?id=57603
--- Comment #9 from PennRobotics irischer.posaunist@gmail.com --- The component for this can be changed to winex11.drv
----- (I'm using a different log file when any numeric value is shown:)
Some background, there are four windows created by yabridge: parent (16012db) wrapper (2200000) wine (2000003) host (1600130)
wrapper_window makes parent_window its parent. wine_window makes wrapper_window its parent.
wrapper_window has WS_EX_TOOLWINDOW and WS_POPUP, it seems, which was what "facilitated" relative coordinates before.
The trace then shows: host_window_re parent 402, window 200192 (604,402)-(1516,1110) host_window_re parent 200192, window 200193 (0,0)-(912,708) root_coords 1 host_window_re parent 200193, window 1600130 (0,0)-(912,708) root_coords 1 host_window_re parent 1600130, window 16012db (0,0)-(644,659) root_coords 1 host_window_re parent 16012db, window 2200000 (0,0)-(805,460) root_coords 1 host_window_re parent 2200000, window 2000003 (0,0)-(1920,1200) root_coords 0
I imagine the larger windows with ids 20019x belong to REAPER (in my case). I have no idea why the coordinates for parent_window(?) are (644,659). These numbers never show up again.
During a failed click, event:call_event_handler 204 reports ButtonPress for 0x20070/2000003 (wine_window) X11DRV_ButtonPress has the correct position 19,16 and then calls: ...cursor:map_event_coords, having event_root 402, x_root 889, y_root 493 Because event_root is root_window, pt becomes (x_root, y_root) when it should be (pt->x, pt->y)
...which causes WM_NCHITTEST to fail when the plugin window is too far away from (0,0)
From above, we know that the event window, 2000003, has bounds (1920,1200). That yabridge is getting the correct coordinate to the X11DRV_Buttonpress, we know the client code (Editor::fix_local_coordinates) is getting the information it needs about the child window offset and sending the correct value to Wine.
The patch other users have been reporting is to delete the check for (event_root == root_window), which also doesn't fix where menus appear, but what are the other avenues for getting to (pt->x, pt->y)?
1. Somehow making window = root_window. I don't believe this is possible, right? 2. Making event_root not root_window.
I don't know where event_root comes from. I only know from the above trace that window 2000003 has some extra note, "root_coords 0" where the others have 1.
Other possibilities:
There are a handful of XCB events that are not handled by yabridge, notably XCB_MAP_NOTIFY and XCB_UNMAP_WINDOW. The former happens twice when the plugin is opened (coincidentally the same number of times a reparent occurs) while the latter seems to eventually follow each mouse click event (whether these clicks land on the plugin window or not).
Whether or not yabridge is missing something or the Wine code does not handle this use case, one solution is to create a flag/argument and then use the original (pt->x, pt->y) coordinates---for both mouse events and showing menus---and yabridge calls yabridge-host.exe with the argument.
https://bugs.winehq.org/show_bug.cgi?id=57603
--- Comment #10 from PennRobotics irischer.posaunist@gmail.com --- Created attachment 78111 --> https://bugs.winehq.org/attachment.cgi?id=78111 debug log from 10.2-62-g974c3c9b2b9
A merge request, https://gitlab.winehq.org/wine/wine/-/merge_requests/7429 , seems to fix this bug.
This log is generated by yabridge-host.exe and includes the Wine output but has a slightly different format.
WINEDEBUG=+x11drv,+event,+cursor,+win,+msg,+message,+hid YABRIDGE_DEBUG_FILE=yabridge-log.txt YABRIDGE_DEBUG_LEVEL=1+editor
https://bugs.winehq.org/show_bug.cgi?id=57603
--- Comment #11 from PennRobotics irischer.posaunist@gmail.com --- Clicking and dragging work, but context menus still show up in the wrong location. I could open a separate bug since this one relates to mouse clicks and the context menu for my program always opens at the same global screen coordinate (no matter where the window is moved)
https://bugs.winehq.org/show_bug.cgi?id=57603
Rémi Bernon rbernon@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |rbernon@codeweavers.com
--- Comment #12 from Rémi Bernon rbernon@codeweavers.com --- This should probably be fixed in yabridge. https://github.com/robbert-vdh/yabridge/pull/405 should make things work without any change to Wine.
https://bugs.winehq.org/show_bug.cgi?id=57603
--- Comment #13 from Manuel Barrio Linares mbarriolinares@gmail.com --- (In reply to Rémi Bernon from comment #12)
This should probably be fixed in yabridge. https://github.com/robbert-vdh/yabridge/pull/405 should make things work without any change to Wine.
I've tested that patched yabridge with wine 10.2, it didn't fix the issue
Tested with "carla" and "https://www.bluecataudio.com/Products/Bundle_AllPluginsPack/"
https://bugs.winehq.org/show_bug.cgi?id=57603
--- Comment #14 from Rémi Bernon rbernon@codeweavers.com --- Could you attach the log file when running with `WINEDEBUG=+x11drv,+event,+cursor YABRIDGE_DEBUG_FILE=yabridge-log.txt YABRIDGE_DEBUG_LEVEL=1+editor`?
https://bugs.winehq.org/show_bug.cgi?id=57603
--- Comment #15 from Manuel Barrio Linares mbarriolinares@gmail.com --- Created attachment 78116 --> https://bugs.winehq.org/attachment.cgi?id=78116 yabridge-log.txt
patched yabridge with this pull: https://github.com/robbert-vdh/yabridge/pull/405
Running "Carla" with this command:
WINEDEBUG=+x11drv,+event,+cursor YABRIDGE_DEBUG_FILE=yabridge-log.txt YABRIDGE_DEBUG_LEVEL=1+editor carla
Added a plugin, opened it, mouse clicks are not where they are supposed to be. Moved the plugin window to the top-left of the screen. Now mouse clicks are registered where they are supposed to be.
https://bugs.winehq.org/show_bug.cgi?id=57603
--- Comment #16 from Rémi Bernon rbernon@codeweavers.com --- The log shows "Initializing yabridge version 5.1.1" without a git hash, and the log doesn't have any of the new "MapRequest / ConfigureRequest" events that the MR adds, which tells me that it's still using the system version.
Please make sure that you are using the actual yabridge version that you built. It probably needs PATH / LD_LIBRARY_PATH to be adjusted to make the built version take precedence over the system one.
https://bugs.winehq.org/show_bug.cgi?id=57603
--- Comment #17 from Manuel Barrio Linares mbarriolinares@gmail.com --- Created attachment 78117 --> https://bugs.winehq.org/attachment.cgi?id=78117 yabridge-log.txt
I confirm I was and am running the latest master branch, I just didn't update the package name. Here is the PKGBUILD i use to build: https://pastebin.com/jXarsUP7
Patched yabridge with this pull: https://github.com/robbert-vdh/yabridge/pull/405
Running "Carla" with this command:
WINEDEBUG=+x11drv,+event,+cursor YABRIDGE_DEBUG_FILE=yabridge-log.txt YABRIDGE_DEBUG_LEVEL=1+editor carla
Added a plugin, opened it, mouse clicks are not where they are supposed to be. Moved the plugin window to the top-left of the screen. Now mouse clicks are registered where they are supposed to be.
https://bugs.winehq.org/show_bug.cgi?id=57603
--- Comment #18 from Manuel Barrio Linares mbarriolinares@gmail.com --- (In reply to Rémi Bernon from comment #16)
The log shows "Initializing yabridge version 5.1.1" without a git hash, and the log doesn't have any of the new "MapRequest / ConfigureRequest" events that the MR adds, which tells me that it's still using the system version.
Please make sure that you are using the actual yabridge version that you built. It probably needs PATH / LD_LIBRARY_PATH to be adjusted to make the built version take precedence over the system one.
Check the new log. I see MapRequest there, I don't see ConfigureRequest.
https://bugs.winehq.org/show_bug.cgi?id=57603
--- Comment #19 from Rémi Bernon rbernon@codeweavers.com --- Yes thanks, I think I can see what went wrong here and made an update on the yabridge PR, let's move the discussion to https://github.com/robbert-vdh/yabridge/pull/405 if you don't mind, as it's more a yabridge bug than a Wine bug.
https://bugs.winehq.org/show_bug.cgi?id=57603
Manuel Barrio Linares mbarriolinares@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Resolution|--- |NOTOURBUG
--- Comment #20 from Manuel Barrio Linares mbarriolinares@gmail.com --- Fixed in https://github.com/robbert-vdh/yabridge/pull/405