Bug 417455

Effects me as well.

STEPS TO REPRODUCE
1. Set comositor to XRender
2. Enable xorg running in 10bit/30bpp via DefaultDepth in 20-amdgpu.conf
3. Reboot
4. Login via SDDM
5. Change compositor to OpenGL 2.0 or 3.1
6. Black screen with cursor (cursor changes shape according to the invisible windows when moved)


SOFTWARE/OS VERSIONS
Linux host 5.6.0-rc1-1-mainline #1 SMP PREEMPT Sat, 15 Feb 2020 00:48:40 +0000 x86_64 GNU/Linux

KDE Plasma Workspace 5.18.0
KDE Frameworks 5.67.0
Qt 5.14.1 (kompiliert gegen 5.14.1)
mesa-git 20.1.0_devel.120193.8f5a252d350-1

ADDITIONAL INFORMATION
Navi 14 [Radeon RX 5500/5500M / Pro 5500M] (rev c5)

(In reply to yankee from comment #0)
> SUMMARY
> Black screen with compositor turned on in OpenGL mode. No black screen with
> compositor in XRender or compositor turned off. 
> No black screen in Gnome/xorg or starting plasmashell via terminal in Gnome
> desktop environment (with compositor turned on in OpenGL mode)
> 
> STEPS TO REPRODUCE
> 1. Enable xorg running in 10bit/30bpp via DefaultDepth in 20-amdgpu.conf 
> 2. Turn compositor on in OpenGL mode
> 3. Logout/restart  & login via SDDM
> 
> OBSERVED RESULT
> black screen with mouse cursor after SDDM login and start screen.
> 
> SOFTWARE/OS VERSIONS
> KDE Plasma Version: 5.17.5
> KDE Frameworks Version: 5.66.0
> Qt Version: 5.14.1
> 
> ADDITIONAL INFORMATION
> Amd Radeon Vega64


Update:

No problems detected with AMD RX 580 on same OS specifications on another device.
Worked with OpenGL based compositor and 10 bits on xorg with AMDGPU_PRO OpenGL drivers on this device.
Suppose that this error depends on drivers installed.

Affecting me with a 5700 XT. Using plasma-desktop 5.18.0 on kernel 5.5

I have the same issue on a 5700xt with AMDGPU - XRender works, OpenGL causes black screen when compositing is enabled but cursor always works perfectly. However with AMDGPU Pro the OpenGL backend works fine.

Plasma 5.18.2 (on Arch Linux)
Linux 5.5.6
amdgpu 19.1.0
andgpu-pro 19.30

AMDGPU Pro is a proprietary overlay on top of the FOSS AMDGPU driver that provides 'enhanced' OpenGL/OpenCL/Vulkan implementations, for me I just had to install the amdgpu-pro-libgl Arch AUR package to get the OpenGL part and make kwin work.

With 10bpc AMDGPU and XRender text also gets purple fringing, noticeable in the settings screen to change the compositing backend and also in other applications like Dolphin. This doesn't happen at 8bpc with AMDGPU, or with AMDGPU Pro on XRender or OpenGL at 10bpc. Overall it seems like there are issues with the free AMD drivers, not with kwin.

Had the same issue(open source AMDGPU) it appears that something is broken in their glx backend. My solution was to switch to egl. You could try it, just create ~/.config/plasma-workspace/env/use_egl.sh with 

export KWIN_OPENGL_INTERFACE=egl

inside.
There is still other issues like spectacle capture inverted colors, but in general everything looks fine.

I also encounter the same issues. What bothers me is that no one seems to show any interest in fixing them...

BTW, using 10 bits + egl caused me so many issues (random crashes in chromium based browsers...) that it's a no go...


Radeon RX 550 Series (POLARIS11, DRM 3.35.0, 5.4.0-31-generic, LLVM 9.0.1)

Operating System: Kubuntu 20.04
KDE Plasma Version: 5.18.5
KDE Frameworks Version: 5.68.0
Qt Version: 5.12.8
Kernel Version: 5.4.0-31-generic
OS Type: 64-bit

Do I understand correctly that this issue is only present when using 30bpp depth?

Yes, based on my experience and what other comments have said, this is the situation:

8 bit: Works fine in any configuration

10 bit AMDGPU: Works only with egl backend, compositing fails without specifying egl. Appears to be a bug in the AMD drivers, because:

10 bit AMDGPU Pro: Works out of the box with the default backend. No idea how this one works with egl.

Regardless, any 10bpc configuration causes issues with applications like VLC, Chromium, etc. But those shouldn't be relevant here; KWin appears to be working fine.

> What bothers me is that no one seems to show any interest in fixing them...
Given that this requires a relatively high-end monitor, and possibly also a relatively high-end graphics card, to reproduce and most of the people working on KWin aren't paid to do it, this isn't very surprising. You should bring this up with the AMD and Chromium devs, they're the ones getting paid by AMD and Google to make sure their products work well (unless 10bpc with/without egl works fine in GNOME or another DE, in which case this is actually a KDE bug - anyone want to test?).

Just tested this on ArchLinux with:

kwin 5.18.5-1
libdrm 2.4.101-1
mesa 20.0.7-3
xf86-video-amdgpu 19.1.0-2

After logging in from sddm, I just get blank screen (mouse cursor moves normally).
Killing kwin_x11 causes konsole to re-appear. I don't have other X11 window managers installed to test with.

Setting KWIN_OPENGL_INTERFACE=egl as suggested in comment #5 did not help.

Happy to run further tests if necessary.

Xorg.0.log confirms that the server is running in 10bpp:


[  8387.363] (II) AMDGPU(0): Creating default Display subsection in Screen section
        "default" for depth/fbbpp 30/32
[  8387.363] (**) AMDGPU(0): Depth 30, (--) framebuffer bpp 32
[  8387.363] (II) AMDGPU(0): Pixel depth = 30 bits stored in 4 bytes (32 bpp pixmaps)
[  8387.363] (==) AMDGPU(0): Default visual is TrueColor
[  8387.363] (**) AMDGPU(0): Option "VariableRefresh" "true"
[  8387.363] (==) AMDGPU(0): RGB weight 101010
[  8387.363] (II) AMDGPU(0): Using 10 bits per RGB (8 bit DAC)
[  8387.363] (--) AMDGPU(0): Chipset: "Radeon RX Vega" (ChipID = 0x687f)

...

[  8387.411] (II) AMDGPU(0): glamor X acceleration enabled on Radeon RX Vega (VEGA10, DRM 3.36.0, 5.6.14-arch1-1, LLVM 10.0.0)
[  8387.411] (II) AMDGPU(0): glamor detected, initialising EGL layer.
[  8387.411] (==) AMDGPU(0): TearFree property default: auto
[  8387.411] (**) AMDGPU(0): VariableRefresh: enabled
[  8387.411] (II) AMDGPU(0): KMS Pageflipping: enabled
...
[  8387.425] (II) AMDGPU(0): 10 bits per channel

Here we go again.

It should be the target to enable 10 bits via AMDGPU FOSS drivers.

Another point, @bernie@codewiz.org 

Xorg tells you that DAC is 8 bits. So, you still have no 10 bits on your monitor. Your EDID is blocking. Check your EDID first.
This was another problem. My monitor has a bug in the EDID. On Windows, I modified the EDID via CustomResolutionUtility aka CRU.
On Linux, there is a tool, called wxEDID, but it is extreme buggy. You need to tell xorg, that the monitor can handle 10 bits. So, check your EDID.

It is a never ending story. How can the industry sell that bullshit. No casual customer can handle that.

This is not a KWin issue; please report it to the developers of the AMD drivers. There isn't anything we can do here to work around broken drivers. Ultimately the responsible party is AMD.

The reason I thought it depends on KDE was that I had no problems with 10bit/30bpp and OpenGL compositor enabled when I started a GNOME session. Perhaps, sb can confirm that it works under GNOME, XFCE, ..., with FOSS drivers.

(In reply to Nate Graham from comment #12)
> This is not a KWin issue; please report it to the developers of the AMD
> drivers. There isn't anything we can do here to work around broken drivers.
> Ultimately the responsible party is AMD.

I'd be happy to file a bug upstream, but first I need to know:

1. is the AMD bug in the mesa gallium driver, kernel amdbgpu module, or in the X11 DDX (
xf86-video-amdgpu)?
2. what is KWin doing to trigger it? The depth 30 display works just fine until KWin starts.

The issue disappeared after updating to mesa 20.1.0-1 and linux 5.6.15.arch1-1.

xdpyinfo shows the X server is using 30bpp:

screen #0:
  dimensions:    3440x1440 pixels (910x381 millimeters)
  resolution:    96x96 dots per inch
  depths (8):    30, 1, 4, 8, 15, 16, 24, 32
  root window id:    0x70a
  depth of root window:    30 planes
  number of colormaps:    minimum 1, maximum 1
  default colormap:    0x20
  default number of colormap cells:    1024
  preallocated pixels:    black 0, white 1073741823
  options:    backing-store WHEN MAPPED, save-unders NO
  largest cursor:    128x128
  current input event mask:    0xfa8033
    KeyPressMask             KeyReleaseMask           EnterWindowMask          
    LeaveWindowMask          ExposureMask             StructureNotifyMask      
    SubstructureNotifyMask   SubstructureRedirectMask FocusChangeMask          
    PropertyChangeMask       ColormapChangeMask       
  number of visuals:    504
  default visual id:  0x21
  visual:
    visual id:    0x21
    class:    TrueColor
    depth:    30 planes
    available colormap entries:    1024 per subfield
    red, green, blue masks:    0x3ff00000, 0xffc00, 0x3ff
    significant bits in color specification:    10 bits

The issue is gone for me too on up-to-date Arch Linux, so it seems this is fully resolved. Applications like Spectacle and VLC still have some fails with 10bpc, but KWin & compositing work with no issues.

> Applications like Spectacle and VLC still have some fails with 10bpc [...]

I have a fix out for Spectacle:
  https://invent.kde.org/graphics/spectacle/-/merge_requests/10

I use mpv, which works fine in 10bpc, and can output HDR video.
VLC also seems to work. Which problems did you have with it?

(In reply to Subramaniyam Raizada from comment #16)
> The issue is gone for me too on up-to-date Arch Linux, so it seems this is
> fully resolved.

Still present on Fedora 32 with kwin 5.19.3, mesa 20.1.3 and kernel 5.7.8.
Would be good to pinpoint which particular component in Arch Linux fixed the bug.

Let's continue in Bug 423014.

*** This bug has been marked as a duplicate of bug 423014 ***