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
Move finding, opening and managment of the KMS file descriptor to
MetaMonitorManagerKms. This means that the monitor manager creation can
now fail, both if more than one GPU with connectors is discovered, or
if finding or opening the primary GPU fails.
https://bugzilla.gnome.org/show_bug.cgi?id=785381
Instead of passing it around or fetching the singleton, keep a pointer
to the monitor manager that owns the CRTC. This will eventually be
replaced with a per GPU/graphics card object.
https://bugzilla.gnome.org/show_bug.cgi?id=785381
Instead of passing it around or fetching the singleton, keep a pointer
to the monitor manager that owns the output. This will eventually be
replaced with a per GPU/graphics card object.
https://bugzilla.gnome.org/show_bug.cgi?id=785381
Convert MetaCrtcMode from a plain struct to a GObject. This changes the
storage format, and also the API, as the API was dependent on the
storage format.
https://bugzilla.gnome.org/show_bug.cgi?id=785381
Turn MetaCrtc into a GObject and move it to a separate file. This
changes the storage format, resulting in changing the API for accessing
MetaCrtcs from using an array, to using a GList.
https://bugzilla.gnome.org/show_bug.cgi?id=785381
Turn MetaOutput into a GObject and move it to a separate file. This
changes the storage format, resulting in changing the API for accessing
MetaOutputs from using an array, to using a GList.
https://bugzilla.gnome.org/show_bug.cgi?id=785381
Check that configurations where monitors are disabled are properly
used. Also test that old configurations with explicitly disabled
outputs are migrated properly.
https://bugzilla.gnome.org/show_bug.cgi?id=787629
When we update state, we might not have set the current config yet (for
example if the Xrandr assignment didn't change), so pass the monitors
config we should derive from instead of fetching it from the monitor
config manager.
https://bugzilla.gnome.org/show_bug.cgi?id=787477
Give clients (such as Xwayland) a chance to bind the wl_output global
before we continue, otherwise there is an significant risk that mutter
won't see the bind request until after the next hot plug which might
have destroyed the global object.
https://bugzilla.gnome.org/show_bug.cgi?id=730551
The foreach CRTC monitor mode helper incorrectly iterated over outputs
without CRTC when non-tiled modes were set on tiled monitors. This was
not expected by callers, so fix the helper to only iterate over active
outputs (that has or should have a CRTC).
The test cases uses the incorrect behaviour of the foreach CRTC helper
to check that the disabled outputs mode are set to NULL, so add a
foreach output helper and change the tests to use that instead.
https://bugzilla.gnome.org/show_bug.cgi?id=730551
When headless, we don't have any logical monitors to derive a screen
size from, but we can't set it to empty as that will cause issues with
the clutter stage, UI widget layout and other things. To avoid such
issues, just fall back to a 640 x 480 screen size when headless.
https://bugzilla.gnome.org/show_bug.cgi?id=730551
When opening a laptop lid, one will likely want to restore the
configuration one had prior to closing it, so when ensuring monitor
configuration, first try to see if the previously set configuration is
both complete (all connected monitors are configured) and applicable
(it is a valid configuration) and only try to generate a new from
scratch if that failed.
https://bugzilla.gnome.org/show_bug.cgi?id=777732
So far some basic testing, including:
* Test that the migrated configuration is applicable
* Test that a monitors.xml with multiple configurations are translated
* Test rotation
* Test tiled monitor discovery (well, test a made up tiled monitor
configuration since I don't have a real one)
https://bugzilla.gnome.org/show_bug.cgi?id=777732
This commit changes the new configuration system to use monitors.xml
instead of monitors-experimental.xml. When starting up and the
monitors.xml file is loaded, if a legacy monitors.xml file is
discovered (it has the version number 1), an attempt is made to migrate
the stored configuration onto the new system.
This is done in two steps:
1) Parsing and translation of the old configuration. This works by
parsing file using the mostly the old parser, but then translating the
resulting configuration structs into the new configuration system. As
the legacy configuration system doesn't carry over some state (such as
tiling and scale used), some things are not available. For tiling, the
migration paths makes an attempt to discover tiled monitors by
comparing EDID data, and guessing what the main tile is. Determination
of the scale of a migrated configuration is postponed until the
configuration is actually applied. This works by flagging the
configuration as 'migrated'.
2) Finishing the migration when applying. When a configuration with the
'migrated' flag is retrieved from the configuration store, the final
step of the migration is taken place. This involves calculating the
preferred scale given the mode configured, while making sure this
doesn't result in any overlapping logical monitor regions etc.
https://bugzilla.gnome.org/show_bug.cgi?id=777732
Test that a tiled monitor with tile (0, 0) as the non-main output,
where main output is defined as the output that is active as long as
the monitor is active.
https://bugzilla.gnome.org/show_bug.cgi?id=781723
Differentiate between non-interlaced and interlaced modes. This is done
by appending an "i" after the resolution part of the mode ID, and
adding a 'is-interlaced' (b) property to the mode properties.
https://bugzilla.gnome.org/show_bug.cgi?id=765011
This changes the API to pass supported scales per mode instead of
providing a global list. This allows for more flexible scaling
scenarious, where a scale compatible with one mode can still be made
available even though another mode is incompatible.
https://bugzilla.gnome.org/show_bug.cgi?id=765011
When the logical layout mode is used, allow configuring the scaling to
be non-integer. Supported scales are so far hard coded to include at
most 1, 1.5 and 2, and scales that doesn't result in non-fractional
logical monitor sizes are discarded.
Wayland outputs are set to have scale ceil(actual_scale) meaning well
behaving Wayland clients will provide buffers with buffer scale 2, thus
being scaled down to the fractional scale.
https://bugzilla.gnome.org/show_bug.cgi?id=765011
This commit makes it possible to configure logical monitor scale also
when running on top of an X11 server using Xrandr. An extra property
'requires-globla-scale' is added to the D-Bus API is added to instruct
a configuration application to only allow setting a global logical
monitor scale.
This is needed to let gsd-xsettings use the configured state to set a
XSettings state that respects the explicit monitor configuration.
https://bugzilla.gnome.org/show_bug.cgi?id=777732
Introduce MetaSettings and add the settings managed by MetaBackend into
the new object. These settings include: experimental-features and UI
scaling factor.
https://bugzilla.gnome.org/show_bug.cgi?id=777732
Test that configuration works as expected when the backend doesn't
support handling the transform and an intermediate offscreen
framebuffer is used.
https://bugzilla.gnome.org/show_bug.cgi?id=777732
In order to test deriving the logical state from the underlying
configuration, as is always done on X11, make the test backend derive
the state when stage views are disabled.
https://bugzilla.gnome.org/show_bug.cgi?id=777732
