Commit Graph

6 Commits

Author SHA1 Message Date
Jonas Ådahl
43eeb009ce monitor-config-migration: Discard if configured mode is missing
If a configuration key matched a current system state, but no monitor
mode was found (for example because of an incorrect refresh rate),
discard it while logging a warning.

https://bugzilla.gnome.org/show_bug.cgi?id=787668
2017-10-04 09:45:02 -04:00
Jonas Ådahl
ea4dbd14bc monitor-config: Keep track of disabled monitors for stored configs
When saving and restoring monitor configurations, we must take disabled
monitors into account, as otherwise one cannot store/restore a
configuration where one or more monitors are explicitly disabled. Make
this possible by adding a <disabled> element to the <configure> element
which lists the monitors that are explicitly disabled. These ones are
included when generating the configuration key, meaning they'll be
picked up correctly.

https://bugzilla.gnome.org/show_bug.cgi?id=787629
2017-10-02 15:34:24 -04:00
Rui Matos
ab541e3e0f monitor-config-migration: Fix a minor leak when parsing fails
https://bugzilla.gnome.org/show_bug.cgi?id=787477
2017-09-20 17:26:32 +08:00
Jonas Ådahl
96572fbe6a monitor-config-migration: Don't destroy autoptr:ed hash table
It'll be destroyed automatically, so don't do it manually as well.

https://bugzilla.gnome.org/show_bug.cgi?id=787477
2017-09-20 17:25:00 +08:00
Jonas Ådahl
4ab47e72e5 monitor-config-migration: Clean up properly when deriving
We cleaned up an unused monitor config list, but what we should do is
clear up the logical monitor config list. This commit does that, as
well as removes the unused monitor config list.
2017-09-20 17:24:49 +08:00
Jonas Ådahl
bc3162460f Migrate old monitor configuration files to new system
This commit changes the new configuration system to use monitors.xml
instead of monitors-experimental.xml. When starting up and the
monitors.xml file is loaded, if a legacy monitors.xml file is
discovered (it has the version number 1), an attempt is made to migrate
the stored configuration onto the new system.

This is done in two steps:

1) Parsing and translation of the old configuration. This works by
parsing file using the mostly the old parser, but then translating the
resulting configuration structs into the new configuration system. As
the legacy configuration system doesn't carry over some state (such as
tiling and scale used), some things are not available. For tiling, the
migration paths makes an attempt to discover tiled monitors by
comparing EDID data, and guessing what the main tile is. Determination
of the scale of a migrated configuration is postponed until the
configuration is actually applied. This works by flagging the
configuration as 'migrated'.

2) Finishing the migration when applying. When a configuration with the
'migrated' flag is retrieved from the configuration store, the final
step of the migration is taken place. This involves calculating the
preferred scale given the mode configured, while making sure this
doesn't result in any overlapping logical monitor regions etc.

https://bugzilla.gnome.org/show_bug.cgi?id=777732
2017-08-21 12:23:51 +08:00