When maximizing a window, the previous location is saved so that
un-maximize would restore the same original window location.
However, if a Wayland client starts with a window maximized, the
previous location will be 0x0, so if we have to force placement in
xdg_toplevel_set_maximized(), we should update the location as well so
that the window is placed on the right monitor when un-maximizing.
For that purpose, add a new flag to force the update of the window
location, and use that flag from xdg_toplevel_set_maximized().
https://bugzilla.gnome.org/show_bug.cgi?id=783901
When closing a window and showing a new one, the new one may not be
granted input focus until it gets a buffer on Wayland.
If another window is chosen to receive focus and raised on top of stack,
the newly mapped window is focused but placed underneath that other
window.
Meaning that for Wayland surfaces, we need to defer adding the window to
the stack until we actually get to show it, once we have a buffer
attached.
Rather that checking the windowing backend prior to decide if a window
is stackable or not, introduce a new vfunc is_stackable() which tells
if a window should be added to the stack regardless of the underlying
windowing system.
Also add meta_window_is_in_stack() API rather than checking the stack
position directly (replacing the define WINDOW_IN_STACK only available
in stack.c) and remove a window from the stack only if it is present
in the stack, so that the test in meta_stack_remote() becomes
irrelevant.
https://bugzilla.gnome.org/show_bug.cgi?id=780820
Wayland clients using the wl_shell interface were never receiving mouse
input. It meant they also couldn't be raised with a click.
This was because the call to meta_wayland_surface_set_window for wl_shell
surfaces did nothing while surface->window == window already. As such, it
never called clutter_actor_set_reactive() and the wl_shell window remained
a non-reactive actor.
Just make sure surface->window isn't already set before calling
meta_wayland_surface_set_window so it can actually do what it's meant to.
https://bugzilla.gnome.org/show_bug.cgi?id=790309
If input happens to be grabbed somewhere along the shell, and ungrabbed
while a touch operation is ongoing, the wayland bits will happily start
sending wl_touch.update events from an undeterminate point, without
clients having ever received wl_touch.down for that id.
Consider those touches grabbed for the entirety of their lifetime, if
wl_touch.down wasn't received by the client, no other events will.
https://bugzilla.gnome.org/show_bug.cgi?id=776220
On VT switch, the xkb state layout index is lost and reset to the first
group, so if the first layout is not the last one being used, the xkb
state used in both meta-wayland-keyboard.c and clutter/evdev will be
desynchronized with the keyboard source indicator in the gnome-shell UI.
Save the effective layout chosen along with the seat so it can be
restored when reclaiming devices.
Use the saved layout index from the clutter/evdev's seat to restore the
layout in meta-wayland-keyboard, so that switching VT doesn't reset the
layout and causes further discrepancies with the layout indicator in the
gnome-shell UI.
https://bugzilla.gnome.org/show_bug.cgi?id=791383
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
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
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
We tried to get the geometry scale, which may depend on the main
logical monitor assigned to the window. To avoid dereferencing a NULL
logical monitor when headless, instead assume the geometry scale is 1.
https://bugzilla.gnome.org/show_bug.cgi?id=788764
The layout group determines what actual keyboard layout in the keymap
to use when translating modifier state and key codes to key syms.
When changing a keymap to another, the layout groups has no relation to
the layout groups in the old keymap, thus there is no reason to
transfer it to the new state.
This fixes an issue where the xkb state in meta-wayland-keyboard.c got
desynchronized with the xkb state in clutter-device-manager-evdev.c.
https://bugzilla.gnome.org/show_bug.cgi?id=789300
The handlers depend on a role being assigned. Destroying the window
causes it to become unmapped, which would sometimes trigger one of the
handlers, resulting in an is-assigned assert hitting in one of the
handlers. Avoid this by disconnecting the handlers earlier, so that
there is no risk that any them being triggered before the role is
assigned.
https://bugzilla.gnome.org/show_bug.cgi?id=789552
In the unlikely case that a surface is moved by the compositor while
holding a pointer confinement, we also need to update the pointer
position when the surface actor gets moved.
https://bugzilla.gnome.org/show_bug.cgi?id=782344
Both notify::position on the surface actor and position-changed on
MetaWindow are listened to, in order to trigger wl_output updates for
wl_surfaces whenever the surfaces move across them.
Both signals are necessary in order to cater for toplevel and subsurface
relocations (Because it's the parent window actor what changes position
in this last case).
Also, shuffle signal disconnection, so each signal goes away with
the object reference held by MetaWaylandSurface.
https://bugzilla.gnome.org/show_bug.cgi?id=782344
Adding an internal signal and use it to update the internal state before
emitting "monitors-changed" which will be repeated by the screen to the world.
https://bugzilla.gnome.org/show_bug.cgi?id=788860
The modifier event was only added in v3 of the client; sending it to
older clients (e.g. GStreamer waylandsink) causes them to disconnect
immediately.
Send the older 'format' event to all clients, and only send the newer
'modifier' event to resource versions 3 or above.
https://bugzilla.gnome.org/show_bug.cgi?id=788558
Following up the previous patch, this patch makes the
Wayland backend send the edge constraints through a
custom protocol extension internal to GTK.
As it mature, we can think of upstreaming the protocol
to Wayland itself.
https://bugzilla.gnome.org/show_bug.cgi?id=751857
We would free the shortcut inhibit data only when the client destroys
its request, which is not the case when the clients itself is
destroyed, leading to a leak of the shortcut inhibit data.
Free the data on resource destruction instead, and simply destroy the
resource on destroy request.
https://bugzilla.gnome.org/show_bug.cgi?id=787568
On Wayland, the grab()/ungrab() in gtk+/gdk are wired to the shortcut
inhibitor mechanism, which in turn shows the dialog, which can take
focus away from the client window when the dialog is shown.
If the client issues an ungrab() when the keyboard focus is lost, we
would hide the dialog, causing the keyboard focus to be returned to the
client surface, which in turn would issue a new grab(), so forth and so
on, causing a continuous show/hide of the shortcut inhibitor dialog.
To avoid this issue, keep the dialog around even if the shortcut inhibit
is canceled by the client, so that the user is forced to make a choice
that we can reuse on the next request without showing the dialog again.
Instead of hiding the dialog when the shortcut inhibitor is destroyed by
the client, we simply mark the request as canceled and do not apply the
user's choice.
https://bugzilla.gnome.org/show_bug.cgi?id=787568
When cleaning up the display name string management, the display name
string retrieved from libwayland-server was also passed to free() on
clean up. This is invalid as the display name string ownership is not
transferred to us. Fix this by strdup:ing the string before saving it.
https://bugzilla.gnome.org/show_bug.cgi?id=730551
This avoids updating state (such as position, size etc) when going
headless. Eventually, when non-headless, things will be updated again,
and not until then will we be able to update to a valid state.
https://bugzilla.gnome.org/show_bug.cgi?id=730551
In order to give the clients the best chance to bind the wl_output
before we later remove it (for example on fast hot plugs or in the test
suite), flush the client sockets after creating the global.
https://bugzilla.gnome.org/show_bug.cgi?id=730551
Apparently my understanding of Cogl pixel formats, or at least their
use, was somewhat shaky.
Un-invert the inversion of the DRM FourCC -> Cogl pixel format mapping
when creating dmabufs from clients, fixing inverted channel ordering
seen from GL clients, e.g. gold highlights in gtk4-demo when using the
GSK GL backend when they should be blue.
https://bugzilla.gnome.org/show_bug.cgi?id=786677
The meta_wayland_surface_hide_inhibit_shortcuts_dialog() function
disconnected the "destroy" handler, but we'd still be listening on
response events. Change this to just hide the dialog, leaving the data
intact with the proper life time signal in place.
https://bugzilla.gnome.org/show_bug.cgi?id=786385
The 'data' object is attached to the MetaWaylandSurface as a GObject
qdata. It is created once, and stays allocated until the surface is
destroyed. To make things clearer, connect to the "destroy" signal just
after creating, and from a on_surface_destroyed() callback call the
.._free() function.
https://bugzilla.gnome.org/show_bug.cgi?id=786385
Plug the new MetaInhbitShortcutsDialog to the relevant Wayland protocol
implementation.
Also, remember the last user choice for a given surface to avoid asking
continuously the same question.
https://bugzilla.gnome.org/show_bug.cgi?id=783342
Add a mechanism to MetaWaylandSurface that inhibits compositor's own
shortcuts when the surface has input focus, so that clients can receive
all key events regardless of the compositor own shortcuts.
This will help with implementing "fake" active grabs in Wayland and
XWayland clients.
https://bugzilla.gnome.org/show_bug.cgi?id=783342
The cursor surface would be remembered until the next proximity in
event, causing flashing of the old cursor till the client underneath
the tablet tool sent the zwp_tablet_tool.set_cursor request.
Forgetting about the cursor surface on proximity out makes the cursor
invisible till the request is made.
More specifically, avoid crossing events, since clutter does not set
modifier/button state on those. Fixes implicit grabs being broken when
the pointer moves past the surface boundaries.
https://bugzilla.gnome.org/show_bug.cgi?id=785347
