Bug 237662 - x11-toolkits/qt5-declarative: qml-application renders text invisible on i7-3770 CPU
Summary: x11-toolkits/qt5-declarative: qml-application renders text invisible on i7-37...
Status: Closed FIXED
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: amd64 Any
: --- Affects Only Me
Assignee: freebsd-kde (group)
URL:
Keywords:
Depends on: 241506
Blocks:
  Show dependency treegraph
 
Reported: 2019-04-29 22:05 UTC by Jesper Schmitz Mouridsen
Modified: 2019-11-06 19:33 UTC (History)
7 users (show)

See Also:


Attachments
Image showing working qml in Vbox (145.15 KB, image/png)
2019-04-29 22:05 UTC, Jesper Schmitz Mouridsen
no flags Details
Image showing working qml in Vbox and not working qml on bare metal (188.17 KB, image/png)
2019-04-29 22:06 UTC, Jesper Schmitz Mouridsen
no flags Details
simple script that tries to gather relevant system info. (925 bytes, text/plain)
2019-05-03 15:27 UTC, Jesper Schmitz Mouridsen
no flags Details
wayland platform has same isssue (45.01 KB, image/png)
2019-05-06 21:17 UTC, Jesper Schmitz Mouridsen
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Jesper Schmitz Mouridsen freebsd_committer freebsd_triage 2019-04-29 22:05:36 UTC
Created attachment 204103 [details]
Image showing working qml in Vbox

see https://people.freebsd.org/~jsm/bug/

It contains the test case invisbletext and the attached pngs. It works as you can see in a virtual machine, but on bare metal it i7-3770 CPU it does not.

/boot/modules/i915kms.ko was installed by package drm-fbsd12.0-kmod-4.16.g20190424
Comment 1 Jesper Schmitz Mouridsen freebsd_committer freebsd_triage 2019-04-29 22:06:17 UTC
Created attachment 204104 [details]
Image showing working qml in Vbox and not working qml on bare metal
Comment 2 Jan Beich freebsd_committer freebsd_triage 2019-04-30 01:07:32 UTC
Maybe layering rather than rendering artifact. I can't reproduce even inside 11.2 amd64 jails (under 13.0-CURRENT).

Does the application print anything on terminal? Something about missing fonts, theme components, etc.

Can you reproduce outside of host desktop environment? Try a simple window manager (or none at all).
Comment 3 Gleb Popov freebsd_committer freebsd_triage 2019-04-30 03:20:07 UTC
I wonder if it is the same as my problem in https://bugs.kde.org/show_bug.cgi?id=399143

Can you try out workaround proposed there?
Comment 4 Mark Linimon freebsd_committer freebsd_triage 2019-04-30 03:24:28 UTC
To which port does this PR apply?
Comment 5 Gleb Popov freebsd_committer freebsd_triage 2019-04-30 04:37:09 UTC
(In reply to Mark Linimon from comment #4)

x11-toolkits/qt5-declarative, I think.
Comment 6 Jesper Schmitz Mouridsen freebsd_committer freebsd_triage 2019-04-30 06:02:17 UTC
(In reply to Gleb Popov from comment #3)
export QML_DISABLE_DISTANCEFIELD=1 works.
(Whatever that actually does behind the scenes)
Comment 7 Gleb Popov freebsd_committer freebsd_triage 2019-04-30 06:07:27 UTC
(In reply to Jesper Schmitz Mouridsen from comment #6)
It only strengths my belief that the bug is within our video drivers. Relevant bug report on kms-drm GitHub: https://github.com/FreeBSDDesktop/kms-drm/issues/109
Comment 8 Adriaan de Groot freebsd_committer freebsd_triage 2019-04-30 09:57:10 UTC
I have drm-fbsd12.0-kmod-4.16.g20190305, a fairly recent 12-STABLE kernel and whatever KDE Plasma is current. With an i7 6700, the major general is displayed in yellow, white, yellow, white, and in several different typefaces (i.e. "can't reproduce the problem").

This suggests that we need to collect information more carefully to figure out where the problem lives. I might have an older i3 around here somewhere.

In the meantime it'd be useful to have a procedure for the collection of needed data: I can't, for instance, easily spot what SVN version my kernel is from, nor which driver X is actually using.
Comment 9 Jesper Schmitz Mouridsen freebsd_committer freebsd_triage 2019-05-03 15:27:39 UTC
Created attachment 204194 [details]
simple script that tries to gather relevant system info.
Comment 10 Jesper Schmitz Mouridsen freebsd_committer freebsd_triage 2019-05-06 21:17:48 UTC
Created attachment 204239 [details]
wayland platform has same isssue

FWIW: "--platform xvnc" does render the text visible.
I installed sway and recompiled kernel with evdev, and as the
images shows the text is still rendered invisble on platform --wayland.
I also tried different x11-drivers vesa and scfb, both having the same issue.
sway both under X11 and started directly exposes the issue of invisible rendered text..
Comment 11 Jesper Schmitz Mouridsen freebsd_committer freebsd_triage 2019-05-08 21:10:05 UTC
Just a little more research.
I have the same issue on Intel(R) Pentium(R) CPU N4200 @ 1.10GHz
Setting QSG_DISTANCEFIELD_ANTIALIASING=gray solves it.
No need for QML_DISABLE_DISTANCEFIELD=1.
Comment 12 Serge Volkov 2019-05-09 15:16:25 UTC
(In reply to Jesper Schmitz Mouridsen from comment #11)

I deleted QML_DISABLE_DISTANCEFIELD=1 from /etc/xprofile and set QSG_DISTANCEFIELD_ANTIALIASING=gray.
And it works for me on Intel Core i5-2500 with /boot/modules/i915kms.ko or VESA driver.
Comment 13 Jesper Schmitz Mouridsen freebsd_committer freebsd_triage 2019-10-07 15:55:47 UTC
CPU: Intel(R) Atom(TM) Processor E3930 @ 1.30GHz (1286.40-MHz K8-class CPU) works without issues, being apollo lake like non working Intel(R) Pentium(R) CPU N4200 @ 1.10GHz this does not seem to be a generation question..
Comment 14 Jesper Schmitz Mouridsen freebsd_committer freebsd_triage 2019-10-23 15:05:53 UTC
This turns out to be locale related. And is NOT related to hardware..

Running with locale 

LANG=da_DK.UTF-8
LC_CTYPE="da_DK.UTF-8"
LC_COLLATE="da_DK.UTF-8"
LC_TIME="da_DK.UTF-8"
LC_NUMERIC="da_DK.UTF-8"
LC_MONETARY="da_DK.UTF-8"
LC_MESSAGES="da_DK.UTF-8"
LC_ALL=
I have the problem

export LC_ALL=C
rm -rf .cache/qtshadercache/
rm -rf .cache/mesa_shader_cache/

And the text appears...

looking closer chancing on LC_ at the time LC_NUMERIC is the trouble maker
So i think it could be computation of decimal numbers since the decimal separator is "," and not "." in my locale. Perhaps QT localizes its numbers a little to soon or in the wrong places..
Comment 15 Serge Volkov 2019-10-23 18:18:56 UTC
(In reply to Jesper Schmitz Mouridsen from comment #14)

Maybe this is really locale related problem.

Running with locale 

LANG=ru_RU.UTF-8
LC_CTYPE="ru_RU.UTF-8"
LC_COLLATE="ru_RU.UTF-8"
LC_TIME="ru_RU.UTF-8"
LC_NUMERIC="ru_RU.UTF-8"
LC_MONETARY="ru_RU.UTF-8"
LC_MESSAGES="ru_RU.UTF-8"
LC_ALL=

I have the problem too.

export LC_ALL=C
rm -rf .cache/qtshadercache/
rm -rf .cache/mesa_shader_cache/

And the text appears...

But if I change only LC_NUMERIC to "C" the problem does not disappear.

I am still using QSG_DISTANCEFIELD_ANTIALIASING=gray in /etc/xprofile to fix the problem.

------
FreeBSD 12.0-RELEASE-p10 (amd64), KDE Plasma 5.17.0, KDE Frameworks 5.63.0, Qt 5.13.0
Comment 16 Serge Volkov 2019-10-23 18:35:03 UTC
(In reply to Jesper Schmitz Mouridsen from comment #14)

Sorry, I was wrong. I tested again. 
Change LC_NUMERIC to "C" really solves the problem.

------
FreeBSD 12.0-RELEASE-p10 (amd64), KDE Plasma 5.17.0, KDE Frameworks 5.63.0, Qt 5.13.0
Comment 17 Jesper Schmitz Mouridsen freebsd_committer freebsd_triage 2019-10-26 17:58:15 UTC
Follow up in bug #241506