Mutter's new display configuration API allows configurable per-monitor
scales within a finite set determined by mutter. We expose the
available values in a simple slider widget for each monitor.
https://bugzilla.gnome.org/show_bug.cgi?id=782785
The new API checks with mutter every time update_apply_button() is
called and mutter is very strict about this so it already does these
adjustments internally.
https://bugzilla.gnome.org/show_bug.cgi?id=782785
When setting the primary monitor off we were setting all other
monitors as non-primary which is clearly wrong. It only worked
correctly because the backend code in GnomeRR would implicitly
select a primary for us.
https://bugzilla.gnome.org/show_bug.cgi?id=782785
Use mutter's new display configuration API if it's available or
fallback to the old API via GnomeRR. The new API requires a new way to
identify outputs so we also need to use an alternative monitor labeler
API.
https://bugzilla.gnome.org/show_bug.cgi?id=782785
This removes the direct dependency on GnomeRR while keeping the
existing functionality.
All the tiled monitor special casing was removed since the new API
doesn't expose tiled monitors in the first place.
A check for virtual size limits was removed but it wasn't being
enforced anyway.
We also introduce a blank error state for when the backend API isn't
available.
https://bugzilla.gnome.org/show_bug.cgi?id=782785
We need to check the interlaced flag too when preselecting the current
resolution in the combo box since we now have separate entries for
interlaced and regular resolutions of the same size.
https://bugzilla.gnome.org/show_bug.cgi?id=772708
If no items are added to the GVariantBuilder, g_variant_builder_close()
would throw a critical, g_variant_builder_end() would throw a
segmentation fault.
As this can only happen when there are no items added to the output_ids
hashtable, this should only happen if there are no displays known to
libgnome-desktop (and therefore mutter).
See https://bugzilla.redhat.com/show_bug.cgi?id=1280075https://bugzilla.gnome.org/show_bug.cgi?id=771875
Adds a switch that allows to control overscan compensation, when the
driver supports it.
Based on a patch by Tomeu Vizoso <tomeu.vizoso@collabora.com>
https://bugzilla.gnome.org/show_bug.cgi?id=725135
When a mode has 2 very close refresh rates such as 59.94Hz and 60Hz,
most of the time, we'll want the 59.94Hz version.
Hide the "PC" 60Hz version and only show the 59.94Hz version in those
cases, and mark the frequency as "60Hz (ATSC)" so that those
knowledgeable know that it's really 59.94Hz, and doesn't confuse those
who expect rates to be multiple of 30Hz or 25Hz.
See also https://en.wikipedia.org/wiki/NTSC#Lines_and_refresh_rate
Note that we also do this for half and double that rate, eg. close to
~30Hz and ~120Hz.
https://bugzilla.gnome.org/show_bug.cgi?id=655041
There's really no point showing a resolution that's smaller than the
fixed width of the shell, and isn't the preferred resolution for the
screen either. This stops the problematic 720x576 resolution showing on
an HD screen.
Don't break out of loop if we weren't primary, as this
is stopping the user swapping back and forward between
primary and secondary with a tiled monitor.
i.e. user sets monitor to secondary and attempts to
go back to primary and it fails to move it.
https://bugzilla.gnome.org/show_bug.cgi?id=751680
This moves the two functions to the top of the file, changes the
get_geometry to return x/y if requested, and refactors the callers to
use it.
It also refactors some code that open coded the same basic code.
https://bugzilla.gnome.org/show_bug.cgi?id=750312
If there's an accelerometer builtin to the display, don't show the
rotation buttons, it will be handled by the user rotating the display,
eventually with the rotation lock in use.
https://bugzilla.gnome.org/show_bug.cgi?id=750410
We assume that the RR configuration is valid in various callbacks from
both our modal dialogs which doesn't hold if there's an hotplug while
a dialog is open (e.g. monitor is plugged/unplugged).
Closing the dialog in that case seems the right thing to do since it
would be operating on an outdated view of the world otherwise and
likely end up crashing.
https://bugzilla.gnome.org/show_bug.cgi?id=655041
GnomeRRMode is a boxed type which means that if stored as such in a
tree model, the model creates a copy to use internally. In addition,
it means that gtk_tree_model_get() will also get a copy which must be
freed by the caller which we were not doing.
In this case though, we don't need the copies since all the
GnomeRRModes that we use outlive the model so we can simplify things
by just storing a plain pointer in the model instead.
https://bugzilla.gnome.org/show_bug.cgi?id=655041
Otherwise we could fail to validate the new configuration depending on
which output we're initializing mirror mode from.
gnome_rr_config_applicable() creates a temporary array of outputs for
validation and, in clone mode, all of them are assigned the same
geometry but, since it lacks context about which output the user is
currently on, it just uses the first one's geometry for all of
them. If this first output isn't the one the user is changing in the
UI then we never called _set_geometry() on it with a clone mode
geometry and thus the validation would fail because the geometry used
is that output's current mode which might not match the clone mode's.
https://bugzilla.gnome.org/show_bug.cgi?id=743816
CcRRLabeler assumes an X11 session using override redirect toplevel
windows which are positioned in global desktop coordinates. Since this
isn't available on Wayland sessions, we're moving to a DBus API which
gnome-shell implements and works the same on both X11 an Wayland
sessions.
As side-effects, we get native looking gnome-shell OSD labels without
having to mimic the style ourselves and we're also now able to easily
show labels on mirrored setups.
https://bugzilla.gnome.org/show_bug.cgi?id=743743
When rotating a screen, the user has to first select the kind of
rotation and then press Apply. However, the meaning of the symbolic
icons may not be clear before actually pressing one of them.
This patch adds appropriate tooltips to the buttons so that the user has
a textual clue about what is going to happen.
https://bugzilla.gnome.org/show_bug.cgi?id=743888
This achieves a very similar result (darkening the background color)
without having to peek into the style context. Note that the stroke
is removed because it isn't really visible anyway.
https://bugzilla.gnome.org/show_bug.cgi?id=740986
When rotating the left-most monitor, we could end up with one
of two scenarios:
- Huge gap between monitor one and two when the left monitor is made
to be vertical
- Monitor two overlapping on top of monitor one when monitor is
back to being horizontal.
In addition to adding a bit more debug, we now take the old and new
rotation of monitor one into account when calculating the moving
screen edges.
https://bugzilla.gnome.org/show_bug.cgi?id=731166
Consider whether rotation has changed when checking whether
we need to relayout the screens. Before, we would only have changed the
layout if the resolution changed.
This doesn't fix the problem of the relayouting code not taking rotation
into account, but it will at least allow us to run that code when only
the rotation changes.
https://bugzilla.gnome.org/show_bug.cgi?id=731166
We create rotate_box only when show_rotation is TRUE, and the
conditions for checking the different kinds of rotation do not make
sense when show_rotation is FALSE.
https://bugzilla.gnome.org/show_bug.cgi?id=727023
