The CRTC position depends on the transform and how the transform is
implemented. The function calculating the positions still doesn't
support anything but the non-transformed case; this commit is in
preparation of adding support for transforms.
https://bugzilla.gnome.org/show_bug.cgi?id=777732
Add a 'is_underscanning' entry to the properties map, if the monitor
supports underscanning. The client should assume a monitor does not
support underscanning if no property was added.
https://bugzilla.gnome.org/show_bug.cgi?id=777732
Replace the 'scale' of an output with a vfunc on the MetaMonitorManager
class that takes a monitor and a monitor mode which calculates the
scale. On X11 this always returns 1, on KMS, the old formula is used.
On the dummy and test backends, the already configured values are
returned.
https://bugzilla.gnome.org/show_bug.cgi?id=777732
The default (calculated) scale is derived from the output, but
ultimately set via the monitor scale. This will enable config files to
override the scale. Yet to be done is handling when a scale is not
supported by a backend (i.e. the X11 backend).
https://bugzilla.gnome.org/show_bug.cgi?id=777732
Previously, the size of the logical monitor was derived directly from
the tiling information. This works fine until we add transformations,
or set modes with a dimension different from the resulting resolution
when tiled. Fix this by traversing the assigned CRTC rects, as these
are already transformed by the configuration system.
https://bugzilla.gnome.org/show_bug.cgi?id=779745
Split up logical monitor cration into derived (when derived from
current underlying configuration) and non-derived (when creating from a
logical monitor configuration). This avoids that type of logic in the
logical monitor creation function.
https://bugzilla.gnome.org/show_bug.cgi?id=779745
Add support for non-tiled monitor modes on tiled monitors. This is done
by adding all the other supported modes, except the modes with the
same resolution as the tile dimensions.
https://bugzilla.gnome.org/show_bug.cgi?id=779745
MetaMonitorConfigStore provides an XML storage mechanism for
MetaMonitorConfigManager. It stores configuration files defined in the
same level as the MetaMonitorsConfig format, i.e. refers to high level
"monitors" and "monitor modes" instead of connectors and CRTCs.
Only reading custom files are implemented and so far unused.
https://bugzilla.gnome.org/show_bug.cgi?id=777732
Adds an API to get the position suggested by the backend. This
translates to position advertised by some VM:s, used to hint at a
position making the position more natural (i.e. placed similarly to how
it may be placed on the host desktop).
https://bugzilla.gnome.org/show_bug.cgi?id=777732
The new monitor configuration system (MetaMonitorConfigManager) aims to
replace the current MetaMonitorConfig. The main difference between the
two is that MetaMonitorConfigManager works with higher level input
(MetaMonitor, MetaMonitorMode) instead of directly looking at the CRTC
and connector state. It still produces CRTC and connector configuration
later applied by the respective backends.
Other difference the new system aims to introduce is that the
configuration system doesn't manipulate the monitor manager state; that
responsibility is left for the monitor manager to handle (it only
manages configuration and creates CRTC/connector assignments, it
doesn't apply anything).
The new configuration system allows backends to not rely on deriving the
current configuration from the CRTC/connector state, as this may no longer be
possible (i.e. when using KMS and multiple framebuffers).
The MetaMonitorConfigManager system is so far disabled by default, as
it does not yet have all the features of the old system, but eventually
it will replace MetaMonitorConfig which will at that point be removed.
This will make it possible to remove old hacks introduced due to
limitations in the old system.
https://bugzilla.gnome.org/show_bug.cgi?id=777732
When a logical monitor constains monitors with different subpixel
ordering, make the wl_output have the subpixel order 'unknown' so that
clients don't make assumptions given only a subset of the monitors of
the given region.
https://bugzilla.gnome.org/show_bug.cgi?id=777732
A monitor spec object is meant to be used to identify a certain monitor
on a certain output. The spec is unique per actual monitor and connector,
meaning that a monitor that changes from one connector from another
(e.g. HDMI1 to HDMI2) will not be identified as the same. It is meant
to associate for example a configuration entry with an actual monitor.
https://bugzilla.gnome.org/show_bug.cgi?id=777732
Add a "mode spec" concept, meaning to be used as a identifier for an
actual monitor mode. It consists of details making a mode unique, i.e.
the total resolution and refresh rate. This will later be used to get
the actual monitor mode (set of one or more CRTC modes).
https://bugzilla.gnome.org/show_bug.cgi?id=777732
Add "monitor modes" abstracting the modes set on a monitor. On normal
monitors, this directly maps to the CRTC modes, but on tiled monitors,
a monitor mode can consist modes per tiled output.
https://bugzilla.gnome.org/show_bug.cgi?id=777732
Don't deal with adding/removing tiled Xrandr monitors in the generic
backend, but leave it to the Xrandr backend. The tiled monitor will
itself notify the backend when such a monitor is added and removed.
Tiled Xrandr monitors are now based no MetaMonitor instead of
MetaLogicalMonitor. This means that mirrored tiled monitors will now be
represented correctly.
https://bugzilla.gnome.org/show_bug.cgi?id=777732
Instead of using crtcs and outputs to generate logical monitors, use
the ready made monitor abstraction that hides irrelevant things such as
monitor tiling etc.
https://bugzilla.gnome.org/show_bug.cgi?id=777732
Generate a set of "monitors" abstracting the physical concepts. Each
monitor is built up of one or more outputs; multiple outputs being
tiled monitors. Logical monitors will later be built from these.
https://bugzilla.gnome.org/show_bug.cgi?id=777732
