[PATCH] shell: Set the DPMS state if the screensaver fails to launch or dies

Kristian Høgsberg hoegsberg at gmail.com
Fri Feb 15 13:27:51 PST 2013


On Fri, Feb 15, 2013 at 06:44:19PM +0200, Ander Conselvan de Oliveira wrote:
> From: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira at intel.com>
> 
> The lock hook in desktop-shell only changes the DPMS state the second
> time it is called, because during the first time it launches the
> screensaver and wakes the compositor again when the screensaver surface
> is configured. However, if the screensaver fails to launch, the output
> is left in an enabled state, even thought there's no content being
> displayed on the screen.
> 
> Fix this by disabling the outputs when the screensaver dies if the
> shell is still locked.

Yeah, that looks like the problem.  I've committed the patch and
closed the bug, but this state machine is a little wonky overall.
First off, once we get sigchild from failing to launch the
screensaver, the compositor is still in th IDLE state.  This means we
still have a timer running and eventually ends up calling into lock
again, and setting dpms off once more.  We could add a
weston_compositor_sleep() that sets the sleep state and cancels the
timer, and then call that from the sigchild handler as well.

However, I think we need to overhaul the split between shell.c and
core weston a bit more.  The whole fade-to-black behavior shouldn't be
hard-coded in core weston, and the lock and unlock signals would be
better named idle_signal and wake_signal and they'd do only that.
Changing compositor state and fading in or out would be controlled by
shell.c.  Then we can track the fade/screensaver/lock dialog/dpms
state in shell.c and it should all be a little easier to follow, and
we avoid the hardcoded fade policy in core weston.  We can move all
the fade code to util.c.  Or maybe we should move all the
spring/animation/fade code from util. into animation.c, the binding
code into bindings.c and the last couple of util.c functions back into
compositor.c.  And then just kill off util.c (always avoid util.c
files).

Also, I don't know if I have a problem with my kernel or something,
but my laptop never comes back after we hit dpms off.  I doubt it's a
kernel problem though - X works fine, and I had the same problem on my
old laptop with an older Fedora install.  Did you see this problem or
were you able to recover?

Kristian

> https://bugs.freedesktop.org/show_bug.cgi?id=60084
> ---
>  src/shell.c |    9 +++++++++
>  1 file changed, 9 insertions(+)
> 
> diff --git a/src/shell.c b/src/shell.c
> index dcbabf3..8d89bc2 100644
> --- a/src/shell.c
> +++ b/src/shell.c
> @@ -2085,7 +2085,16 @@ static const struct wl_shell_interface shell_implementation = {
>  static void
>  handle_screensaver_sigchld(struct weston_process *proc, int status)
>  {
> +	struct desktop_shell *shell =
> +		container_of(proc, struct desktop_shell, screensaver.process);
> +	struct weston_output *output;
> +
>  	proc->pid = 0;
> +
> +	if (shell->locked)
> +		wl_list_for_each(output, &shell->compositor->output_list, link)
> +			if (output->set_dpms)
> +				output->set_dpms(output, WESTON_DPMS_STANDBY);
>  }
>  
>  static void
> -- 
> 1.7.9.5
> 
> _______________________________________________
> wayland-devel mailing list
> wayland-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/wayland-devel


More information about the wayland-devel mailing list