Tests that test case EDID is setup correctly, and that color devices for
monitors are created.
tests/color: Add hotplugging tests
Checks that changing the number of connected monitors reflects the
number of current color devices, and that we end up with the correct end
state.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2164>
Ready means it has established the connection to colord and can operate.
Will be used by tests to make sure tests don't fail due to race
conditions when connecting to colord.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2164>
gsd-color provides this API, which exposes details about the night light
state. Currently, gsd-color also turns this state into CRTC gamma
changes, but this will eventually change, and this is a preparation for
this.
The proxy isn't yet used for anything.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2164>
Previously, gsd-color handled adding color devices. It got information
about those via the GnomeRR API, which is part of libgnome-desktop.
libgnome-desktop itself got this information from the
org.gnome.Mutter.DisplayConfig.GetResources() D-Bus method, implemented
by mutter.
Now, mutter itself will add all the monitor color devices itself,
without having to go via gsd-color.
We sometimes need to delete colord devices synchronously, in certain
race conditions when we add and remove devices very quickly (e.g. in
tests). However, we cannot use libcolord's 'sync' API variants, as it
has a nested takes-all main loop as a way to invoke the sync call. This
effectively means we end up sometimes not return from this function in a
timely manner, causing wierd issues.
Instead, create our own sync helper, that uses a separate context that
we temporarly push as the thread-default one.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2141>
It's not really about monitors, even though it is used for monitors.
Lets shrink MetaMonitorManager a bit moving it to the backend.
While at it, stop leaking it too.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2141>
What determines whether one MetaMonitor is the same as the other should
be whether the actual monitor is the same. The way to check this is
comparing the EDID vendor/product/serial fields. Whene these are
incomplete, fall back on the 'winsys ID'.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2141>
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>
As for the types of monitor, X11 and KMS are currently assumed to always be
physical, while the virtual ones are assumed to be virtual. In theory
X11 ones could be virtual, but lets not bother. KMS ones can be virtual
in the case of virtual KMS, but we typically use that for testing as if
it was physical, so lets leave it as such.
Will later be used to feed correct information to colord.
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>
Although its atomic KMS support seems to work at first, mode sets to
anything other than the Xilinx preferred max resolution of 2048x1280
would result in a hang. The xlnx kernel driver is given:
`DRM_MODE_ATOMIC_ALLOW_MODESET | DRM_MODE_PAGE_FLIP_EVENT`
and it does complete the mode set without error, but page flip events
never arrive and so you're frozen on the first frame.
Revert to legacy KMS which has no such problem with non-default modes.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2596>
The "activate" and "deactivate" signals on ClutterStage are used by
Cally to track the key-focus when the user is interacting with shell UI.
key-focus only gets tracked while the stage is activated.
Wayland has no concept of the stage receiving focus or not, so right now
the activation state is bound to whether there's a focus_window in
meta_display_sync_wayland_input_focus(). Since display->focus_window is
set pretty much all the time, this effectively binds activation state to
whether the stage holds a grab or not. This is almost good enough, but
it misses cases where key-focus is on the stage without a grab, for
example when keyboard-navigating the panel after using Ctrl+Alt+Tab.
It seems to make more sense to bind the activation state to whether
key-focus is set to an actor or to NULL, so let's do that instead.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2329>
Since commit 1bf70334 "tests/runner: Make test runner use the headless
backend", tests are run with the native backend in headless mode, which
will attempt to open each GPU and show a warning (fatal during tests)
if it cannot.
However, in headless mode we might not be logged in on any seat (for
example we might be logged in via ssh instead), which means we might
legitimately not have permission to use any GPUs, even if they exist.
Downgrade the warning to a debug message in this case.
Resolves: https://gitlab.gnome.org/GNOME/mutter/-/issues/2381
Signed-off-by: Simon McVittie <smcv@debian.org>
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2584>
This adds the 4 new connector types that mutter didn't know about from
drm_mode.h in the kernel.
Noticed because mutter kept crashing when plugging in a USB-C adapter to
use an external monitor.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2577>
When we e.g. generate switch configs (i.e. the ones from pressing the
Super+P or the switch-config key on laptops), try a bit harder to find a
"good" monitor scale.
With "good", it means pick a scale that was used in a previous
configuration. In practice, this means that if you for example have
configured your external monitor to use a specific scale, then pressed
e.g. "built in only", and then switched back to e.g. "external only" or
"linear", the generated configuration will use the scale that was
previously configured.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2479>
If two modes are roughly the same, they should probably use the same UI
scaling factor. I.e. for the same monitor, if a 4K mode was configured to
have a certain scaling factor, and we generate a new configuration with
a similar sized 4K mode, we should re-use the scale previously
configured; however if we e.g. go from a 4K mode to a FHD mode, we
shouldn't.
This allows implementing better hueristics when using the switch-config
feature, where we'd be less likely to loose the for a certain monitor
mode combination previously configured scaling factor.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2479>
This will eventually help with better hueristics for finding a good
scale. It currently doesn't change much, but the helper will later gain
more functionality that will also help when coming up with mirroring
configs.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2479>
