Created attachment 141774 [details] (manually edited) screenshot showing the problem With Linux 4.14.55 and 4.19-rc5 (drm-tip), Xfce 4.13 and the Radeon device below, a user reports, that sometimes parts of the terminal window (Xfce and GNOME Terminal) get transparent. $ lspci -nn -s 65:00.0 65:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. [AMD/ATI] Lexa XT [Radeon PRO WX 3100] [1002:6985] After one or two seconds the problem fixes itself. Nothing is in the Linux logs regarding this issue.
Please attach the corresponding Xorg log file and the outputs of dmesg and glxinfo.
Created attachment 141778 [details] Linux 4.14.55 messages
Created attachment 141779 [details] /var/log/gdm/:0.log
Created attachment 141818 [details] Output of `glxinfo` Please find the output of `glxinfo` attached. Here is an excerpt. ``` Extended renderer info (GLX_MESA_query_renderer): Vendor: X.Org (0x1002) Device: AMD Radeon Pro WX3100 (POLARIS12, DRM 3.19.0, 4.14.55.mx64.224, LLVM 6.0.1) (0x6985) Version: 18.1.6 Accelerated: yes Video memory: 4096MB Unified memory: no Preferred profile: core (0x1) Max core profile version: 4.5 Max compat profile version: 3.1 Max GLES1 profile version: 1.1 Max GLES[23] profile version: 3.1 ```
Does restarting xfwm4 with any of these arguments make a difference? xfwm4 --replace --vblank=off xfwm4 --replace --vblank=glx xfwm4 --replace --vblank=xpresent
(In reply to Michel Dänzer from comment #5) > Does restarting xfwm4 with any of these arguments make a difference? > > xfwm4 --replace --vblank=off > xfwm4 --replace --vblank=glx > xfwm4 --replace --vblank=xpresent The user wasn’t able to reproduce the problem with `xfwm4 --replace --vblank=off` yet. Should he also test the other suggestions nevertheless?
(In reply to Paul Menzel from comment #6) > The user wasn’t able to reproduce the problem with `xfwm4 --replace > --vblank=off` yet. Should he also test the other suggestions nevertheless? Yes, please. It'll be valuable to know if it happens with both of the other ones, or only one of them.
libXpresent was not installed here, so xfwm didn’t have support for it. ``` $ xfwm4 --version This is xfwm4 version 4.13.1 (revision 942156e4) for Xfce 4.12 Released under the terms of the GNU General Public License. Compiled against GTK+-3.22.30, using GTK+-3.22.30. Build configuration and supported features: - Startup notification support: Yes - XSync support: Yes - Render support: Yes - Xrandr support: Yes - Xpresent support: No - Embedded compositor: Yes - Epoxy support: Yes - KDE systray proxy (deprecated): No ``` Installing libXpresent and rebuilding xfwm, the report that everything works now. As I do not know the dependencies between all components, I cannot say, that it’s really no driver bug.
I think this is because the glXWaitX implementation in Mesa isn't reliable. xfwm4 relies on it to synchronize between X11 protocol drawing to a pixmap and sampling from an OpenGL texture bound to the corresponding GLXPixmap via GLX_EXT_texture_from_pixmap.
Specifically, with xfwm4, loader_dri3_wait_x() is currently a no-op, because draw->have_fake_front is false.
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/mesa/mesa/issues/114.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.