Avoid those devices when applying the configuration to touchpads, and ensure
the devices grouped with the tablet are all synchronized wrt the left handed
setting.
Closes: https://gitlab.gnome.org/GNOME/mutter/issues/562
Naming the keyboard accessibility settings `a11y_settings` wrongly
assumes there will never be any other type of accessibility settings.
Rename `a11y_settings` to `keyboard_a11y_settings` to avoid future
confusion.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/512
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
MetaProfiler is not built when -Dprofiler=false, and that
breaks the build since MetaBackend unconditionally imports
and uses it.
Fix that by wrapping MetaProfiler in compile-time checks.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/603
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'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
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
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
Extract the next buffer -logic into a new function. This allows to
simplify copy_shared_framebuffer_cpu () making it more readable.
This change is a pure refactoring, no functional changes.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/593
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
When running in slow or busy machines (hey CI!) or under valgrind headless
tests could fail because of a non fatal warning during initialization.
So define a fatal handler that ignores the frame counter warning.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/581
Creating a window could take some time, causing false-positive failures when
running in slower or busy hardware like:
window 1/2 isn't known to Mutter
So before we proceed in doing any operation on it, wait for the client.
Do this in the test runner instead of repeating the same in every .metatest.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/581
This debug statement is actually applied all the times, while it could be useful
for crashes analysis, these days the same can be done using `MALLOC_CHECK_` and
`MALLOC_PERTURB_` env variables.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/581
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
Code underneath seems to handle errors properly, and 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
We use a GtkIconTheme (thus icon-theme, thus xsettings, thus x11) just to
grab a "missing icon" icon to show in place. Relax this requirement that
surfaces for icon/mini-icon will be set, and just let it have NULL here.
It seems better to have the callers (presumably UI layers) aware of this
and set a proper icon by themselves, but AFAICS there is none in sight,
not even plain mutter seems to use MetaWindow::[mini-]icon. Probably
worth a future cleanup.
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
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
We'd break the loop for moving attached windows at the first window,
meaning we'd only ever move a single attached dialogs or popup if it was
the first window in the list. This doesn't work out well when there are
multiple popups open, so don't break out of the loop at all until all
windows are potentially moved.
This fixes an issue in gtk4 where one or more non-grabbing popups would
end up unattached if there were more than one and the parent window was
moved.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/592
XkbNewKeyboardNotify informs the client that there is a new keyboard
driving the VCK. It is essentially meant to notify that the keyboard
possibly has a different range of HW keycodes and/or a different
geometry.
But the translation of those keycodes remain the same, and we don't
do range checks or geometry checks (beyond using KEY_GRAVE as "key
under Esc", but that is hardly one). It seems we can avoid the
busywork that is releasing all our passive grabs, reloading the keymap
and regenerating the keycombos and restoring the passive grabs.
Closes: https://gitlab.gnome.org/GNOME/mutter/issues/398
