GitLab

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: #398

Modal ungrabs may be followed by other clients trying to grab themselves,
flush the connection so we ensure the right order of events on the Xserver
side.

An example of this is js/ui/modalDialog.js in gnome-shell, as the alt-F2
dialog may launch X11 clients trying to grab themselves, commit a40daa3c22
in gnome-shell handled the case and added a gdk_display_sync() call to
ensure no grab existed at the time of executing.

This commit aims to achieve the same built in MetaBackend. A full sync
seems excessive though, as we just need to make sure the server got the
messages queued before the other side tries to grab, a XFlush seems
sufficient for this.

The order and way include macros were structured was chaotic, with no
real common thread between files. Try to tidy up the mess with some
common scheme, to make things look less messy.

meta_backend_x11_grab_device is performing X server clock comparison
using the MAX macro, which comes down to a simple greater-than.

Use XSERVER_TIME_IS_BEFORE, which is a better macro for X server
clock comparisons, as it accounts for 32-bit wrap-around.

!174

Force update the cursor renderer after theme or size changes; otherwise
we'll be stuck with the old theme and/or size until something else
triggers resetting of the cursor.

This fixes mutter --nested --wayland without X11

https://bugzilla.gnome.org/show_bug.cgi?id=759538

- Stop using CurrentTime, introduce META_CURRENT_TIME
- Use g_get_monotonic_time () instead of relying on an
  X server running and making roundtrip to it

https://bugzilla.gnome.org/show_bug.cgi?id=759538

While MetaStage, MetaWindowGroup and MetaDBusDisplayConfigSkeleton don't
appear explicitly in the public API, their gtypes are still exposed via
meta_get_stage_for_screen(), meta_get_*window_group_for_screen() and
MetaMonitorManager's parent type. Newer versions of gjs will warn about
undefined properties if it encounters a gtype without introspection
information, so expose those types to shut up the warnings.

https://bugzilla.gnome.org/show_bug.cgi?id=781471

Now that we've removed the X11 specific backend of the idle monitor,
add back a cut-down version of it for the explicit purpose of being
told about idle time resets when XTest events are used.

XTest events are usually used by test suites and remote display software
to inject events into an X11 session. We should consider somebody moving
the mouse remotely to be just as "active" as somebody moving it locally.

https://bugzilla.gnome.org/show_bug.cgi?id=705942

And use the old "native" backend for both X11 and Wayland. This will
allow us to share fixes between implementations without having to delve
into the XSync X11 extension code.

https://bugzilla.gnome.org/show_bug.cgi?id=705942

This was done by the clutter X11 backend before prior to introducing
MetaRenderer, but during that work, enabling of said extension was lost.
Let's turn it on again.

https://bugzilla.gnome.org/show_bug.cgi?id=739178

A comparison in translate_device_event() does not account for the fact
that X's clock wraps about every 49.7 days.  When triggered, this causes
an unresponsive GUI.

Replace simple less-than comparison with XSERVER_TIME_IS_BEFORE macro,
which accounts for the wrapping of X's clock.

Closes: #12

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

Will be used to trigger keyboard binding rebuild.

https://bugzilla.gnome.org/show_bug.cgi?id=786408

Add API to get the layout group (layout index) currently active. In the
native backend this is done by fetching the state directly from the
evdev backend; on X11 this works by listening for XkbStateNotify
events, caching the layout group value.

https://bugzilla.gnome.org/show_bug.cgi?id=786408

Don't wait for clutter to initialize for connecting to X11; do it when
constructing the backend instance. This way we can later depend on
having an X11 connection earlier during initialization.

https://bugzilla.gnome.org/show_bug.cgi?id=786408

Split up the MetaRendererX11 class into one for when running as a
X11 compositing manager, and one for when running as a nested Wayland
compositor.

https://bugzilla.gnome.org/show_bug.cgi?id=777732

Implement MetaDnd for emitting DnD signals to plugins such as gnome-shell. The
xdnd handling code comes from gnome-shell, and it is hidden behind MetaDnd now.

https://bugzilla.gnome.org/show_bug.cgi?id=765003

When running nested, the pointer can be outside of the stage, meaning
outside of any logical monitor. Handle this when getting the current
logical monitor by falling back to the first logical monitor when the
pointer coordinate is outside of any logical monitor.

https://bugzilla.gnome.org/show_bug.cgi?id=779001

Set up things so that if the INTEL_swap_event extension is not present,
but the driver is known to have good thread support, we use an extra
thread and call glXWaitVideoSync() in the thread. This allows idles
to work properly, even when Mutter is constantly redrawing new frames;
otherwise, without INTEL_swap_event, we'll just block in glXSwapBuffers().

https://bugzilla.gnome.org/show_bug.cgi?id=779039

https://bugzilla.gnome.org/show_bug.cgi?id=777800

Split up the X11 backend into two parts, one for running as a
Compositing Manager, and one for running as a nested Wayland
compositor.

This commit also cleans up the compositor configuration calculation,
attempting to make it more approachable.

https://bugzilla.gnome.org/show_bug.cgi?id=777800

Make the X11 backend derivable so that we can base a nested test backend
on it.

https://bugzilla.gnome.org/show_bug.cgi?id=777732

The method used for getting the current logical monitor (the monitor
where the pointer cursor is currently at) depends on the backend type,
so move that logic to the corresponding backends.

https://bugzilla.gnome.org/show_bug.cgi?id=777732

https://bugzilla.gnome.org/show_bug.cgi?id=777732

Lets prepare for being able to declare the MetaBackend type using
the macro helper.

https://bugzilla.gnome.org/show_bug.cgi?id=777732

Save the state on NumLock so that is can be (optionally) restored on
next login.

bugzilla: https://bugzilla.gnome.org/show_bug.cgi?id=757943

Only paint the per monitor stage views when enabled, otherwise bad
things happen.

https://bugzilla.gnome.org/show_bug.cgi?id=768976

Add support for drawing a stage using multiple framebuffers each making
up one part of the stage. This works by the stage backend
(ClutterStageWindow) providing a list of views which will be for
splitting up the stage in different regions.

A view layout, for now, is a set of rectangles. The stage window (i.e.
stage "backend" will use this information when drawing a frame, using
one framebuffer for each view. The scene graph is adapted to explictly
take a view when painting the stage. It will use this view, its
assigned framebuffer and layout to offset and clip the drawing
accordingly.

This effectively removes any notion of "stage framebuffer", since each
stage now may consist of multiple framebuffers. Therefore, API
involving this has been deprecated and made no-ops; namely
clutter_stage_ensure_context(). Callers are now assumed to either
always use a framebuffer reference explicitly, or push/pop the
framebuffer of a given view where the code has not yet changed to use
the explicit-buffer-using cogl API.

Currently only the nested X11 backend supports this mode fully, and the
per view framebuffers are all offscreen. Upon frame completion, it'll
blit each view's framebuffer onto the onscreen framebuffer before
swapping.

Other backends (X11 CM and native/KMS) are adapted to manage a
full-stage view. The X11 CM backend will continue to use this method,
while the native/KMS backend will be adopted to use multiple view
drawing.

https://bugzilla.gnome.org/show_bug.cgi?id=768976

The stage resizing was placed in the generic backend, which was only
run on certain configurations (when running nested or using the native
backend). This commits makes the resizing more explicit thus more
obvious.

https://bugzilla.gnome.org/show_bug.cgi?id=768976

MetaRenderer is meant to be the object responsible for rendering the
scene graph. It will contain the logic related to the cogl winsys
backend, the clutter backend, and the clutter stage window.

https://bugzilla.gnome.org/show_bug.cgi?id=768976

Introduce two new clutter backends: MetaClutterBackendX11 and
MetaClutterBackendNative. They are so far only wrap ClutterBackendX11
and ClutterBackendEglNative respectively, but the aim is to move things
from the original clutter backends when needed.

https://bugzilla.gnome.org/show_bug.cgi?id=768976

Emit a signal so that interested parties can recreate their FBOs and
queue a full scene graph redraw to ensure we don't end up showing
graphical artifacts.

This relies on the GL driver supporting the
NV_robustness_video_memory_purge extension and cogl creating a
suitable GL context. For now we only make use of it with the X backend
since the only driver with which this is useful is NVIDIA.

https://bugzilla.gnome.org/show_bug.cgi?id=739178

Ubuntu ships a patch in the X server that makes the group switch
keybindings only work on key release, i.e. the X server internal group
locking happens on key release which means that mutter gets the
XKB_KEY_ISO_Next_Group key press event, does its XLockGroup() call
with a new index and then, on key release, the X server moves the
index further again.

We can work around this without affecting our behavior in unpatched X
servers by doing a XLockGroup() every time we're notified of the
locked group changing if it doesn't match what we requested.

https://bugzilla.gnome.org/show_bug.cgi?id=756543

This shouldn't fail but apparently sometimes it does and in that case
having a possibly wrong idea of the keymap is still better than
crashing.

https://bugzilla.gnome.org/show_bug.cgi?id=754979

Use a specialized cursor renderer when running as a nested Wayand
compositor. This new renderer sets an empty X11 cursor and draws the
cursor as part of the stage using the generic cursor renderer drawing
path.

https://bugzilla.gnome.org/show_bug.cgi?id=744932

This fixes build error caused by commit 614d6bd0. We can simply remove
the usage of meta-wayland.c functions in non-wayland build because
META_BACKEND_X11_MODE_NESTED is only used in wayland.

https://bugzilla.gnome.org/show_bug.cgi?id=753948

If the user Alt-Tabs out of the window, we will be left thinking
the Alt key is still pressed since we don't see a release for it.

Solve this and other related issues for the nested X11 compositor
by selecting for KeymapStateMask which causes a KeymapNotify event
to be sent after each FocusIn, and when we get these events, update
the internal XKB state and send any necessary modifiers events to
clients.

https://bugzilla.gnome.org/show_bug.cgi?id=753948