|Summary:||devel/qt5: Red and blue reversed with Intel driver|
|Product:||Ports & Packages||Reporter:||Jason W. Bacon <jwb>|
|Severity:||Affects Some People||CC:||adridg, bengta, kidon, maxclsb, mikael.urankar, tcberner, w.schwarzenfeld|
Description Jason W. Bacon 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: https://forum.qt.io/topic/54929/color-reversal-qt-embedded-and-24bpp 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 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 2017-11-13 06:43:22 UTC
Is it only the QML based stuff that shows the problem?
Comment 3 Adriaan de Groot 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 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 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 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 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 2017-11-14 00:48:49 UTC
Same results here: VESA normal, intel or modesetting flipped.
Comment 10 Jason W. Bacon 2017-11-14 01:21:48 UTC
Adding 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 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 2017-11-14 16:12:22 UTC
What is tcberner's sample application?
Comment 13 Adriaan de Groot 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 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 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: 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: 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 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: patch-src_platformsupport_glxconvenience_qglxconvenience.cpp
Comment 22 Jason W. Bacon 2017-12-15 16:24:54 UTC
Patch confirmed to work here...
Comment 23 Tobias C. Berner 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 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 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 29 Jason W. Bacon 2018-02-08 17:50:20 UTC
NOT seeing the issue on my Lenovo T61 anymore. xf86-video-intel-2.99.917.20180111 qt5-gui-5.9.4_1
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: 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 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 Log: 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) Changes: head/x11-toolkits/qt5-gui/Makefile head/x11-toolkits/qt5-gui/files/patch-src_platformsupport_glxconvenience_qglxconvenience.cpp
Comment 40 Adriaan de Groot 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: https://git.qt.io/consulting-usa/qtbase-xcb-rendering/commit/5f39a0ef8d037ed8d1fa19d5514308ed4a2ca161 This patch covers much more, but includes a less crude check for non-RGB visuals.