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
What "restart" means is somewhat different between x11 and wayland
sessions. A X11 compositor may restart itself, thus having to manage
again all the client windows that were running. A wayland compositor
cannot restart itself, but might restart X11, in which case there's
possibly a number of wayland clients, plus some x11 app that is
being started.
For the latter case, the assert will break, so just make it
conditional. Also rename the function so it's more clear that it
only affects X11 windows.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/709
Using the master device, as we did, won't yield the expected result when
looking up the device node (it comes NULL as this is a virtual device).
Use the slave device, as the g-s-d machinery essentially expects.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/678
The device ID is kind of pointless on Wayland, so it might be better to
stick to something that works for both backends. Passing the device here
allows the higher layers to pick.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/676
As per commit 7718e67f, destroying the compositor causes destroying window
actors and this leads to stack changes, but at this point the stack was already
disposed and cleared.
So, clear the stack when any component that could use it (compositor, and X11)
has already been destroyed.
As consequence, also the stamps should be destroyed at later point.
Fixes https://gitlab.gnome.org/GNOME/mutter/issues/623https://gitlab.gnome.org/GNOME/mutter/merge_requests/605
We're currently emitting the 'grab-op-end' signal when the grab prerequisites
are met, but when display->grab_op is still set to a not-NONE value and thus
meta_display_get_grab_op() would return that in the signal callback.
And more importantly when this is emitted, devices are still grabbed.
Instead, emit this signal as soon as we've unset all the grab properties and
released the devices.
Helps with https://gitlab.gnome.org/GNOME/gnome-shell/issues/1326https://gitlab.gnome.org/GNOME/mutter/merge_requests/596
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
If the check happens on --nested (X11 backend) while there is no X11
display we would get a crash. Since the barriers are non-effective on
nested, just take it out into a separate condition.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/420
This explicit ungrab is made to ensure the other X11 display connection
is able to start an active grab immediately on the device without receiving
AlreadyGrabbed.
This is just relevant if there's two X11 display connections to transfer
grabs across, which may just happen on X11 windowing.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/420
The check for the focus xwindow is called, but not used. Fix that by
renaming the variable to reflect better what it does and actually using
the return value of the check.
This was the original intention of the author in commit
05899596d1 and got broken in commit
8e7e1eeef5.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/535
This is a simple clipboard manager implementation on top of MetaSelection.
It will inspect the clipboard content for UTF-8 text and image data whenever
any other selection source claims ownership, and claim it for itself
whenever the clipboard goes unowned.
The stored text has a maximum size of 4MB and images 200MB, to prevent the
compositor from allocating indefinite amounts of memory.
This is not quite a X11 clipboard manager, but also works there.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/320
When focus stealing prevention kicks in, mutter would set the demand
attention flag on the window.
Focus stealing prevention would also prevent the window from being
raised and focused, which is expected as its precisely its purpose.
Yet, when that occurs, the user expects the window which has just been
prevented from being focused to be the next one in the MRU list, so
that pressing [Alt]-[Tab] would raise and give focus to that window.
This works fine when the window is placed on the primary monitor, but
not when placed on another monitor, in which case the window which has
been denied focus is placed ahead of the MRU list and pressing
[Alt]-[Tab] would leave the focus on the current window.
This is because of a mechanism in `meta_display_get_tab_list()` which
forces the windows with the demand attention flag set to be placed first
in the MRU list when they're placed on a workspace different from the
current one.
But because workspaces apply only to the primary monitor (by default),
the windows placed on other outputs have their workspace set to `NULL`
which forces them ahead of the MRU list by mistake.
Fix this by using the appropriate `meta_window_located_on_workspace()
function to check if the window is on another workspace.
Closes: https://gitlab.gnome.org/GNOME/mutter/issues/523
Splitting out the X11 display initialization from display_open() broke
restoring the previously active workspace in two ways:
- when dynamic workspaces are used, the old workspaces haven't
been restored yet, so we stay on the first workspace
- when static workspaces are used, the code tries to access
the compositor that hasn't been initialized yet, resulting
in a segfault
Fix both those issues by splitting out restoring of the active workspace.
https://gitlab.gnome.org/GNOME/mutter/issues/479
Commit 25f416c13d added additional compilation warnings, including
-Werror=return-type. There are several places where this results
in build failures if `g_assert_not_reached()` is disabled at compile
time and the compiler misses a return value.
https://gitlab.gnome.org/GNOME/mutter/issues/447
This is a simple libcanberra abstraction object, so we are able
to play file/theme sounds without poking into GTK+/X11. Play
requests are delegated to a separate thread, so we don't block
UI on cards that are slow to wake up from power saving.
While leaving the runtime checks in place, requiring xrandr 1.5 at build
time allows us to remove some seemingly unnecessary conditional
inclusion of functionality.
The order and way include macros were structured was chaotic, with no
real common thread between files. Try to tidy up the mess with some
common scheme, to make things look less messy.
The function is intentionally provided as macro to not require a
cast. Recently the macro was improved to check that the passed in
pointer matches the free function, so the cast to GDestroyNotify
is now even harmful.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/176
MetaDisplay still had workspace signals, but nothing emitted them,
meaning we wouldn't get warnings if handlers were added there instead
of to MetaWorkspaceManager.
https://bugzilla.gnome.org/show_bug.cgi?id=759538
Under Xorg the cursor size preference was pre-scaled originating from
gtk, while with Wayland it came directly from GSettings remaining
unscaled. Under Xwayland this caused the X11 display code to set the
wrong size with HiDPI configurations, which was often later overridden
by the equivalent code in gtk, but not always.
Fix this by always having the cursor size preference unscaled, scaling
the size correctly where it's used, depending on how it's used.
https://bugzilla.gnome.org/show_bug.cgi?id=759538
