[Bug 39440] New: embedded (XEMBED) windows are blank
https://bugs.winehq.org/show_bug.cgi?id=39440 Bug ID: 39440 Summary: embedded (XEMBED) windows are blank Product: Wine Version: 1.7.52 Hardware: x86 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: winex11.drv Assignee: wine-bugs(a)winehq.org Reporter: anton.kalmykov(a)gmail.com Distribution: --- Created attachment 52555 --> https://bugs.winehq.org/attachment.cgi?id=52555 patch file I'm the author of airwave VST bridge (https://github.com/phantom-code/airwave). My project is intended to use Windows VST plugins in Linux VST hosts (Bitwig Studio, Ardour, etc). This task involves embedding the VST plugin window inside of the VST host window (I use the XEMBED protocol to achieve this functionality). The problem here is that after sending XEMBED_EMBEDDED_NOTIFY message, the embedding window stays blank. I was able to workaround this issue by inserting some delays (https://github.com/phantom-code/airwave/blob/master/src/plugin/plugin.cpp#L3...), but this "solution" doesn't work in all cases. I've changed a few lines in winex11.drv code (patch is attached) and it helped to solve the "blank window" issue, but this is only a workaround (I don't know how to do a correct fix). Anyway, increasing the size of embedded window will cause appearing of additional blank regions. -- 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.
https://bugs.winehq.org/show_bug.cgi?id=39440 --- Comment #1 from phant0m <anton.kalmykov(a)gmail.com> --- Created attachment 52556 --> https://bugs.winehq.org/attachment.cgi?id=52556 Simple code to demonstrate the bug I've created a simple program, which can help to catch this issue (see it in the attachments). You can build it via simple "make" command and run the "embedder" binary. Ideally, you should see the white square (embedded window) on the black background. But all window will be black. The child embedded window isn't visible without my patch. -- 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.
https://bugs.winehq.org/show_bug.cgi?id=39440 Sebastian Lackner <sebastian(a)fds-team.de> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |sebastian(a)fds-team.de -- 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.
https://bugs.winehq.org/show_bug.cgi?id=39440 phant0m <anton.kalmykov(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #52555|0 |1 is obsolete| | --- Comment #2 from phant0m <anton.kalmykov(a)gmail.com> --- Created attachment 52559 --> https://bugs.winehq.org/attachment.cgi?id=52559 Fix visibility of the embedded windows It seems that I've fixed also a resize issue. The patch is updated. -- 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.
https://bugs.winehq.org/show_bug.cgi?id=39440 --- Comment #3 from Sebastian Lackner <sebastian(a)fds-team.de> --- Your embedder code does not following the XEMBED specification correctly. The specification says, that the embedder is responsible to map/unmap the client, depending on the XEMBED_MAPPED property: --- snip --- XEMBED_MAPPED If set the client should be mapped. The embedder must track the flags field by selecting for PropertyNotify events on the client and map and unmap the client appropriately. (The embedder can leave the client unmapped when this bit is set, but should immediately unmap the client upon detecting that the bit has been unset.) Rationale: the reason for using this bit rather than MapRequest events is so that the client can reliably control it's map state before the inception of the protocol without worry that the client window will become visible as a child of the root window. --- snip --- -- 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.
https://bugs.winehq.org/show_bug.cgi?id=39440 --- Comment #4 from phant0m <anton.kalmykov(a)gmail.com> --- Thanks for your comment, Sebastian. That was my fault that I didn't implement the handling of PropertyNotify. But now I've implemented it and it seems that resizing issue is still present. The first section of my patch file is still needed to fix the issue. PS: Just in case my English is not good enough, here is a video, demonstrating the "size increasing issue": https://dl.dropboxusercontent.com/u/33529975/resize-issue.ogv -- 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.
https://bugs.winehq.org/show_bug.cgi?id=39440 --- Comment #5 from Sebastian Lackner <sebastian(a)fds-team.de> --- (In reply to phant0m from comment #4)
Thanks for your comment, Sebastian. That was my fault that I didn't implement the handling of PropertyNotify. But now I've implemented it and it seems that resizing issue is still present. The first section of my patch file is still needed to fix the issue.
Can you provide the updated test code? -- 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.
https://bugs.winehq.org/show_bug.cgi?id=39440 --- Comment #6 from phant0m <anton.kalmykov(a)gmail.com> --- Created attachment 52606 --> https://bugs.winehq.org/attachment.cgi?id=52606 Updated example code Sure, I've attached the updated example code. But it's impossible to demonstrate the problem using this example (it doesn't load a real VST plugin). Also, I can push the updated airwave code to github if needed. -- 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.
https://bugs.winehq.org/show_bug.cgi?id=39440 Alexandre Bique <bique.alexandre(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |bique.alexandre(a)gmail.com -- 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.
https://bugs.winehq.org/show_bug.cgi?id=39440 winetest(a)luukku.com changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |winetest(a)luukku.com --- Comment #7 from winetest(a)luukku.com --- Since there has been no update for this long time, could you suggest your patch at wine-patches list or ask opinions at wine-devel list? Patch sitting here doesn't help anyone. It would be more fruitful to get it merged at wine or wine-staging. -- 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.
https://bugs.winehq.org/show_bug.cgi?id=39440 Stan <markau0(a)lycos.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |markau0(a)lycos.com --- Comment #8 from Stan <markau0(a)lycos.com> --- I can confirm that this bug still exists in the latest Wine versions. After a XEMBED_EMBEDDED_NOTIFY has been sent to a reparented Linux Daw window using __wine_x11_whole_window for the reparent, the resulting window can be blank or half show up and/or not be in a usable state. -- 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.
https://bugs.winehq.org/show_bug.cgi?id=39440 --- Comment #9 from Alexandre Bique <bique.alexandre(a)gmail.com> --- This bug is assigned to Mr. Bugs, so no one is going to fix it right? -- 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.
https://bugs.winehq.org/show_bug.cgi?id=39440 Fabian Maurer <dark.shadow4(a)web.de> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |dark.shadow4(a)web.de --- Comment #10 from Fabian Maurer <dark.shadow4(a)web.de> ---
This bug is assigned to Mr. Bugs, so no one is going to fix it right?
Uh, most bugs are assigned to Mr. Bugs. It just means that currently no developer is assigned this bug. -- 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.
https://bugs.winehq.org/show_bug.cgi?id=39440 --- Comment #11 from Stan <markau0(a)lycos.com> --- Who is this Mr Bugs, Bugs Bunny or maybe Harvey the invisible Rabbit. This bug has been sitting here for nearly 2 years with the solution posted, talk about not seeing the Pink Elephant in the room or the wood for the trees. The bug is only breaking the functioning of vst's in about 4 Linux daws that's all. Someone somewhere pleaaaaaaaaaaaase take a look at it. -- 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.
https://bugs.winehq.org/show_bug.cgi?id=39440 --- Comment #12 from phant0m <anton.kalmykov(a)gmail.com> --- (In reply to Stan from comment #11)
Who is this Mr Bugs, Bugs Bunny or maybe Harvey the invisible Rabbit.
This bug has been sitting here for nearly 2 years with the solution posted, talk about not seeing the Pink Elephant in the room or the wood for the trees.
The bug is only breaking the functioning of vst's in about 4 Linux daws that's all.
Someone somewhere pleaaaaaaaaaaaase take a look at it.
I wouldn't say that my patch is a solution, it's more like a rough workaround. I didn't learn the logic of the module well when I created it. -- 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.
https://bugs.winehq.org/show_bug.cgi?id=39440 --- Comment #13 from Stan <markau0(a)lycos.com> --- (In reply to phant0m from comment #12)
(In reply to Stan from comment #11)
Who is this Mr Bugs, Bugs Bunny or maybe Harvey the invisible Rabbit.
This bug has been sitting here for nearly 2 years with the solution posted, talk about not seeing the Pink Elephant in the room or the wood for the trees.
The bug is only breaking the functioning of vst's in about 4 Linux daws that's all.
Someone somewhere pleaaaaaaaaaaaase take a look at it.
I wouldn't say that my patch is a solution, it's more like a rough workaround. I didn't learn the logic of the module well when I created it.
It's at least a starting point for a Wine dev to work with if they ever get around to appointing someone that's not an invisible rabbit. This bug has to also affect other possible apps using XEMED in the future and maybe the past. I understand that XEMBED was thrown together and is not in a complete state, so it needs a bit of a makeover. -- 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.
https://bugs.winehq.org/show_bug.cgi?id=39440 --- Comment #14 from Austin English <austinenglish(a)gmail.com> --- (In reply to Stan from comment #13)
(In reply to phant0m from comment #12)
(In reply to Stan from comment #11)
Who is this Mr Bugs, Bugs Bunny or maybe Harvey the invisible Rabbit.
This bug has been sitting here for nearly 2 years with the solution posted, talk about not seeing the Pink Elephant in the room or the wood for the trees.
The bug is only breaking the functioning of vst's in about 4 Linux daws that's all.
Someone somewhere pleaaaaaaaaaaaase take a look at it.
I wouldn't say that my patch is a solution, it's more like a rough workaround. I didn't learn the logic of the module well when I created it.
It's at least a starting point for a Wine dev to work with if they ever get around to appointing someone that's not an invisible rabbit.
Making snarky comments isn't a good way to get people interested in a bug; especially on a project that's run by volunteers. Feel free to submit your own patch instead. -- 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.
https://bugs.winehq.org/show_bug.cgi?id=39440 --- Comment #15 from Stan <markau0(a)lycos.com> --- (In reply to Austin English from comment #14)
(In reply to Stan from comment #13)
(In reply to phant0m from comment #12)
(In reply to Stan from comment #11)
Who is this Mr Bugs, Bugs Bunny or maybe Harvey the invisible Rabbit.
This bug has been sitting here for nearly 2 years with the solution posted, talk about not seeing the Pink Elephant in the room or the wood for the trees.
The bug is only breaking the functioning of vst's in about 4 Linux daws that's all.
Someone somewhere pleaaaaaaaaaaaase take a look at it.
I wouldn't say that my patch is a solution, it's more like a rough workaround. I didn't learn the logic of the module well when I created it.
It's at least a starting point for a Wine dev to work with if they ever get around to appointing someone that's not an invisible rabbit.
Making snarky comments isn't a good way to get people interested in a bug; especially on a project that's run by volunteers. Feel free to submit your own patch instead.
The comments (I wouldn't call them snaky) are in the context of this bug being nearly 2 years old since being reported and being reported with a possible starting point patch. I understand that Wine devs (and other devs) have loads of things to do, but 2 years of nothing? -- 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.
https://bugs.winehq.org/show_bug.cgi?id=39440 --- Comment #16 from Stan <markau0(a)lycos.com> --- I'll take a look at it and see what I can do and maybe post a patch. This is an unconfirmed bug assigned to Mr Bugs (no one), so if the bug actually gets looked at then that would be all that I am asking. If a bug that has possible patches doesn't even get looked at, then what is the use of posting more patches. -- 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.
https://bugs.winehq.org/show_bug.cgi?id=39440 --- Comment #17 from Austin English <austinenglish(a)gmail.com> --- There are currently 6501 open bugs, there simply isn't enough manpower to look at all of them. While sample patches are useful, patches aren't typically reviewed on bugzilla. They should be sent to wine-devel@ for feedback. See https://wiki.winehq.org/Submitting_Patches -- 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.
https://bugs.winehq.org/show_bug.cgi?id=39440 Sebastian Lackner <sebastian(a)fds-team.de> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.winehq.org/sho | |w_bug.cgi?id=43711 -- 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.
https://bugs.winehq.org/show_bug.cgi?id=39440 --- Comment #18 from Stan <markau0(a)lycos.com> --- I'll continue to test various things. This code works for Pipelight but not for a shared Linux library (in a daw host) communicating with a Wine based server. Linux shared library code child is __wine_x11_whole_window (from the Wine servers hwnd) sent to the Linux shared library from the Wine server, parent is the daw host plugin window. display = XOpenDisplay(0); XReparentWindow(display, child, parent, 0, 0); sendXembedMessage(display, child, XEMBED_EMBEDDED_NOTIFY, 0, parent, 0); XMapWindow(display, child); XSync(display, false); XFlush(display); XCloseDisplay(display); Wine server code then a message is sent to the Wine server to run ShowWindow(hwnd) and UpdateWindow(hwnd) If a 1/2 second delay is placed before calling the Wine server code, then it's sort of ok but even that can be hit/miss on different Linux setups. -- 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.
https://bugs.winehq.org/show_bug.cgi?id=39440 Alexey Chernov <4ernov(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |4ernov(a)gmail.com --- Comment #19 from Alexey Chernov <4ernov(a)gmail.com> --- Ironically, I've been trying do roughly the same functionality, as @phant0m used to do with Airwave (which worths many thanks for quite matured, but apparently nowadays unmaintained product) and faced the same issue, but after digging a little deeper into the mechanics, Wine source code and XEmbed and WINAPI specifications I tend to think the Wine implementation of XEmbed management is OK for now, and the cause of the problem is just timing/sequence violations during the opening of the windows. In short, here's what we're trying to do to make the VST plugin window content be built-in in the plugin window provided by the DAW: 1. Create "pseudo" parent window in Wine world to pass its handle as a parent window to VST routines (so that all the window content be embedded in something). 2. Get X11 window-id of this parent window and embed it to real X11 parent window (kindly passed to us by the DAW) to make it feel like the plugin visual content is embedded into plugin window opened by the DAW. So, there are 3 windows involved instead of two, as we typically can't "convert" real X11 parent window to Wine window to use it as parent there. Since step 2 implies a sequence of actions which are generally not atomic and also sometimes asynchronous, different problems may arise, from the normal expected behaviour to the described artifacts appeared. I found the following sequence working stable for me (I'll reference my code on GitLab, have just made a separate branch there especially for this report to make code links consistent over time): 1. We create "pseudo" parent window in Wine (https://gitlab.com/aclex/violin/blob/wine_bug_report_39440/src/host/wine/edi...) and starting to receive Windows messages for it. Window creation seems to be synchronous. 2. We pass the handle of this window to VST plugin as a parent window, it starts to paint etc. (https://gitlab.com/aclex/violin/blob/wine_bug_report_39440/src/host/host.h#L... but that part is not so relevant). 3. Being subscribed to the "pseudo" parent window messages, we soon receive WM_PARENTNOTIFY message with WM_CREATE parameter (https://gitlab.com/aclex/violin/blob/wine_bug_report_39440/src/host/wine/edi...), which means the plugin has done its job, created the window. We pass this message together with the updated window size to our X11/non-Wine side (https://gitlab.com/aclex/violin/blob/wine_bug_report_39440/src/host/wine/edi...). 4. On our X11 side we first resize our real parent window to the reported size, then re-parent our "pseudo" parent window (by its X11 window id found by "__wine_x11_whole_window" on Wine side and kindly passed to us from there) to the real parent window and also embed the former to the latter (https://gitlab.com/aclex/violin/blob/wine_bug_report_39440/src/plugin/plugin... https://gitlab.com/aclex/violin/blob/wine_bug_report_39440/src/plugin/editor... https://gitlab.com/aclex/violin/blob/wine_bug_report_39440/src/plugin/editor...). Now it's apparently safe to map our "pseudo" parent window finally. Carefully keeping this sequence in order is enough, to my experiments, to always have the window opened and painted stable and fine. So, my personal short conclusion is that this bug is safe to be closed on the Wine side, as I haven't found any misbehaviour, yet. Still, as I'm not an expert in this area and just has to be my knowledge refreshed after my experiments with it about a year ago, it probably might need additional research, if there's manpower/will for it. -- 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.
participants (1)
-
wine-bugs＠winehq.org