In almost all cases, the configuration will be "valid" in the sense that
g-c-c can represent it in the UI. However, there are cases like
mirroring setups with three monitors that we do not allow.
In case that the user has such a configuration, ensure that the
configuration we represent is actually valid according to our
expectations. This should not affect normal use cases, but allows users
to recover again if the configuration is broken for some reason.
Fixes#383
When the user has more than two monitors, then they can disable each
monitor separately. If the user creates an invalid configuration because
they disabled the last monitor, then enable a different one immediately.
The new logic selects a single configuration type rather than detecting
which types can be considered valid. This simplifies the UI rebuilding
somewhat, but also changes some internal behaviour. We will now always
be in the correct mode internally, even if the UI may not represent this
change (i.e. with more than two monitors it always looks the same).
We should show unusable monitors in the monitor selection drop-down
list. So always add them to the combobox and add the code to make the
switch to enable them insensitive.
We should only enforce single mode, when we have exactly two monitors
and the two button UI is used to switch between them in single mode.
Move the code to ensure the single configuration into the relevant
callback handler, rather than trying to solve this globally.
We need to also set rebuilding while updating some other UI elements.
Make it into a counter to allow for recursive setting.
Note that additional checks for rebuilding will be added in later
commits.
It generally makes more sense to reset the resolution of a monitor after
we switch configuration types. The main case where this is relevant is
switching from a mirror configuration (CLONE) to either join or single.
In this case, higher resolutions for monitors may become available.
Note that this might be annoying to some users, because there may be
monitors reporting a lower "preferred" resolution than the highest
supported resolution. There is little we can do though, as always
selecting the highest resolution doesn't seem like a much better
approach.
If no monitors are enabled, then the variant would end up with an
invalid variant type, causing a crash later on. This case only happened
due to other bugs (i.e. in principle we should never send a
configuration without any monitors to the server).
Prevent the serialization error by specifying the correct type for the
builder, therefore potentially preventing a crash in such a corner case.
When enabling the first monitor, we need to select it as primary as we
otherwise end up without a primary monitor (rendering the configuration
invalid). "Unsetting" the NULL primary monitor effectively causes the
first and only available monitor to become the primary, while not doing
anything if we have a primary monitor.
The new code had a bug in that it only ever enabled the first monitor
rather than all usable ones. Fix this by removing the erroronuous break.
Also clarify the comment a bit that the current solution is not really
ideal as it may result in invalid configurations (i.e. we enable more
outputs than are possible with the number of available CRTCs).
Fixes#418
As per the binding that we have between the list store and the combo-box, when
the first element is added to the list-store, the combo box set this value as
the selected-index, and this leads to a call to cc_display_monitor_set_primary
which set the first-listed monitor as primary and unset the real primary monitor.
To avoid this, just ignore the binding when rebuilding the UI, since in this
phase control-center should just reflect the actual state without changing
anything.
Fixes https://gitlab.gnome.org/GNOME/gnome-control-center/issues/419
GNOME/gnome-control-center!387 ported info panel to use UDisks2 instead
of GUnixMounts and thus the helpers from gsd-disk-space-helper.[h|c] are
no more needed.
Disabled monitors may or may not have a mode selected. This means, we
need to skip the mode comparison if the two compared monitors are
disabled (i.e. have no logical monitor).
Move the mode check to the end and skip it if both monitors are disabled.
This fixes cases where identical configurations are misdetected, because
we applied a mode to a monitor and disabled the monitor again. This
happens for example when switching the active monitor in "single" mode.
In the case where the user plugged/unplugged a screen, we could run into
the case where we would first enable and then disable the same output.
This could potentially result in an invalid configuration.
Prevent this by not disabling the output if no switch happened.
The dialog tried to retain the current configuration mode. However,
doing so means that we end up in the wrong mode in some situation (e.g.
opening the dialog with two displays but only one enabled).
Fix this by always selecting a configuration mode. This potentially
switches the user from "join" to "single" if only one monitor is left.
However, the user has no way to do this manually, so no unexpected UI
change will happen.
