| Bug ID | 108095 |
|---|---|
| Summary | Window becomes partially transparent for short time |
| Product | DRI |
| Version | DRI git |
| Hardware | Other |
| OS | All |
| Status | NEW |
| Severity | normal |
| Priority | medium |
| Component | DRM/AMDgpu |
| Assignee | dri-devel@lists.freedesktop.org |
| Reporter | pmenzel+bugs.freedesktop@molgen.mpg.de |
Created attachment 141774 [de=
tails]
(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 diffe= rence? xfwm4 --replace --vblank=3Doff xfwm4 --replace --vblank=3Dglx xfwm4 --replace --vblank=3Dxpresent
(In reply to Michel D=C3=A4nzer from comment #5) > Does restarting xfwm4 with any of these argument= s make a difference? >=20 > xfwm4 --replace --vblank=3Doff > xfwm4 --replace --vblank=3Dglx > xfwm4 --replace --vblank=3Dxpresent The user wasn=E2=80=99t able to reproduce the problem with `xfwm4 --replace --vblank=3Doff` yet. Should he also test the other suggestions nevertheless= ?
(In reply to Paul Menzel from comment #6) > The user wasn=E2=80=99t able to reproduce the pr= oblem with `xfwm4 --replace > --vblank=3Doff` yet. Should he also test the other suggestions neverth= eless? 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=E2=80=99t hav=
e 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=E2=80=99s really no driver bug.
| What | Removed | Added |
|---|---|---|
| Version | DRI git | git |
| Product | DRI | Mesa |
| Component | DRM/AMDgpu | GLX |
| QA Contact | mesa-dev@lists.freedesktop.org | |
| Assignee | dri-devel@lists.freedesktop.org | mesa-dev@lists.freedesktop.org |
I think this is because the glXWaitX implementation in Mesa is= n'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.