Description of problem: when 30-bit color depth is enabled (using Nvidia cards and monitors supporting this depth) all the colors in KDE desktops are corrupted. In detail: * The log-in screen is corrupted * The splash screen is *not* corrupted * The desktop is all corrupted except window title bars and the "Run command" dialog (ALT+F2) which are OK In GNOME the situation is a bit better, but then applications show problems as in DKE Version-Release number of selected component (if applicable): 4.5.1-1 (but also all the previous ones) How reproducible: Set 30-bit color depth in xorg.conf (with a 30-bit capable videocard and monitor) Steps to Reproduce: 1.Seto 30-bit color depth in xorg.conf (with a 30-bit capable videocard and monitor) 2. Restart X 3. Login Actual results: Corrupted colors all the way around Expected results: Correct colors shown Additional info: Also applications have problems with 30-bit colors. It looks like a common effort should be put to solve this long standing problem. 30-bit monitors are getting common and being able to exploit the 30-bit LUT would be of great help to the ones working with color-critical applications
Pretty sure this is more a Qt toolkit issue. To be honest, the likelihood of us downstream being able to help fix this is near nil (esp if this feature is implemented only in the nvidia nonfree driver), I would suggest contacting Qt upstream, https://bugreports.qt-project.org
Nouveau also appears to support 30-bit color depth (Depth 30), looking up: "depth 30" nouveau in a search engine finds several places in Nouveau code where it handles it. That said, I agree that this needs to be addressed by upstream Qt.
I do agree that this should be addressed also upstream Qt and there are some bugs open on this both on Qt and on KDE bugtracking systems. Though, this is not sufficient, there seems also to be some configuration issues that should probably be addressed at distribution level. Furthermore, there should be someone that looks into the problem and tries to understand where it is exactly. At the moment everybody seems to blame Qt, but I am not that sure it is only a Qt problem. Qt guys seems to ignore this bug (that has been in their bugtracking system for years now).
If there are existing bugs filed, please do provide pointers/references to them.
> I do agree that this should be addressed also upstream Qt and there are some > bugs open on this both on Qt and on KDE bugtracking systems. Can you please give us the bug IDs so we can reference them here? > Though, this is not sufficient, there seems also to be some configuration > issues that should probably be addressed at distribution level. I doubt that. It should just work! > Furthermore, there should be someone that looks into the problem and tries to > understand where it is exactly. At the moment everybody seems to blame Qt, but > I am not that sure it is only a Qt problem. I think the problem is that the raster paint engine (the default in Qt 4.8) simply hardcodes 24-bit color depth, i.e. either 32 = 24 (color) + 8 (alpha) (the mode normally used) or 24 = 24 (color) + 0 (alpha). We also have trouble with anything lower (16-bit in particular), see bug #810161, and upstream was not very cooperative (see https://bugreports.qt-project.org/browse/QTBUG-25198). Can you please try the workaround for bug #810161, i.e.: export QT_GRAPHICSSYSTEM=native ? > Qt guys seems to ignore this bug (that has been in their bugtracking system for > years now). I'm not surprised, they also ignored the 16 bpp one. I suspect the 24 bpp assumption is ingrained deep into their paint system.
(In reply to Kevin Kofler from comment #5) > > I do agree that this should be addressed also upstream Qt and there are some > > bugs open on this both on Qt and on KDE bugtracking systems. > > Can you please give us the bug IDs so we can reference them here? This one in for KDE (it is started as an Ubuntu-related bug, but it is similar in Fedora): https://bugs.kde.org/show_bug.cgi?id=214011 This one in on Qt: https://bugreports.qt-project.org/browse/QTBUG-25998 > > Furthermore, there should be someone that looks into the problem and tries to > > understand where it is exactly. At the moment everybody seems to blame Qt, but > > I am not that sure it is only a Qt problem. > > I think the problem is that the raster paint engine (the default in Qt 4.8) > simply hardcodes 24-bit color depth, i.e. either 32 = 24 (color) + 8 (alpha) > (the mode normally used) or 24 = 24 (color) + 0 (alpha). We also have > trouble with anything lower (16-bit in particular), see bug #810161, and > upstream was not very cooperative (see > https://bugreports.qt-project.org/browse/QTBUG-25198). > > Can you please try the workaround for bug #810161, i.e.: > export QT_GRAPHICSSYSTEM=native > ? This improves the situation to some extent, but it does not look to be a viable solution (I tried that in the past and re-tried today), but still it does not solve the problem: with the native option the desktop is OK (right colors all around!), but some of the applications do not work. For example Geeqie (GTK2) shows a black square instead of images; the same does Rawtherapee. GIMP works great except for the icons in the toolbox that have corrupted colors. Firefox works great. As I was mentioning, to me this looks to be not only a Qt problem.
Those other apps are gtk apps, so it would appear gtk needs fixing too
marking FutureFeature
Is there an upstream bug filed already against GTK+ 2 (at upstream GNOME)? The Qt issue is already filed upstream and will need to be addressed there, so I'm closing this bug here.
There is one for GTK+, but it is two years old and it is still unconfirmed (even though, there is a patch attached): https://bugzilla.gnome.org/show_bug.cgi?id=625202 What surprises me is that GIMP works well in 30 bit (isn't it GTK+ based too?) at least for what concern the image window.
Thanks
Upstream fix has landed, I'll try backporting it now.
Test builds including the upstream fix: qt-4.8.6-8.fc20: https://koji.fedoraproject.org/koji/buildinfo?buildID=521197 qt-4.8.6-8.fc19: https://koji.fedoraproject.org/koji/buildinfo?buildID=521198 We'll probably be sending this off to updates-testing sooner or later, let me know if you'd rather test it from there instead.
Hi, this is really a great news!! I installed the testing libraries and, in a quick test, everything seems to be working fine. No color corruption in desktop, login screen, and applications when 30-bit depth is enabled. Unofrtunately I cannot test the library extensively as some of the applications that I use the most are based GTK where the problem is still there. I will anyway keep the modified libraries installed. Thanks again! Best, Alberto
qt-4.8.6-9.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/qt-4.8.6-9.fc20
qt-4.8.6-9.fc19 has been submitted as an update for Fedora 19. https://admin.fedoraproject.org/updates/qt-4.8.6-9.fc19
Package qt-4.8.6-9.fc20: * should fix your issue, * was pushed to the Fedora 20 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing qt-4.8.6-9.fc20' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2014-7284/qt-4.8.6-9.fc20 then log in and leave karma (feedback).
qt-4.8.6-9.fc20 has been pushed to the Fedora 20 stable repository. If problems still persist, please make note of it in this bug report.
qt-4.8.6-9.fc19 has been pushed to the Fedora 19 stable repository. If problems still persist, please make note of it in this bug report.