Another workaround is to leave compositing backend to OpenGL but replace intel driver with modesetting.

I had the same problem (bug 24070). The first workaround helped. In /.config/kwin I replaced "OpenGLIsUnsafe=false" by "Backend=XRender"

CC: (none) => ed1

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.

CC: (none) => mageia

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.

CC: (none) => lebarhon
Keywords: 7beta2 => (none)

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?

Keywords: (none) => 7beta2

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

CC: (none) => tmb

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!

changing .config/kwinrc

[Compositing]
OpenGLIsUnsafe=false

to

[Compositing]
OpenGLIsUnsafe=true

corrects the issue for me

CC: (none) => westel

(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.

CC: (none) => mageia

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:
https://github.com/qt/qtbase/commit/6178913a234dfbb5a24c9128f6460f070fb7ce14

QT release schedule only states "January 2019" for 5.12.1:
https://wiki.qt.io/Qt_5.12_Release

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?

*** Bug 24196 has been marked as a duplicate of this bug. ***

CC: (none) => udhams

The Plasma/KF5 update in updates_testing does not fix this bug when using an Intel GPU.

My Intel install on real hardware is holding nicely.

.config/kwinrc
[Compositing]
OpenGLIsUnsafe=true

Also still broken with NVIDIA/nouveau. As before, NVIDIA/nvidia340 is OK.

My flickering (with Nouveau) is gone with kwin-5.14.5-2

(In reply to JanKusanagi from comment #19)
> My flickering (with Nouveau) is gone with kwin-5.14.5-2

Seems to be OK now here also with intel driver and default kwinrc.

Confirmed fixed by the -2 update on both my Intel and NVIDIA systems. Congratulations Nicolas!

Updating everything in core updates_testing on an affected machine as I type this - all 429 packages. (Another Grand Update...) Hoping it won't be a disaster.

Will report on if that fixes things once it is done...

Before getting anything from Core Updates_testing, I confirmed the problem was still there on my Probook 6550b. After updating everything from Core Updates_testing, it's confirmed fixed after a reboot. 

This is the install that prompted Bug 24070. My desktop icons were re-arranged for me, and they look different, farther apart horizontally, but that's not a release blocker.

Bill Kenney, you may have to manually change OpenGLIsUnsafe back to "false," then log out and back in before it takes effect. I don't think the update will change it back for you.

(In reply to Thomas Andrews from comment #23)
 
> Bill Kenney, you may have to manually change OpenGLIsUnsafe back to "false,"
> then log out and back in before it takes effect. I don't think the update
> will change it back for you.

Will do as soon as all this trickles through the repo.

(In reply to Jüri Ivask from comment #20)
> (In reply to JanKusanagi from comment #19)
> > My flickering (with Nouveau) is gone with kwin-5.14.5-2
> 
> Seems to be OK now here also with intel driver and default kwinrc.

But the panel still flickers with intel driver. Open dolphin and copy some large file from one directory to another. As the progress bars run in the panel taskbar, the panel flickers intensively. Change the video driver to modesetting - no flickering...

(In reply to Jüri Ivask from comment #25)
> (In reply to Jüri Ivask from comment #20)
> > (In reply to JanKusanagi from comment #19)
> > > My flickering (with Nouveau) is gone with kwin-5.14.5-2
> > 
> > Seems to be OK now here also with intel driver and default kwinrc.
> 
> But the panel still flickers with intel driver. Open dolphin and copy some
> large file from one directory to another. As the progress bars run in the
> panel taskbar, the panel flickers intensively. Change the video driver to
> modesetting - no flickering...

Also on intel (UHD Graphics 630, i7-8700 coffee lake).

The last update fixed it for me. Great job!

Jüri, I tried copying a multi-gigabyte file a couple of times, but couldn't observe any flickering. Not while the progress bar in the panel taskbar is running, and neither while displaying the progress bar in the notifications popup. Also tried to hover or click on items in the panel taskbar; still flicker free.
I did observe once the copying finished dialog staying visible with empty content though. Probably another bug, but I'll keep my eyes open.

CC: (none) => smout.jan

(In reply to Jan Smout from comment #26)
> (In reply to Jüri Ivask from comment #25)

> Jüri, I tried copying a multi-gigabyte file a couple of times, but couldn't
> observe any flickering. Not while the progress bar in the panel taskbar is
> running, and neither while displaying the progress bar in the notifications
> popup. Also tried to hover or click on items in the panel taskbar; still
> flicker free.
> I did observe once the copying finished dialog staying visible with empty
> content though. Probably another bug, but I'll keep my eyes open.


After the latest update with qt 5.12.1, I am now also seeing what Jüri reported :-(

And it is not limited to the progress bar when copying files.
* Just hover quickly over elements in the panel taskbar below.
* The hidden icons popup also flickers heavily while hovering over the elements.
* The login screen and startup of kde has heavy flickering and the splash screen when shutting down also when hovering over the suspend,reboot,shutdown,logout icons. 

But, the compositor is still working with opengl. No flickering from kwin. The above workarounds ("OpenGLIsUnsafe=true" and/or "Backend=XRender" therefore have no effect.

Setting the driver to modesetting indeed makes the problem go away. It also sort of fixes my issue with google-earth-pro (at a performance cost).

Should this become a separate bug report?

Can confirm flickering in SDDM. Also some elements of Plasma panel eg when I open the start menu and move mouse cursor over start menu items.
Maybe just some Plasma & KF5 packages (and SDDM) need to be rebulit with new qt 5.12.1 ?

(In reply to Jüri Ivask from comment #28)
> Can confirm flickering in SDDM. Also some elements of Plasma panel eg when I
> open the start menu and move mouse cursor over start menu items.
> Maybe just some Plasma & KF5 packages (and SDDM) need to be rebulit with new
> qt 5.12.1 ?

Forgot to mention, that this is with intel driver. With modesetting everything seems to be OK.

I'm seeing the panel flicker during a copy operation, too. This is with a Core 2 Duo, 8GB of RAM and the Intel graphics of my DQ45CB motherboard.

But, I'm only seeing it during an intense copy, and only once in a while. On my machine, it's definitely easier to ignore than what we had prior to these Plasma etc. updates. 

I'm considering downgrading this bug from release blocker and critical because of the vast improvements I'm seeing. Do any of you who are still seeing artifacts object to that?

(In reply to Thomas Andrews from comment #30)
> I'm seeing the panel flicker during a copy operation, too. This is with a
> Core 2 Duo, 8GB of RAM and the Intel graphics of my DQ45CB motherboard.
> 
> But, I'm only seeing it during an intense copy, and only once in a while. On
> my machine, it's definitely easier to ignore than what we had prior to these
> Plasma etc. updates. 
> 
> I'm considering downgrading this bug from release blocker and critical
> because of the vast improvements I'm seeing. Do any of you who are still
> seeing artifacts object to that?

Depends on how you target your audience. Surely, anything that fixed kwin compositor is a vast improvement because the original situation was simply not functional.
The situation as it is now is quite ugly. It is systematic in SDDM and when hovering icons in the taskbar panel and start menu - not limited to file copy.
If I were to try a new distro and experiencing this, I'd probably remove and forget about it. But that's my own personal opinion.

T(In reply to Jan Smout from comment #31)
> (In reply to Thomas Andrews from comment #30)
> > I'm seeing the panel flicker during a copy operation, too. This is with a
> > Core 2 Duo, 8GB of RAM and the Intel graphics of my DQ45CB motherboard.
> > 
> > But, I'm only seeing it during an intense copy, and only once in a while. On
> > my machine, it's definitely easier to ignore than what we had prior to these
> > Plasma etc. updates. 
> > 
> > I'm considering downgrading this bug from release blocker and critical
> > because of the vast improvements I'm seeing. Do any of you who are still
> > seeing artifacts object to that?
> 
> Depends on how you target your audience. Surely, anything that fixed kwin
> compositor is a vast improvement because the original situation was simply
> not functional.
> The situation as it is now is quite ugly. It is systematic in SDDM and when
> hovering icons in the taskbar panel and start menu - not limited to file
> copy.
> If I were to try a new distro and experiencing this, I'd probably remove and
> forget about it. But that's my own personal opinion.

Yeah, dont downgrade it atleast for now...

It can be "ok" for a beta release, but not for a final release

Thank you for your opinions. Leaving it alone for now.

Now that I'm looking for it, I'm seeing the flickering in the panel more than I did before, but only in the panel. 

It's not enough for me to find annoying, but then I'm a pretty easy-going guy, trained over the years to get along with imperfection.

@TJ, do you also see the flickering on your NVIDIA system (when using nouveau)?

When I updated my Intel hardware M7 test system today ( about 125 updates ) upon reboot the Plasma desktop became completely unusable. Flicker, task bar empty. Lots of issues. I zeroed out the drive and did a netinstall from an up-to-date repo and ultimately during desktop configure the same issues arose.

(In reply to Martin Whitaker from comment #34)
> @TJ, do you also see the flickering on your NVIDIA system (when using
> nouveau)?

I had not used my nouveau-driven system in about two weeks. I fired it up this evening, and updated it - something like 200 packages, including a new kernel and glibc.

After the reboot I am not seeing the same flicker I see on my Intel system. But I see something much more serious. 

I have four virtual desktops on this machine, in one activity. That's the same as the Intel machine. On the Intel machine, I would see the flicker easiest if I had an app open in two or more desktops, when I would use the mouse to sweep across the panel. The faster I sweep, the more flicker I see.

On the nvidia machine with the nouveau driver, if I open more than one app the system becomes unresponsive to mouse clicks, both right and left. The only response I saw came after pushing the pwer button to bring up the logout display, when a left click on "Shutdown" did shut the system down.

The compositor had been switched to Xrender on this system before all this, as I had seen some rendering glitches with the nouveau driver before this, nothing that I haven't seen with nouveau and Plasma right along, and Xrender seemed to clear them up.

I have another nvidia system, different hardware, currently using the nvidia340 driver, but it too needs 200 or so updates before I can do a valid test. It's too late to start on that tonight. I will test it with both drivers tomorrow.

(In reply to William Kenney from comment #35)
> When I updated my Intel hardware M7 test system today ( about 125 updates )
> upon reboot the Plasma desktop became completely unusable. Flicker, task bar
> empty. Lots of issues. I zeroed out the drive and did a netinstall from an
> up-to-date repo and ultimately during desktop configure the same issues
> arose.

I'm seeing the panel flickering on all of my Intel i915 systems, now that I know how to make it happen, but I'm not seeing any of the other things you mention. My systems are fully updated. Oh, wait - the applet just popped up with new updates again.

As for the second nvidia system, I had forgotten that I had not yet installed from the round 2 beta 2 iso on that one. Over 600 updates pending, getting them now. This may take a while...

OK, updates complete on the second nvidia system, and I've done some more thorough tests:

With the nvidia340 driver, and OpenGL as compositor, looks good.

With nouveau and OpenGL, I'm seeing symptoms like Bill describes in Comment 35. At first, it looks OK, but when I went to scroll a web page in Firefox, it "jittered." I left Firefox open on one desktop, then opened Dolphin on another and The Gimp on another one yet. Switching from one to another worked a couple of times, then started to get glitchy, finally seeming to freeze. I tried to close one app - nothing. But I waited, and about a minute later it closed. The system still appeared frozen, but really wasn't. Right-clicking on what should have been an empty desktop brought up the context menu, and I was able to shut down.

Speculation: It was as if screen redrawing kept stumbling and stalling out. 

The modesetting driver also seems to work OK, though mouse wheel scrolling isn't particularly smooth.

For the time being going forward on testing M7 at this point I trust only
an install using:

Mageia-Cauldron-netinstall-x86_64.iso

and that to a blank drive be it on real hardware or in a Vbox client.

I did a clean Plasma DE install on my laptop with Intel HD graphics, using my personal mirror which was last synced 3 days ago (Feb 3rd). No flicker. I then updated everything except the Qt packages from a public mirror. No flicker. I then updated the Qt packages (5.12.0 -> 5.12.1). Very noticeable flickering. So I think it's safe to say the problem is in the latest Qt update.

I'll go and run the same test on my NVIDIA test system now.

Same results on my NVIDIA system (8800GT, nouveau driver), with the addition that the panel and applications will die at random intervals. The system log shows serious errors being reported by the nouveau kernel driver.

Switching to the modesetting DDX driver cures the flicker on both the Intel and NVIDIA systems, but does not cure the other problems on the NVIDIA system.

This HP laptop picked up several updates last night, including a new kernel and several kwin files. If anything, the flickering is worse.

As an aside, resuming from suspend is now broken. It worked before the updates.

I haven't done much with them so far, but after updating several QT packages this evening it appears that the flickering has disappeared on two of my Intel installs.

Will see if nouveau is any better tomorrow. Too late to start on that tonight.

I'll try a from a blank drive up netinstall of M7 Plasma x86_64 tomorrow
California time. 10 Feb. By that time the repos should be settled down.

I've tested the nouveau driver with the updated qt packages with the qtbase-everywhere-src-5.12.1-revert-commit-97600.patch applied and the flicker is gone both with compositor enabled or disabled for me. I did notice there is a long delay from login to get to a fully functional desktop. dmesg shows:

 nouveau 0000:09:00.0: fifo: fault 01 [WRITE] at 000000000025a000 engine 00 [GR] client 0f [GPC0/PROP_0] reason 82 [] on channel 14 [007f55e000 plasmashell[3506]]
[   18.582590] nouveau 0000:09:00.0: fifo: channel 14: killed
[   18.582592] nouveau 0000:09:00.0: fifo: runlist 0: scheduled for recovery
[   18.582595] nouveau 0000:09:00.0: fifo: engine 0: scheduled for recovery
[   18.582602] nouveau 0000:09:00.0: fifo: engine 6: scheduled for recovery
[   18.582605] nouveau 0000:09:00.0: plasmashell[3506]: channel 14 killed!

Hope this help a little and thanks for looking for a fix to Qt 5.12.1.

CC: (none) => texstar

For me, the latest update to qtbase (qtbase5-5.12.1-2) fixes the flickering on both Intel and NVIDIA systems, and also the random panel crashes on the NVIDIA system. I have not seen any nouveau kernel driver errors in the system log since this update.

(In reply to Martin Whitaker from comment #46)
> For me, the latest update to qtbase (qtbase5-5.12.1-2) fixes the flickering
> on both Intel and NVIDIA systems, and also the random panel crashes on the
> NVIDIA system. I have not seen any nouveau kernel driver errors in the
> system log since this update.

My Intel is also stable again ^_^

To be honest, the update also pulled in a new glibc, kernel and xorg, so can't demonstrate which package(s) did the trick. But my money is on the qtbase5-5.12.1-2 update.

My main Intel machine had picked up glibc and the new kernel earlier in the day. The flickering was still there after those updates, though possibly reduced a bit. I didn't notice if xorg was among those earlier updates.

The updates that made the problem go away were all QT-related, as I recall.

I have now tested with nouveau using my Geforce 9800GT card, and from what I've seen so far Plasma is now the most stable with nouveau that I have seen yet - and that includes all of Mageia 6.

BTW, I made sure that nouveau and OpenGL 2.0 were both being used.

Makes me really wonder if some of the older nvidia hardware, those no longer supported with proprietary drivers, would now work with Plasma.

Tried now on a machine using a Geforce 210 card. First boot after getting many updates was using Xrender as compositor. That was stable. Another boot after switching to OpenGL 2.0 had a few glitches (Jittery scrolling using mouse wheel in Firefox, flashing when the logout screen appeared), but did not freeze. 

Auto-login is active on these systems. The second and subsequent boots show a momentary (1-2 seconds) video glitch (a "scrambling" is how I would describe it) when the sddm video first shows, but corrects and is very stable after that, including when shutting down. Checking the 9800GT system again shows the same momentary glitch and subsequent stability.

While not quite as perfect as I thought it was when I typed Comment 49, it is definitely now usable.

10 Feb 2019, 09:00AM California time.
Up-to-date Local repo sync'd to mirrors.kernel.org
I executed an install to:

Intel Core i5-4460 Haswell Quad-Core 3.2GHz LGA 115
Gigabyte GA-B85M-D3H LGA 1150 Intel B85 chipset
Integrated Graphics Processor - Intel HD Graphics support
Audito chipset - Realtek ALC892, 7.1 channels
Corsair Vengeance 8GB ( 2 x 4GB ) 240-pin DDR3 SDRAM 1600
2TB Seagate HD

This platform suffered badly from the recent QT troubles with M7.

The install used:

Mageia-Cauldron-netinstall-x86_64.iso 2/9/19
Plasma

The install went clean without a problem.
The system booted to a working desktop.
During the setup of the Plasma desktop the system would freeze
and do strange things but after repeated reboots, some forced,
the install settled down. I could reboot to a working desktop
without a problem. An NFS link worked properly.

The main thing that sticks out here is some functions take an
interminable amount of time. The HD activity light may flash
for 5-minutes or so but things would eventually settle down
and work properly after that first pause.

The flashing is gone.

Example: hitting the MicroSoft hotkey brings up the menu bar
immediately on M6. Hitting the MicroSoft Hotkey on M7 for the
first time takes a few minutes for it to respond and display
properly. After that first 2-minute wait the second time
you hit it it comes up almost immediately.

A warm reboot works properly except that it will boot to
the Plasma desktop without desktop icons which appear a
minute or so later.

Upgraded my Cauldron install to latest packages and changed the X driver back to intel. The flickering is gone and plasma desktop seems be ok and fully functional.
So - can we mark this bug as resolved - fixed?

There are still problems with intel driver and SDDM when dual monitor setup is used (with modesetting it is ok), but that should be a separate bug.

I agree. This bug appears to be fixed. There have been no new reports of it resurfacing in some time now.

Status: NEW => RESOLVED
Resolution: (none) => FIXED