Description of problem: This seems to be a bizarre regression - in f22, I could move the mouse to wake up the screen then press esc to unlock the screen, but after upgrading to f23 a few days ago, it had not been the case. By trial and error, I managed to figure out that if I do ctrl-alt-f1 (the usual user session is on vt2) to get at the Xwayland login-screen, and select myself again, I could unlock the screen. This is really bizarre. I don't know why this is acceptable for release... Version-Release number of selected component (if applicable): gnome-shell-3.18.1-1.fc23.x86_64 How reproducible: Always Steps to Reproduce: 1. wait a bit for the screen to go to sleep and go blank and dark 2. try moving the mouse - the screen lights up but shows nothing (in f22 it used to show the digital clock on a blue background at this stage); pressing escape does not seem to have any effect. 3. Actual results: complex manoeuvre to unlock screen - ctrl-alt-f1 to get to login-screen, type in password, etc. Expected results: It should wake and unlock on simple key press/mouse movement. Additional info: upgraded through 'dnf --releasever=23 ...' if that's relevant.
(In reply to Hin-Tak Leung from comment #0) > Description of problem: > This seems to be a bizarre regression - in f22, I could move the mouse to > wake up the screen then press esc to unlock the screen, but after upgrading > to f23 a few days ago, it had not been the case. By trial and error, I > managed to figure > out that if I do ctrl-alt-f1 (the usual user session is on vt2) to get at > the Xwayland login-screen, and select myself again, I could unlock the > screen. This is really bizarre. > > I don't know why this is acceptable for release... As you can imagine, this is not happening for most other people, so we need to figure out what is different with your system and why it is happening to you. - Are you using a wayland or X session? - Do any error messages appear in your journalctl logs? - What sort of input device are you using? It's possible this is some sort of input issue where input events aren't changing the X server out of the idle state, though if neither the keyboard or mouse has an effect, this is less likely.
running X session - gnome-classic, no error message in journlctl. It is a laptop, with its built-in touchpad. # ps -ax | grep X 1031 ? Ss 0:00 /usr/bin/abrt-watch-log -F Backtrace /var/log/Xorg.0.log -- /usr/bin/abrt-dump-xorg -xD 1656 tty1 Sl+ 0:00 /usr/bin/Xwayland :1024 -rootless -noreset -listen 4 -listen 5 -displayfd 6 2072 tty2 Sl+ 35:18 /usr/libexec/Xorg vt2 -displayfd 3 -auth /run/user/1000/gdm/Xauthority -nolisten tcp -background none -noreset -keeptty -verbose 3 22097 pts/2 S+ 0:00 grep --color=auto X # ps -ax | grep gdm 1251 ? Ssl 0:00 /usr/sbin/gdm 1263 ? Sl 0:00 gdm-session-worker [pam/gdm-launch-environment] 1424 tty1 Ssl+ 0:00 /usr/libexec/gdm-wayland-session /usr/bin/gnome-session --autostart /usr/share/gdm/greeter/autostart --session gnome-wayland 1565 tty1 Sl+ 0:00 /usr/libexec/gnome-session-binary --autostart /usr/share/gdm/greeter/autostart --session gnome-wayland 1575 tty1 Sl+ 0:34 gnome-shell --mode=gdm --wayland --display-server 1941 ? Sl 0:00 gdm-session-worker [pam/gdm-password] 2062 tty2 Ssl+ 0:00 /usr/libexec/gdm-x-session --run-script env GNOME_SHELL_SESSION_MODE=classic gnome-session --session gnome-classic 2072 tty2 Sl+ 35:19 /usr/libexec/Xorg vt2 -displayfd 3 -auth /run/user/1000/gdm/Xauthority -nolisten tcp -background none -noreset -keeptty -verbose 3 22125 pts/2 S+ 0:00 grep --color=auto gdm
As a test, can you try logging in to the standard (non-classic) session and see if the problem occurs there? The classic session does get enough testing that I'd expect this problem to have been reported already if that was the only trigger, but it's definitely the less common variant on Fedora.
(In reply to Owen Taylor from comment #3) > As a test, can you try logging in to the standard (non-classic) session and > see if the problem occurs there? The classic session does get enough testing > that I'd expect this problem to have been reported already if that was the > only trigger, but it's definitely the less common variant on Fedora. It gets interesting - my regular account can't even start the standard session; but the wayland session sleeps and unlocks correctly AFAIS. A separate test account also sleep and unlock like I prefer (just move mouse to wake screen and press esc) under the classic session also. So it seems that something under my regular account is stopping the standard x session from launch, and also causing this bizarre regression under the classic session. I have two extensions under ~/.local/share/gnome-shell/extensions/ system-monitor.gmail.com weather-extension both of which I have since updated to latest (which supposedly support gnome-shell 3.18) but no improvement.
Any log messages when you try to log in with the standard X session? Does disabling the extensions (from gnome-tweak-tool or the website) and logging out and logging back in help?
I think this might be related: Dec 03 21:58:50 localhost.localdomain gnome-settings-daemon.desktop[2292]: (gnome-settings-daemon:2292): GnomeDesktop-WARNING **: Failed to acquire idle monitor proxy: Timeout was reached Dec 03 21:58:50 localhost.localdomain gnome-settings-daemon.desktop[2292]: (gnome-settings-daemon:2292): GnomeDesktop-WARNING **: Error setting property 'PowerSaveMode' on interface org.gnome.Mutter.DisplayConfig: Timeout was reached (g-io-error-quark, 24) Dec 03 21:59:04 localhost.localdomain gnome-settings-daemon.desktop[2292]: (gnome-settings-daemon:2292): GnomeDesktop-WARNING **: Failed to acquire idle monitor proxy: Timeout was reached Dec 03 21:59:04 localhost.localdomain gnome-settings-daemon.desktop[2292]: (gnome-settings-daemon:2292): GnomeDesktop-WARNING **: Error setting property 'PowerSaveMode' on interface org.gnome.Mutter.DisplayConfig: Timeout was reached (g-io-error-quark, 24) Any idea what these messages about? It seems that it isn't about what session, but that I always have firefox running with many windows. There is one particular occasion which might be related - my machine goes into suspend when power is critical; so one day everything get paged out and I plugged it back in time. But gnome-shell just won't page back in. After working in the virtual console for an hour I got fed up with it and did 'gnome-shell --replace -d :0 &' This got my X responsive immediately. However I later found out that I could not reboot/shutdown from the new gnome-shell's menu; and there are a few mesasges on the controlling VT saying gnome-shell can't talk to dbus or something. I think this is a timeout thing, as well as gnome-shell not running with high-enough privilege/priority, like it did before the move to X without setuid root and Xwayland.
Switching the mouse cursor theme away from the default adwaita actually improves the situation a great deal and I can unlock the usual way most of the time after the change. I have no idea how/why. Strangely enough, searching for: "'PowerSaveMode' on interface org.gnome.Mutter.DisplayConfig: Timeout was reached (g-io-error-quark, 24)" on google lead to some reports about gnome-shell hanging, - on archlinux, I think - led to the advice of switching the mouse cursor theme away from the default adwaita with gnome-tweak-tool. This seems harmless enough so I gave it a try. The worst I get is a different mouse pointer I might like , right? So I did. and very surprised that it makes a lot of difference.
This message is a reminder that Fedora 23 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 23. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '23'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 23 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 23 changed to end-of-life (EOL) status on 2016-12-20. Fedora 23 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.