xeyes works as expected now. subwindows are popped also as expected. This
patch should fix the following:
https://bugs.freedesktop.org/show_bug.cgi?id=59983
Signed-off-by: Tiago Vignatti <tiago.vignatti@intel.com>
We used to rely on an ugly hack where the xwayland server would always
report RGB X windows as having ARGB pixels, so that texturing from these
would also sample the undefined alpha. We also relied on Xrender rendering
to RGB X windows to write the alpha channel correctly, so that when we
texture from the RGB X window as an ARGB surface we end up getting the
alpha written by Xrender.
That was obviously all broken. We can instead reparent client windows into
ARGB frame windows. That way we can render the decorations using a
ARGB render pictformat and sample back those alpha values in a well-defined
way. We can also unbreak xwayland and let it report RGB pixel format for
RGB windows. We still need the opaque region or the RGB-only client window
but that's OK.
Xeyes is the counter-example that fails on that heuristic and won't be caught
on kill binding. This and the last two patches should fix:
https://bugs.freedesktop.org/show_bug.cgi?id=53679
Signed-off-by: Tiago Vignatti <tiago.vignatti@intel.com>
On X the global absolute coordinates are sent in ConfigureNotify and transient
windows are mapped exactly on that position. On Wayland we don't have the
concept of global coordinates, and that's a problem for transient surfaces
without transient_for set because they rely on such hint for setting their
positioning.
So this solution is a workaround. It guesses a parent based on the last
focused window to determine the relative position of the transient surface.
This put transient windows of Chrome browser back to work.
Signed-off-by: Tiago Vignatti <tiago.vignatti@intel.com>
We just print properties when they change now instead of dumping all
properties whenever we re-read them. Also, make the property output a
little more concise.
Kristian Høgsberg
Tiago Vignatti