2011-09-06 21:48:16 +04:00
|
|
|
<protocol name="desktop">
|
|
|
|
|
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>
2013-05-22 19:03:09 +04:00
|
|
|
<interface name="desktop_shell" version="2">
|
2012-04-16 18:31:40 +04:00
|
|
|
<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
|
|
|
|
background, panels and locking surfaces.
|
|
|
|
</description>
|
|
|
|
|
2011-09-06 21:48:16 +04:00
|
|
|
<request name="set_background">
|
2011-11-22 15:43:52 +04:00
|
|
|
<arg name="output" type="object" interface="wl_output"/>
|
2012-06-27 00:29:50 +04:00
|
|
|
<arg name="surface" type="object" interface="wl_surface"/>
|
2011-09-06 21:48:16 +04:00
|
|
|
</request>
|
|
|
|
|
|
|
|
<request name="set_panel">
|
2011-11-22 15:43:52 +04:00
|
|
|
<arg name="output" type="object" interface="wl_output"/>
|
2012-06-27 05:19:23 +04:00
|
|
|
<arg name="surface" type="object" interface="wl_surface"/>
|
2011-09-06 21:48:16 +04:00
|
|
|
</request>
|
|
|
|
|
desktop-shell: screen locking protocol
Add protocol and functions for supporting screen locking, triggered by
activity timeout.
After activity timeout, compositor starts the fade to black, and then
enters SLEEPING state. At that point it calls lock() in the shell
plugin.
When input events trigger a wakeup, unlock() in the shell plugin is
called. This sends prepare_lock_surface event to the desktop-shell
client. The screen stays locked while the compositor starts fade-in.
At this point, desktop-shell client usually creates a surface for the
unlocking GUI (e.g. a password prompt), and sends it with the
set_lock_surface request. The compositor supposedly shows and allows
interaction only with the given lock surface (not yet implemented).
When desktop-shell has authenticated the user, or instead of issuing
set_lock_surface, it sends the unlock request. Upon receiving the unlock
request, the shell plugin unlocks the screen.
If desktop-shell client dies, the screen is unlocked automatically.
Signed-off-by: Pekka Paalanen <ppaalanen@gmail.com>
2011-11-15 15:34:48 +04:00
|
|
|
<request name="set_lock_surface">
|
2012-06-27 05:44:35 +04:00
|
|
|
<arg name="surface" type="object" interface="wl_surface"/>
|
desktop-shell: screen locking protocol
Add protocol and functions for supporting screen locking, triggered by
activity timeout.
After activity timeout, compositor starts the fade to black, and then
enters SLEEPING state. At that point it calls lock() in the shell
plugin.
When input events trigger a wakeup, unlock() in the shell plugin is
called. This sends prepare_lock_surface event to the desktop-shell
client. The screen stays locked while the compositor starts fade-in.
At this point, desktop-shell client usually creates a surface for the
unlocking GUI (e.g. a password prompt), and sends it with the
set_lock_surface request. The compositor supposedly shows and allows
interaction only with the given lock surface (not yet implemented).
When desktop-shell has authenticated the user, or instead of issuing
set_lock_surface, it sends the unlock request. Upon receiving the unlock
request, the shell plugin unlocks the screen.
If desktop-shell client dies, the screen is unlocked automatically.
Signed-off-by: Pekka Paalanen <ppaalanen@gmail.com>
2011-11-15 15:34:48 +04:00
|
|
|
</request>
|
|
|
|
|
|
|
|
<request name="unlock"/>
|
|
|
|
|
2012-06-28 19:08:05 +04:00
|
|
|
<request name="set_grab_surface">
|
|
|
|
<description summary="set grab surface">
|
|
|
|
The surface set by this request will receive a fake
|
|
|
|
pointer.enter event during grabs at position 0, 0 and is
|
|
|
|
expected to set an appropriate cursor image as described by
|
|
|
|
the grab_cursor event sent just before the enter event.
|
|
|
|
</description>
|
2012-06-05 17:58:51 +04:00
|
|
|
<arg name="surface" type="object" interface="wl_surface"/>
|
|
|
|
</request>
|
|
|
|
|
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>
2013-05-22 19:03:09 +04:00
|
|
|
<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>
|
|
|
|
|
2011-09-06 21:48:16 +04:00
|
|
|
<!-- We'll fold most of wl_shell into this interface and then
|
|
|
|
they'll share the configure event. -->
|
|
|
|
<event name="configure">
|
|
|
|
<arg name="edges" type="uint"/>
|
2012-06-27 00:29:50 +04:00
|
|
|
<arg name="surface" type="object" interface="wl_surface"/>
|
2011-09-06 21:48:16 +04:00
|
|
|
<arg name="width" type="int"/>
|
|
|
|
<arg name="height" type="int"/>
|
|
|
|
</event>
|
|
|
|
|
2012-04-16 18:31:40 +04:00
|
|
|
<event name="prepare_lock_surface">
|
|
|
|
<description summary="tell the client to create, set the lock surface">
|
|
|
|
Tell the shell we want it to create and set the lock surface, which is
|
|
|
|
a GUI asking the user to unlock the screen. The lock surface is
|
|
|
|
announced with 'set_lock_surface'. Whether or not the shell actually
|
|
|
|
implements locking, it MUST send 'unlock' request to let the normal
|
|
|
|
desktop resume.
|
|
|
|
</description>
|
|
|
|
</event>
|
2012-06-28 19:08:05 +04:00
|
|
|
|
|
|
|
<event name="grab_cursor">
|
|
|
|
<description summary="tell client what cursor to show during a grab">
|
|
|
|
This event will be sent immediately before a fake enter event on the
|
|
|
|
grab surface.
|
|
|
|
</description>
|
|
|
|
<arg name="cursor" type="uint"/>
|
|
|
|
</event>
|
|
|
|
|
|
|
|
<enum name="cursor">
|
|
|
|
<entry name="none" value="0"/>
|
|
|
|
|
|
|
|
<entry name="resize_top" value="1"/>
|
|
|
|
<entry name="resize_bottom" value="2"/>
|
|
|
|
|
|
|
|
<entry name="arrow" value="3"/>
|
|
|
|
|
|
|
|
<entry name="resize_left" value="4"/>
|
|
|
|
<entry name="resize_top_left" value="5"/>
|
|
|
|
<entry name="resize_bottom_left" value="6"/>
|
|
|
|
|
|
|
|
<entry name="move" value="7"/>
|
|
|
|
|
|
|
|
<entry name="resize_right" value="8"/>
|
|
|
|
<entry name="resize_top_right" value="9"/>
|
|
|
|
<entry name="resize_bottom_right" value="10"/>
|
|
|
|
|
|
|
|
<entry name="busy" value="11"/>
|
|
|
|
</enum>
|
2011-09-06 21:48:16 +04:00
|
|
|
</interface>
|
|
|
|
|
protocol: add screensaver interface
Add the screensaver interface to the desktop-shell protocol file. Also
add stubs for it in the compositor, and make wscreensaver to bind to the
screensaver interface. Wscreensaver gets a new option --demo to retain
the current behaviour as a regular wayland client.
When a screensaver application starts, it should bind to the screensaver
interface, enumerate all outputs, create a surface per output, and
register those surfaces via screensaver::set_surface request. Then it
continues with the usual animation loop, waiting for frame events. The
compositor will decide, when the given screensaver surfaces are
displayed. A screensaver application should respond to outputs coming
and going away by creating and destroying surfaces.
The compositor is supposed to activate a screensaver by exec'ing it, and
stop the screensaver by killing the client process. Only one client may
be bound to the screensaver interface at a time. If there already is a
client, the compositor could either kill it first, or not exec a new
one.
Signed-off-by: Pekka Paalanen <ppaalanen@gmail.com>
2011-11-24 13:34:05 +04:00
|
|
|
<interface name="screensaver" version="1">
|
2012-04-16 18:31:40 +04:00
|
|
|
<description summary="interface for implementing screensavers">
|
|
|
|
Only one client can bind this interface at a time.
|
|
|
|
</description>
|
protocol: add screensaver interface
Add the screensaver interface to the desktop-shell protocol file. Also
add stubs for it in the compositor, and make wscreensaver to bind to the
screensaver interface. Wscreensaver gets a new option --demo to retain
the current behaviour as a regular wayland client.
When a screensaver application starts, it should bind to the screensaver
interface, enumerate all outputs, create a surface per output, and
register those surfaces via screensaver::set_surface request. Then it
continues with the usual animation loop, waiting for frame events. The
compositor will decide, when the given screensaver surfaces are
displayed. A screensaver application should respond to outputs coming
and going away by creating and destroying surfaces.
The compositor is supposed to activate a screensaver by exec'ing it, and
stop the screensaver by killing the client process. Only one client may
be bound to the screensaver interface at a time. If there already is a
client, the compositor could either kill it first, or not exec a new
one.
Signed-off-by: Pekka Paalanen <ppaalanen@gmail.com>
2011-11-24 13:34:05 +04:00
|
|
|
|
|
|
|
<request name="set_surface">
|
2012-04-16 18:31:40 +04:00
|
|
|
<description summary="set the surface type as a screensaver">
|
|
|
|
A screensaver surface is normally hidden, and only visible after an
|
|
|
|
idle timeout.
|
|
|
|
</description>
|
|
|
|
|
2012-06-27 06:15:53 +04:00
|
|
|
<arg name="surface" type="object" interface="wl_surface"/>
|
protocol: add screensaver interface
Add the screensaver interface to the desktop-shell protocol file. Also
add stubs for it in the compositor, and make wscreensaver to bind to the
screensaver interface. Wscreensaver gets a new option --demo to retain
the current behaviour as a regular wayland client.
When a screensaver application starts, it should bind to the screensaver
interface, enumerate all outputs, create a surface per output, and
register those surfaces via screensaver::set_surface request. Then it
continues with the usual animation loop, waiting for frame events. The
compositor will decide, when the given screensaver surfaces are
displayed. A screensaver application should respond to outputs coming
and going away by creating and destroying surfaces.
The compositor is supposed to activate a screensaver by exec'ing it, and
stop the screensaver by killing the client process. Only one client may
be bound to the screensaver interface at a time. If there already is a
client, the compositor could either kill it first, or not exec a new
one.
Signed-off-by: Pekka Paalanen <ppaalanen@gmail.com>
2011-11-24 13:34:05 +04:00
|
|
|
<arg name="output" type="object" interface="wl_output"/>
|
|
|
|
</request>
|
|
|
|
|
|
|
|
</interface>
|
2011-09-06 21:48:16 +04:00
|
|
|
</protocol>
|