Certains keys (such as ~ and |) are in the keyboard map behind the
second shift level. This means in order for them to be input, the
shift key needs to be held down by the user.
The GNOME Shell on-screen keyboard presents these keys separately on
a page of keys that has no shift key. Instead, it relies on mutter
to set a shift latch before the key event is emitted. A shift latch
is a virtual press of the shift key that automatically gets released
after the next key press (in our case the ~ or | key).
The problem is using a shift latch doesn't work very well in the face
of key repeat. The latch is automatically released after the first
press, and subsequent repeats of that press no longer have shift
latched to them.
This commit fixes the problem by using a shift lock instead of a shift
latch. A shift lock is never implicitly released, so it remains
in place for the duration of key repeat.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2045>
Currently, when a remote desktop user submits a keycode, it will be
interpreted differently, when using the x11 session, instead of a
wayland session.
In a wayland session, submitting a keycode will have the expected
result (as if the key was pressed locally).
In a x11 session, this is not the case. Instead of getting the expected
key, some other key will be pressed (or sometimes even none).
The reason for this is that the native backend interprets the keycode
as evdev keycode and the x11 backend interprets the keycode as xkb
keycode.
To ensure that both backends produce the same behaviour when submitting
a keycode, fix the x11 backend to always interpret the keycode as evdev
keycode, instead of a xkb keycode.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1732>
MetaVirtualInputDeviceX11 currently doesn't handle smooth scroll events
at all.
So, if a user of the remote desktop API uses smooth scroll events, then
only the wayland backend handles these events.
The user of the remote desktop API however, might not know which
backend is being used and actually the user should not even have to
care about it.
Actual smooth events cannot be emulated in the X11 events.
What can be done however is accumulating smooth events and then when
the accumulated steps surpass the DISCRETE_SCROLL_STEP value, emit a
discrete scroll event.
So, do exactly that, to make smooth scroll events work when the remote
desktop API is used with the x11 backend.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1727>
The end goal is to have all clutter backend code in src/backends. Input
is the larger chunk of it, which is now part of our specific
MutterClutterBackendX11, this extends to device manager, input devices,
tools and keymap.
This was supposed to be nice and incremental, but there's no sane way
to cut this through. As a result of the refactor, a number of private
Clutter functions are now exported for external backends to be possible.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/672
