We don't get notifications from X11 when the mode is reset, so
our cached value can get stale. To work around that, always forward
requests to the backend (and let it deal with ignoring the change
if wanted)
https://bugzilla.gnome.org/show_bug.cgi?id=707649
If, checking the event timestamps, we see that a new configuration
was explicitly requested by an another XRandR client, don't proceed to
apply the intended configuration again, even if looking at the
EDIDs it appears that the outputs changed.
This works around some buggy Xorg drivers (qxl, vbox) that generate
a new serial number everytime the user resizes the host window.
https://bugzilla.gnome.org/show_bug.cgi?id=706735
Using out-of-band notifications from the wayland protocol or from
X is racy, in that the client could ask for the new resources before
we have them.
Instead, with a signal, we are sure that when the client asks for
it, it will get the right values.
https://bugzilla.gnome.org/show_bug.cgi?id=706382
Add "edid-file", if we have one (in the KMS case, where we can point
people to the right sysfs file), or "edid" with inline data.
These are needed by colord to build the default ICC profile for
uncalibrated displays.
https://bugzilla.gnome.org/show_bug.cgi?id=705670
Instead of keeping a forest of if backend else ..., use a subclass
and virtual functions to discriminate between XRandR and the
dummy backend (which lives in the parent class togheter with the
common code)
https://bugzilla.gnome.org/show_bug.cgi?id=705670
We want to show a dialog when a display change happens from the
control center. To do so, add a new vfunc to MetaPlugin and
call it when a configuration change is requested via DBus.
https://bugzilla.gnome.org/show_bug.cgi?id=705670
Add GetCrtcGamma() and SetCrtcGamma(), that wrap the similarly
named XRandR API. These are used by GnomeRR inside the color
plugin of the control center (and may go away if the color
plugin decides to do something different under wayland)
https://bugzilla.gnome.org/show_bug.cgi?id=705670
GnomeRR needs that too.
The backlight is exported as a normalized 0-100 value, or -1 if not
supported. Clamping to HW limits is handled by the backend.
Changing backlight uses a different method call, to avoid recomputing
the full display configuration every time the user presses the
backlight keys.
https://bugzilla.gnome.org/show_bug.cgi?id=705670
The default configuration is extended, which is only possible
if there are as many CRTCs as outputs, so make sure that's true.
Also, add more and bigger modes, so that different sizes will
be chosen for the three outputs.
A nice side effect of this is that with a real 1920x1080 + 1600x900
layout, if you disable the VGA you get a stage that matches the
screen size, which triggers the legacy fullscreen path in the
outside mutter.
https://bugzilla.gnome.org/show_bug.cgi?id=705670
Use a private output property to store if the output is in
presentation mode or not, so that this information is not lost
after the configuration read back from the server.
https://bugzilla.gnome.org/show_bug.cgi?id=705670
Ripped off libgnome-desktop, trimming the parts that checked
that the configuration was plausible, as that should be done
in gnome-control-center before asking mutter for a change.
https://bugzilla.gnome.org/show_bug.cgi?id=705670
Add a new object, MetaMonitorConfig, that takes care of converting
between the logical configurations stored in monitors.xml and
the HW resources exposed by MonitorManager.
This commit includes loading and saving of configurations, but
still missing is the actual CRTC assignments and a default
configuration when none is found in the file.
https://bugzilla.gnome.org/show_bug.cgi?id=705670
Read the current transform from XRandR, and expose the transforms
that are really supported on the bus.
The dummy backend now advertises all transforms, since it doesn't
actually apply them.
https://bugzilla.gnome.org/show_bug.cgi?id=705670
Add a number of dummy outputs and modes to the dummy backend,
and implement the writing bits.
The only visible effect is that you can change the screen size,
which resizes the output window.
https://bugzilla.gnome.org/show_bug.cgi?id=705670
Now MonitorManager does its own handling of XRandR events, which
means we no longer handle ConfigureNotify on the root window.
MetaScreen reacts to MonitorManager::monitor-changed and updates
its internal state, including the new size.
This paves the way for doing display configuration using only
the dummy backend, which would allow testing wl_output interfaces.
https://bugzilla.gnome.org/show_bug.cgi?id=705670
Implement ApplyConfiguration in terms of XRandR calls.
Error checking is done before actually committing the configuration.
If mutter is using one of the other monitor config backends, an
error is reported and nothing happens.
https://bugzilla.gnome.org/show_bug.cgi?id=705670
Turns out that even if two outputs say that they can be controlled
by a given CRTC, you can't configure them in the same CRTC unless
they are marked as "possible clones" one of the other.
This can further restrict the configuration options, so we need
to expose this limitation in the DBus API.
https://bugzilla.gnome.org/show_bug.cgi?id=705670
This new interface will be used by the control center and possibly
the settings daemon to configure the screens. It is designed to
resemble a simplified XRandR, while still exposing all the quirks
of the hardware, so that the panel can limit the user choices
appropriately.
To do so, MetaMonitorMode needs to track CRTCs, outputs and modes,
so the low level objects have been decoupled from the high-level
MetaMonitorInfo, which is used by core and API and offers a simplified
view of HW, that hides away the details of what is cloned and how.
This is still not efficient as it should be, because on every
HW change we drop all data structures and rebuild them from scratch
(which is not expensive because there aren't many of them, but
at least in the XRandR path it involves a few sync X calls)
https://bugzilla.gnome.org/show_bug.cgi?id=705670
Consolidate all places that deal with output configuration in
MetaScreen, which gets it either from XRandR or from a dummy static configuration.
We still need to read the Xinerama config, even when running xwayland,
because we need the indices for _NET_WM_FULLSCREEN_MONITORS, but
now we do it only when needed.
https://bugzilla.gnome.org/show_bug.cgi?id=705670
