Bug 1018566 - RFE: Qt support for 30-bit depth
RFE: Qt support for 30-bit depth
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: qt (Show other bugs)
rawhide
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Rex Dieter
Fedora Extras Quality Assurance
: FutureFeature, Reopened, Triaged
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-10-13 07:44 EDT by Alberto Ferrante
Modified: 2014-06-26 22:28 EDT (History)
11 users (show)

See Also:
Fixed In Version: qt-4.8.6-9.fc20
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2014-06-14 21:50:09 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
GNOME Desktop 625202 None None None Never
KDE Software Compilation 214011 None None None Never
Qt Bug Tracker QTBUG-25998 None None None Never

  None (edit)
Description Alberto Ferrante 2013-10-13 07:44:13 EDT
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
Comment 1 Rex Dieter 2013-10-13 08:04:29 EDT
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
Comment 2 Kevin Kofler 2013-10-13 19:55:43 EDT
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.
Comment 3 Alberto Ferrante 2013-10-14 04:56:59 EDT
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).
Comment 4 Rex Dieter 2013-10-14 06:15:09 EDT
If there are existing bugs filed, please do provide pointers/references to them.
Comment 5 Kevin Kofler 2013-10-14 08:07:43 EDT
> 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.
Comment 6 Alberto Ferrante 2013-10-14 08:47:39 EDT
(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.
Comment 7 Rex Dieter 2013-10-14 08:50:11 EDT
Those other apps are gtk apps, so it would appear gtk needs fixing too
Comment 8 Rex Dieter 2013-10-14 08:52:33 EDT
marking FutureFeature
Comment 9 Kevin Kofler 2013-10-14 09:32:29 EDT
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.
Comment 10 Alberto Ferrante 2013-10-14 10:27:33 EDT
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.
Comment 11 Rex Dieter 2013-10-14 10:39:31 EDT
Thanks
Comment 12 Rex Dieter 2014-06-03 18:25:09 EDT
Upstream fix has landed, I'll try backporting it now.
Comment 13 Rex Dieter 2014-06-04 06:15:48 EDT
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.
Comment 14 Alberto Ferrante 2014-06-04 19:11:07 EDT
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
Comment 15 Fedora Update System 2014-06-11 08:35:14 EDT
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
Comment 16 Fedora Update System 2014-06-11 08:36:15 EDT
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
Comment 17 Fedora Update System 2014-06-12 02:25:38 EDT
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).
Comment 18 Fedora Update System 2014-06-14 21:50:09 EDT
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.
Comment 19 Fedora Update System 2014-06-26 22:28:28 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.