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>
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>
g_hash_table_steal leaked the MetaMonitorSpec key in the old
compositor->outputs hash table:
==1059254== 62 (32 direct, 30 indirect) bytes in 1 blocks are definitely lost in loss record 8,232 of 13,059
==1059254== at 0x48489F3: calloc (vg_replace_malloc.c:1340)
==1059254== by 0x4C65C19: g_malloc0 (gmem.c:133)
==1059254== by 0x4956FE8: meta_monitor_spec_clone (meta-monitor.c:108)
==1059254== by 0x4A7B9E8: meta_wayland_compositor_update_outputs (meta-wayland-outputs.c:555)
==1059254== by 0x4A7C09E: meta_wayland_outputs_init (meta-wayland-outputs.c:796)
==1059254== by 0x4A63B60: meta_wayland_compositor_new (meta-wayland.c:874)
==1059254== by 0x49B58D0: meta_context_start (meta-context.c:523)
==1059254== by 0x10A8D7: main (mutter.c:148)
==1059254==
==1059254== 62 (32 direct, 30 indirect) bytes in 1 blocks are definitely lost in loss record 8,233 of 13,059
==1059254== at 0x48489F3: calloc (vg_replace_malloc.c:1340)
==1059254== by 0x4C65C19: g_malloc0 (gmem.c:133)
==1059254== by 0x4956FE8: meta_monitor_spec_clone (meta-monitor.c:108)
==1059254== by 0x4A7B9E8: meta_wayland_compositor_update_outputs (meta-wayland-outputs.c:555)
==1059254== by 0x4A7BA8C: on_monitors_changed (meta-wayland-outputs.c:572)
==1059254== by 0x4F5E9BF: g_closure_invoke (gclosure.c:833)
==1059254== by 0x4F72D82: signal_emit_unlocked_R.isra.0 (gsignal.c:3887)
==1059254== by 0x4F747A8: signal_emit_valist_unlocked (gsignal.c:3519)
==1059254== by 0x4F7A665: g_signal_emit_valist (gsignal.c:3262)
==1059254== by 0x4F7A722: g_signal_emit (gsignal.c:3582)
==1059254== by 0x49691BD: meta_monitor_manager_notify_monitors_changed (meta-monitor-manager.c:1241)
==1059254== by 0x496EA8D: meta_monitor_manager_rebuild (meta-monitor-manager.c:3968)
v2:
* Use g_autoptr. (Sebastian Wick, Jonas Ådahl)
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/4149>
Add a flag to MetaMonitor indicating if the monitor is available for
lease and store/update it from the monitor configuration.
Also, add unit tests validating that the configuration is applied and
that invalid configurations fail.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/4112>
Dropped obsolete Free Software Foundation address pointing
to the FSF website instead as suggested by
https://www.gnu.org/licenses/gpl-howto.html
keeping intact the important part of the historical notice
as requested by the license.
Resolving rpmlint reported issue E: incorrect-fsf-address.
Signed-off-by: Sandro Bonazzola <sbonazzo@redhat.com>
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3155>
This will be used to extract the resolution and refresh rate from
strings like "1920x1080@60.0" or "1280x720". This aims to replace the
use of the locale dependent sscanf() function.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2902>
This adds a new 'experimental-hdr' string property to the MonitorManager
which can be changed from looking glass.
Currently when the string equals 'on', HDR (PQ, Rec2020) will be enabled
on all monitors which support it. In the future support for more
transfer functions and color spaces as well as HDR metadata can be
added.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2879>
The first monitor in stacking tests is the primary monitor but that
doesn't have to stay this way forever. Instead of special casing the
name "primary" to refer to whatever monitor happens to be the primary
monitor, we add an `assert_primary_monitor` command to verify that the
monitor that should be the primary monitor actually is.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2748>
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>
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>
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>
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>
Some monitors support hardware features to enable the privacy screen
mode that allows users to toggle (via software or hardware button) a
state in which the display may be harder to see to people not sitting
in front of it.
Expose then this capability to the monitor level so that we can get its
state and set it.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1952>
The testing currently done is:
* Creating a virtual monitor succeeds and gets the right configuration
* Painting a few times results in the expected output
* Changing the content of the stage also changes the painted content
accordingly
* Destroying the virtual monitor works as expected
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1698>
Before each frame is maybe redrawn, push any new cursor KMS state to the
pending update. It'll then either be posted during the next page flip,
or when the same frame finishes, in case nothing was redrawn.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
The display name is being used by the monitor manager to expose to name
to the DBUS API.
It is being rebuilt each time, so instead build the displa yname once
for the monitor and keep it around, with an API to retrieve it, so that
we can reuse it in preparation of xdg-output v2 support.
https://gitlab.gnome.org/GNOME/mutter/issues/645
Make meson link libmutter using -fvisibility=hidden, and introduce META_EXPORT
and META_EXPORT_TEST defines to mark a symbols as visible.
The TEST version is meant to be used to flag symbols that are only used
internally by mutter tests, but that should not be considered public API.
This allows us to be more precise in selecting what is exported and what is
not, without the need of a version-script file that would be more complicated
to maintain.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/395
The order and way include macros were structured was chaotic, with no
real common thread between files. Try to tidy up the mess with some
common scheme, to make things look less messy.
Avoid exporting through org.gnome.Mutter.DisplayConfig.GetCurrentState
excessively-low screen resolutions setting both a minimum width and a minimum
height. GetCurrentState is e.g. used by Gnome Control Center to build a list of
selectable resolutions.
Fixes: https://bugzilla.gnome.org/show_bug.cgi?id=793223
Some x86 clamshell design devices use portrait tablet LCD panels while
they should use a landscape panel, resoluting in a 90 degree rotated
picture.
Newer kernels detect this and rotate the fb console in software to
compensate. These kernels also export their knowledge of the LCD panel
orientation vs the casing in a "panel orientation" drm_connector property.
This commit adds support to mutter for reading the "panel orientation"
and transparently (from a mutter consumer's pov) fixing this by applying
a (hidden) rotation transform to compensate for the panel orientation.
Related: https://bugs.freedesktop.org/show_bug.cgi?id=94894https://bugzilla.gnome.org/show_bug.cgi?id=782294
Check that if there are multiple modes with the same ID (resolution,
refresh rate and handled flags) we correctly add the preferred mode to
the list of monitor modes.
https://bugzilla.gnome.org/show_bug.cgi?id=789153
