Description of problem:Qt 5.12 & Plasma 5.14.4 & KF 5.53 update causes Plasma desktop screen to flicker and impossible to use
Version-Release number of selected component (if applicable): 5.14.4
Steps to Reproduce:
1. Upgrade to Qt 5.12 & Plasma 5.14.4 & KF 5.53 & all other packages to latest
2. Restart Plasma Desktop
3. Desktop flickers and is impossible to use
Workaround is to edit /.config/kwinrc fail and in the [Compositing] section replace Backend=OpenGL with Backend=XRender
Device: Intel Corporation Skylake GT2 [HD Graphics 520] (Thinkpad X260)
Another workaround is to leave compositing backend to OpenGL but replace intel driver with modesetting.
Qt 5.12 & Plasma 5.14.4 & KF 5.53 update causes Plasma desktop screen to flicker when OpenGL compositing background is used =>
Qt 5.12 & Plasma 5.14.4 & KF 5.53 update causes Plasma desktop screen to flicker when OpenGL compositing background is used (on Skylake)Assignee:
I had the same problem (bug 24070). The first workaround helped. In /.config/kwin I replaced "OpenGLIsUnsafe=false" by "Backend=XRender"
For me, on two different machines exhibiting this bug, just changing "OpenGLIsUnsafe=false" to "OpenGLIsUnsafe=true" in ~/.config/kwinrc fixed it.
Machine 1 has Intel Core i7-3630QM CPU with hybrid Intel/NVIDIA graphics (bug seen when using Intel graphics, i915 kernel driver).
Machine 2 has Intel Atom 23735F CPU.
Qt 5.12 & Plasma 5.14.4 & KF 5.53 update causes Plasma desktop screen to flicker when OpenGL compositing background is used (on Skylake) =>
Qt 5.12 & Plasma 5.14.4 & KF 5.53 update causes Plasma desktop screen to flicker when OpenGL compositing background is used (when using intel or nouveau video drivers)
same bug here, there wasn't Backend=OpenGL in /.config/kwinrc but I added Backend=XRender anyway. It worked.
I deleted Backend=XRender and changed "OpenGLIsUnsafe=false" to "OpenGLIsUnsafe=true", it worked as well. In both case, system was very slow, about 1 mn between connexion screen and the desktop.
OK, this may get a bit complicated. I'll try to explain what happened, and what I have found. Bear with me, please.
This is all on real hardware, with an Athlon X2 processor, 8GB of RAM, Geforce 9800 GT (nvidia340 driver), and an Atheros-based wifi card. Any installs done are "semi-clean," meaning I format the / partition but leave /home alone. The user I create during the install is the same one I was using on the install it replaced.
A few days ago, I did a Plasma install from the beta 1 Live iso, using the "free" driver (nouveau). After getting over 1,000 pending updates, it was affected by the bug. I made the system usable by changing OpenGLIsUnsafe to "true."
I tried the round 1 beta 2 Live iso earlier today, booting into Live mode with and without the nonfree drivers. free was affected, nonfree was not. I did not do an install from that iso.
I then used the round 1 beta 2 CI iso to install a "standard" Plasma, telling it along the way that I didn't want the proprietary driver.
(Probably unrelated, but I mention this just-in-case) It appears that the nvidia340 driver module was built and installed during the first boot, even though I said I didn't want it. However, indications afterward are that it is not being used.
The resulting system is not affected by the bug. I am using it now. OpenGLIsUnsafe is still "true." One significant change occurs when I look at systemsettings5/Display and Monitor/Compositor. It looks different, almost identical to the same screen in Mageia 6 when the i915 driver is used. (I'll attach a screenshot after I finish this comment.) There is a notice/message at the top about OpenGL crashing kwin in the past, with a button to turn something off if you believe you are now using a "stable" video driver. When using the proprietary nvidia in M6 this notice does NOT appear, and it never did appear after updating the beta1 install.
This notice did NOT suddenly appear when I originally changed OpenGLIsUnsafe, either. It only appeared after I installed a new Plasma/kwin while that change was in effect in my user's .config/kwinrc.
I don't know what can be done with this information, but I would ask... Why can't we do something with Mageia 7 Plasma kwinrc settings during the install process that's similar to what was done with Mageia 6.1 installs?
Created attachment 10656 [details]
screenshot of a Plasma system settings compositor page
And of course it's never as simple as "everything using a certain driver."
I just did some checking with my old Dell Dimension E310, vintage around 2004. Details on the hardware can be found at https://wiki.mageia.org/en/QA_iso_hardware_list. It uses the i915 video driver.
This aging hardware is happily using 64-bit Mageia 6 Plasma, updated over time from a Mageia 6 CI install. It is as stable as a rock. Looking at kwinrc, OpenGLIsUnsafe is set to "false."
This is my brother's production computer, so I don't want to do anything that might break his current system, like install Cauldron in its present state on the hard drive. However, I did just boot the Round 2 Plasma Live iso into live mode from a usb stick. Unlike my trials on other Intel systems, it is rock-solid stable. And OpenGLIsUnsafe=false in the live mode kwinrc.
So it looks like the age of the Intel graphics hardware is also an important factor.
Following on from a discussion on qa-discuss, I have:
1. Installed a minimal Plasma system from the beta1 64-bit CI ISO.
2. Updated everything except the qt5/kf5/Plasma stack from my beta2 repo snapshot.
3. Updated the qt5/kf5/Plasma stack from my beta2 repo snapshot.
After step 2, everything still worked fine. After step3, the display corruption was present. So I think we can rule out a regression in Mesa or the video drivers.
Over to the KDE maintainers...
I see qt 5.12.1 and plasma 5.14.5 is being prepared upstream... hopefully they will improve the situation
also affects nvidia Geforce 8100.
install beta2 plasma5 live and rebooted without issue to a working desktop.
add "virtualbox" via Mageia Welcome an d reboot for new kernel
rebooted again during the reboot after dkms installed virtual box driver?
bootedinto an unusable desktop!
corrects the issue for me
(In reply to Thomas Backlund from comment #9)
> I see qt 5.12.1 and plasma 5.14.5 is being prepared upstream... hopefully
> they will improve the situation
i will prepare them on our svn.
i am uploading plasma 5.14.5 in the svn.
I don't see any qt 5.12.1 yet available.
(In reply to Nicolas Lécureuil from comment #12)
> I don't see any qt 5.12.1 yet available.
Yeah, I dont know what the exact plan for that is... I saw version bumps in qt git, and some already starting to work on 5.12.2:
QT release schedule only states "January 2019" for 5.12.1:
KDE Frameworks 5.54.0 is available.
But just a question - as for example KDE Neon switched to using modesetting driver as a default one for intel graphics hardware already in November 2016 (https://phabricator.kde.org/T3734), then isn't it time for that change in Mageia too?