Changing the test monitor managers ability to rotate CRTCs in one test
affected the next test. Avoid leaking such state by resetting it before
each test. To continue passing, some tests needed to be updated
regarding to still pass.
https://bugzilla.gnome.org/show_bug.cgi?id=788915
Add a test case that checks that we don't try to revert to a
laptop-panel-only configuration after closing the lid after an external
monitor is connected.
https://bugzilla.gnome.org/show_bug.cgi?id=788915
Check that if there are multiple modes with the same ID (resolution,
refresh rate and handled flags) we correctly add the preferred mode to
the list of monitor modes.
https://bugzilla.gnome.org/show_bug.cgi?id=789153
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
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
Instead of using a environment variable, add a new 'experimental
feature' gsetting keyword "monitor-config-manager" that enables the use
of the new MetaMonitorConfigManager. This commit also makes it possible
to switch between the two systems without restarting mutter.
The D-Bus API is disabled when the experimental feature is not enabled,
and clients trying to access it will get a access-denied error in
response. A new property 'IsExperimentalApiEnabled' is added to let the
D-Bus client know whether it is possible to use the experimental API or
not.
https://bugzilla.gnome.org/show_bug.cgi?id=777732
This commit adds support for rendering onto enlarged per logical
monitor framebuffers, using the scaled clutter stage views, for HiDPI
enabled logical monitors.
This works by scaling the mode of the monitors in a logical monitors by
the scale, no longer relying on scaling the window actors and window
geometry for making windows have the correct size on HiDPI monitors.
It is disabled by default, as in automatically created configurations
will still use the old mode. This is partly because Xwayland clients
will not yet work good enough to make it feasible.
To enable, add the 'scale-monitor-framebuffer' keyword to the
org.gnome.mutter.experimental-features gsettings array.
It is still possible to specify the mode via the new D-Bus API, which
has been adapted.
The adaptations to the D-Bus API means the caller need to be aware of
how to position logical monitors on the stage grid. This depends on the
'layout-mode' property that is used (see the DisplayConfig D-Bus
documentation).
https://bugzilla.gnome.org/show_bug.cgi?id=777732
Make the concept of maximum screen size optional, as it is not
necessarily a thing on all systems (e.g. when using the native backend
and stage views).
The meta_monitor_monitor_get_limits() function is replaced by a
meta_monitor_manager_get_max_screen_size() which fails when no screen
limit is available. Callers and other users of the previous max screen
size fields are updated to deal with the fact that the limit is
optional.
The new D-Bus API is changed to move it to the properties bag, where
its absence means there is no applicable limit.
https://bugzilla.gnome.org/show_bug.cgi?id=777732
Add a new D-Bus API that uses the state from GetCurrentState to
configure high level monitors, instead of low level CRTCs and
connectors. So far persistent configuration is not implemented, as
writing to the configuration store is still not supported.
https://bugzilla.gnome.org/show_bug.cgi?id=777732
Logical monitors in a configuration must be adjecent to each other,
meaning there will be at least one pixel long side touching some other
logical monitor.
The exception to this is when there is only one logical monitor, which
cannot be adjecent to any other.
https://bugzilla.gnome.org/show_bug.cgi?id=777732
Let the backends decide whether to just rebuild a derived state, or use
the NULL config to rebuild an empty logical state.
This also changes the expected screen size values of the no-outputs
test; as this case is actually handled now.
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
Expose via a new API whether the transform on a logical monitor is
handled by the backend. This was previously only exposed only in the
native backend. This will be used to emulate not supporting transforms
in the backend in the nested backend.
https://bugzilla.gnome.org/show_bug.cgi?id=779745
Make sure that each logical monitor owns the expected actual monitors.
This currently needs special care when dealing with laptop lid the
configuration, as the MetaMonitorConfigManager path still deosn't
handle restoring the previous configuration, meaning the logical
monitor with the external monitor will continue being primary.
https://bugzilla.gnome.org/show_bug.cgi?id=777732
This is partly redundant given that the current monitor mode is checked
against the CRTC mode, but this also checks the disabled CRTCs. Later
the configured mode position and transform will be checked.
https://bugzilla.gnome.org/show_bug.cgi?id=777732
Check that the crtc mode has the correct intra-monitor position. In
effect, this tests that the CRTCs in a tiled monitor are configured with
the correct mode on the correct position.
https://bugzilla.gnome.org/show_bug.cgi?id=777732
The main output of the main (first) monitor of a primary logical
monitor should have the MetaOutput::is_primary field set; all other
outputs should have it not set.
All outputs associated with a logical monitor with presentation set
should have MetaOutput::is_presentation set. No other outputs should
have it set.
https://bugzilla.gnome.org/show_bug.cgi?id=777732
Add a flag to the test setup creation function enabling the caller to
specify whether a stored config should be used. This is done by
changing the value of the hotplug_mode_update MetaOutput field,
normally used by VMs to do the same.
https://bugzilla.gnome.org/show_bug.cgi?id=777732
Both the monitor unit tests and monitor store unit tests will want to
check whether the config manager is used and set custom configuration
files.
https://bugzilla.gnome.org/show_bug.cgi?id=777732
Don't let a dummy option context consume the arguments; just let the
GLib test suite do it. It'll handle the basic command line arguments
and allow doing things such as specifying what test to run.
https://bugzilla.gnome.org/show_bug.cgi?id=777732
This tests only the monitor configuration and basic functionality. It
does not test anything related to window management and Wayland client
interaction.
https://bugzilla.gnome.org/show_bug.cgi?id=777732
Use the g_assert_cmp(int|uint|...) macros when comparing integers and
unsigned integers. This means that the mismatched numbers are printed
in the test report.
https://bugzilla.gnome.org/show_bug.cgi?id=777732
Add a test case that checks that configuration works when the lid is
initialy closed then later opened. This test case is disabled when the
legacy configuration is used as it does not handle that situation.
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
