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@winehq.org Reporter: anton.kalmykov@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.
https://bugs.winehq.org/show_bug.cgi?id=39440
--- Comment #1 from phant0m anton.kalmykov@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.
https://bugs.winehq.org/show_bug.cgi?id=39440
Sebastian Lackner sebastian@fds-team.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |sebastian@fds-team.de
https://bugs.winehq.org/show_bug.cgi?id=39440
phant0m anton.kalmykov@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #52555|0 |1 is obsolete| |
--- Comment #2 from phant0m anton.kalmykov@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.
https://bugs.winehq.org/show_bug.cgi?id=39440
--- Comment #3 from Sebastian Lackner sebastian@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 ---
https://bugs.winehq.org/show_bug.cgi?id=39440
--- Comment #4 from phant0m anton.kalmykov@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
https://bugs.winehq.org/show_bug.cgi?id=39440
--- Comment #5 from Sebastian Lackner sebastian@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?
https://bugs.winehq.org/show_bug.cgi?id=39440
--- Comment #6 from phant0m anton.kalmykov@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.
https://bugs.winehq.org/show_bug.cgi?id=39440
Alexandre Bique bique.alexandre@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |bique.alexandre@gmail.com
https://bugs.winehq.org/show_bug.cgi?id=39440
winetest@luukku.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |winetest@luukku.com
--- Comment #7 from winetest@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.
https://bugs.winehq.org/show_bug.cgi?id=39440
Stan markau0@lycos.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |markau0@lycos.com
--- Comment #8 from Stan markau0@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.
https://bugs.winehq.org/show_bug.cgi?id=39440
--- Comment #9 from Alexandre Bique bique.alexandre@gmail.com --- This bug is assigned to Mr. Bugs, so no one is going to fix it right?
https://bugs.winehq.org/show_bug.cgi?id=39440
Fabian Maurer dark.shadow4@web.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |dark.shadow4@web.de
--- Comment #10 from Fabian Maurer dark.shadow4@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.
https://bugs.winehq.org/show_bug.cgi?id=39440
--- Comment #11 from Stan markau0@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.
https://bugs.winehq.org/show_bug.cgi?id=39440
--- Comment #12 from phant0m anton.kalmykov@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.
https://bugs.winehq.org/show_bug.cgi?id=39440
--- Comment #13 from Stan markau0@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.
https://bugs.winehq.org/show_bug.cgi?id=39440
--- Comment #14 from Austin English austinenglish@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.
https://bugs.winehq.org/show_bug.cgi?id=39440
--- Comment #15 from Stan markau0@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?
https://bugs.winehq.org/show_bug.cgi?id=39440
--- Comment #16 from Stan markau0@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.
https://bugs.winehq.org/show_bug.cgi?id=39440
--- Comment #17 from Austin English austinenglish@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
https://bugs.winehq.org/show_bug.cgi?id=39440
Sebastian Lackner sebastian@fds-team.de changed:
What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.winehq.org/sho | |w_bug.cgi?id=43711
https://bugs.winehq.org/show_bug.cgi?id=39440
--- Comment #18 from Stan markau0@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.
https://bugs.winehq.org/show_bug.cgi?id=39440
Alexey Chernov 4ernov@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |4ernov@gmail.com
--- Comment #19 from Alexey Chernov 4ernov@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.
-
wine-bugs＠winehq.org