shell: wait for desktop-shell init before fade in
authorPekka Paalanen <ppaalanen@gmail.com>
Wed, 22 May 2013 15:03:09 +0000 (18:03 +0300)
committerKristian Høgsberg <krh@bitplanet.net>
Wed, 22 May 2013 22:07:30 +0000 (18:07 -0400)
commit79346ab3a5ae3ebaa83ba398913c481cc918ee46
tree0471af6acdd9f681899676a8114c3e7b9b055d56
parent17bd884bffdd35c61f6dcbe7f99649942c6ab1ba
shell: wait for desktop-shell init before fade in

On Raspberry Pi, weston-desktop-shell is so slow to start, that the
compositor has time to run the fade-in before the wallpaper is up. The
user launching Weston sees the screen flipping to black, the fbcon
fading in, and then the desktop popping up.

To fix this, wait for the weston-desktop-shell to draw
everything before starting the initial fade-in. A new request is
added to the private desktop-shell protocol to signal it. If a
desktop-shell client does not support the new request, the fade-in
happens already at bind time.

If weston-desktop-shell crashes, or does not send the 'desktop_ready'
request in 15 seconds, the compositor will fade in anyway. This should
avoid a blocked screen in case weston-desktop-shell malfunction.

shell_fade_startup() does not directly start the fade-in but schedules
an idle callback, so that the compositor can process all pending events
before starting the fade clock. Otherwise (on RPi) we risk skipping part
of the animation. Yes, it is a hack, that should have been done in
window.c and weston-desktop-shell instead.

Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
clients/desktop-shell.c
protocol/desktop-shell.xml
src/shell.c