Confirmed here, it happens quite often and is a recent change.

Priority: Normal => release_blocker
Assignee: bugsquad => kde
Severity: normal => major

Also happens here (Plasma5 DE, SDDM, breeze theme), but not only during splash screen but also when just running Plasma desktop & different applications. Mostly the workaround (switching to VT2 and back to VT1) helps, but in some cases the desktop remains frozen.
Opened (gtk?) apps windows remain operational and it is possible to work there until you eg minimize them...

CC: (none) => jyri2000

(In reply to Jüri Ivask from comment #2)
> Also happens here (Plasma5 DE, SDDM, breeze theme), but not only during
> splash screen but also when just running Plasma desktop & different
> applications. Mostly the workaround (switching to VT2 and back to VT1)
> helps, but in some cases the desktop remains frozen.
> Opened (gtk?) apps windows remain operational and it is possible to work
> there until you eg minimize them...

I confirm this too.

I have also experienced freezes of the desktop (mageia theme). Nothing in the panel responds to mouse clicks. Events seems to be queued though. Clicks on icons in the launcher results in the corresponding applications opening after the VT2-VT1 switch.
A freeze has happened from within 10 minutes till after several hours use.
I can, however, make it happen after a few seconds with the following actions:
Hover over an icon in the launcher until the description pop up appears. Then move the cursor rapidly back and forth in the launcher area. After a short while, the panel freezes with one of the icon descriptions being constantly displayed.

My GPU is Intel HD 6000

Confirmed here too :(

CC: (none) => geiger.david68210

(In reply to Jüri Ivask from comment #2)
> Also happens here (Plasma5 DE, SDDM, breeze theme), but not only during
> splash screen but also when just running Plasma desktop & different
> applications. Mostly the workaround (switching to VT2 and back to VT1)
> helps, but in some cases the desktop remains frozen.
> Opened (gtk?) apps windows remain operational and it is possible to work
> there until you eg minimize them...

I do not have the SDDM issue on Fedora (probably related to not using prefdm, but who knows?), but I do have the plasmashell freezes, though only on my multi-display systems. There's a related bug filed in the Red Hat Bugzilla about it for Fedora[1], and it increasingly looks like something is wrong at the kernel level, though no one is really sure.

[1]: https://bugzilla.redhat.com/show_bug.cgi?id=1399396

CC: (none) => ngompa13
See Also: (none) => https://bugzilla.redhat.com/show_bug.cgi?id=1399396

could this issue coming from new xorg 1.19 (x11-server)?

(In reply to David GEIGER from comment #7)
> could this issue coming from new xorg 1.19 (x11-server)?

Either that or Mesa. I seem to recall a Mesa-related upgrade not long before I started experiencing the problems, and the problems (Plasma freezes, mpv freezes, vlc freezes) seem to be related to OpenGL.

Looking for related upstream bugs, I came across this one:
https://bugs.kde.org/show_bug.cgi?id=373131
Following the suggestion in the LinuxQuestions.org post linked to in Comment 16 (adapted to the intel driver), I found that enabling DRI3 in the xorg configuration seems to have removed the freeze.

(In reply to Arne Spiegelhauer from comment #9)
> Looking for related upstream bugs, I came across this one:
> https://bugs.kde.org/show_bug.cgi?id=373131
> Following the suggestion in the LinuxQuestions.org post linked to in Comment
> 16 (adapted to the intel driver), I found that enabling DRI3 in the xorg
> configuration seems to have removed the freeze.

Confirmed here too adding <Option "DRI" "3"> in xorg.conf file seems have fixed this freeze issue.

Hmm, according to Archwiki: https://wiki.archlinux.org/index.php/Intel_graphics
"DRI3 is the default DRI version in xf86-video-intel. On some systems this can cause issues such as this. To switch back to DRI2 add the following line to your configuration file:
Option "DRI" "2" "

At first tried that Option "DRI" "3" workaround here, but the result was that all Plasma desktop windows had no window control elements, so this workaround is not appliable here.

Instead of just removing that line as it was, I changed it to: Option "DRI" "2" and during last hour I have had no freezes so far. I'll keep testing...

Intel Graphics Media Accelerator 4500MHD here using intel driver.

Here on my Intel(R) Sandybridge Mobile change to Option "DRI" "2" result at freezes back :(

Yes, I was too optomistic here - the first system start today resulted a frozen Plasma splash screen :(
Interesting if switching to modesetting driver (which many distros are doing now) instead of intel helps?

I'm testing the system with modesetting driver instead of intel and so far there has been no freezes any more...

For the record, with nouveau here, and adding the "DRI" "3" option in xorg.conf stopped both Plasma freezes and mpv freezes.

It brings other problems (flickering) in my case, but that's something else =)

Hopefully there's a real fix that does not involve switching to DRI3 :p

(In reply to Jüri Ivask from comment #14)
> I'm testing the system with modesetting driver instead of intel and so far
> there has been no freezes any more...

I haven't been able to reproduce the freeze using the modesetting driver either

KDE bug report: https://bugs.kde.org/show_bug.cgi?id=373427

Keywords: (none) => UPSTREAM
See Also: (none) => https://bugs.kde.org/show_bug.cgi?id=373427

Same here on otherwise okay notebook listed under QA hardware.

IMHO this may need to be in our Errata

CC: (none) => dvgevers

This bug happens after update of the x11-* packages. I use AMD 8550G video and r600 driver. I also tried to not update x11-driver-video-ati package and update other x11-* packages - still freezes, so this isn't a problem with the driver but with the X server itself. Switching to another VT and back unfreezes the screen.

Video players (vlc and mplayer) often hangs, especially if I rewind the video. With the vlc I even need to sent a SIGKILL to it.

If I rollback my system to the state before the update of the x11-* packages, all works fine. Video players doesn't hangs too.

CC: (none) => krnekit
Summary: After logging into Plasma from SDDM, the splash screen may freeze (STA1 updated 2016-11-29) => Screen freeze on fade in/fade out effects (Plasma splash screen) and video playback
Source RPM: (none) => x11-server-1.19.0-9.mga6.src.rpm

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

CC: (none) => unruh

I created https://bugs.freedesktop.org/show_bug.cgi?id=99333

Also after asking in #xorg-devel on freenode, I was asked to test the following patch but either I did not apply it correctly, or it does not fix the problem:

From 1b42f9505ff3a39b441464f553442079b750fe88 Mon Sep 17 00:00:00 2001
              
From: Peter Hutterer
                                                               
Date: Thu, 8 Dec 2016 14:32:06 +1000
Subject: [PATCH] os: return 0 from check_timers if we touched any of them

Fixes a regression introduced in 0b2f30834b1a9f. If a driver posts input
events during a timer function (wacom and synaptics do this during tap
timeouts), ProcessInputEvents() is not called for these events. There are no
new events on any fds, so the events just sit in the queue waiting for
something else to happen.

Fix this by simply returning 0 from check_timers if we ran at least one of
them or reset them all. This way the callers ospoll_wait will exit and
continue with normal processing.

Signed-off-by: Peter Hutterer
Reviewed-by: Keith Packard
---
 os/WaitFor.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/os/WaitFor.c b/os/WaitFor.c
index ff1c85e..613608f 100644
--- a/os/WaitFor.c
+++ b/os/WaitFor.c
@@ -143,7 +143,7 @@ check_timers(void)
 {
     OsTimerPtr timer;
 
-    while ((timer = first_timer()) != NULL) {
+    if ((timer = first_timer()) != NULL) {
         CARD32 now = GetTimeInMillis();
         int timeout = timer->expires - now;
 
@@ -157,6 +157,8 @@ check_timers(void)
             /* time has rewound.  reset the timers. */
             CheckAllTimers();
         }
+
+        return 0;
     }
     return -1;
 }
-- 
2.10.2

Upstream patch available already.

I haven't been able to reproduce the freeze with this patch applied.

(In reply to Arne Spiegelhauer from comment #23)
> I haven't been able to reproduce the freeze with this patch applied.

https://bugs.freedesktop.org/attachment.cgi?id=128844

Awesome Arne, your analysis posted on the upstream bug report greatly helped having it fixed quickly!

Now we just need thierry or another packager to apply it to our xorg-server package.

Keywords: (none) => PATCH

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

CC: (none) => ftg

Thank you Arne, this is much needed :)

CC: (none) => fri

I uploaded x11-server-1.19.0-10.mga6, hoping that I named the patch correctly. Please test.

Testing it now, with nouveau driver.

So far so good, with Xorg using DRI2, with Plasma's desktop effects enabled, and 2 mpv instances playing with the OpenGL output, which also suffered from this issue =)

I've task-switched, desktop-switched and minimized/restored the players a lot, which before caused the freeze easily, and I haven't reproduced the problem yet.

Thanks!

Marja tested and reported to me on IRC and I installed the new package as well. So far so good. Closing as fixed.

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

Seem to have solved the issues here too, on both xorg ATI  (Thinkpad T60) and Nvidia proprietary drivers (Thinkpad T61p)  :)

I think https://bugs.mageia.org/show_bug.cgi?id=19883 is a duplicate of this one, in case anyone wants to close that.

And for the record, several hours later and quite a lot of use, and I still haven't experienced any problems =)

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

CC: (none) => mageia

Sorry to differ, but I am.  I'm still seeing the freezes of the panel after updating cauldron this morning and rebooting.  I thought perhaps this was due to implementing the previous workaround of setting "DRI" "3", so I reset to "DRI" "2" and rebooted.  It took quite a while for the problem to recur, but it did.

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

(In reply to Frank Griffin from comment #34)
> Sorry to differ, but I am.  I'm still seeing the freezes of the panel after
> updating cauldron this morning and rebooting.  I thought perhaps this was
> due to implementing the previous workaround of setting "DRI" "3", so I reset
> to "DRI" "2" and rebooted.  It took quite a while for the problem to recur,
> but it did.

Ok, I reopened your bug 20030 instead because you probably hit a different situation than the one fixed here.

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