That is is_presentation, is_primary, is_underscanning and backlight.
The first three are set during CRTC assignment as they are only valid
when active. The other is set separately, as it is untied to
monitor configuration.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1287
To make it more reliable to distinguish between values that are read
from the backend implementation (which is likely to be irrelevant for
anything but the backend implementation), split out those values (e.g.
layout).
This changes the meaning of what was MetaCrtc::rect, to a
MetaCrtcConfig::layout which is the layout the CRTC has in the global
coordinate space.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/1042
This is inspired by 98892391d7 where the usage of
`g_signal_handler_disconnect()` without resetting the corresponding
handler id later resulted in a bug. Using `g_clear_signal_handler()`
makes sure we avoid similar bugs and is almost always the better
alternative. We use it for new code, let's clean up the old code to
also use it.
A further benefit is that it can get called even if the passed id is
0, allowing us to remove a lot of now unnessecary checks, and the fact
that `g_clear_signal_handler()` checks for the right type size, forcing us
to clean up all places where we used `guint` instead of `gulong`.
No functional changes intended here and all changes should be trivial,
thus bundled in one big commit.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/940
Instead of doing a roundtrip to the X server before setting it, rely on
the previous value fetched before the configuration was sent over DBus.
This matches the argument check we already do elsewhere, and will allow
us to more easily add an additional condition to determine if underscan
is supported.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/673
Since 4cae9b5b11, and indirectly before that as well, the
MetaMonitorManager::power-save-mode-changed is emitted even
when the power save mode didn't actually change.
On Wayland, this causes a mode set and therefore a stuttering.
It became more proeminent with the transactional KMS code.
Only emit 'power-save-mode-changed' when the power save mode
actually changed.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/674
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
DPMS is configured from a bit all over the place: via D-Bus, via X11 and
when reading the current KMS state. Each of these places did it slightly
differently, directly poking at the field in MetaMonitorManager.
To make things a bit more managable, move the field into a new
MetaMonitorManagerPrivate, and add helpers to get and set the current
value. Prior to this, there were for example situations where the DPMS
setting was changed, but without signal listeners being notified about
it.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/506
Commit 25f416c13d added additional compilation warnings, including
-Werror=return-type. There are several places where this results
in build failures if `g_assert_not_reached()` is disabled at compile
time and the compiler misses a return value.
https://gitlab.gnome.org/GNOME/mutter/issues/447
MonitorManager was inheriting from MetaDBusDisplayConfigSkeleton, this was
causing introspection to see this like a GDBus skeleton object exposing to
clients methods that were not required.
Also, this required us to export meta_dbus_* symbols to the library, while
these should be actually private.
So, make MetaMonitorManager to be just a simple GObject holding a skeleton
instance, and connect to its signals reusing most of the code with just few
minor changes.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/395
Switch-configs are only to be used in certain circumstances (see
meta_monitor_manager_can_switch_config()) so when ensuring
configuration and attempting to create a linear configuration, use the
linear configuration constructor function directly without going via the
switch config method, otherwise we might incorrectly fall back to the
fallback configuration (only enable primary monitor).
This is a regression introduced by 6267732bec.
Fixes: https://gitlab.gnome.org/GNOME/mutter/issues/342
It wasn't implemented by any subclass, it's not provided by DRM either.
And even if a subclass were to have only a file available, it could read
it into a GBytes as well and just use `read_edid()`.
Found this while working on !269.
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.
When constructing MetaMonitorsConfig objects, store which type
of switch_config they are for (or UNKNOWN if it is not such
type of config).
Stop unconditionally setting current_switch_config to UNKNOWN when
handling monitors changed events. Instead, set it to the switch_config
type stored in the MonitorsConfig in the codepath that updates logical
state. In addition to being called in the hotplug case along the same
code flow that generates monitors changed events, this is also called
in the coldplug case where a secondary monitor was connected before
mutter was started.
When creating the default linear display config, create it as a
switch_config so that internal state gets updated to represent
linear mode when this config is used.
The previous behaviour of unconditionally resetting current_switch_config
to UNKNOWN was breaking the internal state machine for display config
switching, causing misbehaviour in gnome-shell's switchMonitor UI when
using display switch hotkeys. The lack of internal tracking when the
displays are already in the default "Join Displays" linear mode was
then causing the first display switch hotkey press to do nothing
(it would attempt to select "Join Displays" mode, but that was already
active).
Fixes: https://gitlab.gnome.org/GNOME/mutter/issues/281https://gitlab.gnome.org/GNOME/mutter/merge_requests/213
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
Rather than handle UpClient in both MetaBackend (to reset the idletime
when the lid is opened), and in MetaMonitorManager and
MetaMonitorConfigManager (to turn the screen under the lid on/off
depending on its status), move the ability to get the lid status from
UPower or mock it in one place, in MetaBackend.
Restarting UPower will make every property of UpClient emit a "notify"
signal (as a GDBusProxy would). Avoid mutter reconfiguring the displays
when upower restarts by caching the last known value of "lid-is-closed"
and only reconfiguring the displays if it actually changed.
This fixes a black out of the screen when UPower restarts.
For some reason "backends: Remove X11 idle-monitor backend" removed
unrelated warning messages for when generated monitor configurations
that should work didn't, which also made the unit tests fail.
This commit adds them back, which also makes the tests pass again.
When deriving the global scale directly from the current hardware state
(as done when using the X11 backend) we are inspecting the logical
state they had prior to the most recent hot plug. That means that a
primary monitor might have been disabled, and a new primary monitor may
not have been assigned yet.
Stop assuming a primary monitor has an active mode before having
reconstructed the logical state by finding some active monitor if the
old primary monitor was disabled. This avoids a crash when trying to
derive the global scale from a disabled monitor.
Closes: https://gitlab.gnome.org/GNOME/mutter/issues/130
And use the old "native" backend for both X11 and Wayland. This will
allow us to share fixes between implementations without having to delve
into the XSync X11 extension code.
https://bugzilla.gnome.org/show_bug.cgi?id=705942
Output ID is set equal to 'i' later in the loop. But 'i' was never
incremented, so all outputs were getting the same ID (equal to
the number of CRTCs, because 'i' was reused from the previous loop).
(cherry picked from commit 23c3f8bb18)
If a LCD panel has a non normal orientation (mounted upside-down or 90
degrees rotated) then the kernel will report touchscreen coordinates with
the origin matching the native (e.g. upside down) coordinates of the panel.
Since we transparently rotate the image on the panel to correct for the
non normal panel-orientation, we must apply the same transform to input
coordinates to keep the aligned.
https://bugzilla.gnome.org/show_bug.cgi?id=782294
We only counted configured monitors and whether the config was
applicable (could be assigned), howeverwe didn't include disabled
monitors when comparing. This could caused incorrect configurations to
be applied when trying to use the previous configuration.
One scenario where this happened was one a system with one laptop
screen and one external monitor that was hot plugged some point after
start up. When the laptop lid was closed, the 'previous configuration'
being the configuration where only the laptop panel was enabled, passed
'is-complete' check as the number of configured monitors were correct,
and the configuration was applicable.
Avoid this issue by simply comparing the configuration key of the
previous configuration and the configuration key of the current state.
This correctly identifies a laptop panel with the lid closed as
inaccessible, thus doesn't incorrectly revert to the previous
configuration.
https://bugzilla.gnome.org/show_bug.cgi?id=788915
Adding an internal signal and use it to update the internal state before
emitting "monitors-changed" which will be repeated by the screen to the world.
https://bugzilla.gnome.org/show_bug.cgi?id=788860
In order to eventually support multilpe GPUs with their own connectors,
split out related meta data management (i.e. outputs, CRTCs and CRTC
modes) into a new MetaGpu GObject.
The Xrandr backend always assumes there is always only a single "GPU" as
the GPU is abstracted by the X server; only the native backend (aside
from the test backend) will eventually see more than one GPU.
The Xrandr backend still moves some management to MetaGpuXrandr, in
order to behave more similarly to the KMS counterparts.
https://bugzilla.gnome.org/show_bug.cgi?id=785381
