diff options
| author | Pekka Paalanen <ppaalanen@gmail.com> | 2013-05-22 18:03:09 +0300 |
|---|---|---|
| committer | Kristian Høgsberg <krh@bitplanet.net> | 2013-05-22 18:07:30 -0400 |
| commit | 79346ab3a5ae3ebaa83ba398913c481cc918ee46 (patch) | |
| tree | 0471af6acdd9f681899676a8114c3e7b9b055d56 /protocol | |
| parent | 17bd884bffdd35c61f6dcbe7f99649942c6ab1ba (diff) | |
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>
Diffstat (limited to 'protocol')
| -rw-r--r-- | protocol/desktop-shell.xml | 13 |
1 files changed, 12 insertions, 1 deletions
diff --git a/protocol/desktop-shell.xml b/protocol/desktop-shell.xml index d48c3dd3..65e44a73 100644 --- a/protocol/desktop-shell.xml +++ b/protocol/desktop-shell.xml @@ -1,6 +1,6 @@ <protocol name="desktop"> - <interface name="desktop_shell" version="1"> + <interface name="desktop_shell" version="2"> <description summary="create desktop widgets and helpers"> Traditional user interfaces can rely on this interface to define the foundations of typical desktops. Currently it's possible to set up @@ -33,6 +33,17 @@ <arg name="surface" type="object" interface="wl_surface"/> </request> + <request name="desktop_ready" since="2"> + <description summary="desktop is ready to be shown"> + Tell the server, that enough desktop elements have been drawn + to make the desktop look ready for use. During start-up, the + server can wait for this request with a black screen before + starting to fade in the desktop, for instance. If the client + parts of a desktop take a long time to initialize, we avoid + showing temporary garbage. + </description> + </request> + <!-- We'll fold most of wl_shell into this interface and then they'll share the configure event. --> <event name="configure"> |