2011-09-06 21:48:16 +04:00
|
|
|
<protocol name="desktop">
|
|
|
|
|
|
|
|
|
|
<interface name="desktop_shell" version="1">
|
|
|
|
|
<request name="set_background">
|
2011-11-22 15:43:52 +04:00
|
|
|
<arg name="output" type="object" interface="wl_output"/>
|
2011-09-06 21:48:16 +04:00
|
|
|
<arg name="surface" type="object" interface="wl_surface"/>
|
|
|
|
|
</request>
|
|
|
|
|
|
|
|
|
|
<request name="set_panel">
|
2011-11-22 15:43:52 +04:00
|
|
|
<arg name="output" type="object" interface="wl_output"/>
|
2011-09-06 21:48:16 +04:00
|
|
|
<arg name="surface" type="object" interface="wl_surface"/>
|
|
|
|
|
</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">
|
|
|
|
|
<arg name="surface" type="object" interface="wl_surface"/>
|
|
|
|
|
</request>
|
|
|
|
|
|
|
|
|
|
<request name="unlock"/>
|
|
|
|
|
|
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="time" type="uint"/>
|
|
|
|
|
<arg name="edges" type="uint"/>
|
|
|
|
|
<arg name="surface" type="object" interface="wl_surface"/>
|
|
|
|
|
<arg name="width" type="int"/>
|
|
|
|
|
<arg name="height" type="int"/>
|
|
|
|
|
</event>
|
|
|
|
|
|
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
|
|
|
<!-- 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. -->
|
|
|
|
|
<event name="prepare_lock_surface"/>
|
2011-09-06 21:48:16 +04:00
|
|
|
</interface>
|
|
|
|
|
|
|
|
|
|
</protocol>
|