The end goal is to have all clutter backend code in src/backends. Input
is the larger chunk of it, which is now part of our specific
MutterClutterBackendX11, this extends to device manager, input devices,
tools and keymap.
This was supposed to be nice and incremental, but there's no sane way
to cut this through. As a result of the refactor, a number of private
Clutter functions are now exported for external backends to be possible.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/672
Unmanaging the windows may trigger stack operations that we later try
to synchronize despite being in dispose() stage. This may trigger
MetaStackTracker warnings when trying to apply those operations.
Switching destruction order (First dispose the X11 stack representation,
then unmanage windows) won't trigger further stack changes on X11 windows
after having signaled MetaDisplay::x11-display-closing.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/709
In the case mutter is a x11 compositor, it doesn't matter much
since the stack tracker will go away soon. In the case this is a
wayland compositor with mandatory Xwayland, it matters even less
since the session would be shutting down in those paths.
But if this a wayland compositor that can start Xwayland on demand,
this is even harmful, as the MetaStackTracker should be cleared of
x11 windows at this moment, and we actually did right before dispose
on ::x11-display-closing.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/709
We need to set XdndAware and XdndProxy on the stage window if running
a X11 compositor, this is not necessary on wayland.
Takes over gnome-shell code doing this initialization.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/667
Starting from commit 7713006f5, during X11 disposition we also unmanage the
windows using the xids hash table values list.
However, this is also populated by the X11 Meta barrier implementation and then
contains both Windows and Barriers.
So when going through the values list, check whether we're handling a window or
a barrier and based on that, unmanage or destroy it.
Fixes https://gitlab.gnome.org/GNOME/mutter/issues/624https://gitlab.gnome.org/GNOME/mutter/merge_requests/605
Since commit 956ab4bd made libcanberra mandatory, we never use
the system bell for handling the `audible-bell` setting. So
instead of reacting to settings changes with the exact same call
to XkbChangeEnabledControls(), just call it once when initializing.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/598
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
This object takes care of the X11 representation of the window stack,
namely the _NET_CLIENT_LIST and _NET_CLIENT_LIST_STACKING root window
properties.
This code has been lifted from src/core/stack.c into src/x11 as it's
dependent on the X11 display availability. This also leaves MetaStack
squeaky clean of x11 specifics.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/420
This code takes care of both setting up X11 selection sources whenever
X11 clients claim selection ownership, and claiming selection ownership
on a mutter X11 window whenever other selection sources claim ownership.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/320
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
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.
Closing a GdkDisplay during an event handler is not currently supported by Gdk
and it will result in a crash when doing e.g. 'mutter --replace'. Using an idle
function will close it safely in a subsequent main loop iteration.
Fixes: https://gitlab.gnome.org/GNOME/gnome-shell/issues/595
XcursorLibraryLoadCursor can return 'None' if the current cursor theme
is missing the requested icon. If XFreeCursor is then called on this
cursor, it generates a BadCursor error causing gnome-shell to crash.
Fixes https://gitlab.gnome.org/GNOME/mutter/issues/254
Force update the cursor renderer after theme or size changes; otherwise
we'll be stuck with the old theme and/or size until something else
triggers resetting of the cursor.
If we wait with opening the X11 window decoration GDK connection, we
might end up with a terminated X11 server before we finish
initializing, depending on the things happening after spawning Xwayland
and before opening the MetaX11Dispaly. In gnome-shell, this involves
e.g. creating a couple of temporary X11 connections, and on disconnect,
if they happen to be the last client, the X server will terminate
itself.
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
- Stop using CurrentTime, introduce META_CURRENT_TIME
- Use g_get_monotonic_time () instead of relying on an
X server running and making roundtrip to it
https://bugzilla.gnome.org/show_bug.cgi?id=759538
Split X11 specific parts into MetaX11Display. This also required
changing MetaScreen to stop listening to any signals by itself, but
instead relying on MetaDisplay forwarding them. This was to ensure the
ordering. MetaDisplay listens to both the internal and external
monitors-changed signal so that it can pass the external one via the
redundant MetaDisplay(prev MetaScreen)::monitors-changed.
https://bugzilla.gnome.org/show_bug.cgi?id=759538
They are X11 specific functions, used for X11 code. They have been
improved per jadahl's suggestion to use gdk_x11_lookup_xdisplay and
gdk_x11_display_error_trap_* functions, instead of current code.
https://bugzilla.gnome.org/show_bug.cgi?id=759538
- Moved xdisplay, name and various atoms from MetaDisplay
- Moved xroot, screen_name, default_depth and default_xvisual
from MetaScreen
- Moved some X11 specific functions from screen.c and display.c
to meta-x11-display.c
https://bugzilla.gnome.org/show_bug.cgi?id=759538
