This is an old relic from when ClutterStageView was being added, and
tests were somewhat prepared to be able to test the "X11 style" of
things, with the nested backend some how managing to emulate that.
Lets drop that stuff, it isn't used by the test suite, and isn't useful
anyway; if we want to test X11 configurations, we should use the actual
X11 backend, which didn't make use of this anyway.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2619>
This allows using two separate ICC profiles for one "color profile",
which is necessary to properly support color transform
calibration profiles from an EFI variable.
These types of profiles are intended to be applied using the color
transformation matrix (CTM) property on the output, which makes the
presented output match sRGB. In order to avoid color profile aware
clients making the wrong assumption, we must set the profile exposed
externally to be what is the expected perceived result, i.e. sRGB, while
still applying CTM from the real ICC profile.
The separation is done by introducing a MetaColorCalibration struct,
that is filled with relevant data. For profiles coming from EFI, a
created profile is practically an sRGB one, but the calibration data
comes from EFI, while for other profiles, the calibration data and the
ICC profile itself come from the same source.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2568>
Instead of passing 4 arguments (red, green and blue arrays as well as a
size), always pass them together in a new struct MetaGammaLut. Makes
things slightly less tedious.
The KMS layer still has its own variant, but lets leave it as that for
now, to keep the KMS layer "below" the cross backend CRTC layer.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2165>
In practice, for KMS backend CRTC's, we cache the gamma in the monitor
manager instance, so that anyone asking gets the pending or up to date
value, instead of the potentially not up to date value if one queries
after gamma was scheduled to be updated, and before it was actually
updated.
While this is true, lets still move the API to the MetaCrtc type; the
backend specific implementation can still look up cached values from the
MetaMonitorManager, but for users, it becomes less cumbersome to not
have to go via the monitor manager.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2165>
Same applies to MetaOutput. The reason for this is to make it possible
to more reliably know when there was EDID telling us about these
details. This will be used for colord integration.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2141>
Create a color manager type that eventually will be the high level
manager of color related behavior, such as ICC profiles and
color "temperature" a.k.a. night light.
For now, it's only an empty shell. It's also constructed by the actual
backend, as at a later point, the X11 and native color management
implementations will differ.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2141>
Prior to this commit, barriers were created with a MetaDisplay pointer,
despite being entities related and owned by the backend. In the X11
case, it was also not hooked up to the backend X11 connection, but the
clutter one, meaning for example that the logic was active (but dormant)
also for the Xwayland connection.
Fix this by moving X11 barrier management and event processing fully to
the backend. Also replace passing a display pointer with passing a
backend pointer. Keep the display pointer around for a release, but mark
it as deprecated.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2442>
We don't make use of the refresh rate in any useful way in the X11, and
in this case we just ended up with warnings since the refresh rate was
NaN. Fix this by making it 0.0 to mean "no refresh rate". This also is
what 'xrandr' itself reports.
Fixes warnings when launching 'mutter --x11' in Xvfb.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2434>
Even though it's great that XI2 has an event to notify about device
changes, this is something we can let the MetaBackend code handle
consistently for all backends, since looking for the source device
works everywhere.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/285>
What the keymap eventually is after, are things handled by the actual
backend (MetaBackendX11), so let it keep a pointer to that. This
eliminates some usages of globals.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2014>
Let the meta_cursor_sprite_realize() function return a boolean value
telling whether there was an actual change in the sprite cursor. E.g.
the surface/icon for it changed in between.
This is used in the native backend to avoid converting/uploading again
the cursor surface.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1915>
