With the addition of xauth support (commit a8984a81c), Xwayland would
rely only on the provided cookies for authentication.
As a result, running an Xclient from another VT (hence without the
XAUTHORITY environment variable set) would result in an access denied.
The same on X11 is granted because the local user is automatically
granted access to Xserver by the startup scripts.
Add the local user to xhost at startup on Xwayland so that the user can
still run a client by setting the DISPLAY as long as it's the same user
on the same host.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/735
There may be cases where a X11 client does not spawn any X11 windows (eg.
simple clients like xinput --list, or xlsclients), in this case the Xwayland
server would remain running until X11 windows happen to come and go in the
future.
Firing the shutdown timeout on restart caters for this, and would be undone
if the client maps X11 windows.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/728
Where the prepare_auth_file() call is, it does create a new one on every
respawn of Xwayland. This is not benefitial, as the XAUTHORITY envvar is
already fixed in the session.
Only create the XAuthority file once, and reuse it on future Xwayland
respawns.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/728
When primary_offer_receive checks if the requested mime_type is supported,
it should check against the list of mime-types supported by the
primary-selection, instead of the list for the clipboard.
This fixes primary selection copy paste from X11 apps to Wayland apps
not working.
Fixes: https://gitlab.gnome.org/GNOME/mutter/issues/702
We only listen for those so we know there's no more X11 clients that we
should keep the Xwayland server alive for. Check first that we really did
request Xwayland to be handled on demand for this, otherwise the check is
superfluous, even harmful.
https://gitlab.gnome.org/GNOME/mutter/issues/719
The Xwayland manager now has 4 distinct phases:
- Init and shutdown (Happening together with the compositor itself)
- Start and stop
In these last 2 phases, handle orderly initialization and shutdown
of Xwayland. On initialization We will simply find out what is a
proper display name, and set up the envvar and socket so that clients
think there is a X server.
Whenever we detect data on this socket, we enter the start phase
that will launch Xwayland, and plunge the socket directly to it.
In this phase we now also set up the MetaX11Display.
The stop phase is pretty much the opposite, we will shutdown the
MetaX11Display and all related data, terminate the Xwayland
process, and restore the listening sockets. This phase happens
on a timeout whenever the last known X11 MetaWindow is gone. If no
new X clients come back in this timeout, the X server will be
eventually terminated.
The shutdown phase happens on compositor shutdown and is completely
uninteresting. Some bits there moved into the stop phase as might
happen over and over.
This is all controlled by META_DISPLAY_POLICY_ON_DEMAND and
the "autostart-xwayland" experimental setting.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/709
This is important when using a touchscreen or stylus instead of a mouse
or touchpad. If the cursor only gets hidden and the focus stays the
same, the window will still send hover events to the UI element under
the cursor causing unexpected distractions while interacting with the
touchscreen.
Fix this by emitting a visibility-changed signal from the cursor tracker
which then triggers a focus surface sync and always set the focus
surface to NULL when it's synced while the cursor is hidden.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/448
The way code was structured made it easy to misunderstand things as the
surface actor of a window actor could change over time. So is not the
case, however, the intention of the corresponding "update" function was
so that a surface actor could be assigned to a window actor as soon as
the X11 window was associated with its corresponding wl_surface, if the
window in question came from Xwayland.
Restructure the code and internal API a bit to make it clear that a
window actor only once gets a surface actor assigned to it, and that it
after that point never changes.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/659
We used to have wayland-specific paths for this in src/wayland, now we
have ClutterKeymap that we can rely on in order to do state tracking,
and can do this all on src/backend domain.
This accomodates the feature in common code, so will work on both
Wayland and X11.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/590
We get a signed integer (-1 meaning "no workspace specified"), store it in
an unsigned integer, check for >= 0 (of course it is!) and set as the window
workspace (signed integer, -1 meaning "show on all workspaces"). What could
possibly go wrong?
https://gitlab.gnome.org/GNOME/mutter/merge_requests/639
The include <sys/random.h> was added to glibc-2.25, previously was
<linux/random.h>.
Adjust meson build and code to accomodate both.
Fixes: a8984a81c "xwayland: Generate a Xauth file and pass this to
Xwayland when starting it"
https://gitlab.gnome.org/GNOME/mutter/merge_requests/633
Before this commit, sudo x11-app, e.g. sudo gvim /etc/some-file, fails
when running a Wayland session. Where as doing this under a "GNOME on Xorg"
session works fine. For a user switching from the Xorg session to the
Wayland session, this is regression, which we want to avoid.
This commit fixes this by creating and passing an xauth file to Xwayland when
mutter starts it. Just like gdm or startx pass a xauth file to Xorg when they
start Xorg.
Fixes#643https://gitlab.gnome.org/GNOME/mutter/issues/643
When we're unfullscreening, we might be returning to a window state that
has its size either managed by constraints (tiled, maximized), or not
(floating). Lets just pass the configure size 0x0 when we're not using
constrained sizes (i.e. the window going from being fullscreen to not
maximized) and let the application decide how to size itself.
Fixes: https://gitlab.gnome.org/GNOME/mutter/issues/638https://gitlab.gnome.org/GNOME/mutter/merge_requests/621
Attaching a NULL buffer should hide the cursor sprite. In these cases,
we we'll have neither surface nor buffer damage, so also update when we
just attached a NULL buffer.
Fixes: https://gitlab.gnome.org/GNOME/mutter/issues/630
When 252e64a0ea moved the texture
ownership to MetaWaylandSurface, it failed to handle the case when a
NULL-buffer is attached, leaving the texture reference in place. This
caused issues when the surface should have been hidden (e.g. attaching a
NULL buffer to a cursor surface for hiding the cursor sprite).
Related: https://gitlab.gnome.org/GNOME/mutter/issues/630
To emulate X11 grabs, mutter as a Wayland compositor would disable its
own keyboard shortcuts and when the X11 window is an override redirect
window (which never receives focus), it also forces keyboard focus onto
that X11 O-R window so that all keyboard events are routed to the
window, just like an X11 server would.
But that's a bit of a “all-or-nothing” approach which prevents
applications that would legitimately grab the keyboard under X11 (like
virtual machine viewers) to work by default.
Change “xwayland-allow-grabs” to control whether the keyboard focus
should be locked onto override redirect windows in case of an X11 grab.
For stringent needs, careful users can still use the blacklisting
feature (i.e. a list containing “!*”) to prevent grabs from any X11
applications to affect other Wayland native applications.
https://gitlab.gnome.org/GNOME/mutter/issues/597
Having a cursor role with a NULL renderer is valid state, and even desirable
on tablets (eg. after proximity out). In those cases it should be
interpreted as the cursor surface not being over any output.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/545
We handle this in backend specific code for x11, so do the wayland
bits here. We can only honor this on applications that request focus
on a surface after a startup request, as we do need an explicit
surface to apply the workspace on (and we don't have additional clues
like WMCLASS on X11). Notably, gtk_shell1.notify_startup doesn't suffice.
Another gotcha is that the .request_focus happens when the surface is
already "mapped". Due to the way x11 and the GDK api currently work (first
reply on the startup id, then map a window, then request focus on that
window). This means the surface will ignore at this point
window->initial_workspace, so it must be actively changed.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/544
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/issues/674
On a successful DnD operation we may expect the wl_data_source and
wl_data_offer to live long enough to finish the data transfer, despite the
grab operation (and other supporting data) being gone.
When that happens, the compositor expects a wl_data_offer.finish request to
notify that it finished. However the client may still chose not to send that
and destroy the wl_data_offer instead, resulting in the MetaSelectionSource
owner for the DnD selection not being unset.
When that happens, the DnD MetaSelectionSource still exists but it's
detached from any grab operation, so will not be unset if eg. the drag
source client destroys the wl_data_source. This may result in crashes when
the next drag operation tries to replace the owner DnD MetaSelectionSource.
Check explicitly for this case, in order to ensure the DnD owner is unset
after such operations.
Closes: https://gitlab.gnome.org/GNOME/mutter/issues/591
This argument instructs Xwayland to exit when there are no further
client connections. However we eventually want to handle restarts
ourselves (where, notably, mutter's will be at least the last client
connection).
This behavior could also induce race conditions on startup with clients
that quickly open and close a display, which is a more pressing issue.
Also, add -noreset back (which was also removed in commit 054c25f693 that
added -terminate). We don't want to reset the X server to a pristine state
in that situation either.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/420
Code underneath seems to handle errors properly, or be x11-agnostic
entirely, this is apparently here to save a few XSync()s on X11. Just
drop this windowing dependent bit to make things cleaner.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/420
It is now separated into meta_xwayland_start(), which picks an unused
display and sets up the sockets, and meta_xwayland_init_xserver(), which
does the actual exec of Xwayland and MetaX11Display initialization.
This differentiation will be useful when Mutter is able to launch Xwayland
lazily, currently the former calls into the latter.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/420
In all places (including src/wayland) we tap into meta_x11_display* focus
API, which then calls meta_display* API. This relation is backwards, so
rework input focus management so it's the other way around.
We now have high-level meta_display_(un)set_input_focus functions, which
perform the backend-independent maintenance, and calls into the X11
functions where relevant. These functions are what callers should use.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/420
All child classes of `MetaWaylandShellSurface` as well as
`MetaWaylandSurfaceRoleXWayland` should only sync their actor if
their toplevel surface has a window. Currently this check is done
in the actor-surface class, but not all surface classes have a
toplevel window, e.g. dnd-surfaces.
Move the check to the right places.
For subsurfaces this assumes that the subsurface is not the child of
a window-less surface (like, as stated above, e.g. a dnd-surface).
If we want to support subsurfaces of window-less surfaces in the future
we have to extend the check here.
But as this is not a regression, ignore this case for now.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/537
