Some devices have panels with a native resolution in portrait mode. In
these cases the monitor will likely be used in landscape mode.
Accept the modes as if they are landscape rather than portrait. A
further improvement would be to restrict the orientation setting.
Fixes#639
Make possible to set scaled size constraints per configuration, and add a method
to verify if the current mode at scale is allowed for such config.
This allows to perform such check also in case we have global scaling enabled,
as in such case we must verify that all the selected current modes are supported
by the given scale.
FixesGNOME/mutter#407
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.
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.
When comparing configurations, the monitor positions are compared
directly. This comparison will not work properly if one of the
configurations has an offset.
This results in the "Apply" button to show up incorrectly after moving
the top/left monitor position.
When changing the display mode, the apply button does not appear if the
current mode and new mode differ only in their interlaced flag.
The display mode comparison function now takes the interlaced flag into
account.
If mutter requires the same scale on all logical monitors we must
propagate a scale set on one monitor to the remaining ones or we'll
fail validation leaving users wondering why it doesn't work.
https://bugzilla.gnome.org/show_bug.cgi?id=790809
As the comment hinted at, fixing layouts automatically to ensure their
applicability doesn't actually work in all cases and in fact may force
users to redo their layout completely after a seemingly small change.
So, let's stop pretending we can do it and instead leave it to users
to fix it manually.
https://bugzilla.gnome.org/show_bug.cgi?id=789711
Mutter uses round() while we are just truncating via the implicit
double -> int type conversion, meaning that mutter will reject some
configurations that should work. Fix that by using the same rounding
as mutter.
https://bugzilla.gnome.org/show_bug.cgi?id=786919
Whether a mode is interlaced or not is now exported by adding a
'is-interlaced' (b) value to the mode properties variant. Implement the
is_interlaced() vfunc using this information.
The mode format communicated via the new D-Bus API changed to
specifying modes using a per monitor unique mode ID string. The uint
'flags' was also changed to more flexible a{sv} 'properties' structure.
This adapts as much as possible mutter's new display config API to the
current display panel's expectations. In particular we keep the
concept of logical monitors hidden from the panel. They will later be
exposed when we re-design the panel to make full use of the new API.
https://bugzilla.gnome.org/show_bug.cgi?id=782785
