Only a tiny number of tablet pads that have more than one mode
group, everyone else has one mode toggle button and one group.
Let's not display "Group 0" for everyone if (almost) no-one has a Group
1 anyway.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/4248>
The "seat" property is already used by the parent
ClutterVirtualInputDevice - re-using this property means the parent's
propery never gets set so clutter_virtual_input_device_get_seat()
returns NULL.
This causes mutter to crash if a tablet pad sends a key event via a pad
ring or strip.
Since this type is only ever constructed with a MetaSeatNative as seat
we can extract that object through the parent and drop our property.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/4247>
HDR being enabled was controlled by toggling a property on
org.gnome.Mutter.DebugControl, which affected how the color space and
HDR metadata of the output was configured. Replace this with a higher
level MetaMonitor / MetaOutput level "color mode" enum, that is also
reflected in the monitor configuration API.
This enum is then used to derive the color space and HDR metadata at the
lower level where it matters. The ForceHDR debug control property is
still left there, as it only affects the color space and transfer
function of the view related to a monitor.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/4192>
Finding configurations relevant for inspiration when creating a new one
can be useful for finding more things to inherit from previous
configurations than the scale, so put the configuration gathering code
in a helper.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/4192>
Available modes are 'default', which is always added, and BT.2100,
which is added if the BT.2020 color space, and the PQ transfer function,
is supported by the output.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/4192>
Commit 48d070dae changed the logic to compare the modifiers mask as a
whole.
Unfortunately, that does not work with all combinations of modifiers, as
some may not be reported when the ISO_Next_Group key is notified.
Revert to the original logic which is to compare against each modifier
mask individually.
Fixes: commit 48d070dae - keybindings: Check for ISO_Next_Group keysym
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/4237>
In process_iso_next_group(), we would use try to match mask and keycode
of ISO_Next_Group to tell whether the key combo has been activated.
That works on X11, but not on Wayland with the native backend, because
the keycode does not match.
But we do not need to go all through that burden to match the key combo
we could just use the keysym instead, which would work even when there
is no physical key for ISO_Next_Group.
All we need to do is check whether the symbol is ISO_Next_Group and the
modifier mask matches, which simplifies the code as well.
(Note that we still need to keep the resolved iso_next_group_combo
key combo around because the X11 backend grabs that key combo.)
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/3883
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/4232>
The gravity argument is no longer effective since the previous
commit. Drop the argument, and rename it to "meta_window_resize_frame",
all callers have been updated.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3972>
Ignore the gravity argument in the move_resize_internal() vmethod,
and use the window getter to get it. It should be functionally
equivalent, and will eventually replace the argument entirely.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3972>
We really only need the logind API which can be provided either by
libsystemd or libelogind.
This also pulls out finding a logind provider from the native backend
only code because we make use of it in the generic backend code as well.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/4223>
This page does not seem to have been archived properly when the wiki got
shut down so the link does not work anymore. There is no replacement
page in the handbook either.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/4229>
The reference images were generated using the Adwaita theme, so make sure that
the test client also draws a cursrom from the Adwaita theme rather than reading the
default theme from the environment.
Ideally the test suite would embed the cursor theme and point XCURSOR_PATH to
it, so that even if the Adwaita icon theme changes in the future the test
wouldn't suddently break; I did not implement this yet.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/4225>
When the cursor is captured via metadata, schedule updates when the
sprite changes or position moves, so we can gather the cursor change
during dispatch.
Also use the new skipped-paint stage watch to avoid having to guess
whether something will be painted by peeking at the pending damage.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/4067>
