Description of problem: In clutter-1.16.2-2 monitor sleep mode -> resume artifacts or Whenever inputing, flickers in display and Click ctrl + alt + fn -> returns, gnome3 is normal. Version-Release number of selected component (if applicable): 1.16.2-2 How reproducible: always Steps to Reproduce: 1. sleep mode 2. resume 3. Actual results: Expected results: Additional info: this issue doesn't happens in clutter-1.16.2-1. VGA Intel HD Graphics 4600 xorg-x11-drv-intel-2.21.15-5.fc20.x86_64
Was there a new version of mesa at the same time? It's unlikely to be clutter but the 3D driver is in mesa not xorg-x11-drv-intel
I can confirm this problem. It seems that it is really caused by clutter. With clutter-1.16.2-1 everything works fine. With clutter-1.16.2-2 the screen is sometimes garbled after screen resume. The only change between those clutter versions is: - Avoid excessive redraws when windows are moved in gnome-shell http://pkgs.fedoraproject.org/cgit/clutter.git/commit/?h=f20&id=f17f73a21a621c8a58018b766d187865c2836223 That sounds like a likely source of these problems. To reproduce this, I need to have automatic screen locking disabled (i.e. I'm not asked for password after I raise the shield) and I also need to let GNOME put my monitor to sleep automatically. A handy command for reproducing is: $ gsettings set org.gnome.desktop.session idle-delay 3 (otherwise you need to wait a long time) If I lock the screen manually, GNOME requires a password, and the artefacts don't appear (or they appear just slightly before unlocking the session, and then everything is OK). You really need to let the screen suspend automatically. I hit this in it about 10-50% of screen resumes. Sometimes I see corruption several times in a row, sometimes it's OK ten times in a row. Probably a race condition. Sometimes, the corruption hits the shield and the shield becomes "transparent" - I see all my windows before screen suspended, but I can't click on them - the shield is active, just "invisible" (that can be easily a security bug). Sometimes the shield is visible, but I see blue flashes all over the screen, even after unlocking. In all cases, switching to tty2 and back fixes the problem. Same as the original report, I see the problem on Intel HD Graphics 4600 (Haswell). I don't see this problem on Intel HD 3000. There is _nothing_ in the logs when the corruption happens. Not a single line is appended into journal. Please revert the commit and please don't push https://admin.fedoraproject.org/updates/FEDORA-2013-22280/clutter-1.16.2-2.fc20 stable. My packages: xorg-x11-drv-intel-2.21.15-5.fc20.x86_64 mesa-dri-drivers-9.2.4-1.20131128.fc20.x86_64 gnome-shell-3.10.2.1-3.fc20.x86_64 gnome-settings-daemon-3.10.2-3.fc20.x86_64 clutter-1.16.2-2.fc20.x86_64 Please tell me if I should provide further information.
Unfortunately it seems that some corruption is present even with clutter-1.16.2-1. But so far I've seen in only once (in dozens of attempts) and it was really minor - the shield was corrupted, but after raising the system was not. So, the clutter update is not the root cause of this. It only makes it worse. Probably a driver problem?
Created attachment 834927 [details] clutter corruption with clutter-1.16.2-3.fc20 With mutter-3.10.2-3.fc20 and clutter-1.16.2-3.fc20, the corruption goes almost away. Almost. I'm still able to reproduce it (with 100% reliability) this way: 1. Let your monitor suspend due to user inactivity 2. Press any key that doesn't raise the shield or wiggle mouse 3. You see (uncorrupted) shield 4. Do not do anything, so that monitor goes to suspend again 5. Again press a key or wiggle mouse 6. See corrupted screen I can get rid of corruption by any of these methods: a) raise shield by whatever method available (mouse drag, mouse wheel, keyboard) b) switch to console TTY and back c) hit Printscreen (the bug doesn't want to be documented, apparently). The shield is redrawn to a correct state and only after that the screenshot is taken. If you look at the picture I attached, the colors very closely resemble a firefox icon, which was my active window before monitor went to suspend. I tried to repeat that with other applications (e.g. pidgin, to see some purplish corruption), but since then, I received only a full-blue or a full-black screen (and sometimes the sliding arrows at the bottom center draw a rectangle on this black or blue screen).
*Finally* I found this bug! Suggest subject change since this is affecting everyone who runs Fedora on Haswell. Suggest appending words "haswell" and "Intel HD Graphics 4600" and possibly "i915" to the bug title.
"*Finally* I found this bug! Suggest subject change since this is affecting everyone who runs Fedora on Haswell." Um. Are you sure this is the right bug? Because this bug relates to a package which never went to stable, and indeed is no longer even in updates-testing.
Strike that, 1.16.2-1 was part of F20 Final.
c#5 author - can you say whether 1.16.2-3 is better, worse or the same as 1.16.2-1 on your system? http://koji.fedoraproject.org/koji/buildinfo?buildID=483768
clutter-1.16.2-3.fc20.x86_64 seems a lot better, possibly even fixed it.
Kamil: if 1.16.2-3 was better for you too, perhaps we should ask desktop team to re-submit it as its own update.
I covered clutter-1.16.2-3.fc20 in comment 4. I'm happy to give it +1 karma if -2 and -3 updates were supposed to fix other issues as well.
clutter-1.16.2-3.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/clutter-1.16.2-3.fc20
So this all got a bit messy what with this bug and https://bugzilla.redhat.com/show_bug.cgi?id=1012844 and multiple package updates and WOW MUCH CONFUSE, but bottom line, I decided to just submit 1.16.2-3 as an update again, with a rather long explanatory note: https://admin.fedoraproject.org/updates/clutter-1.16.2-3.fc20 as that says, please only down-vote it if it's worse than 1.16.2-1, as that's what is currently in stable. If I read everything correctly, I don't think anyone's actually claimed that 1.16.2-3 is worse than 1.16.2-1 at any point, so it seems to make sense to get it out there.
clutter-1.16.2-3.fc20 has been pushed to the Fedora 20 stable repository. If problems still persist, please make note of it in this bug report.
This is still an issue. gnome-desktop3-3.10.2-2.fc20.x86_64 clutter-1.16.2-4.fc20 xorg-x11-drv-intel-2.21.15-7.fc20.x86_64 mesa-dri-drivers-10.1.5-1.20140607.fc20.x86_64 i7-4600U w/ HD graphics 4400 (from lspci) Intel Corporation Haswell-ULT Integrated Graphics Controller (rev 0b) The problem seems to always occur after the screen wakes up from power saving mode. The screen is either a jumbled login screen or the desktop is visible even with the mouse pointer moveable but no interaction. Entering in the user password and hitting enter restores the desktop correctly, closing the laptop to force suspend and resuming displays the login screen correctly, and switching to a text console and back displays the login screen correctly. It seems like some sort of reinitialization or redraw isn't happening after the screen wakes up. It seems more like a driver issue than clutter.
I did a little more troubleshooting on this: Running the following commands: xset dpms force off No issues cinnamon-screensaver-command No issues xset dpms force off ; cinnamon-screensaver-command Screen corruption 100% of the time cinnamon-screensaver-command ; xset dpms force off Screen corruption 100% of the time I pulled xorg-x11-drv-intel-2.99.914-1.fc22.src.rpm from rawhide, rebuilt it for fc20 (no changes required), and the screen corruption disappeared. It seems like some strange interaction between the screensaver and screen sleep mode (or wake-up), but the good news is it looks like whatever the issue is, it fixed upstream at some point in the last year. Is it possible to rebase xorg-x11-drv-intel to 2.99.x in FC20 or do we need to narrow it to the specific change?
Aviso, thanks for debugging. This ticket should have been fixed after comment 14, the system apparently failed to do that. If you have narrowed down the remaining issue to the intel driver, could you please create a new bug report against xorg-x11-drv-intel and reference this bug for further information? Hopefully intel developers will be able to backport the fix to the current F20 driver. Let's put the new BZ number here so that interested people can subscribe to it (or use the See Also field). Thanks a lot.
The new bug was created as bug 1128871, I'm closing this one.