Enumerate the different surface purposes for the shell: background, panel,
lock surface, and normal (other) surfaces.
Instead of testing wlsc_surface pointers against known pointers, check
the purpose field.
This change will ease implementing per-output background, panel, etc.
when the number of "known" surface pointers grows dynamically.
Signed-off-by: Pekka Paalanen <ppaalanen@gmail.com>
Add a pointer to wlsc_surface for shell-private data. This is a
temporary solution.
Add struct shell_surface, where you can add any shell-private data
members related to a wlsc_surface. The getter function takes care of
creating the private data if it does not exist yet.
Not used anywhere yet.
Signed-off-by: Pekka Paalanen <ppaalanen@gmail.com>
We'll want to enhance later the driver regarding the tool being used, but for
now just remove unused bits.
Signed-off-by: Tiago Vignatti <tiago.vignatti@intel.com>
Very likely that 2.4 kernels won't be used with Wayland compositor so the
check for signal value is pretty much useless.
It's okay to change e->value inside evdev_process_absolute_motion_touchpad
given it's not used later on, and I also rather not touch this snip because it
will be changed when multi-touch support arrives.
Signed-off-by: Tiago Vignatti <tiago.vignatti@intel.com>
A copy & paste bug, that resulted setting to NULL something else than
shell->lock_surface when that surface was destroyed.
The symptom: let compositor lock down, unlock it, let it lock down
again, and the unlock dialog is never requested again. This bug was
triggered by the previous fix "shell: fix compositor wakeup while
locked".
Signed-off-by: Pekka Paalanen <ppaalanen@gmail.com>
Compositor is locked, woken up, unlock dialog is shown; if the
compositor does to sleep again, before being unlocked, it will never
wake up again, because unlock() becomes a no-op, yet it should wake the
compositor up.
Fix this by letting unlock() to wake up the compositor, if lock surface
is present.
Signed-off-by: Pekka Paalanen <ppaalanen@gmail.com>
When the lock surface was map()'d while the compositor was locked,
wlsc_surface_configure() was never called for the lock surface. Hence,
the surface->output was NULL, and the 'frame' event was never sent,
causing desktop-shell to loop in dri2_swap_buffers().
Fix this by calling wlsc_surface_configure() for the lock surface
always in map().
Additionally, adjust the comments in map() to make it more readable.
Signed-off-by: Pekka Paalanen <ppaalanen@gmail.com>
This way we can still use surface->link when a surface is not in
the main compositor surface list and don't need the hidden_surface
wrapper object. Also, setting surface->output to NULL will block
the surface frame callback until we put the surface back into the
main list. This has the effect of blocking animations while a surface
isn't visible.
When the compositor is locked, all surfaces are moved from the
compositor's list to a private list in the shell plugin. This prevents
any of those surfaces from being visible or receiving input. All new
surfaces will be moved to the private list, too.
The background surface is an exception, it is left to the compositor's
list, so the background will be painted. It is assumed that the
background surface does not allow any actions while being locked.
When desktop-shell announces a lock surface (an unlock dialog), it is
added to the compositor's list, so the user can interact with it.
Signed-off-by: Pekka Paalanen <ppaalanen@gmail.com>
Check that wlsc_surface::link is part of a list before assuming it is
part of the compositor->surface_list list.
The shell plugin may want to remove a surface from the compositor's
surface list to hide it. Note, that the shell plugin cannot use
wlsc_surface::link for its own purposes.
Signed-off-by: Pekka Paalanen <ppaalanen@gmail.com>
wlsc_compositor_fade() ends up in wlsc_compositor_schedule_repaint(),
which is a no-op if compositor is SLEEPING.
On wakeup, first set status to ACTIVE, then call wlsc_compositor_fade()
to start and actually show the animation.
Before, fade was called first, which reset the animation, but did not
cause a repaint. The following wakeup (any input event) would then cause
a repaint, showing the animation from the middle or end of it.
Signed-off-by: Pekka Paalanen <ppaalanen@gmail.com>
With the idle_inhibit optimization, wlsc_compositor_wake() is a no-op if
idle_inhibit > 0.
When the shell is waking up the compositor from SLEEPING state as an
indirect response to input activity, it does not work. The call path is:
notify_key() / notify_button()
wlsc_compositor_idle_inhibit()
wlsc_compositor_activity()
shell->unlock()
send prepare_lock_surface event
idle_inhibit++
and when the desktop-shell client responds to the event:
desktop_shell_set_lock_surface() / desktop_shell_unlock()
wlsc_compositor_wake()
no-op, because idle_inhibit > 0
Fix this by removing the idle_inhibit check from wlsc_compositor_wake().
The optimization did not work for pointer motion while no keys pressed,
anyway, so the performance hit is probably unobservable.
Now the compositor wakes up also on key or button press.
Signed-off-by: Pekka Paalanen <ppaalanen@gmail.com>
When compositor enters SLEEPING state, the shell plugin goes locked. If
compositor wakes up itself, it will fade in while the shell may not yet
have a lock surface to show.
Fix this by assigning wake-up to be called from the shell, if the
compositor is SLEEPING. The shell may wait for the lock surface request,
and only then wake up the compositor. The compositor will fade in
directly to the lock screen.
krh: original patch for compositor.c
ppaalanen: integration and shell.c changes
Signed-off-by: Pekka Paalanen <ppaalanen@gmail.com>
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>
Pass the correct pointer to free().
This is just a cosmetic change, because 'resource' happens to be the
first member in wlsc_frame_callback.
Signed-off-by: Pekka Paalanen <ppaalanen@gmail.com>
This is the same as the damage of the top-level surface so just use that.
There's a problem that if we change the stacking, the damage layering breaks,
but that's a problem we already have.
The shell module only needs to deal with attach when it's either the initial
attach or when the attach changes the size of the surface. In case of
initial attach, the shell needs to pick a position for the surface and a
place in the surface stack. We split this case out as a new shell->map
callback. The other case is split into the shell->configure callback,
where the shell may adjust the surface position or reject the new size.
The third parameter of open() is for file-creation modes. File flags are passed
in the second paramater.
Signed-off-by: David Herrmann <dh.herrmann@googlemail.com>
Check, that only the desktop-shell client spawned by the compositor
(desktop-shell plugin) is allowed to bind to desktop_shell interface.
Other clients will receive an error like:
wl_display@1.error(desktop_shell@20, 0,
"permission to bind desktop_shell denied")
The error has the proper object id and interface type.
Note: desktop-shell cannot be started manually anymore, it has to be
started by the compositor automatically.
Signed-off-by: Pekka Paalanen <ppaalanen@gmail.com>
Fork and exec desktop-shell in the compositor. This is a way to create
an authenticated client. Later, the desktop-shell interface will be
reserved for this client only.
For exec to work, the compositor should be started from the
wayland-demos' root directory.
Signed-off-by: Pekka Paalanen <ppaalanen@gmail.com>
All the compositors are using GLES2 so check for the appropriate
surfaceless extension.
Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
The repaint logic breaks when finish_frame is called from the present
callback. Ideally we should throttle to vsync (or even better, the
compositor repaint cycle, but hey, X is X), but this goes a long way.
Pekka Paalanen
Kristian Høgsberg
Benjamin Franzke
Tiago Vignatti
David Herrmann
Ander Conselvan de Oliveira