Created attachment 60025 [details] 30 bit color depth issues. Version: unspecified (using KDE 4.6.2) OS: Linux When 30 bit display color depth (DefaultDepth 30 and Depth 30) is enabled and desktop effects are enabled too the window decoration and the window shadow is not displayed correctly. When this issue happens blue/violet colors are displayed instead. Disabling deskop effects fix this issue. Reproducible: Always Steps to Reproduce: Enable 30 bit color depth and desktop effects. Hardware: nvidia quadro 4000 2 Gb Driver: nvidia-drivers-260.19.36 Section "Device" Identifier "Device0" Driver "nvidia" VendorName "NVIDIA Corporation" BoardName "Quadro 4000" EndSection Section "Screen" Identifier "Screen0" Device "Device0" Monitor "Monitor0" DefaultDepth 30 Option "TwinView" "0" Option "metamodes" "2560x1600_60 +0+0" SubSection "Display" Depth 30 EndSubSection EndSection
Created attachment 60026 [details] KDE 2 window decoration
Created attachment 60027 [details] Disabled desktop effects
the code has changed recently in master, please verify with latest git snapshots and try to keep it up to date during the next few days as it is likely to change again.
Created attachment 60032 [details] kwin from master. kwin from master (15/05/2011).
I've built kwin from master on top of kdelibs 4.6.2 (with just a couple of small hacks). As you can see in the last screenshot the bug is still there.
some documentation about 30 bit color depth: http://www.nvidia.com/docs/IO/40049/TB-04701-001_v02_new.pdf
I assume you won't consider checking for depth and disabling compositing if != 32 as a fix, right?
actually the only fix we can do is disabling compositing. Let me highlight a part of the linked documentation: > When connected to a 30-bit capable monitor, the driver by default switches to 30-bit scan out. On Windows Vista, this mode automatically disables Windows Aero regardless of whether 30-bit application is running. If Aero must be enabled (therefore reverting to 24-bit color rendering), the NVIDIA® Display Control Panel has a "Deep Color for 3D Applications" setting that can be set to “disable” (Figure 5). If we go further down the documentation, we see that we have to change the initialisation for GLX. It is unlikely that we will change this crucial code of our compositing initialization to support this mode. We don't have the manpower for it and GLX is our legacy code path. If you want to have support for it, you will have to provide a patch. As it is a change request, I set to wishlist from bug and close as wontfix, as that is probably the truth: we don't have the manpower to implement support for it.
No, that is a workaround to get an usable windeco. >I assume you won't consider checking for depth and disabling compositing if != >32 as a fix, right? Did you mean "disable compositing if bpp > 24"? 30 bpp means that you have 10 bit for each channel instead of usual 8 bits. This is really useful if you want to work on RAW images from cameras. kwin must also preserve high color depth when a window is displayed on the screen: if you manage windows as textures you have to make sure that you keep their original color depth. Anyway this bug might be a kwin bug too: https://bugs.kde.org/show_bug.cgi?id=273349 This is an interesting bug that prevents to see images with gwenview: https://bugs.kde.org/show_bug.cgi?id=273345
If you provide me some hints/small patches I can test all the code but I have no idea how to start to fix this problem. Do you expect to see any improvement in the future on new backends? Please note that this is an important feature in photo editing and it will be more and more important as more new high color monitors are sold.
the only hint I can give is looking at scene_opengl_glx.cpp for the code looking like the example code in the linked document (be aware that changes there might break millions of user's compositing experience). There is nothing else I can do. I neither have such a graphics card nor such a screen and my primary system uses the EGL backend which is the future code and not mentioned at all in the NVIDIA document. As long as NVIDIA is not even able to support Aero with it, I do not consider this of any importance.
From the nvidia readme: "Since depth 30 visuals have only 2 bits of alpha" ... i do not think this will ever really "fix" if the system has only 4 alpha values (2^2) Other than this, choosing RGB10_A2 as texture format should be sufficient to fix colors, but again: You can not have alpha gradients this way! Does btw the XRender backend somehow work? And no, the gwenview issue is certainly related but not caused by kwin. Same (likely) goes for the plasma panel - Qt::transparent is Qt::black + alpha(0) and Qt likely only supports an ARGB/8 colortable for ARGB windows (-> Qt issue?!)
yes, XRender works. As I know the panel should use Qt::WA_TranslucentBackground so according to Qt documentation Qt::WA_TranslucentBackground requires some work on the window manager side.