This fixes a race between Xwayland committing the surface content via
the wl_surface, and the XWM setting the role of the surface.
We now keep track of the (first) content commit on the surface and
forward it to the shell when we finally get the role.
There is no need to track later changes, as the only way for Xwayland to
unmap a surface is to destroy it.
Signed-off-by: Quentin Glidic <sardemff7+git@sardemff7.net>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Acked-by: Daniel Stone <daniels@collabora.com>
When we receive configure_notify we should update the surface's
position by calling xwayland_api->set_xwayland(). Otherwise some surfaces
like dnd surfaces from xwayland views are "stuck" at one place. When
setting XWAYLAND state though we should always call view_set_position(),
not just the first time we set this state.
Signed-off-by: Ilia Bozhinov <ammen99@gmail.com>
Reviewed-by: Quentin Glidic <sardemff7+git@sardemff7.net>
Fix up the window position whenever the geometry info changes.
If the window geometry changes, we want to keep the input-responding
content anchored to top-left. It is done by manipulating the dx,dy
arguments originating from a wl_surface.attach request.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Reviewed-by: Louis-Francis Ratté-Boulianne <lfrb@collabora.com>
Acked-by: Daniel Stone <daniels@collabora.com>
X11 applications expect -geometry command line option to work for
setting the initial window position, but currently this does not work.
Add provision to relay the initial position through libweston-desktop:
- weston_desktop_api gains a new entry set_xwayland_position
- implement set_toplevel_with_position() in xwayland internal interface
Once xwayland plugin starts calling set_toplevel_with_position(),
libweston-desktop can relay that information to a shell if the shell
wants to hear it.
If a shell does not implement the set_xwayland_position hook, the
old behaviour remains: the shell positions xwayland toplevels like any
other.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Reviewed-by: Quentin Glidic <sardemff7+git@sardemff7.net>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Currently, layers’ order depends on the module loading order and it does
not survive runtime modifications (like shell locking/unlocking).
With this patch, modules can safely add their own layer at the expected
position in the stack, with runtime persistence.
v4 Reviewed-by: Giulio Camuffo <giuliocamuffo@gmail.com>
Signed-off-by: Quentin Glidic <sardemff7+git@sardemff7.net>
Acked-by: Daniel Stone <daniels@collabora.com>
[Pekka: fix three whitespace issues]
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Helps tracking what happens with XWM.
Use the same debugging guard as XWM.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Reviewed-by: Quentin Glidic <sardemff7+git@sardemff7.net>
X client's don't have a wl_client associated with their
weston_desktop_client, so make sure to not use it.
Signed-off-by: Giulio Camuffo <giuliocamuffo@gmail.com>
Reviewed-by: Quentin Glidic <sardemff7+git@sardemff7.net>
The xwayland window type XWAYLAND is not handled by the shell at all,
instead libweston-desktop maps such surfaces itself. However, it forgot
to set weston_surface::is_mapped and weston_view::is_mapped.
weston_surface::is_mapped affects the behaviour of weston_view_unmap()
and weston_surface_attach().
weston_view::is_mapped affects the behaviour of weston_view_unmap() and
weston_view_destroy().
When manually mapping a window of type XWAYLAND, mark both the view and
surface as mapped. This follows the expections in libweston, even though
the meaning of is_mapped is not clearly defined for either surface or
view.
Also, when the XWAYLAND window is manually unmapped, unmap the
weston_surface. This updates weston_surface::is_mapped to reflect the
state. However, as a side-effect it will also unmap all sibling views,
should any exist.
v2: rename surface_base to wsurface
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Reviewed-by: Quentin Glidic <sardemff7+git@sardemff7.net>
Acked-by: Daniel Stone <daniels@collabora.com>
Add documentation (asserts) that show that windows of types XWAYLAND are
never registered with the shell.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Quentin Glidic <sardemff7+git@sardemff7.net>
Setting to a constant is much easier to read and grep for than setting to
a computed variable.
There are no functional changes.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Quentin Glidic <sardemff7+git@sardemff7.net>
Add an assert to ensure that a window of type XWAYLAND is never
attempted with a parent. Following the code though, the assert can be
made even stricter by allowing only TRANSIENT to have a parent.
This is essentially adding documentation.
v2: use stricter assert
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Reviewed-by: Daniel Stone <daniels@collabora.com>
With this weston_view_destroy() call, Xwayland popups make Weston freeze
in a busy-loop (probably corrupted wl_list).
Signed-off-by: Quentin Glidic <sardemff7+git@sardemff7.net>
Reviewed-by: Bryce Harrington <bryce@osg.samsung.com>
It doesn't destroy the view per se (except for internal surfaces) and
require the caller to also destroy the view itself at the appropriate
time.
Signed-off-by: Quentin Glidic <sardemff7+git@sardemff7.net>
Reviewed-by: Jonas Ådahl <jadahl@gmail.com>
Instead we store the buffer move and just use it when the signal is
fired.
Signed-off-by: Quentin Glidic <sardemff7+git@sardemff7.net>
Reviewed-by: Jonas Ådahl <jadahl@gmail.com>
libweston-desktop is an abstraction library for compositors wanting to
support desktop-like shells.
The API is designed from xdg_shell features, as it will eventually be
the recommended shell for modern applications to use.
In the future, adding new shell protocols support will be easier, as
limited to libweston-desktop.
The library versioning is the same as libweston. If one of them break
ABI compatibility, the other will too.
The compositor will only ever see toplevel surfaces (“windows”), with
all the other being internal implementation details.
Thus, popups and associated grabs are handled entirely in
libweston-desktop.
Xwayland special surfaces (override-redirect) are special-cased to a
dedicated layer, as the compositor should not know about them.
All the shell error checking is taken care of too, as well as some
specification rules (e.g. sizes constraint for maximized and fullscreen
surfaces).
All the compositor has to do is define a few callbacks in the interface
struct, and manage toplevel surfaces.
Signed-off-by: Quentin Glidic <sardemff7+git@sardemff7.net>
Reviewed-by: Jonas Ådahl <jadahl@gmail.com>
Acked-by: Giulio Camuffo <giulio.camuffo@kdab.com>
Differential Revision: https://phabricator.freedesktop.org/D1207
Quentin Glidic