This protocol is limited to Xwayland only and is not visible/usable by
any other client.
Mutter uses the following mechanisms to determine if an X11 client
should be granted a grab:
- is "xwayland-allow-grabs" set?
- if set, is the client blacklisted?
- otherwise, has the client set the X11 window property
_XWAYLAND_MAY_GRAB_KEYBOARD on the window using a client message?
- if not, is it a client white-listed either via the default system
list or the settings "xwayland-grab-access-rules"?
https://bugzilla.gnome.org/show_bug.cgi?id=783342
Add a new client message "_XWAYLAND_MAY_GRAB_KEYBOARD" that X11 clients
can use to tell mutter this is a well behaving X11 client so it may
grant the keyboard grabs when requested.
An X11 client wishing to be granted Xwayland grabs by gnome-shell/mutter
must send a ClientMessage to the root window with:
- message_type set to "_XWAYLAND_MAY_GRAB_KEYBOARD"
- window set to the xid of the window on which the grab is to be issued
- data.l[0] to a non-zero value
Note: Sending this client message when running a plain native X11
environment would have no effect.
https://bugzilla.gnome.org/show_bug.cgi?id=783342
MetaWindowXwayland derives from MetaWindowX11 to allow for some Xwayland
specific vfunc that wouldn't apply to plain X11 windows, such as
shortcut inhibit routines.
https://bugzilla.gnome.org/show_bug.cgi?id=783342
The xdg-output protocol aims at describing outputs in way which is
more in line with the concept of an output on desktop oriented systems.
For now it just features the position and logical size which describe
the output position and size in the global compositor space.
This is however much useful for Xwayland to advertise the output size
and position to X11 clients which need this to configure their surfaces
in the global compositor space as the compositor may apply a different
scale from what is advertised by the output scaling property (to achieve
fractional scaling, for example).
This was added in wayland-protocols 1.10.
https://bugzilla.gnome.org/show_bug.cgi?id=787363
When the top window actor is destroyed, we need to make sure that
all its references are removed or it could be picked again in next
windows sync, causing crashes.
Since the window might or might not be destroyed when removed (depending
weather animations are in progress over it or not), it's just safer
to wait it to be destroyed before cleaning up any of its reference.
https://bugzilla.gnome.org/show_bug.cgi?id=791006
Changing the test monitor managers ability to rotate CRTCs in one test
affected the next test. Avoid leaking such state by resetting it before
each test. To continue passing, some tests needed to be updated
regarding to still pass.
https://bugzilla.gnome.org/show_bug.cgi?id=788915
Add a test case that checks that we don't try to revert to a
laptop-panel-only configuration after closing the lid after an external
monitor is connected.
https://bugzilla.gnome.org/show_bug.cgi?id=788915
We only counted configured monitors and whether the config was
applicable (could be assigned), howeverwe didn't include disabled
monitors when comparing. This could caused incorrect configurations to
be applied when trying to use the previous configuration.
One scenario where this happened was one a system with one laptop
screen and one external monitor that was hot plugged some point after
start up. When the laptop lid was closed, the 'previous configuration'
being the configuration where only the laptop panel was enabled, passed
'is-complete' check as the number of configured monitors were correct,
and the configuration was applicable.
Avoid this issue by simply comparing the configuration key of the
previous configuration and the configuration key of the current state.
This correctly identifies a laptop panel with the lid closed as
inaccessible, thus doesn't incorrectly revert to the previous
configuration.
https://bugzilla.gnome.org/show_bug.cgi?id=788915
When deriving the list of disabled monitors when creating new monitors
configs, don't include the laptop panel if the lid is currently closed,
as we consider the laptop panel nonexistent when the laptop lid is
closed when it comes to configuration.
The laptop panel connector(s) will either way be appropriately disabled
anyway, as the field listing disabled monitors in the configuration do
not affect actual CRTC/connector assignments.
https://bugzilla.gnome.org/show_bug.cgi?id=788915
If a parent doesn't have a window, it means it could have been
dismissed (for example due to a input serial race), but the more recent
popup might win the input serial race and try to map anyway. This would
result in a crash later on when trying to process the placement rule,
as the parent already has no window.
https://bugzilla.gnome.org/show_bug.cgi?id=790358
Move the top-most-popup correctness check to the finish_popup_setup()
function after checking the serial. If we pass the serial check, we
should have reached a state that if there are any popups they should be
the one from the same client.
Also avoid failing a client that correctly set the top-most popup at map
time, but where at the time of processing the top most popup have
already been dismissed by the compositor for some arbitrary reason.
https://bugzilla.gnome.org/show_bug.cgi?id=790358
Commit b1a0bf891 broke the previous logic that we would only fallback
to the root cursor if 1) windows are not interactable or 2) no window
cursor is currently set (i.e. not hovering over any window). Now it
will set up the root cursor if it's NULL, which breaks clients
explicitly setting an invisible cursor. This commit restaurates the
previous behavior.
https://bugzilla.gnome.org/show_bug.cgi?id=754806
This function is supposedly not failable, so just move the theme_dirty
flag clearing to the beginning of the function. Protects against cases
where requesting a cursor image may result in it being loaded and set
as a texture, which emits ::texture-changed, which may end up requesting
the cursor image again.
https://bugzilla.gnome.org/show_bug.cgi?id=754806
As wayland implements the cursor role, it consists of a persistent
MetaCursorSprite that gets the backing texture changed. This is
inconvenient for the places using MetaCursorTracker to track cursor
changes, as they actually track MetaCursorSprites.
This signal will be used to trigger emission of
MetaCursorTracker::cursor-changed, which will make users able to
update accordingly.
https://bugzilla.gnome.org/show_bug.cgi?id=754806
Just like X11/XFixes behaves, the current cursor is not affected
by its visibility, so it can be queried while invisible (possibly
to be replaced).
For this, keep an extra effective_cursor pointer that will be
either equal to displayed_cursor (maybe a bit of a misnomer now)
or NULL if the cursor is invisible. The MetaCursorRenderer
management is tied to the former, and the ::cursor-changed signal
emission to the latter.
https://bugzilla.gnome.org/show_bug.cgi?id=754806
We must emit ::dnd-leave to pair the ::dnd-enter that shall be
emitted whenever the plugin grab begins, otherwise we leave
listeners unable to clean up if the plugin begins and ends a
grab while there is an ongoing DnD operation.
https://bugzilla.gnome.org/show_bug.cgi?id=784545
Adds a set of convenient functions that can be shared between x11 input
device backends (namely core-x11 and xi2) to control XKB accessibility
features.
https://bugzilla.gnome.org/show_bug.cgi?id=788564
MetaWaylandKeyboard maintains its own xkb_state used to update Wayland
clients.
Add the necessary hooks to make sure the sticky keys modifier masks set
in clutter-evdev are also applied in MetaWaylandKeyboard's xkb_state so
that Wayland clients also benefit from sticky keys.
https://bugzilla.gnome.org/show_bug.cgi?id=788564
Implementing keyboard accessibility in clutter means we need to be able
to notify higher layers of possible modifier masks or setting changes
(as some keyboard accessibility can be disabled or enabled by keyboard).
For this purpose, add two new signals:
ClutterDeviceManager::kbd-a11y-mods-state-changed
ClutterDeviceManager::kbd-a11y-flags-changed
https://bugzilla.gnome.org/show_bug.cgi?id=788564
Use a set of bitwise enum flags to set different keyboard accessibility
features and the necessary vfunc hooks in clutter input device so that
keyboard preferences can be passed to different input device
implementations.
The idea is to be able to configure either the clutter own
implementation of keyboard accessibility for evdev, or eventually
configure AccessX from the X11 clutter input device using the same
mechanism.
https://bugzilla.gnome.org/show_bug.cgi?id=788564
On X11, when AccessX is enabled, all X11 clients benefit from the
AccessX features, including gnome-shell/mutter, meaning that special
keys like the overview or other shortcuts are also affected.
To achieve the same in Wayland, we need to implement the same features
in clutter main rather than the Wayland backend, so that all depending
code within the compositor but also Wayland clients (which rely on the
compositor to get keyboard events) similarly benefit from the
accessibility features.
Add hooks to the clutter main loop to be able to implement such
features.
https://bugzilla.gnome.org/show_bug.cgi?id=788564
We'll need a way to trigger a bell from within clutter for keyboard
accessibility features, add the necessary hooks to be able to call a
backend bell-notify method.
https://bugzilla.gnome.org/show_bug.cgi?id=788564
