After the introduction of locate-pointer (commit 851b7d063 -
“keybindings: Trigger locate-pointer on key modifier”), inhibiting
shortcuts would no longer forward the overlay key to the client.
Restore the code that was inadvertently removed so that inhibiting
shortcuts works on the overlay key again.
Fixes: https://gitlab.gnome.org/GNOME/mutter/issues/734
Geometry scale is applied to each surface individually, using
Clutter scales, and not only this breaks subsurfaces, it also
pollutes the toolkit and makes the actor tree slightly too
fragile. If GNOME Shell mistakenly tries to set the actor scale
of any of these surfaces, for example, various artifacts might
happen.
Move geometry scale handling to MetaWindowActor. It is applied
as a child transform operation, so that the Clutter-managed
scale properties are left untouched.
In the future where the entirety of the window is managed by a
ClutterContent itself, the geometry scale will be applied
directly into the transform matrix of MetaWindowActor. However,
doing that now would break the various ClutterClones used by
GNOME Shell, so the child transform is an acceptable compromise
during this transition.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/409
meta_shaped_texture_update_area() is a private function that
is exposed in the public headers. It is not used anywhere
outside Mutter, and should really be in the private header.
Move it to the private header.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/409
Now that MetaShapedTexture is not a ClutterActor anymore, it does
not make sense to make it a MetaCullable semi-implementation. This
is, naturally, a responsibility of MetaSurfaceActor, since now
MetaShapedTexture is a ClutterContent and as such, it only cares
about what to draw.
Move the MetaCullable implementation of MetaShapedTexture to
MetaSurfaceActor.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/409
By implementing ClutterContent, it is expected that
MetaShapedTexture can draw on any actor. However,
right now this is not possible, since it assumes
that the drawing coordinates and sizes of the actor
are synchronized with its own reported width and
height.
It mistakenly draws, for example, when setting an
actor's content to it. There is no way to trigger
this wrong behavior right now, but it will become
a problem in the future where we can collect the
paint nodes of MetaShapedTexture as part of other
ClutterContent implementations.
Use the allocation box passed by the actor to draw
the pipelines of MetaShapedTexture.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/409
Now that MetaShapedTexture is a ClutterContent implemetation that
is aware of its own buffer scale, it is possible to simplify the
event translation routines.
Set the geometry scale in MetaSurfaceActor, and stop adjusting the
surface scale when translating points. Also remove the now obsoleted
meta_wayland_actor_surface_calculate_scale() function.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/409
MetaWindowActor is the compositor-side representative of a
MetaWindow. Specifically it represents the geometry of the
window under Clutter scene graph. MetaWindowActors are backed
by MetaSurfaceActors, that represent the windowing system's
surfaces themselves. Naturally, these surfaces have textures
with the pixel content of the clients associated with them.
These textures are represented by MetaShapedTexture.
MetaShapedTextures are currently implemented as ClutterActor
subclasses that override the paint function to paint the
textures it holds.
Conceptually, however, Clutter has an abstraction layer for
contents of actors: ClutterContent. Which MetaShapedTexture
fits nicely, in fact.
Make MetaShapedTexture a ClutterContent implementation. This
forces a few changes in the stack:
* MetaShapedTexture now handles buffer scale.
* We now paint into ClutterPaintNode instead of the direct
framebuffer.
* Various pieces of Wayland code now use MetaSurfaceActor
instead of MetaShapedTexture.
* MetaSurfaceActorWayland doesn't override size negotiation
vfuncs anymore
https://gitlab.gnome.org/GNOME/mutter/merge_requests/409
Mutter needs to know which framebuffer the paint nodes will be
drawn into, and using cogl_get_draw_framebuffer() directly is
not an option since ClutterRootNode only pushes the draw fb
at draw time.
Expose clutter_paint_node_get_framebuffer().
https://gitlab.gnome.org/GNOME/mutter/merge_requests/409
One of the man pages is now generated using asciidoc, which is missing
from the CI image. But given that this doesn't depend on mutter in any
way, just disable man pages in the gnome-shell build instead of updating
the Dockerfile.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/740
Incompressible events already pass through unmodified, so queuing them
just wasted time and memory.
We would however like to keep the ordering of events so we can only
apply this optimization if the queue is empty.
This reduces the input latency of incompressible events like touchpad
scrolling or drawing tablets by up to one frame. It also means the same
series of events now arrives at the client more smoothly and not in
bursts.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/711
Until now we would:
1. Enqueue modifier key event on the stage.
2. Update device modifier state.
3. Dequeue and process modifier key event with NEW device modifier state.
But if we consider optimizing out the queuing in some cases then there
will become a problem:
1. Process modifier key event with OLD device modifier state.
2. Update device modifier state.
To correct the above we now do:
1. Update device modifier state.
2. Queue/process modifier key event with NEW device modifier state.
It appears commit dd940a71 which introduced the old behaviour was correct
in the need to update the device modifier state, but is at least no longer
correct (if it ever was) that it should be done after queuing the event.
If queuing is working, as it is right now, then it makes no difference
whether the device modifier state is updated before or after. Because both
cases will come before the dequeing and processing.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/711
Thanks to the now removed global/context grabs, we can move pointer and
keyboard grabs back home to where they belong.
While at it, also add handling of CLUTTER_TABLET_DEVICE devices to
`on_grab_actor_destroy` and `clutter_input_device_get_grabbed_actor`.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/536
With the addition of xauth support (commit a8984a81c), Xwayland would
rely only on the provided cookies for authentication.
As a result, running an Xclient from another VT (hence without the
XAUTHORITY environment variable set) would result in an access denied.
The same on X11 is granted because the local user is automatically
granted access to Xserver by the startup scripts.
Add the local user to xhost at startup on Xwayland so that the user can
still run a client by setting the DISPLAY as long as it's the same user
on the same host.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/735
If possible, GLib will try to use the va_marshaller to pass the signal
arguments, rather than unboxing into and out of a `GValue`. This is much
more performant and especially good for often-thrown signals.
The original bug even mentions Clutter performance issues as a drive to
implement the va_marshaller in GLib (see
https://bugzilla.gnome.org/show_bug.cgi?id=661140).
https://gitlab.gnome.org/GNOME/mutter/merge_requests/700
Some of the marshallers we generate in `clutter-marshal.list` are also
available in GLib, so we don't need to generate them ourselves. Even
more, by passing NULL to `g_signal_new` in these cases will actually
internally optimize this even more by also setting the valist
marshaller, which is a little bit faster than the regular marshalling
using `GValue` and libffi.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/700
A base type shouldn't know about sub types, so let MetaDisplay make
the correct choice of what type of MetaCompositor it should create. No
other semantical changes introduced.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/727
Introduce MetaCompositorX11, dealing with being a X11 compositor, and
MetaCompositorServer, being a compositor while also being the display
server itself, e.g. a Wayland display server.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/727
When double clicking to un-maximize an X11 window under Wayland, there
is a race between X11 and Wayland protocols and the X11 XConfigureWindow
may be processed by Xwayland before the button press event is forwarded
via the Wayland protocol.
As a result, the second click may reach another X11 window placed right
underneath in the X11 stack.
Make sure we do not forward the button press event to Wayland if it was
handled by the frame UI.
https://gitlab.gnome.org/GNOME/mutter/issues/88
