Running weston master (0eee0a) and wayland master. I have locking=true in weston.ini and [screensaver] # Uncomment path to disable screensaver path=/opt/wayland/libexec/weston-screensaver duration=300 Running weston on x11 launches the screensaver after a while, but moving the mouse or pressing keys doesn't cause the screensaver to go away. The screensaver keeps running as if nothing had happened. I'm testing on drm to see if this is only affecting the x11 backend, and will try to bisect it.
I can't reproduce this one...
It happens when I build with --with-cairo=gl (so weston-screensaver is built). After 5 minutes with weston/x11 idling in the background, the screen dims and goes black. Returning to it and moving the mouse or pressing any keys doesn't do anything, the window stays fully black. There's no sign of weston-screensaver running: [08:43:44.561] x11 output 1024x640, window id 39845893 [08:43:44.561] Loading module '/opt/wayland/lib/weston/desktop-shell.so' [08:43:44.561] Compositor capabilities: arbitrary surface rotation: yes screen capture uses y-flip: yes [08:43:44.561] libwayland: using socket /run/user/1000/wayland-0 [08:43:44.606] launching '/opt/wayland/libexec/weston-desktop-shell' emilio 3553 0.0 0.1 127236 14260 pts/0 S+ 08:43 0:00 /opt/wayland/bin/weston emilio 3554 0.0 0.2 156952 20388 pts/0 S+ 08:43 0:00 /opt/wayland/libexec/weston-keyboard emilio 3555 0.0 0.4 172504 34872 pts/0 S+ 08:43 0:00 /opt/wayland/libexec/weston-desktop-shell
I had a typo in weston.ini... *sigh*
Ok, after fixing the typo weston-screensaver launches and runs and I see the matrix-like screensaver. However upon moving the mouse or pressing any key, nothing happens - the screensaver keeps running as if I hadn't done anything. I have added some printfs in shell.c and this is what I get: [09:48:19.764] libwayland: using socket /run/user/1000/wayland-0 [09:48:19.766] launching '/opt/wayland/libexec/weston-desktop-shell' shell_fade(): type: fade in shell_fade(): creating animation with shell_fade_done callback shell_fade_done, type: 0 shell_fade(): type: fade out shell_fade(): creating animation with shell_fade_done callback shell_fade_done, type: 1 lock() launch_screensaver(): launching screensaver [09:53:22.382] launching '/opt/wayland/libexec/weston-screensaver' shell_fade(): type: fade in shell_fade(): creating animation with shell_fade_done callback shell_fade_done, type: 0 unlock(): calling desktop_shell_send_prepare_lock_surface shell_fade(): type: fade out shell_fade(): creating animation with shell_fade_done callback shell_fade_done, type: 1 lock(): already locked unlock(): calling desktop_shell_send_prepare_lock_surface shell_fade(): type: fade in If I build with cairo=gles and comment out weston-screensaver in weston.ini but keep locking=true, weston goes black after 5m and when moving the mouse I get the little unlock dialog with the green dot, and weston unlocks fine.
Things are working fine again. I don't know what was going on, but I'll investigate further if I can reproduce it again. But for now let's close this.
I am also having this issue. I built weston --with-cairo=gl and it seems like this usually happens the *second* time the screensaver comes up, I don't see the prompt to unlock the screen, despite how much I move the mouse, or press the keyboard. Although it seems once Weston puts the screen to sleep, (after showing the screensaver for a while) and then waking it up I got the prompt.
Reproducing this problems requires building weston with GL and cairo-gl (not GLES2) so the screensaver gets compiled and run. Fixed in: commit 4e20e9b84778cc2c3526c447335b6975547f58cd Author: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com> Date: Thu Apr 10 14:49:35 2014 +0300 shell: Disarm the screensaver timeout timer on terminate_screensaver() The timer was left running after the screensaver was terminated. When it triggered, a fade out that would in turn cause the screen to be locked was started. Since that could happen without the compositor emitting the idle signal, there would be no wake signal to make the shell show the lock screen, so the system was left unresponsive until the idle signal actually triggered. https://bugs.freedesktop.org/show_bug.cgi?id=70923
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.