Currently, we would only disable a11y if a certain flag is passed
but the function is always called with NONE flag. Instead
drop the flag, use a new environment variable for that
That value is then used by actors to short-circuit get_accessible
implementation and return NULL if the accessibility is not enabled
Also clean the other accessibility functions
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3917>
Instead of doing that in both MetaStage & CallyStage.
This allows ClutterStage to also emits the relavant acessibility
bits directly without having a roundtrip through Cally
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3917>
The generic term updated can mean anything. This is specifically about
calibration related updates like changing the sink colorimetry
(Colorspace, HDR metadata) and changes to the white point for night
light etc.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3904>
Previously the color device was destroyed when it was attached to a
monitor that was going away. However, the MetaMonitor objects are
ref-counted and can stay around for longer, even if the underlying
resources went away. We need color devices for as long as the
MetaMonitors are alive.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3904>
Every monitor should eventually have a corresponding color device. To
make sure this can work, we must handle situations where the color
manager didn't connect to colord yet, and thus isn't ready.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3904>
When triple buffering, `meta_onscreen_native_prepare_frame` for the next
frame is called before `notify_view_crtc_presented` for the previous frame.
So our booleans were unfortunately still TRUE in the second prepare_frame,
resulting in two frames with the same property updates.
When double buffering, having roughly one frame interval between
`meta_onscreen_native_prepare_frame` and `notify_view_crtc_presented`
meant that property updates signalled between the swap and presentation
wouldn't get attached to a KMS update, and would be forgotten when
`notify_view_crtc_presented` resets the flags to FALSE.
To solve these we now keep a separate flag and counter per property,
tracking invalidation and pending updates respectively. The latter is a
counter rather than a boolean in support of triple buffering where two
updates may be pending concurrently (next and posted).
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3912>
Because if the current theme has exceeded the dimensions of
`DRM_CAP_CURSOR_WIDTH/HEIGHT` then the warning is just going to repeat
every time the cursor changes. We still fall back to software cursors
just fine so it's not important to repeat the warning.
In Mutter 46 the warning was "Invalid theme cursor size". Same problem.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/3597
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3924>
As it was originally the function to be used before
making it private and providing safer wrappers around it for x11/win32.
Nowadays, it is only used in x11 and only internally in mutter, exposing
a 'safer' variant costs us exposing more of x11 renderer APIs without
much benefits.
With this change, the only internal xlib renderer we need from meta is
set_foreign_display which can't be easily worked around
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3910>
by executing `global.context.get_debug_control().exported = true`.
This makes it possible to get access to the debug service without having
to start with `--enable-debug`.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3902>
It won't be used until later when we flip, and in fact assigning
it early could have led to its own assertion failing on the next frame
in the unlikely event that we return with "Failed to ensure KMS FB ID...
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3891>
Introduced in libinput 1.26 this feature allows restricting the
tablet tool pressure range to a subset of its physical range. The
use-case is either to require some higher-than-usual minimum pressure
before the pen reacts, or lower-than-usual pressure to reach the maximum
logical pressure.
libinput takes a [0.0, 1.0] normalized range which we expose as percent
in the gsettings. The wacom driver doesn't have an exact equivalent but
it has a Threshold setting (range [1, 2048]) that defines when a button
is generated for tip down.
See gsettings-desktop-schemas!84
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3794>
Unlike most other schemas the path for a tool requires a bit of
processing (serial number or tablet vid/pid if there's no serial number).
Let's make the tool settings available through the MetaInputSettings
instead of having to duplicate that path composition in the caller.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3649>
Stylus actions that don't map into LMR or back/forward are now created
as a clutter button event with a button number of zero. Nothing is
actually done with those events for now, they're just discarded later.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3649>
