In the wl_shell_surface migration, I forgot to correct one cast in
shell_surface_set_transient(). 'parent_resource' is not a (struct
wlsc_surface *) but (struct shell_surface *).
This bug corrupts a wlsc_surface::output field, which later (in my
experiments) leads to a segmentation fault in surface_frame().
Fix the casts.
Signed-off-by: Pekka Paalanen <ppaalanen@gmail.com>
One less syscall and error path to check, and feels like a cleaner approach.
The commit adds two lines, but that's because we actually handle the
potential error now.
The signal mask is inherited over fork() and exec(), we need to
explicitly reset it.
This allows the children to receive the signals the compositor itself
has blocked, for example SIGINT and SIGTERM.
Signed-off-by: Pekka Paalanen <ppaalanen@gmail.com>
shell.c and tablet-shell.c had almost the same code for forking their
special shell client. Generalise this code and put it into
wlsc_client_launch() in compositor.c.
Improve error cleanup and reporting in wlsc_client_launch().
Signed-off-by: Pekka Paalanen <ppaalanen@gmail.com>
(!x < 0) is always false and doesn't make sense here. Looks like a typo so
remove the negation.
Signed-off-by: David Herrmann <dh.herrmann@googlemail.com>
Do not allow multiple wl_shell_surface objects to be created for a
wl_surface object.
Multiple shell_surface objects would confuse the compositor as they
contain separate instances of the shell-private data.
Signed-off-by: Pekka Paalanen <ppaalanen@gmail.com>
Leftovers from an intermediate patch set, the proper function name is
shell_get_shell_surface. Cosmetic change.
Signed-off-by: Pekka Paalanen <ppaalanen@gmail.com>
get_shell_surface() returns NULL, if the client has not created or has
destroyed the wl_shell_surface object.
All but one use of get_shell_surface() just retrieve the surface type,
so just fall back to SHELL_SURFACE_NORMAL there.
Resize hot-key binding really needs the wl_shell_surface object, as that
is the only way to send configure events. For surfaces without a
wl_shell_surface, simply do not resize them.
Signed-off-by: Pekka Paalanen <ppaalanen@gmail.com>
Remove shell_priv member from wlsc_surface, and replace it by a search
through the wl_surface destroy_listener_list.
This technique avoids any "extension" members in the wlsc_surface
structure.
Signed-off-by: Pekka Paalanen <ppaalanen@gmail.com>
Change desktop-shell protocol to use wl_shell_surface instead of
wl_surface.
Adapt the desktop-shell client and the shell plugin.
Signed-off-by: Pekka Paalanen <ppaalanen@gmail.com>
Protocol changes in Wayland core introduced a new interface
wl_shell_surface, and moved all wl_shell surface methods into it. Adapt
the compositor and its Wayland backend, shell plugin, and all clients to
the new interface.
Depends on the Wayland core commit "protocol: introduce wl_shell_surface"
Signed-off-by: Pekka Paalanen <ppaalanen@gmail.com>
Fix two bugs:
- if there are no backgrounds at all, the background pointer would have
been bogus. Lead to a segfault.
- if the hidden_surface_list is empty, wl_list_insert_list() would
corrupt the list. Lead to a hang in pick_surface().
Signed-off-by: Pekka Paalanen <ppaalanen@gmail.com>
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>
