isa/mutter
1
0
Fork 0
mirror of https://github.com/brl/mutter.git synced 2024-11-24 17:10:40 -05:00
Code Issues Packages Projects Releases Wiki Activity
6584d06bb5
mutter/src/backends/meta-monitor-config-manager.h

149 lines
6.1 KiB
C
Raw Normal View History

Introduce new monitor configuration system The new monitor configuration system (MetaMonitorConfigManager) aims to replace the current MetaMonitorConfig. The main difference between the two is that MetaMonitorConfigManager works with higher level input (MetaMonitor, MetaMonitorMode) instead of directly looking at the CRTC and connector state. It still produces CRTC and connector configuration later applied by the respective backends. Other difference the new system aims to introduce is that the configuration system doesn't manipulate the monitor manager state; that responsibility is left for the monitor manager to handle (it only manages configuration and creates CRTC/connector assignments, it doesn't apply anything). The new configuration system allows backends to not rely on deriving the current configuration from the CRTC/connector state, as this may no longer be possible (i.e. when using KMS and multiple framebuffers). The MetaMonitorConfigManager system is so far disabled by default, as it does not yet have all the features of the old system, but eventually it will replace MetaMonitorConfig which will at that point be removed. This will make it possible to remove old hacks introduced due to limitations in the old system. https://bugzilla.gnome.org/show_bug.cgi?id=777732
2017-01-09 01:31:18 -05:00
/* -*- mode: C; c-file-style: "gnu"; indent-tabs-mode: nil; -*- */
/*
* Copyright (C) 2016 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_MANAGER_H
#define META_MONITOR_CONFIG_MANAGER_H
#include "backends/meta-monitor.h"
#include "backends/meta-monitor-manager-private.h"
#define META_TYPE_MONITOR_CONFIG_MANAGER (meta_monitor_config_manager_get_type ())
G_DECLARE_FINAL_TYPE (MetaMonitorConfigManager, meta_monitor_config_manager,
META, MONITOR_CONFIG_MANAGER, GObject)
typedef struct _MetaMonitorConfig
{
MetaMonitorSpec *monitor_spec;
MetaMonitorModeSpec *mode_spec;
MetaMonitorConfig: Rename is_underscanning to enable_underscanning Use better terminology to imply that the configuration enables underscanning, not what already "is". https://bugzilla.gnome.org/show_bug.cgi?id=777732
2017-02-14 05:19:09 -05:00
gboolean enable_underscanning;
Introduce new monitor configuration system The new monitor configuration system (MetaMonitorConfigManager) aims to replace the current MetaMonitorConfig. The main difference between the two is that MetaMonitorConfigManager works with higher level input (MetaMonitor, MetaMonitorMode) instead of directly looking at the CRTC and connector state. It still produces CRTC and connector configuration later applied by the respective backends. Other difference the new system aims to introduce is that the configuration system doesn't manipulate the monitor manager state; that responsibility is left for the monitor manager to handle (it only manages configuration and creates CRTC/connector assignments, it doesn't apply anything). The new configuration system allows backends to not rely on deriving the current configuration from the CRTC/connector state, as this may no longer be possible (i.e. when using KMS and multiple framebuffers). The MetaMonitorConfigManager system is so far disabled by default, as it does not yet have all the features of the old system, but eventually it will replace MetaMonitorConfig which will at that point be removed. This will make it possible to remove old hacks introduced due to limitations in the old system. https://bugzilla.gnome.org/show_bug.cgi?id=777732
2017-01-09 01:31:18 -05:00
} MetaMonitorConfig;
typedef struct _MetaLogicalMonitorConfig
{
MetaRectangle layout;
GList *monitor_configs;
monitor-config-manager: Support logical monitor transforms Add support for rotated monitors. This is done per logical monitor, as every monitor assigned to a logical monitor must be transformed in the same way. This includes being transformed on the same level; e.g. if the backend does not support transforming any monitor of a logical monitor natively, then all monitors will be transformed using the offscreen intermediate framebuffer. https://bugzilla.gnome.org/show_bug.cgi?id=777732
2017-03-21 02:17:18 -04:00
MetaMonitorTransform transform;
logical-monitor: Make scale a float To support fractional scaling, the logical monitor scale must be stored as a float. No other functional changes is part of this commit. https://bugzilla.gnome.org/show_bug.cgi?id=765011
2017-05-25 04:12:51 -04:00
float scale;
Introduce new monitor configuration system The new monitor configuration system (MetaMonitorConfigManager) aims to replace the current MetaMonitorConfig. The main difference between the two is that MetaMonitorConfigManager works with higher level input (MetaMonitor, MetaMonitorMode) instead of directly looking at the CRTC and connector state. It still produces CRTC and connector configuration later applied by the respective backends. Other difference the new system aims to introduce is that the configuration system doesn't manipulate the monitor manager state; that responsibility is left for the monitor manager to handle (it only manages configuration and creates CRTC/connector assignments, it doesn't apply anything). The new configuration system allows backends to not rely on deriving the current configuration from the CRTC/connector state, as this may no longer be possible (i.e. when using KMS and multiple framebuffers). The MetaMonitorConfigManager system is so far disabled by default, as it does not yet have all the features of the old system, but eventually it will replace MetaMonitorConfig which will at that point be removed. This will make it possible to remove old hacks introduced due to limitations in the old system. https://bugzilla.gnome.org/show_bug.cgi?id=777732
2017-01-09 01:31:18 -05:00
gboolean is_primary;
gboolean is_presentation;
} MetaLogicalMonitorConfig;
Introduce MetaMonitorConfigStore MetaMonitorConfigStore provides an XML storage mechanism for MetaMonitorConfigManager. It stores configuration files defined in the same level as the MetaMonitorsConfig format, i.e. refers to high level "monitors" and "monitor modes" instead of connectors and CRTCs. Only reading custom files are implemented and so far unused. https://bugzilla.gnome.org/show_bug.cgi?id=777732
2017-01-12 03:13:48 -05:00
typedef struct _MetaMonitorsConfigKey
{
GList *monitor_specs;
} MetaMonitorsConfigKey;
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
typedef enum _MetaMonitorsConfigFlag
{
META_MONITORS_CONFIG_FLAG_NONE = 0,
META_MONITORS_CONFIG_FLAG_MIGRATED = (1 << 0),
} MetaMonitorsConfigFlag;
Introduce new monitor configuration system The new monitor configuration system (MetaMonitorConfigManager) aims to replace the current MetaMonitorConfig. The main difference between the two is that MetaMonitorConfigManager works with higher level input (MetaMonitor, MetaMonitorMode) instead of directly looking at the CRTC and connector state. It still produces CRTC and connector configuration later applied by the respective backends. Other difference the new system aims to introduce is that the configuration system doesn't manipulate the monitor manager state; that responsibility is left for the monitor manager to handle (it only manages configuration and creates CRTC/connector assignments, it doesn't apply anything). The new configuration system allows backends to not rely on deriving the current configuration from the CRTC/connector state, as this may no longer be possible (i.e. when using KMS and multiple framebuffers). The MetaMonitorConfigManager system is so far disabled by default, as it does not yet have all the features of the old system, but eventually it will replace MetaMonitorConfig which will at that point be removed. This will make it possible to remove old hacks introduced due to limitations in the old system. https://bugzilla.gnome.org/show_bug.cgi?id=777732
2017-01-09 01:31:18 -05:00
struct _MetaMonitorsConfig
{
GObject parent;
Introduce MetaMonitorConfigStore MetaMonitorConfigStore provides an XML storage mechanism for MetaMonitorConfigManager. It stores configuration files defined in the same level as the MetaMonitorsConfig format, i.e. refers to high level "monitors" and "monitor modes" instead of connectors and CRTCs. Only reading custom files are implemented and so far unused. https://bugzilla.gnome.org/show_bug.cgi?id=777732
2017-01-12 03:13:48 -05:00
MetaMonitorsConfigKey *key;
Introduce new monitor configuration system The new monitor configuration system (MetaMonitorConfigManager) aims to replace the current MetaMonitorConfig. The main difference between the two is that MetaMonitorConfigManager works with higher level input (MetaMonitor, MetaMonitorMode) instead of directly looking at the CRTC and connector state. It still produces CRTC and connector configuration later applied by the respective backends. Other difference the new system aims to introduce is that the configuration system doesn't manipulate the monitor manager state; that responsibility is left for the monitor manager to handle (it only manages configuration and creates CRTC/connector assignments, it doesn't apply anything). The new configuration system allows backends to not rely on deriving the current configuration from the CRTC/connector state, as this may no longer be possible (i.e. when using KMS and multiple framebuffers). The MetaMonitorConfigManager system is so far disabled by default, as it does not yet have all the features of the old system, but eventually it will replace MetaMonitorConfig which will at that point be removed. This will make it possible to remove old hacks introduced due to limitations in the old system. https://bugzilla.gnome.org/show_bug.cgi?id=777732
2017-01-09 01:31:18 -05:00
GList *logical_monitor_configs;
Add support for scaled logical monitor framebuffers This commit adds support for rendering onto enlarged per logical monitor framebuffers, using the scaled clutter stage views, for HiDPI enabled logical monitors. This works by scaling the mode of the monitors in a logical monitors by the scale, no longer relying on scaling the window actors and window geometry for making windows have the correct size on HiDPI monitors. It is disabled by default, as in automatically created configurations will still use the old mode. This is partly because Xwayland clients will not yet work good enough to make it feasible. To enable, add the 'scale-monitor-framebuffer' keyword to the org.gnome.mutter.experimental-features gsettings array. It is still possible to specify the mode via the new D-Bus API, which has been adapted. The adaptations to the D-Bus API means the caller need to be aware of how to position logical monitors on the stage grid. This depends on the 'layout-mode' property that is used (see the DisplayConfig D-Bus documentation). https://bugzilla.gnome.org/show_bug.cgi?id=777732
2017-02-24 05:10:52 -05:00
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
MetaMonitorsConfigFlag flags;
Add support for scaled logical monitor framebuffers This commit adds support for rendering onto enlarged per logical monitor framebuffers, using the scaled clutter stage views, for HiDPI enabled logical monitors. This works by scaling the mode of the monitors in a logical monitors by the scale, no longer relying on scaling the window actors and window geometry for making windows have the correct size on HiDPI monitors. It is disabled by default, as in automatically created configurations will still use the old mode. This is partly because Xwayland clients will not yet work good enough to make it feasible. To enable, add the 'scale-monitor-framebuffer' keyword to the org.gnome.mutter.experimental-features gsettings array. It is still possible to specify the mode via the new D-Bus API, which has been adapted. The adaptations to the D-Bus API means the caller need to be aware of how to position logical monitors on the stage grid. This depends on the 'layout-mode' property that is used (see the DisplayConfig D-Bus documentation). https://bugzilla.gnome.org/show_bug.cgi?id=777732
2017-02-24 05:10:52 -05:00
MetaLogicalMonitorLayoutMode layout_mode;
Introduce new monitor configuration system The new monitor configuration system (MetaMonitorConfigManager) aims to replace the current MetaMonitorConfig. The main difference between the two is that MetaMonitorConfigManager works with higher level input (MetaMonitor, MetaMonitorMode) instead of directly looking at the CRTC and connector state. It still produces CRTC and connector configuration later applied by the respective backends. Other difference the new system aims to introduce is that the configuration system doesn't manipulate the monitor manager state; that responsibility is left for the monitor manager to handle (it only manages configuration and creates CRTC/connector assignments, it doesn't apply anything). The new configuration system allows backends to not rely on deriving the current configuration from the CRTC/connector state, as this may no longer be possible (i.e. when using KMS and multiple framebuffers). The MetaMonitorConfigManager system is so far disabled by default, as it does not yet have all the features of the old system, but eventually it will replace MetaMonitorConfig which will at that point be removed. This will make it possible to remove old hacks introduced due to limitations in the old system. https://bugzilla.gnome.org/show_bug.cgi?id=777732
2017-01-09 01:31:18 -05:00
};
#define META_TYPE_MONITORS_CONFIG (meta_monitors_config_get_type ())
G_DECLARE_FINAL_TYPE (MetaMonitorsConfig, meta_monitors_config,
META, MONITORS_CONFIG, GObject)
MetaMonitorConfigManager * meta_monitor_config_manager_new (MetaMonitorManager *monitor_manager);
Introduce MetaMonitorConfigStore MetaMonitorConfigStore provides an XML storage mechanism for MetaMonitorConfigManager. It stores configuration files defined in the same level as the MetaMonitorsConfig format, i.e. refers to high level "monitors" and "monitor modes" instead of connectors and CRTCs. Only reading custom files are implemented and so far unused. https://bugzilla.gnome.org/show_bug.cgi?id=777732
2017-01-12 03:13:48 -05:00
MetaMonitorConfigStore * meta_monitor_config_manager_get_store (MetaMonitorConfigManager *config_manager);
Introduce new monitor configuration system The new monitor configuration system (MetaMonitorConfigManager) aims to replace the current MetaMonitorConfig. The main difference between the two is that MetaMonitorConfigManager works with higher level input (MetaMonitor, MetaMonitorMode) instead of directly looking at the CRTC and connector state. It still produces CRTC and connector configuration later applied by the respective backends. Other difference the new system aims to introduce is that the configuration system doesn't manipulate the monitor manager state; that responsibility is left for the monitor manager to handle (it only manages configuration and creates CRTC/connector assignments, it doesn't apply anything). The new configuration system allows backends to not rely on deriving the current configuration from the CRTC/connector state, as this may no longer be possible (i.e. when using KMS and multiple framebuffers). The MetaMonitorConfigManager system is so far disabled by default, as it does not yet have all the features of the old system, but eventually it will replace MetaMonitorConfig which will at that point be removed. This will make it possible to remove old hacks introduced due to limitations in the old system. https://bugzilla.gnome.org/show_bug.cgi?id=777732
2017-01-09 01:31:18 -05:00
gboolean meta_monitor_config_manager_assign (MetaMonitorManager *manager,
MetaMonitorsConfig *config,
GPtrArray **crtc_infos,
GPtrArray **output_infos,
GError **error);
monitor-config-manager: Prefer to use stored config If not explicitly set by the backend, prefer to use the stored config instead of creating a new one, if available. https://bugzilla.gnome.org/show_bug.cgi?id=777732
2017-01-12 22:01:27 -05:00
MetaMonitorsConfig * meta_monitor_config_manager_get_stored (MetaMonitorConfigManager *config_manager);
Introduce new monitor configuration system The new monitor configuration system (MetaMonitorConfigManager) aims to replace the current MetaMonitorConfig. The main difference between the two is that MetaMonitorConfigManager works with higher level input (MetaMonitor, MetaMonitorMode) instead of directly looking at the CRTC and connector state. It still produces CRTC and connector configuration later applied by the respective backends. Other difference the new system aims to introduce is that the configuration system doesn't manipulate the monitor manager state; that responsibility is left for the monitor manager to handle (it only manages configuration and creates CRTC/connector assignments, it doesn't apply anything). The new configuration system allows backends to not rely on deriving the current configuration from the CRTC/connector state, as this may no longer be possible (i.e. when using KMS and multiple framebuffers). The MetaMonitorConfigManager system is so far disabled by default, as it does not yet have all the features of the old system, but eventually it will replace MetaMonitorConfig which will at that point be removed. This will make it possible to remove old hacks introduced due to limitations in the old system. https://bugzilla.gnome.org/show_bug.cgi?id=777732
2017-01-09 01:31:18 -05:00
MetaMonitorsConfig * meta_monitor_config_manager_create_linear (MetaMonitorConfigManager *config_manager);
MetaMonitorsConfig * meta_monitor_config_manager_create_fallback (MetaMonitorConfigManager *config_manager);
monitor-config-manager: Add support for suggested configuration Create a suggested configuration, if such configuration is provided. https://bugzilla.gnome.org/show_bug.cgi?id=777732
2017-01-09 02:38:17 -05:00
MetaMonitorsConfig * meta_monitor_config_manager_create_suggested (MetaMonitorConfigManager *config_manager);
monitor-config-manager: Add API to rotate the current config This will allow us to do automatic rotation of the builtin display if that's the only active monitor. https://bugzilla.gnome.org/show_bug.cgi?id=781906
2017-04-28 11:56:18 -04:00
MetaMonitorsConfig * meta_monitor_config_manager_create_for_orientation (MetaMonitorConfigManager *config_manager,
MetaMonitorTransform transform);
MetaMonitorsConfig * meta_monitor_config_manager_create_for_rotate_monitor (MetaMonitorConfigManager *config_manager);
backends: Add API to switch to predetermined monitor configurations This will allows us to support the XF86Display key present on some laptops, directly in mutter. This is also known, in evdev, as KEY_SWITCHVIDEOMODE. The common usage for this key is to alternate between a few well known multi-monitor configurations though these aren't officially standardized. As an example, Lenovo documents it as: "Switches the display output location between the computer display and an external monitor." On this patch, we're just introducing the configurations that have been implemented in g-s-d until now, which go a bit beyond the above description. https://bugzilla.gnome.org/show_bug.cgi?id=781906
2017-06-07 12:38:10 -04:00
MetaMonitorsConfig * meta_monitor_config_manager_create_for_switch_config (MetaMonitorConfigManager *config_manager,
MetaMonitorSwitchConfigType config_type);
Introduce new monitor configuration system The new monitor configuration system (MetaMonitorConfigManager) aims to replace the current MetaMonitorConfig. The main difference between the two is that MetaMonitorConfigManager works with higher level input (MetaMonitor, MetaMonitorMode) instead of directly looking at the CRTC and connector state. It still produces CRTC and connector configuration later applied by the respective backends. Other difference the new system aims to introduce is that the configuration system doesn't manipulate the monitor manager state; that responsibility is left for the monitor manager to handle (it only manages configuration and creates CRTC/connector assignments, it doesn't apply anything). The new configuration system allows backends to not rely on deriving the current configuration from the CRTC/connector state, as this may no longer be possible (i.e. when using KMS and multiple framebuffers). The MetaMonitorConfigManager system is so far disabled by default, as it does not yet have all the features of the old system, but eventually it will replace MetaMonitorConfig which will at that point be removed. This will make it possible to remove old hacks introduced due to limitations in the old system. https://bugzilla.gnome.org/show_bug.cgi?id=777732
2017-01-09 01:31:18 -05:00
void meta_monitor_config_manager_set_current (MetaMonitorConfigManager *config_manager,
MetaMonitorsConfig *config);
MetaMonitorsConfig * meta_monitor_config_manager_get_current (MetaMonitorConfigManager *config_manager);
monitor-config-manager: Keep short history of configurations In order to go back in monitor configurations, save them to a history. The history is implemented as a max 3 element long queue, where newly set configurations are pushed to the head, and old are popped from the tail. The difference between using a single previous config reference and a queue is that we can now remember the configuration used prior to a D-Bus triggered configuration when the user discarded the configuration. This will later be used to restore a previous configuration when a laptop lid is opened. https://bugzilla.gnome.org/show_bug.cgi?id=777732
2017-08-11 03:16:15 -04:00
MetaMonitorsConfig * meta_monitor_config_manager_pop_previous (MetaMonitorConfigManager *config_manager);
monitor-manager: Hook up config manager to display config confirmation Make it possible to confirm or cancel the new configuration also when the new API is used. https://bugzilla.gnome.org/show_bug.cgi?id=777732
2017-03-23 05:20:07 -04:00
MetaMonitorsConfig * meta_monitor_config_manager_get_previous (MetaMonitorConfigManager *config_manager);
monitor-config-manager: Keep short history of configurations In order to go back in monitor configurations, save them to a history. The history is implemented as a max 3 element long queue, where newly set configurations are pushed to the head, and old are popped from the tail. The difference between using a single previous config reference and a queue is that we can now remember the configuration used prior to a D-Bus triggered configuration when the user discarded the configuration. This will later be used to restore a previous configuration when a laptop lid is opened. https://bugzilla.gnome.org/show_bug.cgi?id=777732
2017-08-11 03:16:15 -04:00
void meta_monitor_config_manager_clear_history (MetaMonitorConfigManager *config_manager);
monitor-manager: Hook up config manager to display config confirmation Make it possible to confirm or cancel the new configuration also when the new API is used. https://bugzilla.gnome.org/show_bug.cgi?id=777732
2017-03-23 05:20:07 -04:00
void meta_monitor_config_manager_save_current (MetaMonitorConfigManager *config_manager);
Add support for scaled logical monitor framebuffers This commit adds support for rendering onto enlarged per logical monitor framebuffers, using the scaled clutter stage views, for HiDPI enabled logical monitors. This works by scaling the mode of the monitors in a logical monitors by the scale, no longer relying on scaling the window actors and window geometry for making windows have the correct size on HiDPI monitors. It is disabled by default, as in automatically created configurations will still use the old mode. This is partly because Xwayland clients will not yet work good enough to make it feasible. To enable, add the 'scale-monitor-framebuffer' keyword to the org.gnome.mutter.experimental-features gsettings array. It is still possible to specify the mode via the new D-Bus API, which has been adapted. The adaptations to the D-Bus API means the caller need to be aware of how to position logical monitors on the stage grid. This depends on the 'layout-mode' property that is used (see the DisplayConfig D-Bus documentation). https://bugzilla.gnome.org/show_bug.cgi?id=777732
2017-02-24 05:10:52 -05:00
MetaMonitorsConfig * meta_monitors_config_new (GList *logical_monitor_configs,
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
MetaLogicalMonitorLayoutMode layout_mode,
MetaMonitorsConfigFlag flags);
monitor-config-manager: Add MetaMonitorsConfig creation helper Add a meta_monitors_config_new() helper. It's exposed outside of meta-monitor-config-manager.c already, as it'll be used externally in a later commit. https://bugzilla.gnome.org/show_bug.cgi?id=777732
2017-01-10 23:13:39 -05:00
Introduce MetaMonitorConfigStore MetaMonitorConfigStore provides an XML storage mechanism for MetaMonitorConfigManager. It stores configuration files defined in the same level as the MetaMonitorsConfig format, i.e. refers to high level "monitors" and "monitor modes" instead of connectors and CRTCs. Only reading custom files are implemented and so far unused. https://bugzilla.gnome.org/show_bug.cgi?id=777732
2017-01-12 03:13:48 -05:00
unsigned int meta_monitors_config_key_hash (gconstpointer config_key);
gboolean meta_monitors_config_key_equal (gconstpointer config_key_a,
gconstpointer config_key_b);
void meta_monitors_config_key_free (MetaMonitorsConfigKey *config_key);
void meta_logical_monitor_config_free (MetaLogicalMonitorConfig *logical_monitor_config);
void meta_monitor_config_free (MetaMonitorConfig *monitor_config);
monitor-config-store: Move config verification to config manager This way we can re-use it for example when verifying configurations from D-Bus. https://bugzilla.gnome.org/show_bug.cgi?id=777732
2017-02-07 21:31:32 -05:00
gboolean meta_verify_monitor_mode_spec (MetaMonitorModeSpec *monitor_mode_spec,
GError **error);
gboolean meta_verify_monitor_spec (MetaMonitorSpec *monitor_spec,
GError **error);
gboolean meta_verify_monitor_config (MetaMonitorConfig *monitor_config,
GError **error);
Add support for scaled logical monitor framebuffers This commit adds support for rendering onto enlarged per logical monitor framebuffers, using the scaled clutter stage views, for HiDPI enabled logical monitors. This works by scaling the mode of the monitors in a logical monitors by the scale, no longer relying on scaling the window actors and window geometry for making windows have the correct size on HiDPI monitors. It is disabled by default, as in automatically created configurations will still use the old mode. This is partly because Xwayland clients will not yet work good enough to make it feasible. To enable, add the 'scale-monitor-framebuffer' keyword to the org.gnome.mutter.experimental-features gsettings array. It is still possible to specify the mode via the new D-Bus API, which has been adapted. The adaptations to the D-Bus API means the caller need to be aware of how to position logical monitors on the stage grid. This depends on the 'layout-mode' property that is used (see the DisplayConfig D-Bus documentation). https://bugzilla.gnome.org/show_bug.cgi?id=777732
2017-02-24 05:10:52 -05:00
gboolean meta_verify_logical_monitor_config (MetaLogicalMonitorConfig *logical_monitor_config,
MetaLogicalMonitorLayoutMode layout_mode,
Add support for rudimentary fractional scaling When the logical layout mode is used, allow configuring the scaling to be non-integer. Supported scales are so far hard coded to include at most 1, 1.5 and 2, and scales that doesn't result in non-fractional logical monitor sizes are discarded. Wayland outputs are set to have scale ceil(actual_scale) meaning well behaving Wayland clients will provide buffers with buffer scale 2, thus being scaled down to the fractional scale. https://bugzilla.gnome.org/show_bug.cgi?id=765011
2017-05-25 05:20:59 -04:00
MetaMonitorManager *monitor_manager,
Add support for scaled logical monitor framebuffers This commit adds support for rendering onto enlarged per logical monitor framebuffers, using the scaled clutter stage views, for HiDPI enabled logical monitors. This works by scaling the mode of the monitors in a logical monitors by the scale, no longer relying on scaling the window actors and window geometry for making windows have the correct size on HiDPI monitors. It is disabled by default, as in automatically created configurations will still use the old mode. This is partly because Xwayland clients will not yet work good enough to make it feasible. To enable, add the 'scale-monitor-framebuffer' keyword to the org.gnome.mutter.experimental-features gsettings array. It is still possible to specify the mode via the new D-Bus API, which has been adapted. The adaptations to the D-Bus API means the caller need to be aware of how to position logical monitors on the stage grid. This depends on the 'layout-mode' property that is used (see the DisplayConfig D-Bus documentation). https://bugzilla.gnome.org/show_bug.cgi?id=777732
2017-02-24 05:10:52 -05:00
GError **error);
monitor-config-store: Move config verification to config manager This way we can re-use it for example when verifying configurations from D-Bus. https://bugzilla.gnome.org/show_bug.cgi?id=777732
2017-02-07 21:31:32 -05:00
gboolean meta_verify_monitors_config (MetaMonitorsConfig *config,
monitor-manager/xrandr: Allow configuring scales on X11 too This commit makes it possible to configure logical monitor scale also when running on top of an X11 server using Xrandr. An extra property 'requires-globla-scale' is added to the D-Bus API is added to instruct a configuration application to only allow setting a global logical monitor scale. This is needed to let gsd-xsettings use the configured state to set a XSettings state that respects the explicit monitor configuration. https://bugzilla.gnome.org/show_bug.cgi?id=777732
2017-04-21 06:01:15 -04:00
MetaMonitorManager *monitor_manager,
monitor-config-store: Move config verification to config manager This way we can re-use it for example when verifying configurations from D-Bus. https://bugzilla.gnome.org/show_bug.cgi?id=777732
2017-02-07 21:31:32 -05:00
GError **error);
Introduce new monitor configuration system The new monitor configuration system (MetaMonitorConfigManager) aims to replace the current MetaMonitorConfig. The main difference between the two is that MetaMonitorConfigManager works with higher level input (MetaMonitor, MetaMonitorMode) instead of directly looking at the CRTC and connector state. It still produces CRTC and connector configuration later applied by the respective backends. Other difference the new system aims to introduce is that the configuration system doesn't manipulate the monitor manager state; that responsibility is left for the monitor manager to handle (it only manages configuration and creates CRTC/connector assignments, it doesn't apply anything). The new configuration system allows backends to not rely on deriving the current configuration from the CRTC/connector state, as this may no longer be possible (i.e. when using KMS and multiple framebuffers). The MetaMonitorConfigManager system is so far disabled by default, as it does not yet have all the features of the old system, but eventually it will replace MetaMonitorConfig which will at that point be removed. This will make it possible to remove old hacks introduced due to limitations in the old system. https://bugzilla.gnome.org/show_bug.cgi?id=777732
2017-01-09 01:31:18 -05:00
#endif /* META_MONITOR_CONFIG_MANAGER_H */
Reference in New Issue Copy Permalink