isa/mutter
1
0
Fork 0
mirror of https://github.com/brl/mutter.git synced 2024-11-28 02:50:41 -05:00
Code Issues Packages Projects Releases Wiki Activity
0aa4bab539
mutter/src/backends/meta-monitor-config-migration.h

42 lines
1.7 KiB
C
Raw Normal View History

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-10 03:12:41 -04:00
/* -*- mode: C; c-file-style: "gnu"; indent-tabs-mode: nil; -*- */
/*
* Copyright (C) 2017 Red Hat
*
* This program is free software; you can redistribute it and/or
* modify it under the terms of the GNU General Public License as
* published by the Free Software Foundation; either version 2 of the
* License, or (at your option) any later version.
*
* This program is distributed in the hope that it will be useful, but
* WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
* General Public License for more details.
*
* You should have received a copy of the GNU General Public License
* along with this program; if not, write to the Free Software
* Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA
* 02111-1307, USA.
*/
#ifndef META_MONITOR_CONFIG_MIGRATION_H
#define META_MONITOR_CONFIG_MIGRATION_H
#include "backends/meta-monitor-manager-private.h"
meta: Hide libmutter symbols by default and selectively export them Make meson link libmutter using -fvisibility=hidden, and introduce META_EXPORT and META_EXPORT_TEST defines to mark a symbols as visible. The TEST version is meant to be used to flag symbols that are only used internally by mutter tests, but that should not be considered public API. This allows us to be more precise in selecting what is exported and what is not, without the need of a version-script file that would be more complicated to maintain. https://gitlab.gnome.org/GNOME/mutter/merge_requests/395
2019-01-22 21:25:35 -05:00
META_EXPORT_TEST
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-10 03:12:41 -04:00
gboolean meta_migrate_old_monitors_config (MetaMonitorConfigStore *config_store,
GFile *in_file,
GError **error);
meta: Hide libmutter symbols by default and selectively export them Make meson link libmutter using -fvisibility=hidden, and introduce META_EXPORT and META_EXPORT_TEST defines to mark a symbols as visible. The TEST version is meant to be used to flag symbols that are only used internally by mutter tests, but that should not be considered public API. This allows us to be more precise in selecting what is exported and what is not, without the need of a version-script file that would be more complicated to maintain. https://gitlab.gnome.org/GNOME/mutter/merge_requests/395
2019-01-22 21:25:35 -05:00
META_EXPORT_TEST
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-10 03:12:41 -04:00
gboolean meta_migrate_old_user_monitors_config (MetaMonitorConfigStore *config_store,
GError **error);
meta: Hide libmutter symbols by default and selectively export them Make meson link libmutter using -fvisibility=hidden, and introduce META_EXPORT and META_EXPORT_TEST defines to mark a symbols as visible. The TEST version is meant to be used to flag symbols that are only used internally by mutter tests, but that should not be considered public API. This allows us to be more precise in selecting what is exported and what is not, without the need of a version-script file that would be more complicated to maintain. https://gitlab.gnome.org/GNOME/mutter/merge_requests/395
2019-01-22 21:25:35 -05:00
META_EXPORT_TEST
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-10 03:12:41 -04:00
gboolean meta_finish_monitors_config_migration (MetaMonitorManager *monitor_manager,
MetaMonitorsConfig *config,
GError **error);
#endif /* META_MONITOR_CONFIG_MIGRATION_H */
Reference in New Issue Copy Permalink