Under X11 we can only ever have the same scale configured on all
monitors. In order to use e.g. scale 2 when there is a HiDPI monitor
connected, we must not disallow it because there is a monitor that does
not support scale 2. Thus we must show the same scale for every monitor
and monitor mode, even though it might result in a bad experience.
Do this by iterating through all the monitors adding all supported
scales by the preferred mode, combining all the supported scales. This
supported scales list is then used for all monitor and modes no matter
what.
https://bugzilla.gnome.org/show_bug.cgi?id=788901
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 code dealing with Xrandr MetaCrtcs and related functionality to its
own file. Eventually, MetaCrtcCrtc should be introduced, based on
MetaCrtc, and this commit is in preparation for that.
https://bugzilla.gnome.org/show_bug.cgi?id=785381
Move code dealing with X11 MetaOutputs and related functionality to its
own file. Eventually, a MetaOutputXrandr should be introduced, based on
MetaOutput, and this commit is in preparation for that.
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
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
The 'normal' transform has the value 0, so the g_warn_if_fail()
expression failed. Correct it so that it doesn't complain when no
transform is checked.
https://bugzilla.gnome.org/show_bug.cgi?id=777732
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
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
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
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
The function meta_monitor_manager_read_current_config() was renamed to
meta_monitor_manager_read_current_state() as it does not read any
configuration, but reads the current state as described by the backend.
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
The MetaMonitorMode referred to the mode of a CRTC, and with the future
introduction of a MetaMonitor, theh old name would be confusing.
Instead call it what it is.
https://bugzilla.gnome.org/show_bug.cgi?id=777732
In preparation for further refactorizations, rename the MetaMonitorInfo
struct to MetaLogicalMonitor. Eventually, part of MetaLogicalMonitor
will be split into a MetaMonitor type.
https://bugzilla.gnome.org/show_bug.cgi?id=777732
We might get modes in XRROutputInfos that aren't in the
XRRScreenResources we get earlier. This always seems to be transient,
i.e. when it happens, the X server will usually send us a follow up
RRScreenChangeNotify where we then get a "stable" view of the world
again.
In any case, when these glitches happen, we end up with NULL pointers
in the MetaOutput->modes array which makes us crash later on. This
patch ensures that doesn't happen.
https://bugzilla.gnome.org/show_bug.cgi?id=756660
We should not be setting random output properties like this.
Use the function we just introduced to only set the underscan flag when
it's actually supported.
So that clients such as the control center can decide to hide an
underscanning checkbutton when the output does not support it.
Support in the KMS / native backend to come later...
It seems that fglrx sometimes gives us absolute junk when requesting the
outputs, and if we don't trap errors, we'll just crash when trying to
configure a junk output. Use xcb so errors simply get ignored.
