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
Since a wl_buffer is independent of the GL context in use (unlike, e.g.,
a GL renderbuffer), EGLImages with the EGL_WAYLAND_BUFFER_WL target must
pass EGL_NO_CONTEXT as the context. Quoting from the
EGL_WL_bind_wayland_display spec:
After querying the wl_buffer layout, create EGLImages for the
planes by calling eglCreateImageKHR with wl_buffer as
EGLClientBuffer, EGL_WAYLAND_BUFFER_WL as the target, NULL
context.
The check was already present inside _cogl_egl_create_image.
https://bugzilla.gnome.org/show_bug.cgi?id=785263
Signed-off-by: Daniel Stone <daniels@collabora.com>
Adds basic support for the "wheel" event from the Wayland tablet protocol.
Ideally we would accumulate the angle and report a wheel event with an
appropriate value for "clicks". We can get away with a much cruder method
for the time being, however, since no Wacom tablet puck actually provides
a smooth scrollwheel. Checking whether the angle in CLUTTER_INPUT_AXIS_WHEEL
exceeds a nominally-small threshold is sufficient to determine that the
wheel has advanced by at least one physical click.
https://bugzilla.gnome.org/show_bug.cgi?id=783716
When updating the main monitor, make sure to update the toplevel main
monitor before trying to use that as the main monitor for non-toplevel
windows (such as popups). Without this, when the main monitor is
updated as a side effect to monitors being changed (for example due to
a hot plug event, or coming back from being suspended) the
main monitor pointer may, after 'monitors-changed' has completed, point to
freed memory resulting in undefined behaviour.
https://bugzilla.gnome.org/show_bug.cgi?id=784867
To be able to render the pointer cursor sprite at sub-(logical)-pixel
positions, track the pointer position using floats instead of ints.
This also requires users of the cursor sprite rect to deal with
floating points, when e.g. finding the logical monitor etc.
https://bugzilla.gnome.org/show_bug.cgi?id=765011
When the logical layout mode is used, allow configuring the scaling to
be non-integer. Supported scales are so far hard coded to include at
most 1, 1.5 and 2, and scales that doesn't result in non-fractional
logical monitor sizes are discarded.
Wayland outputs are set to have scale ceil(actual_scale) meaning well
behaving Wayland clients will provide buffers with buffer scale 2, thus
being scaled down to the fractional scale.
https://bugzilla.gnome.org/show_bug.cgi?id=765011
Window moving and resizing depends on the `meta_wayland_seat_get_grab_info`
function succeeding. At the moment, tablet tools do not generate implicit
grabs like the pointer and touch. This commit adds the necessary elements
to track implicit grabs and retrieve their information.
https://bugzilla.gnome.org/show_bug.cgi?id=777333
