Rename all instances of `MetaClutterBackendX11` so they are called
`clutter_backend_x11`. This is because `MetaBackendX11` will start to be
used for some things, and having both be named `backend_x11` would be
confusing.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2002>
meta_keymap_x11_replace_keycode currently reports to the X server
that the key types data is changed when adding a key to the keymap.
It's not changed. The number of key types is the same, and none of
them are modified.
This has two bad side effects:
1) It sends all of the key types data into the request
2) It hits a bug in the X server leading to the request getting
rejected entirely. See:
https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/761
Furthmore, the changed structure used to report to the X server
that the key types data is changed doesn't actually need to modified
at all in the function. It's already prepped by libX11 with the
correct state for the changes mutter is doing when
XkbChangeTypesOfKey is called.
This commit addresses the above two problems by just removing the
lines causing the issues.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2039>
Keys in the reserved keycode list are always added for the first group.
Before the previous commit such keycodes were not found unless that was
the current group. But now that we can also find matching keycodes that
are not directly in the current group, this is not necessary anymore.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1955>
Some keys, such as enter or backspace are only bound to a single group,
even if multiple groups are configured. Because the code was previously
only looking for keysyms in the same group as the current one, no
matching keycodes for these would be found if the current group is not
the first group. This was causing those keys to not work on the X11 OSK.
To fix this use the correct action to convert an out of range group for
that key according to its group_info field.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1955>
This effectively changes meta_keymap_x11_get_entries_for_keyval() to
meta_keymap_x11_get_entry_for_keyval() and moves the check if the
keycode maps to the keyval in the current group there. This simplifies
the code a bit and will allow a followup fix.
As a side effect this now also causes the reserved kecodes to be
searched, if no keycodes were found, rather than just when only ones
matching the wrong groups.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1955>
In Xrandr we were caching the available scaling modes that were computed just
for the current mode, for each monitor, while we can actually reuse the
default implementation, by just passing the proper scaling constraint.
In monitor we need then to properly filter these values, by only accepting
integer scaling factors that would allow to have a minimal logical monitor
size.
Fixes https://gitlab.gnome.org/GNOME/mutter/issues/407
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/336>
Wayland support is not really a "backend" thing, it just lacked a better
place to store its instance pointer. Eventually we'll have a better
place, but prepare for that by initializing it together with the more
similar subsystems.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1833>
The X server generates a property change notification whenever it processes a
property change request, even if the value of the property is not changing. This
triggers libgdk to probe all display outputs, which can be slow depending on
which display driver and hardware are in use.
#0 0x00007f8e4d5e91a0 in XRRUpdateConfiguration () at /usr/lib/libXrandr.so.2
#1 0x00007f8e505208da in _gdk_x11_screen_size_changed (screen=0x5566e4b7e080, event=0x7ffe0e44bd60) at ../gdk/x11/gdkscreen-x11.c:1199
#2 0x00007f8e505066d1 in gdk_x11_display_translate_event (translator=0x5566e4b5b110, display=0x5566e4b5b110, event=0x7f8dec001b20, xevent=0x7ffe0e44bd60) at ../gdk/x11/gdkdisplay-x11.c:1201
#3 0x00007f8e505135a0 in _gdk_x11_event_translator_translate (translator=0x5566e4b5b110, display=0x5566e4b5b110, xevent=0x7ffe0e44bd60) at ../gdk/x11/gdkeventtranslator.c:51
#4 0x00007f8e50512c97 in gdk_event_source_translate_event (event_source=0x5566e4b764a0, xevent=0x7ffe0e44bd60) at ../gdk/x11/gdkeventsource.c:243
#5 0x00007f8e50512f57 in _gdk_x11_display_queue_events (display=0x5566e4b5b110) at ../gdk/x11/gdkeventsource.c:341
#6 0x00007f8e50497644 in gdk_display_get_event (display=0x5566e4b5b110) at ../gdk/gdkdisplay.c:442
#7 0x00007f8e5051301f in gdk_event_source_dispatch (source=0x5566e4b764a0, callback=0x0, user_data=0x0) at ../gdk/x11/gdkeventsource.c:363
#8 0x00007f8e516ecf9c in g_main_context_dispatch () at /usr/lib/libglib-2.0.so.0
#9 0x00007f8e51740a49 in () at /usr/lib/libglib-2.0.so.0
#10 0x00007f8e516ec503 in g_main_loop_run () at /usr/lib/libglib-2.0.so.0
#11 0x00007f8e508ef5fd in meta_run_main_loop () at ../src/core/main.c:928
#12 0x00007f8e508ef60e in meta_run () at ../src/core/main.c:943
#13 0x00005566e450842a in ()
#14 0x00007f8e50649b25 in __libc_start_main () at /usr/lib/libc.so.6
When GNOME is animating a display fade when the night light feature is toggled
on or off, it sends a lot of change requests for the CTM property in the
process, which triggers a lot of display probes from gdk. In the case of the
night light feature, the CTM itself is not actually changing, so these requests
are redundant. Fix this by caching the CTM value in the MetaOutputXrandr and
skipping the server requests if it's not being changed.
Fixes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/3978
Signed-off-by: Aaron Plattner <aplattner@nvidia.com>
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1816>
XIQueryPointer allocates the button state mask that we were leaking in
some places. We need to manually free this, because there is no XI
function that would do this for us.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1728>
Input settings requires a valid seat in order to initialize the a11y
settings (since commit 1609d145), however in X11 we never set it and
even if we create the input settings early (as per commit 7547891a) we
never initialize the seat for it.
This leads to startup critical errors on X11:
clutter_seat_get_pointer_a11y_settings: assertion
'CLUTTER_IS_SEAT (seat)' failed
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1763>
This commit adds the events created in the function
`meta_seat_x11_notify_devices` to the clutter events queue, which
are currently only added to the stage queue making the events not
being picked up by the `clutter_seat_handle_event_post` function.
This results in devices not getting added to the device-list of
`MetaInputSettings`.
Fixes the bug in which mouse and touchpad settings are not working in
the settings app during x11 session.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1767>
The nested backend may need to have an input setting implementation,
while we don't want to change the host settings (re-using an X11 input
settings) we can add a dummy implementation, until something more
complex is needed.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1769>
This removes the responsibility of tracking these from the backend to
the base object. The backends are instead responsible for calling the
function to update the values.
For the native backend, it's important that this happens on the correct
thread, so each time either of these states may change, post a idle
callback on the main thread that sets the, at the time of queuing said
callback, up to date state. This means that things on the main thread
will always be able to get a "new enough but not too new" state when
listening on the 'notify::' signals and getting the property value
after.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1739>
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>
Given X11 nature, the pointer "leaves" the stage anytime it wanders into
a client window, or any other areas that are not deemed part of the
stage input region.
Yet we want to stay correct in those situations, e.g. have the clutter
side reasonably in sync, picking and highlighting to work properly, etc.
In order to achieve that, emulate motion events on XI_RawMotion. These
are as much throttled as our pointer tracking for a11y, in order to avoid
too many XIQueryPointer sync calls. This emulation only kicks in anytime
that X11 notifies us that we are not "on" the stage.
This replaces some sync_pointer() calls in GNOME Shell code that are
there just to compensate for this trait of X11, e.g. in the message tray
code.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1659>
Ensure we issue a motion event for the current pointer position,
as there might be situations where compositor modals get X grabs
from other clients stacked on top, or missed events in between
otherwise.
Ensure the Clutter state is still up-to-date afterwards here. This
replaces some sync_pointer() calls done in GNOME Shell code, always
done after modality changes.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1659>
Mutter needs to fetch the X11 Window ID from the onscreen and did that
by using an X11 specific API on the CoglOnscreen, where the X11 type was
"expanded" (Window -> uint32_t). Change this by introducing an interface
called CoglX11Onscreen, implemented by both the Xlib and GLX onscreen
implementations, that keeps the right type (Window), while avoiding X11
specific API for CoglOnscreen.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1514>
Thins means that e.g. MetaOnscreenNative now inherits CoglOnscreenEgl,
which inherits CoglOnscreen which inherits CoglFramebuffer, all being
the same GObject instance.
This makes it necessary to the one creating the onscreen to know what it
wants to create. For the X11 backend, the type of renderer (Xlib EGL or
GLX) determines the type, and for the native backend, it's currently
always MetaOnscreenNative.
The "winsys" vfunc entries related to onscreens hasn't been moved yet,
that will come later.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1514>
Make the API used more shared and better named.
meta_monitor_manager_on_hotplug() was renamed
meta_monitor_manager_reconfigure(), and meta_monitor_manager_reload()
was introduced to combine reading the current state and reconfiguring.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1689>
Instead of setting the frame result in the most generic layer, have the
backends do it themselves. This is necessary to communicate that a
swap-buffer call didn't really succeed completely to present the swapped
buffer, e.g. errors from KMS.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
This argument is intended to be used by clutter to be able to
communicate with the onscreen backend, that happens to be the native
backend. It will be used to pass a ClutterFrame pointer, where the
result of page flips, mode sets etc can be communicated whenever it is
available.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
ClutterFrame aims to carry information valid during dispatching a frame.
A frame may or may not include redrawing, but will always end with a
result.
A asynchronous page flip, for example, will result in a
CLUTTER_FRAME_RESULT_PENDING_PRESENTED, while a frame that only
dispatched events etc will result in CLUTTER_FRAME_RESULT_IDLE. Instead
of this being implicit, make the ClutterStageWindow implementation
handle this itself.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
