Bug 69719 - [bug] Weston won't "wake up" after two touch events
Summary: [bug] Weston won't "wake up" after two touch events
Alias: None
Product: Wayland
Classification: Unclassified
Component: weston (show other bugs)
Version: unspecified
Hardware: Other All
: medium normal
Assignee: Wayland bug list
QA Contact:
Depends on:
Reported: 2013-09-23 16:07 UTC by Brian Lovin
Modified: 2013-10-25 00:03 UTC (History)
0 users

See Also:
i915 platform:
i915 features:

Set new state before emitting wake signal in weston_compsitor_wake (2.59 KB, patch)
2013-09-30 12:36 UTC, Neil Roberts
Details | Splinter Review

Description Brian Lovin 2013-09-23 16:07:31 UTC
Weston can be put into a state where it appears Weston won't wake up from Idle using only touch events (the mouse will still wake Weston up)

Steps to reproduce:
1. Start Weston using weston-launch and a low idle time:
 * weston-launch -- -i5
2. Allow Weston to go to idle
3. Wake Weston up using touch, but DO NOT press the green button to unlock Weston
4. Allow Weston to go idle again
5. Wake Weston up with a touch event
6. Notice that the monitor only displays black, even though the monitor is active.

Also of note is that the monitor doesn't go back to sleep - wasting battery life extremely quickly and in a very confusing way.

This was reproduced with the following stack:
Fedora 19
wayland (master) 1.2.91-0-g4125367
drm (master) heads/master-0-g0f4452b
mesa (master) heads/master-0-g6d29db7
weston (master) 1.2.91-0-g7799385
Comment 1 Neil Roberts 2013-09-25 09:00:32 UTC
I wonder if this is related to bug 69759? I think if it is a single-touch device and you were able to do that first tap without moving the finger before releasing it then the bug would be triggered and any subsequent taps would be lost.
Comment 2 Neil Roberts 2013-09-30 12:35:38 UTC
It turns out this bug has nothing to do with touch event handling because you can replicate the same problem if you try to wake up the compositor with the shift key instead.
Comment 3 Neil Roberts 2013-09-30 12:36:29 UTC
Created attachment 86846 [details] [review]
Set new state before emitting wake signal in  weston_compsitor_wake

The wake handler set up by the shell will try to unlock the screen
which works by setting up an animation which fades in the display. The
animation is started by first scheduling a repaint. Subsequent
repaints are scheduled whenever the previous frame is finished.
However in the case of the wake up signal the state is still
WESTON_COMPOSITOR_SLEEPING when the animation is started.
weston_output_schedule_repaint() ignores attempts to schedule a
repaint if the compositor is sleeping which means the animation never
gets run and will never complete.

The animation gets unstuck and continues if anything else schedules a
repaint after the state has been changed so the bug only gets hit in
certain conditions. The first wake up creates the lock surface which
causes a redraw when the first buffer is attached so the first wake up
is always ok. A redraw can be triggered in the subsequent wake ups
just by moving the mouse.

A good way to trigger the bug is to try to wake up the compositor by
pressing the shift key. If you let the compositor go back to sleep
after waking it up without unlocking it, the second press of the shift
key will not cause a redraw so the animation will not run and it won't
fade in.
Comment 4 Kristian Høgsberg 2013-10-01 18:05:08 UTC
(In reply to comment #3)
> Created attachment 86846 [details] [review] [review]
> Set new state before emitting wake signal in  weston_compsitor_wake

Yup, that looks good - another great fix, Neil.

commit 8b62e2043a721f4b6e6e409280f5acbde73e8dfa
Author: Neil Roberts <neil@linux.intel.com>
Date:   Mon Sep 30 13:14:47 2013 +0100

    Set new state before emitting wake signal in weston_compsitor_wake

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.