Bug 223638

Summary: devel/qt5: Red and blue reversed with Intel driver
Product: Ports & Packages Reporter: Jason W. Bacon <jwb>
Component: Individual Port(s)Assignee: kde
Status: Closed FIXED    
Severity: Affects Some People CC: adridg, bengta, kidon, maxclsb, mikael.urankar, tcberner, w.schwarzenfeld
Priority: --- Keywords: needs-qa, regression
Version: LatestFlags: tcberner: maintainer-feedback+
koobs: merge-quarterly?
Hardware: amd64   
OS: Any   
Description Flags
Test application sources
Xorg log
Xorg.log, skylake, no bug
Xorg.0.log ironlake
xorg.conf fragment
workaround patch for x11-toolkits/qt5-gui
updated workaround patch for x11-toolkits/qt5-gui none

Description Jason W. Bacon freebsd_committer 2017-11-13 00:21:45 UTC
Following updates in the past couple weeks, all my FreeBSD systems with an Intel graphics began displaying images with the red and blue intensities reversed in QT5 applications.  It looks like the issue reported here:


QT4 and GTK applications (e.g. ristretto, qiviewer) work fine.  Only QT5 applications (e.g. phototonic, certain Lumina desktop components) display incorrect colors.

The problem does not occur on systems with non-Intel graphics.
Comment 1 Tobias C. Berner freebsd_committer 2017-11-13 06:16:50 UTC
Hi Jason

Yes, I have exactly the same issue on my notebooks. 
I'm not quite sure what changed in the driver to cause this.

mfg Tobias
Comment 2 Tobias C. Berner freebsd_committer 2017-11-13 06:43:22 UTC
Is it only the QML based stuff that shows the problem?
Comment 3 Adriaan de Groot freebsd_committer 2017-11-13 09:24:52 UTC
Is "all FreeBSD systems" multiple versions (10, 11, 12-CURRENT)?
Which driver setup exactly, with X11? Are you using the xf86-video-intel driver (I think consensus is that that's not a good idea)?
Comment 4 Tobias C. Berner freebsd_committer 2017-11-13 10:17:47 UTC
I think it is on multiple versions, not only on Current, I have a report for "FreeBSD 11.1-RELEASE-p1".

I will debug this a bit tonight.
Comment 5 Jason W. Bacon freebsd_committer 2017-11-13 14:54:24 UTC
In my case it's currently two 11.1-RELEASE systems and one 11.0-RELEASE.

My Lenovo T61 was running 10.3-RELEASE when the problem initially occurred.  It was due for an upgrade anyway, so I did a fresh install of 11.1.  After switching the pkg repo to "latest" and running pkg update, the problem returned.

Phototonic does not appear to use QML, unless I'm missing something.

Using a different driver had no effect.
Comment 6 Tobias C. Berner freebsd_committer 2017-11-13 18:34:01 UTC
I think I got it backwards: QML seems to still have the proper colours, but QtWidgets is shifted.
Comment 7 Tobias C. Berner freebsd_committer 2017-11-13 20:25:57 UTC
Can you switch out your graphics driver to 'vesa' and confirm that 
the colours are correct again then -- for me they are. 

[yes, this is not a solution, but helps to identify if x11-drivers/xf86-video-intel is to blame]
Comment 8 Bengt Ahlgren 2017-11-13 22:40:21 UTC
(In reply to Tobias C. Berner from comment #7)
I can confirm that there is no red/blue issue with the vesa Xorg driver.

But, that also means _not_ using the i915kms kernel module.  The problem is there for both the intel Xorg driver and the modesetting Xorg driver, pointing more to i915kms, or something else that is common for both these drivers, but not vesa.

(This is on a TP X201 running 10.4-STABLE with ports updated late October)
Comment 9 Jason W. Bacon freebsd_committer 2017-11-14 00:48:49 UTC
Same results here: VESA normal, intel or modesetting flipped.
Comment 10 Jason W. Bacon freebsd_committer 2017-11-14 01:21:48 UTC

DefaultDepth 16

to the Screen0 section of /etc/X11/xorg.conf (if you have one) will work around the issue at the cost of slightly grainier images.
Comment 11 Adriaan de Groot freebsd_committer 2017-11-14 12:13:37 UTC
 - installed fresh 11.1-R on an older core2duo machine,
 - install xorg, xf86-video-intel, qt5
 - after boot, `kldload i915kms`
 - add a user, add user to `video` group
 - startx as that user
 - in twm, use glxgears to check gl compatibility; check Xorg.0.log that intel(0) is actually being used
 - tcberner's sample application shows me a red box with black text on it

Switch from /quarterly/ to /latest/, pkg upgrade, reboot.

 - `kldload i915kms`
 - start twm, same checks for gl + intel driver
 - sample application is still red like it should be

So either the Q35 chipset is unaffected, or there's something else needed to actually reproduce this. I'm on a D-SUB VGA connector, to a 1280x1024 screen. Maybe you guys are using HDMI and there's a byte swap going on in there?
Comment 12 Jason W. Bacon freebsd_committer 2017-11-14 16:12:22 UTC
What is tcberner's sample application?
Comment 13 Adriaan de Groot freebsd_committer 2017-11-15 13:15:51 UTC
Created attachment 188014 [details]
Test application sources

This tarball contains a simple QtWidgets program, and a QML file -- originally from tcberner@ . Also a makefile. Assuming you have Qt5 installed normally, you can just `make` and it will run two executables, yielding two windows on the desktop.

For me, both of them are red.
Comment 14 Bengt Ahlgren 2017-11-15 16:30:12 UTC
(In reply to Adriaan de Groot from comment #13)
For me the large window is blue, but the small is red.
Comment 15 Jason W. Bacon freebsd_committer 2017-11-15 16:57:06 UTC
Created attachment 188024 [details]
Xorg log

I found a machine with Intel graphics that does *not* exhibit the problem. It's an ASUS Eee PC running 10.3-RELEASE.  Still seeing the problem on my Lenovo T61 (11.1-RELEASE) and Dell desktop (11.0-RELEASE) with basically identical configurations.  ( Lumina desktop installed via sysutils/desktop-installer )
Comment 16 Adriaan de Groot freebsd_committer 2017-11-16 20:09:19 UTC
Created attachment 188056 [details]
Xorg.log, skylake, no bug

This is my Xorg log .. really the only relevant difference I see is that you have composite (RENDER) and I don't (and since this is a skylake box, it's using drm-next-kmod, but you can't see that in the X log).
Comment 17 Bengt Ahlgren 2017-11-17 11:21:11 UTC
Created attachment 188070 [details]
Xorg.0.log ironlake

Xorg log from ironlake (Lenovo Thinkpad X201 - Core i7 M620) that has the issue.

I just noticed that different visuals have different order of the colours, for example (xdpyinfo output) - can that matter?

    visual id:    0xc8
    class:    DirectColor
    depth:    24 planes
    available colormap entries:    256 per subfield
    red, green, blue masks:    0xff, 0xff00, 0xff0000
    significant bits in color specification:    8 bits
    visual id:    0x5f
    class:    TrueColor
    depth:    32 planes
    available colormap entries:    256 per subfield
    red, green, blue masks:    0xff0000, 0xff00, 0xff
    significant bits in color specification:    8 bits
Comment 18 Bengt Ahlgren 2017-12-03 00:11:46 UTC
Two qt5 programs I have (one is wireshark-qt5) do use one of those visuals with different colour order.  xwininfo says:

  Visual: 0xa7

and xdpyinfo prints this info:

    visual id:    0xa7
    class:    TrueColor
    depth:    24 planes
    available colormap entries:    256 per subfield
    red, green, blue masks:    0xff, 0xff00, 0xff0000
    significant bits in color specification:    8 bits
Comment 19 Jason W. Bacon freebsd_committer 2017-12-11 18:22:25 UTC
Created attachment 188725 [details]
xorg.conf fragment

To be more specific about the workaround, dropping this file in /etc/X11/xorg.conf.d and restarting Xorg should make things fully usable until the issue is fixed.

Reducing color depth from 24 to 16 bits won't generally make a noticeable difference, except in images containing a color gradient where subtle shade differences are present side-by-side.
Comment 20 Bengt Ahlgren 2017-12-15 15:20:28 UTC
Created attachment 188861 [details]
workaround patch for x11-toolkits/qt5-gui

My theory on the colour masks seems in the right direction.  The attached patch to x11-toolkits/qt5-gui avoids selecting visuals with red mask=0xff.  This "fixes" the problem for me, but it is clearly a hack that works around the real problem rather than fixing it.

Just make a "files" directory in x11-toolkits/qt5-gui and drop the patch in there and rebuild.
Comment 21 Bengt Ahlgren 2017-12-15 16:07:28 UTC
(In reply to Bengt Ahlgren from comment #20)
... and name the patch file:
Comment 22 Jason W. Bacon freebsd_committer 2017-12-15 16:24:54 UTC
Patch confirmed to work here...
Comment 23 Tobias C. Berner freebsd_committer 2017-12-26 18:21:55 UTC
I think the problem will resolve itself with the upcoming update to Qt-5.9.3 -- at least while testing that on my notebooks, I no longer have wrong colours in KDE Plasma5.

mfg Tobias
Comment 24 maxclsb 2017-12-26 22:34:46 UTC
FWIW, I updated my packages ("Latest" repo) two days ago and after a reboot the problem went away.
Comment 25 Jason W. Bacon freebsd_committer 2017-12-27 01:52:38 UTC
Problem resolved here as well.  I think we can close the PR unless anyone else is still having issues.
Comment 26 w.schwarzenfeld freebsd_triage 2018-02-03 05:31:39 UTC
We have version 5.9.4. Problem seems solved. So I close here.
Comment 27 Philipp Engel 2018-02-08 17:01:43 UTC
The bug still exists on my machine with FreeBSD 11.1 with xf86-video-intel-2.99.917.20180111 and Qt 5.9.4.
Comment 28 w.schwarzenfeld freebsd_triage 2018-02-08 17:08:16 UTC
See comment27 - reopen.
Comment 29 Jason W. Bacon freebsd_committer 2018-02-08 17:50:20 UTC
NOT seeing the issue on my Lenovo T61 anymore.

Comment 30 Bengt Ahlgren 2018-02-08 23:01:35 UTC
I'm not seeing it either on my Lenovo X201 (Ironlake) with qt5-gui-5.9.4_1.  I however have to double-check tomorrow that I haven't the patch applied in my poudriere build.

Philipp, what visual is selected for your window with the issue, and what colour masks do that visual have (check with xwininfo and xdpyinfo)?

I now get a visual for qt5 windows with colour masks that wouldn't be troublesome with previous versions of qt5, and thus does prove that the root problem is solved:

    visual id:    0x90
    class:    TrueColor
    depth:    24 planes
    available colormap entries:    256 per subfield
    red, green, blue masks:    0xff0000, 0xff00, 0xff
    significant bits in color specification:    8 bits
Comment 31 Bengt Ahlgren 2018-02-08 23:05:24 UTC
(In reply to Bengt Ahlgren from comment #30)
..."does NOT prove" I mean!
Comment 32 Philipp Engel 2018-02-09 11:23:33 UTC
I'm having this issue on my X230. Xwininfo says:

xwininfo: Window id: 0x2c0000d "Oracle VM VirtualBox Manager"

  Absolute upper-left X:  215
  Absolute upper-left Y:  328
  Relative upper-left X:  0
  Relative upper-left Y:  0
  Width: 770
  Height: 550
  Depth: 24
  Visual: 0xd7
  Visual Class: TrueColor
  Border width: 0
  Class: InputOutput
  Colormap: 0x2c0000c (not installed)
  Bit Gravity State: NorthWestGravity
  Window Gravity State: NorthWestGravity
  Backing Store State: NotUseful
  Save Under State: no
  Map State: IsViewable
  Override Redirect State: no
  Corners:  +215+328  -935+328  -935-202  +215-202
  -geometry 770x550+215+328
Comment 33 Bengt Ahlgren 2018-02-09 12:06:13 UTC
(In reply to Philipp Engel from comment #32)
and what does xdpyinfo say for that visual (0xd7)?
Comment 34 Philipp Engel 2018-02-09 14:25:04 UTC
In reply to comment #33:

$ xdpyinfo:

    visual id:    0xd7
    class:    TrueColor
    depth:    24 planes
    available colormap entries:    256 per subfield
    red, green, blue masks:    0xff, 0xff00, 0xff0000
    significant bits in color specification:    8 bits
Comment 35 Bengt Ahlgren 2018-02-09 14:32:50 UTC
(In reply to Philipp Engel from comment #34)
Interesting - reversed colour masks (red=0xff), so the bug might still be there!
Comment 36 Bengt Ahlgren 2018-02-09 18:56:22 UTC
Strange...  I don't have any BGR visuals any more (red mask=0xff).  Running 10.4-STABLE from Dec 9 on a TP X201 (Ironlake).  What changed?

Philipp, can you try my workaround patch?  It also applies to qt5-gui 5.9.4
Comment 37 Philipp Engel 2018-02-09 19:28:17 UTC
Bengt, your patch fixes the issue.
Comment 38 Bengt Ahlgren 2018-02-10 13:16:06 UTC
Created attachment 190480 [details]
updated workaround patch for x11-toolkits/qt5-gui

Updated workaround patch for x11-toolkits/qt5-gui: slightly more generic, and for version 5.9.4
Comment 39 commit-hook freebsd_committer 2018-04-08 21:32:50 UTC
A commit references this bug:

Author: adridg
Date: Sun Apr  8 21:32:09 UTC 2018
New revision: 466833
URL: https://svnweb.freebsd.org/changeset/ports/466833

  Avoid BGR visuals with Qt5 on i915 (well, all) platforms. Explanation
  is in the patch and PR.

  PR:		223638
  Submitted by:	Bengt Ahlgren
  Reported by:	Jason W Bacon
  Reviewed by:	Philipp Engel
  Approved by:	tcberner (mentor, implicit)

Comment 40 Adriaan de Groot freebsd_committer 2018-04-08 21:48:36 UTC
Although I don't have any hardware that displays this behavior (e.g. w/ NVidia, all visuals are RGB anyway), I've gone and committed Berdt's patch. Thanks!
Comment 41 Bengt Ahlgren 2018-04-09 11:52:39 UTC
(In reply to Adriaan de Groot from comment #40)
Thanks! I am a little uneasy with committing this, as the patch is a workaround hack. If it results in any problems, we might find a better solution here:


This patch covers much more, but includes a less crude check for non-RGB visuals.