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.
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
Is it only the QML based stuff that shows the problem?
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)?
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.
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.
I think I got it backwards: QML seems to still have the proper colours, but QtWidgets is shifted.
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]
(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)
Same results here: VESA normal, intel or modesetting flipped.
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.
- 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?
What is tcberner's sample application?
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.
(In reply to Adriaan de Groot from comment #13) For me the large window is blue, but the small is red.
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 )
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).
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
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
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.
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.
(In reply to Bengt Ahlgren from comment #20) ... and name the patch file: patch-src_platformsupport_glxconvenience_qglxconvenience.cpp
Patch confirmed to work here...
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
FWIW, I updated my packages ("Latest" repo) two days ago and after a reboot the problem went away.
Problem resolved here as well. I think we can close the PR unless anyone else is still having issues.
We have version 5.9.4. Problem seems solved. So I close here.
The bug still exists on my machine with FreeBSD 11.1 with xf86-video-intel-2.99.917.20180111 and Qt 5.9.4.
See comment27 - reopen.
NOT seeing the issue on my Lenovo T61 anymore. xf86-video-intel-2.99.917.20180111 qt5-gui-5.9.4_1
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
(In reply to Bengt Ahlgren from comment #30) ..."does NOT prove" I mean!
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
(In reply to Philipp Engel from comment #32) and what does xdpyinfo say for that visual (0xd7)?
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
(In reply to Philipp Engel from comment #34) Interesting - reversed colour masks (red=0xff), so the bug might still be there!
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
Bengt, your patch fixes the issue.
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
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
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!
(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.