XWayland misrendering when switching from gui applications from maximized to half screen

Daniel Stone @daniels said:

Jason, any bright ideas? I don't really know the relevant codepaths at all.

Denis said:

Hi. I also can reproduce the issue on this configuration (quite similar to your):

CPU model name: Intel(R) Core(TM) i7-7700U CPU @ 4.20GHz HD Graphics 620 (Kaby Lake GT2) Operating System: Debian GNU/Linux buster/sid Kernel: Linux 4.17.0-1-amd64 GNOME Shell 3.28.3 xwayland 1.20 Mesa 18.1.5

In addition to provided list checked and chromium - it behaves at the most crazy way - you need to put it to the windows mode (somewhere in the middle of the screen) and drag with mouse - you will see big black parts on it, or same corruptions, which were provided by Mark)

vadym said:

Able to reproduce this on KBL as well. But for me same issue is also reproducible with the llvmpipe:

LIBGL_ALWAYS_SOFTWARE=true /usr/bin/firefox

vadym said:

Bug is reproduced only with apps which are using XWayland. Otherwise if app using Wayland natively bug is not reproduced.

With XWayland downgraded to 1.19.2-1 version issue is gone. So looks like this is a regression in Xwayland.

vadym submitted a patch:

Patch 141025, "Patch":
0001-autotools-Handle-case-when-bindir-var-in-xkbcomp.pc-.patch

vadym said:

Issue bisected in Xserver:

72683945 is the first bad commit commit 72683945 Author: Adam Jackson ajax@redhat.com Date: Wed Mar 28 16:11:18 2018 -0400

autotools: Derive xkb configuration from xkbcomp.pc

... if available, falling back to the current heuristics otherwise. This
_finally_ gets me to being able to run util/modular/release.sh without
overriding $prefix.

Signed-off-by: Adam Jackson <ajax@redhat.com>

Problem is that bindir variable is absent in /usr/share/pkgconfig/xkbcomp.pc. And this case is handled incorrectly in configure file in the following line:

pkg-config --variable bindir xkbcomp || echo ${bindir}

Patch with fix is attached.

Denis said:

Applied the patch and build Xwayland using this manual https://wayland.freedesktop.org/ubuntu16.04.html

Upd - after exchanging your original Xwayland with a new one - need to reboot - log off will not work. I couldn’t reproduce the issue then.

Video with patch available in link below:

https://drive.google.com/open?id=1SMJD14e7E1FGKNGp-TMHZjLVHsdrQFvC

Adam Jackson @ajax said:

Applied the above xkbcomp patch, for what it's worth; I don't claim to know whether this bug is fixed though, and I'm seriously baffled how xkbcomp could be responsible.

added Xwayland label

Amazing, it's easily reproducible as described (tiling to left and right quickly back and forth using [Super] [←] [→]) in GNOME on Wayland session.

It doesn't affect all apps though, just some.

For example, google-chrome with hardware rendering is not affected, whereas firefox (with CSD) is.

Similarly, GDK_BACKEND=x11 gtk3-demo also reproduce it.

But plain old xterm doesn't...

/me trying to figure what's the relevant difference between those apps.

Good news, this is not related to Present support added in 1.20, diabling Present support in Xwayland does not solve the issue.

But this is related to glamor, disabling glamor (export XWAYLAND_NO_GLAMOR=1) fixes the issue.

Can't seem to reproduce with amdgpu. Given that and the look of the corruption, could be modifier related?

Previous comments said it's a regression from 1.19, but bisecting pointed to an XKB commit, which doesn't make sense. Might be worth bisecting again.

Yes, exactly my thought... The commit just before the modifiers landed works.

The XKB commit makes no sense to me either.

From what I can see:

commit 9d147305 is good

commit ce8da936 is bad

That limits the scope for the bisect... :)

So, yes, without much surprise, this came out of the bisection:

8d0d8971 is the first bad commit
commit 8d0d8971
Author: Louis-Francis Ratté-Boulianne lfrb@collabora.com
Date: Wed Feb 28 01:19:45 2018 +0000
glamor: Use gbm_bo_create_with_modifiers for internal pixmap allocation

Using modifier might allow the driver to use a more optimal format
(e.g. tiled/compressed). Let's try to use those if possible.

v2: Don't filter out multi-plane modifiers

Signed-off-by: Louis-Francis Ratté-Boulianne <lfrb@collabora.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Acked-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
:040000 040000 99221cad545ac26d319fa29ae343b575cd23ddd3 3616cdeffe6606a90d0fcd10b7801e71f1655abe M glamor
:040000 040000 0689a4e3646bf4938f44e4532af5bd666aa6478d a6e32d92dfd87892225a511fbfec964e277a0b39 M hw

added glamor label

Right, so the commit itself doesn't help much, as expected (there is nothing actually wrong with it, it's just enabling the functionality)

But I made some more tests, the content itself is not corrupted, it's the alpha channel only which is corrupted apparently, which explains why plain old X11 apps aren't effected...

I made the test with a plain X11 app using an ARGB visual and transparency and the issue is reproducible with it as well.

Also the issue occurs only when the window is not resized (as with tiling from left to right), as soon as the size changes, the content is restored.

Humm, I could be wrong, but I suspect a bug in Mesa rather then Xwayland...

mentioned in issue #728 (closed)

I ran some more tests, I think the issue occurs even on X11 but only when transitioning, the client is eventually repainted on X11 so the final state is fine. But looking closely at the screencasts below, the content of the window while moving from left to right and vice-versa ([Super] + [←], [Super] + [→] in GNOME Shell) is corrupted even on X11:

x11