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
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
Instead of storing the logical monitors in an array and having users
either look up them in the array given an index or iterate using
indices, put it in a GList, and use GList iterators when iterating and
alternative API where array indices were previously used.
This allows for more liberty regarding the type of the logical monitor.
https://bugzilla.gnome.org/show_bug.cgi?id=777732
Refactor the tiled monitor assembly code (that constructs a logical
monitor out of tiling information. Part of the reason is to move away
from array based storage, part is to make the code easier to follow,
and part is to separate logical monitor construction from list
manipulation.
https://bugzilla.gnome.org/show_bug.cgi?id=777732
Change meta_monitor_manager_get_logical_monitor_at() to use floats,
replace users of meta_monitor_manager_get_monitor_at_point() to use the
API that returns a logical monitor and remove the now unused function.
https://bugzilla.gnome.org/show_bug.cgi?id=777732
Move the last piece of monitor grid getter API to the monitor manager
away from MetaScreen. The public facing API are still there, but are
thin wrappers around the MetaMonitorManager API.
https://bugzilla.gnome.org/show_bug.cgi?id=777732
Turning a rectangle into a logical monitor also has nothing to do with
the screen (MetaScreen) so move it to MetaMonitorManager which has that
information.
https://bugzilla.gnome.org/show_bug.cgi?id=777732
This is the current equivalent of looking up the logical monitor in the
logical monitor array using the number, but eventually that will be
deprecated, and before that done differently, so add a temporary helper
for the places that has not been ported yet.
https://bugzilla.gnome.org/show_bug.cgi?id=777732
It was just pointer to the actual list; having to synchronize a list of
logical monitors with the actual monitors managed by the backend is
unnecessary.
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
Being a listener to a signal, it is inconvenient to enforce order of
execution between different signal listeners. If there are things in
the backend that should be updated before various other signal
handlers, make sure so is done by emitting the signal after having
explicitly notified the backend.
https://bugzilla.gnome.org/show_bug.cgi?id=768976
Wrap the existing laptop_display_is_on() method in a public function
that gnome-shell can use to query whether a builtin output is present
and enabled.
https://bugzilla.gnome.org/show_bug.cgi?id=765267
The max potential number of logical monitors (i.e. MetaMonitorInfos)
is the number of CRTCs, not the number of outputs.
In cases where we have more enabled CRTCs than connected outputs we
would end up appending more MetaMonitorInfos to the GArray than the
size it was initialized with which means the array would get
re-allocated rendering invalid some MetaCRTC->logical_monitor pointers
assigned previously and thus ending in crashes later on.
https://bugzilla.gnome.org/show_bug.cgi?id=751638
Some monitors return a bunch of bytes on their display descriptor
which aren't valid utf8 and thus we fail to serialize them later on
for the DisplayConfig DBus API.
Let's fall back to the stringified product code and serial number in
that case.
https://bugzilla.gnome.org/show_bug.cgi?id=752673
Tracking back from the monitor to the output every time we need to
figure out the scale of a window on a monitor is inconvenient, so
propagate the scale from the output to the monitor it is associated
with.
https://bugzilla.gnome.org/show_bug.cgi?id=744934
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...
The monitors info structure is created from the tiled outputs
and this is used as the central storage for info about a monitor
as opposed to the output state.
It appears at least the EDID mm w/h is for the whole monitor and
not per tile.
Some DRM drivers have added a consistent set of properties that
allow compensating for the overscan that some TVs do, without the
user being able to disable.
This function returns the monitor_info index corresponding to the given
coordinates, or -1 if none is found at that point. The native backend
has been changed in places where it could make use of this function.
https://bugzilla.gnome.org/show_bug.cgi?id=746896
This just exposes the type and the singleton getter necessary to make
it available to introspection. We'll expose more functionality as it
becomes needed.
https://bugzilla.gnome.org/show_bug.cgi?id=743745
EDID parsing has been refactored to a common meta_output_parse_edid()
function, which ensures the extracted information is the same on both KMS
and X11 backend, so it can be used consistently on eg. settings values.
https://bugzilla.gnome.org/show_bug.cgi?id=742882
It turns out that this was wrong because MetaWindow->monitor points to
the old monitor infos and they are needed to position windows in the
new configuration which happens in a monitors-changed handler.
This reverts commit e1704acda4.
We overrode the property for PowerSaveMode, which meant that gdbus's
auto-generated PropertiesChanged code wasn't being run.
This really confused gnome-rr and gnome-settings-daemon's power plugin
about the current DPMS state of the display, since they used their
cached PowerSaveMode properties, and never saw a PropertiesChanged being
emitted.
If a display was on, they set it to off, and then set it back on, the
setting back on would never fire, since they thought the display was
already off.
To fix this, remove our custom property override and just respond to
notifications on the object.
Namely, this fixes the DPMS management when receiving notifications so
that it now properly times out.
The output_id is more of an opaque identifier for the monitor, based on
its underlying ID from the windowing system. Since we also use the term
"output_id" for the output's index, rename our use of the opaque cookie
"output_id" to "winsys_id".
A gulong is not enough to get 64 bits in all arches, so we must
cast it, or we can corrupt the stack.
This was downstream bug bugzilla.redhat.com/show_bug.cgi?id=1002055
https://bugzilla.gnome.org/show_bug.cgi?id=707267
Right now this just has all of the files in one directory. We'll
be introducing more structure to this in the future, and build
a proper backend system.
