Ignacy Gawędzki authored Nov 16, 2017 and Alberts Muktupāvels committed May 21, 2018

When adding layout info to the hash table, directly assign it to a
group, instead of iterating on the layouts afterwards.

Skip layout if it is already contained in the hashmap.

Signed-off-by: Ignacy Gawędzki <bugs@qult.net>
Signed-off-by: Sebastian Geiger <sbastig@gmx.net>

Ignacy Gawędzki authored May 15, 2018 and Alberts Muktupāvels committed May 16, 2018

Just like 63163777 introduced the same
bug as in Mutter, this needs to be fixed the same way as:
mutter@5ad34e0e



Signed-off-by: Ignacy Gawędzki <bugs@qult.net>
Signed-off-by: Ignacy Gawędzki <ignacy.gawedzki@green-communications.fr>

https://bugzilla.gnome.org/show_bug.cgi?id=794234

The “org.gnome.SettingsDaemon.A11yKeyboard” has been removed:
https://git.gnome.org/browse/gnome-settings-daemon/commit/?id=9553071d0c26

Balázs Meskó authored Jan 25, 2018 and Administrator committed Jan 25, 2018

(cherry picked from commit d1c89963)

Based on mutter commit:
mutter@cfee5879

Based on mutter commit:
mutter@e0d839ae

Based on mutter commit:
mutter@2b3040d0

Based on mutter commit:
mutter@2db55052

Based on mutter commit:
mutter@f64fab1d

Based on mutter commit:
mutter@903537a2

Hans de Goede authored Jan 21, 2018 and Alberts Muktupāvels committed Jan 24, 2018

Using 800x600 as minimum logical size is very 4:3 thinking, while a lot of
modern devices are 16:9. The specific reason for this commit is to allow
1.5 scaling at mini-laptops (clamshell devices) with e.g. a 5.5"
1280x720 screen. Given that this device has a keyboard, one obviously
is not holding it very close to ones eyes and at 220 dpi that means the text
is too small at scale 1.0. For one real world example of such a device see:
https://en.wikipedia.org/wiki/GPD_Win

https://bugzilla.gnome.org/show_bug.cgi?id=792765

Based on mutter commit:
mutter@1db93782

Based on mutter commit:
mutter@9817a6aa

nautilus-desktop has been removed:
nautilus@6584c178

It was removed from gnome-suites-core-deps-3.28.modules:
https://git.gnome.org/browse/jhbuild/commit/?id=c7a7be34b2a9783f22a7cb33f97f66dab1b9fa2b

Jonas Ådahl authored Nov 03, 2017 and Alberts Muktupāvels committed Dec 04, 2017

We only counted configured monitors and whether the config was
applicable (could be assigned), howeverwe didn't include disabled
monitors when comparing. This could caused incorrect configurations to
be applied when trying to use the previous configuration.

One scenario where this happened was one a system with one laptop
screen and one external monitor that was hot plugged some point after
start up. When the laptop lid was closed, the 'previous configuration'
being the configuration where only the laptop panel was enabled, passed
'is-complete' check as the number of configured monitors were correct,
and the configuration was applicable.

Avoid this issue by simply comparing the configuration key of the
previous configuration and the configuration key of the current state.
This correctly identifies a laptop panel with the lid closed as
inaccessible, thus doesn't incorrectly revert to the previous
configuration.

https://bugzilla.gnome.org/show_bug.cgi?id=788915

Jonas Ådahl authored Nov 03, 2017 and Alberts Muktupāvels committed Dec 04, 2017

When deriving the list of disabled monitors when creating new monitors
configs, don't include the laptop panel if the lid is currently closed,
as we consider the laptop panel nonexistent when the laptop lid is
closed when it comes to configuration.

The laptop panel connector(s) will either way be appropriately disabled
anyway, as the field listing disabled monitors in the configuration do
not affect actual CRTC/connector assignments.

https://bugzilla.gnome.org/show_bug.cgi?id=788915

Rui Matos authored Nov 14, 2017 and Alberts Muktupāvels committed Nov 29, 2017

There's no good reason to allow this and it allows g-c-c to properly
show that such a configuration doesn't work.

https://bugzilla.gnome.org/show_bug.cgi?id=790336

Carlos Garnacho authored Oct 27, 2017 and Alberts Muktupāvels committed Nov 06, 2017

Those are being leaked.

https://bugzilla.gnome.org/show_bug.cgi?id=789553

Jonas Ådahl authored Oct 18, 2017 and Alberts Muktupāvels committed Oct 20, 2017

When generating GfMonitorMode's, prefer CRTC modes that has the same
set of flags as the preferred mode. This not only is probably a better
set of configurable modes, but it'll guarantee that the preferred mode
is added.

This fixes a crash when the preferred mode was not the first mode with
the same resolution, refresh rate and set of handled modes.

https://bugzilla.gnome.org/show_bug.cgi?id=789153

Marco Trevisan authored Oct 19, 2017 and Alberts Muktupāvels committed Oct 20, 2017

https://bugzilla.gnome.org/show_bug.cgi?id=789227