sungmg/mutter-performance-source
1
0
Fork 0
Code Activity
mutter-performance-source/src/backends/meta-monitor-manager.c

2997 lines
96 KiB
C
Raw Normal View History

Rework and consolidate monitor handling in MetaScreen Consolidate all places that deal with output configuration in MetaScreen, which gets it either from XRandR or from a dummy static configuration. We still need to read the Xinerama config, even when running xwayland, because we need the indices for _NET_WM_FULLSCREEN_MONITORS, but now we do it only when needed. https://bugzilla.gnome.org/show_bug.cgi?id=705670
2013-07-18 11:09:16 +00:00
/* -*- mode: C; c-file-style: "gnu"; indent-tabs-mode: nil; -*- */
Remove trailing whitespace
2014-05-02 13:34:02 +00:00
/*
Rework and consolidate monitor handling in MetaScreen Consolidate all places that deal with output configuration in MetaScreen, which gets it either from XRandR or from a dummy static configuration. We still need to read the Xinerama config, even when running xwayland, because we need the indices for _NET_WM_FULLSCREEN_MONITORS, but now we do it only when needed. https://bugzilla.gnome.org/show_bug.cgi?id=705670
2013-07-18 11:09:16 +00:00
* Copyright (C) 2001, 2002 Havoc Pennington
* Copyright (C) 2002, 2003 Red Hat Inc.
* Some ICCCM manager selection code derived from fvwm2,
* Copyright (C) 2001 Dominik Vogt, Matthias Clasen, and fvwm2 team
* Copyright (C) 2003 Rob Adams
* Copyright (C) 2004-2006 Elijah Newren
* Copyright (C) 2013 Red Hat Inc.
Remove trailing whitespace
2014-05-02 13:34:02 +00:00
*
Rework and consolidate monitor handling in MetaScreen Consolidate all places that deal with output configuration in MetaScreen, which gets it either from XRandR or from a dummy static configuration. We still need to read the Xinerama config, even when running xwayland, because we need the indices for _NET_WM_FULLSCREEN_MONITORS, but now we do it only when needed. https://bugzilla.gnome.org/show_bug.cgi?id=705670
2013-07-18 11:09:16 +00:00
* 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.
Remove trailing whitespace
2014-05-02 13:34:02 +00:00
*
Rework and consolidate monitor handling in MetaScreen Consolidate all places that deal with output configuration in MetaScreen, which gets it either from XRandR or from a dummy static configuration. We still need to read the Xinerama config, even when running xwayland, because we need the indices for _NET_WM_FULLSCREEN_MONITORS, but now we do it only when needed. https://bugzilla.gnome.org/show_bug.cgi?id=705670
2013-07-18 11:09:16 +00:00
* You should have received a copy of the GNU General Public License
Changed obsolete FSF postal address into generic URL. Fix https://bugzilla.gnome.org/show_bug.cgi?id=721517 #2
2014-01-12 01:42:06 +00:00
* along with this program; if not, see <http://www.gnu.org/licenses/>.
Rework and consolidate monitor handling in MetaScreen Consolidate all places that deal with output configuration in MetaScreen, which gets it either from XRandR or from a dummy static configuration. We still need to read the Xinerama config, even when running xwayland, because we need the indices for _NET_WM_FULLSCREEN_MONITORS, but now we do it only when needed. https://bugzilla.gnome.org/show_bug.cgi?id=705670
2013-07-18 11:09:16 +00:00
*/
#include "config.h"
Clean up include macros mess The order and way include macros were structured was chaotic, with no real common thread between files. Try to tidy up the mess with some common scheme, to make things look less messy.
2018-07-10 08:36:24 +00:00
#include "backends/meta-monitor-manager-private.h"
Rename monitor => meta-monitor-manager
2014-04-01 02:04:10 +00:00
Introduce a new DBus interface for display configuration This new interface will be used by the control center and possibly the settings daemon to configure the screens. It is designed to resemble a simplified XRandR, while still exposing all the quirks of the hardware, so that the panel can limit the user choices appropriately. To do so, MetaMonitorMode needs to track CRTCs, outputs and modes, so the low level objects have been decoupled from the high-level MetaMonitorInfo, which is used by core and API and offers a simplified view of HW, that hides away the details of what is cloned and how. This is still not efficient as it should be, because on every HW change we drop all data structures and rebuild them from scratch (which is not expensive because there aren't many of them, but at least in the XRandR path it involves a few sync X calls) https://bugzilla.gnome.org/show_bug.cgi?id=705670
2013-07-19 12:39:28 +00:00
#include <string.h>
#include <math.h>
MonitorManager: add support for persistent monitor configurations Add a new object, MetaMonitorConfig, that takes care of converting between the logical configurations stored in monitors.xml and the HW resources exposed by MonitorManager. This commit includes loading and saving of configurations, but still missing is the actual CRTC assignments and a default configuration when none is found in the file. https://bugzilla.gnome.org/show_bug.cgi?id=705670
2013-07-24 13:35:47 +00:00
#include <stdlib.h>
Rework and consolidate monitor handling in MetaScreen Consolidate all places that deal with output configuration in MetaScreen, which gets it either from XRandR or from a dummy static configuration. We still need to read the Xinerama config, even when running xwayland, because we need the indices for _NET_WM_FULLSCREEN_MONITORS, but now we do it only when needed. https://bugzilla.gnome.org/show_bug.cgi?id=705670
2013-07-18 11:09:16 +00:00
Clean up include macros mess The order and way include macros were structured was chaotic, with no real common thread between files. Try to tidy up the mess with some common scheme, to make things look less messy.
2018-07-10 08:36:24 +00:00
#include "backends/edid.h"
backend: Move lid-is-closed handling to MetaBackend Rather than handle UpClient in both MetaBackend (to reset the idletime when the lid is opened), and in MetaMonitorManager and MetaMonitorConfigManager (to turn the screen under the lid on/off depending on its status), move the ability to get the lid status from UPower or mock it in one place, in MetaBackend.
2018-04-16 18:07:45 +00:00
#include "backends/meta-backend-private.h"
monitor-manager: Make MetaCrtc a GObject Turn MetaCrtc into a GObject and move it to a separate file. This changes the storage format, resulting in changing the API for accessing MetaCrtcs from using an array, to using a GList. https://bugzilla.gnome.org/show_bug.cgi?id=785381
2017-03-28 04:35:19 +00:00
#include "backends/meta-crtc.h"
monitor-manager: Move logical monitor into its own file https://bugzilla.gnome.org/show_bug.cgi?id=777732
2016-12-13 02:37:11 +00:00
#include "backends/meta-logical-monitor.h"
monitor-manager: Generate a monitor abstraction from outputs and crtcs Generate a set of "monitors" abstracting the physical concepts. Each monitor is built up of one or more outputs; multiple outputs being tiled monitors. Logical monitors will later be built from these. https://bugzilla.gnome.org/show_bug.cgi?id=777732
2016-12-13 02:53:38 +00:00
#include "backends/meta-monitor.h"
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 06:31:18 +00:00
#include "backends/meta-monitor-config-manager.h"
monitor-manager: Hook MetaOrientationManager to change the config On orientation changes we'll apply the appropriate monitor transform to the current configuration if possible. https://bugzilla.gnome.org/show_bug.cgi?id=781906
2017-04-28 15:53:07 +00:00
#include "backends/meta-orientation-manager.h"
Make MetaOutput a GObject Turn MetaOutput into a GObject and move it to a separate file. This changes the storage format, resulting in changing the API for accessing MetaOutputs from using an array, to using a GList. https://bugzilla.gnome.org/show_bug.cgi?id=785381
2017-03-24 09:35:51 +00:00
#include "backends/meta-output.h"
Start creating different subdirectories for each backend
2014-04-01 03:25:37 +00:00
#include "backends/x11/meta-monitor-manager-xrandr.h"
Clean up include macros mess The order and way include macros were structured was chaotic, with no real common thread between files. Try to tidy up the mess with some common scheme, to make things look less messy.
2018-07-10 08:36:24 +00:00
#include "clutter/clutter.h"
#include "core/util-private.h"
#include "meta/main.h"
#include "meta/meta-x11-errors.h"
Rework and consolidate monitor handling in MetaScreen Consolidate all places that deal with output configuration in MetaScreen, which gets it either from XRandR or from a dummy static configuration. We still need to read the Xinerama config, even when running xwayland, because we need the indices for _NET_WM_FULLSCREEN_MONITORS, but now we do it only when needed. https://bugzilla.gnome.org/show_bug.cgi?id=705670
2013-07-18 11:09:16 +00:00
monitor-manager: add API to get the display configuration timeout Instead of hardcoding this into two different places, add an API so that gnome-shell can fetch it. https://bugzilla.gnome.org/show_bug.cgi?id=767805
2014-08-21 00:07:13 +00:00
#define DEFAULT_DISPLAY_CONFIGURATION_TIMEOUT 20
monitor-manager: Keep pointer to backend Instead of accessing the global singleton, keep a pointer to the backend in the MetaMonitorManager struct. https://bugzilla.gnome.org/show_bug.cgi?id=785381
2017-07-10 09:39:07 +00:00
enum
{
PROP_0,
PROP_BACKEND,
PROP_LAST
};
static GParamSpec *obj_props[PROP_LAST];
Rework and consolidate monitor handling in MetaScreen Consolidate all places that deal with output configuration in MetaScreen, which gets it either from XRandR or from a dummy static configuration. We still need to read the Xinerama config, even when running xwayland, because we need the indices for _NET_WM_FULLSCREEN_MONITORS, but now we do it only when needed. https://bugzilla.gnome.org/show_bug.cgi?id=705670
2013-07-18 11:09:16 +00:00
enum {
backends: add 'monitors-updated-internal' signal to only update internal state Adding an internal signal and use it to update the internal state before emitting "monitors-changed" which will be repeated by the screen to the world. https://bugzilla.gnome.org/show_bug.cgi?id=788860
2017-10-13 00:14:40 +00:00
MONITORS_CHANGED_INTERNAL,
MetaPlugin: add a UI hook for confirming display changes We want to show a dialog when a display change happens from the control center. To do so, add a new vfunc to MetaPlugin and call it when a configuration change is requested via DBus. https://bugzilla.gnome.org/show_bug.cgi?id=705670
2013-07-29 08:12:24 +00:00
CONFIRM_DISPLAY_CHANGE,
Rework and consolidate monitor handling in MetaScreen Consolidate all places that deal with output configuration in MetaScreen, which gets it either from XRandR or from a dummy static configuration. We still need to read the Xinerama config, even when running xwayland, because we need the indices for _NET_WM_FULLSCREEN_MONITORS, but now we do it only when needed. https://bugzilla.gnome.org/show_bug.cgi?id=705670
2013-07-18 11:09:16 +00:00
SIGNALS_LAST
};
monitor-manager: Add method to find an output matrix This will be useful to determine input device matrices for touchscreens and tablets. https://bugzilla.gnome.org/show_bug.cgi?id=739397
2014-12-11 17:14:00 +00:00
/* Array index matches MetaMonitorTransform */
static gfloat transform_matrices[][6] = {
{ 1, 0, 0, 0, 1, 0 }, /* normal */
{ 0, -1, 1, 1, 0, 0 }, /* 90° */
{ -1, 0, 1, 0, -1, 1 }, /* 180° */
{ 0, 1, 0, -1, 0, 1 }, /* 270° */
{ -1, 0, 1, 0, 1, 0 }, /* normal flipped */
{ 0, 1, 0, 1, 0, 0 }, /* 90° flipped */
{ 1, 0, 0, 0, -1, 1 }, /* 180° flipped */
{ 0, -1, 1, -1, 0, 1 }, /* 270° flipped */
};
Rework and consolidate monitor handling in MetaScreen Consolidate all places that deal with output configuration in MetaScreen, which gets it either from XRandR or from a dummy static configuration. We still need to read the Xinerama config, even when running xwayland, because we need the indices for _NET_WM_FULLSCREEN_MONITORS, but now we do it only when needed. https://bugzilla.gnome.org/show_bug.cgi?id=705670
2013-07-18 11:09:16 +00:00
static int signals[SIGNALS_LAST];
MonitorManager: inherit directly from DisplayConfig instead of handling signals This way we can handle properties too. https://bugzilla.gnome.org/show_bug.cgi?id=705670
2013-07-23 17:32:17 +00:00
static void meta_monitor_manager_display_config_init (MetaDBusDisplayConfigIface *iface);
Move the dummy monitor manager to his own subclass / file
2014-04-01 01:50:09 +00:00
G_DEFINE_ABSTRACT_TYPE_WITH_CODE (MetaMonitorManager, meta_monitor_manager, META_DBUS_TYPE_DISPLAY_CONFIG_SKELETON,
G_IMPLEMENT_INTERFACE (META_DBUS_TYPE_DISPLAY_CONFIG, meta_monitor_manager_display_config_init));
Rework and consolidate monitor handling in MetaScreen Consolidate all places that deal with output configuration in MetaScreen, which gets it either from XRandR or from a dummy static configuration. We still need to read the Xinerama config, even when running xwayland, because we need the indices for _NET_WM_FULLSCREEN_MONITORS, but now we do it only when needed. https://bugzilla.gnome.org/show_bug.cgi?id=705670
2013-07-18 11:09:16 +00:00
MonitorManager: split the XRandR parts in a subclass Instead of keeping a forest of if backend else ..., use a subclass and virtual functions to discriminate between XRandR and the dummy backend (which lives in the parent class togheter with the common code) https://bugzilla.gnome.org/show_bug.cgi?id=705670
2013-07-29 11:00:15 +00:00
static void initialize_dbus_interface (MetaMonitorManager *manager);
DisplayConfig: make the dummy backend writable Add a number of dummy outputs and modes to the dummy backend, and implement the writing bits. The only visible effect is that you can change the screen size, which resizes the output window. https://bugzilla.gnome.org/show_bug.cgi?id=705670
2013-07-23 08:07:52 +00:00
monitor-manager: Try to restore previous config before regenerating When opening a laptop lid, one will likely want to restore the configuration one had prior to closing it, so when ensuring monitor configuration, first try to see if the previously set configuration is both complete (all connected monitors are configured) and applicable (it is a valid configuration) and only try to generate a new from scratch if that failed. https://bugzilla.gnome.org/show_bug.cgi?id=777732
2017-08-11 07:21:36 +00:00
static gboolean
meta_monitor_manager_is_config_complete (MetaMonitorManager *manager,
MetaMonitorsConfig *config);
monitor-manager: Find active monitor when deriving global scale When deriving the global scale directly from the current hardware state (as done when using the X11 backend) we are inspecting the logical state they had prior to the most recent hot plug. That means that a primary monitor might have been disabled, and a new primary monitor may not have been assigned yet. Stop assuming a primary monitor has an active mode before having reconstructed the logical state by finding some active monitor if the old primary monitor was disabled. This avoids a crash when trying to derive the global scale from a disabled monitor. Closes: https://gitlab.gnome.org/GNOME/mutter/issues/130
2018-04-25 08:43:11 +00:00
static MetaMonitor *
meta_monitor_manager_get_active_monitor (MetaMonitorManager *manager);
monitor-manager: Keep pointer to backend Instead of accessing the global singleton, keep a pointer to the backend in the MetaMonitorManager struct. https://bugzilla.gnome.org/show_bug.cgi?id=785381
2017-07-10 09:39:07 +00:00
MetaBackend *
meta_monitor_manager_get_backend (MetaMonitorManager *manager)
{
return manager->backend;
}
Rework and consolidate monitor handling in MetaScreen Consolidate all places that deal with output configuration in MetaScreen, which gets it either from XRandR or from a dummy static configuration. We still need to read the Xinerama config, even when running xwayland, because we need the indices for _NET_WM_FULLSCREEN_MONITORS, but now we do it only when needed. https://bugzilla.gnome.org/show_bug.cgi?id=705670
2013-07-18 11:09:16 +00:00
static void
meta_monitor_manager_init (MetaMonitorManager *manager)
{
}
monitor-manager: Generate logical monitors from monitors Instead of using crtcs and outputs to generate logical monitors, use the ready made monitor abstraction that hides irrelevant things such as monitor tiling etc. https://bugzilla.gnome.org/show_bug.cgi?id=777732
2016-12-13 03:03:22 +00:00
static void
meta_monitor_manager_set_primary_logical_monitor (MetaMonitorManager *manager,
MetaLogicalMonitor *logical_monitor)
{
manager->primary_logical_monitor = logical_monitor;
if (logical_monitor)
meta_logical_monitor_make_primary (logical_monitor);
}
monitor-manager: Refactor tiled monitor assembly code Refactor the tiled monitor assembly code (that constructs a logical monitor out of tiling information. Part of the reason is to move away from array based storage, part is to make the code easier to follow, and part is to separate logical monitor construction from list manipulation. https://bugzilla.gnome.org/show_bug.cgi?id=777732
2016-12-02 07:48:53 +00:00
static gboolean
is_main_tiled_monitor_output (MetaOutput *output)
{
return output->tile_info.loc_h_tile == 0 && output->tile_info.loc_v_tile == 0;
}
monitor-manager: Generate logical monitors from monitors Instead of using crtcs and outputs to generate logical monitors, use the ready made monitor abstraction that hides irrelevant things such as monitor tiling etc. https://bugzilla.gnome.org/show_bug.cgi?id=777732
2016-12-13 03:03:22 +00:00
static MetaLogicalMonitor *
logical_monitor_from_layout (MetaMonitorManager *manager,
GList *logical_monitors,
MetaRectangle *layout)
monitors: construct tiled monitors info The monitors info structure is created from the tiled outputs and this is used as the central storage for info about a monitor as opposed to the output state. It appears at least the EDID mm w/h is for the whole monitor and not per tile.
2015-03-31 01:08:34 +00:00
{
monitor-manager: Generate logical monitors from monitors Instead of using crtcs and outputs to generate logical monitors, use the ready made monitor abstraction that hides irrelevant things such as monitor tiling etc. https://bugzilla.gnome.org/show_bug.cgi?id=777732
2016-12-13 03:03:22 +00:00
GList *l;
monitors: construct tiled monitors info The monitors info structure is created from the tiled outputs and this is used as the central storage for info about a monitor as opposed to the output state. It appears at least the EDID mm w/h is for the whole monitor and not per tile.
2015-03-31 01:08:34 +00:00
monitor-manager: Generate logical monitors from monitors Instead of using crtcs and outputs to generate logical monitors, use the ready made monitor abstraction that hides irrelevant things such as monitor tiling etc. https://bugzilla.gnome.org/show_bug.cgi?id=777732
2016-12-13 03:03:22 +00:00
for (l = logical_monitors; l; l = l->next)
monitors: construct tiled monitors info The monitors info structure is created from the tiled outputs and this is used as the central storage for info about a monitor as opposed to the output state. It appears at least the EDID mm w/h is for the whole monitor and not per tile.
2015-03-31 01:08:34 +00:00
{
monitor-manager: Generate logical monitors from monitors Instead of using crtcs and outputs to generate logical monitors, use the ready made monitor abstraction that hides irrelevant things such as monitor tiling etc. https://bugzilla.gnome.org/show_bug.cgi?id=777732
2016-12-13 03:03:22 +00:00
MetaLogicalMonitor *logical_monitor = l->data;
monitors: construct tiled monitors info The monitors info structure is created from the tiled outputs and this is used as the central storage for info about a monitor as opposed to the output state. It appears at least the EDID mm w/h is for the whole monitor and not per tile.
2015-03-31 01:08:34 +00:00
monitor-manager: Generate logical monitors from monitors Instead of using crtcs and outputs to generate logical monitors, use the ready made monitor abstraction that hides irrelevant things such as monitor tiling etc. https://bugzilla.gnome.org/show_bug.cgi?id=777732
2016-12-13 03:03:22 +00:00
if (meta_rectangle_equal (layout, &logical_monitor->rect))
return logical_monitor;
monitors: construct tiled monitors info The monitors info structure is created from the tiled outputs and this is used as the central storage for info about a monitor as opposed to the output state. It appears at least the EDID mm w/h is for the whole monitor and not per tile.
2015-03-31 01:08:34 +00:00
}
monitor-manager: Generate logical monitors from monitors Instead of using crtcs and outputs to generate logical monitors, use the ready made monitor abstraction that hides irrelevant things such as monitor tiling etc. https://bugzilla.gnome.org/show_bug.cgi?id=777732
2016-12-13 03:03:22 +00:00
return NULL;
monitor-manager: Refactor tiled monitor assembly code Refactor the tiled monitor assembly code (that constructs a logical monitor out of tiling information. Part of the reason is to move away from array based storage, part is to make the code easier to follow, and part is to separate logical monitor construction from list manipulation. https://bugzilla.gnome.org/show_bug.cgi?id=777732
2016-12-02 07:48:53 +00:00
}
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 06:31:18 +00:00
static void
meta_monitor_manager_rebuild_logical_monitors (MetaMonitorManager *manager,
MetaMonitorsConfig *config)
{
monitor-config-manager: Handle headless setup gracefully Handle headless setup gracefully by having no logical monitors. This commit only makes the monitor management code deal with it; other areas may still not be able to handle it. https://bugzilla.gnome.org/show_bug.cgi?id=777732
2017-01-12 05:47:54 +00:00
GList *logical_monitor_configs;
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 06:31:18 +00:00
GList *logical_monitors = NULL;
GList *l;
int monitor_number = 0;
MetaLogicalMonitor *primary_logical_monitor = NULL;
monitor-config-manager: Handle headless setup gracefully Handle headless setup gracefully by having no logical monitors. This commit only makes the monitor management code deal with it; other areas may still not be able to handle it. https://bugzilla.gnome.org/show_bug.cgi?id=777732
2017-01-12 05:47:54 +00:00
logical_monitor_configs = config ? config->logical_monitor_configs : NULL;
for (l = logical_monitor_configs; l; l = l->next)
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 06:31:18 +00:00
{
MetaLogicalMonitorConfig *logical_monitor_config = l->data;
MetaLogicalMonitor *logical_monitor;
monitor-manager: Split logical monitor creation Split up logical monitor cration into derived (when derived from current underlying configuration) and non-derived (when creating from a logical monitor configuration). This avoids that type of logic in the logical monitor creation function. https://bugzilla.gnome.org/show_bug.cgi?id=779745
2017-03-07 04:34:38 +00:00
logical_monitor = meta_logical_monitor_new (manager,
logical_monitor_config,
monitor_number);
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 06:31:18 +00:00
monitor_number++;
if (logical_monitor_config->is_primary)
primary_logical_monitor = logical_monitor;
logical_monitors = g_list_append (logical_monitors, logical_monitor);
}
/*
* If no monitor was marked as primary, fall back on marking the first
* logical monitor the primary one.
*/
if (!primary_logical_monitor && logical_monitors)
primary_logical_monitor = g_list_first (logical_monitors)->data;
manager->logical_monitors = logical_monitors;
meta_monitor_manager_set_primary_logical_monitor (manager,
primary_logical_monitor);
}
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 08:12:51 +00:00
static float
monitor-manager: Pass config to derive from when updating state When we update state, we might not have set the current config yet (for example if the Xrandr assignment didn't change), so pass the monitors config we should derive from instead of fetching it from the monitor config manager. https://bugzilla.gnome.org/show_bug.cgi?id=787477
2017-09-11 06:10:26 +00:00
derive_configured_global_scale (MetaMonitorManager *manager,
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 10:01:15 +00:00
{
MetaLogicalMonitorConfig *logical_monitor_config;
logical_monitor_config = config->logical_monitor_configs->data;
return logical_monitor_config->scale;
}
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 08:12:51 +00:00
static float
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 10:01:15 +00:00
calculate_monitor_scale (MetaMonitorManager *manager,
MetaMonitor *monitor)
{
MetaMonitorMode *monitor_mode;
monitor_mode = meta_monitor_get_current_mode (monitor);
return meta_monitor_manager_calculate_monitor_mode_scale (manager,
monitor,
monitor_mode);
}
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 08:12:51 +00:00
static float
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 10:01:15 +00:00
derive_calculated_global_scale (MetaMonitorManager *manager)
{
monitor-manager: Find active monitor when deriving global scale When deriving the global scale directly from the current hardware state (as done when using the X11 backend) we are inspecting the logical state they had prior to the most recent hot plug. That means that a primary monitor might have been disabled, and a new primary monitor may not have been assigned yet. Stop assuming a primary monitor has an active mode before having reconstructed the logical state by finding some active monitor if the old primary monitor was disabled. This avoids a crash when trying to derive the global scale from a disabled monitor. Closes: https://gitlab.gnome.org/GNOME/mutter/issues/130
2018-04-25 08:43:11 +00:00
MetaMonitor *monitor = NULL;
monitor = meta_monitor_manager_get_primary_monitor (manager);
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 10:01:15 +00:00
monitor-manager: Find active monitor when deriving global scale When deriving the global scale directly from the current hardware state (as done when using the X11 backend) we are inspecting the logical state they had prior to the most recent hot plug. That means that a primary monitor might have been disabled, and a new primary monitor may not have been assigned yet. Stop assuming a primary monitor has an active mode before having reconstructed the logical state by finding some active monitor if the old primary monitor was disabled. This avoids a crash when trying to derive the global scale from a disabled monitor. Closes: https://gitlab.gnome.org/GNOME/mutter/issues/130
2018-04-25 08:43:11 +00:00
if (!monitor || !meta_monitor_is_active (monitor))
monitor = meta_monitor_manager_get_active_monitor (manager);
if (!monitor)
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 08:12:51 +00:00
return 1.0;
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 10:01:15 +00:00
monitor-manager: Find active monitor when deriving global scale When deriving the global scale directly from the current hardware state (as done when using the X11 backend) we are inspecting the logical state they had prior to the most recent hot plug. That means that a primary monitor might have been disabled, and a new primary monitor may not have been assigned yet. Stop assuming a primary monitor has an active mode before having reconstructed the logical state by finding some active monitor if the old primary monitor was disabled. This avoids a crash when trying to derive the global scale from a disabled monitor. Closes: https://gitlab.gnome.org/GNOME/mutter/issues/130
2018-04-25 08:43:11 +00:00
return calculate_monitor_scale (manager, monitor);
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 10:01:15 +00:00
}
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 08:12:51 +00:00
static float
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 10:01:15 +00:00
derive_scale_from_config (MetaMonitorManager *manager,
monitor-manager: Pass config to derive from when updating state When we update state, we might not have set the current config yet (for example if the Xrandr assignment didn't change), so pass the monitors config we should derive from instead of fetching it from the monitor config manager. https://bugzilla.gnome.org/show_bug.cgi?id=787477
2017-09-11 06:10:26 +00:00
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 10:01:15 +00:00
MetaRectangle *layout)
{
GList *l;
for (l = config->logical_monitor_configs; l; l = l->next)
{
MetaLogicalMonitorConfig *logical_monitor_config = l->data;
if (meta_rectangle_equal (layout, &logical_monitor_config->layout))
return logical_monitor_config->scale;
}
g_warning ("Missing logical monitor, using scale 1");
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 08:12:51 +00:00
return 1.0;
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 10:01:15 +00:00
}
Introduce a new DBus interface for display configuration This new interface will be used by the control center and possibly the settings daemon to configure the screens. It is designed to resemble a simplified XRandR, while still exposing all the quirks of the hardware, so that the panel can limit the user choices appropriately. To do so, MetaMonitorMode needs to track CRTCs, outputs and modes, so the low level objects have been decoupled from the high-level MetaMonitorInfo, which is used by core and API and offers a simplified view of HW, that hides away the details of what is cloned and how. This is still not efficient as it should be, because on every HW change we drop all data structures and rebuild them from scratch (which is not expensive because there aren't many of them, but at least in the XRandR path it involves a few sync X calls) https://bugzilla.gnome.org/show_bug.cgi?id=705670
2013-07-19 12:39:28 +00:00
static void
monitor-manager: Pass config to derive from when updating state When we update state, we might not have set the current config yet (for example if the Xrandr assignment didn't change), so pass the monitors config we should derive from instead of fetching it from the monitor config manager. https://bugzilla.gnome.org/show_bug.cgi?id=787477
2017-09-11 06:10:26 +00:00
meta_monitor_manager_rebuild_logical_monitors_derived (MetaMonitorManager *manager,
MetaMonitorsConfig *config)
Introduce a new DBus interface for display configuration This new interface will be used by the control center and possibly the settings daemon to configure the screens. It is designed to resemble a simplified XRandR, while still exposing all the quirks of the hardware, so that the panel can limit the user choices appropriately. To do so, MetaMonitorMode needs to track CRTCs, outputs and modes, so the low level objects have been decoupled from the high-level MetaMonitorInfo, which is used by core and API and offers a simplified view of HW, that hides away the details of what is cloned and how. This is still not efficient as it should be, because on every HW change we drop all data structures and rebuild them from scratch (which is not expensive because there aren't many of them, but at least in the XRandR path it involves a few sync X calls) https://bugzilla.gnome.org/show_bug.cgi?id=705670
2013-07-19 12:39:28 +00:00
{
monitor-manager: Store logical monitors in a GList Instead of storing the logical monitors in an array and having users either look up them in the array given an index or iterate using indices, put it in a GList, and use GList iterators when iterating and alternative API where array indices were previously used. This allows for more liberty regarding the type of the logical monitor. https://bugzilla.gnome.org/show_bug.cgi?id=777732
2016-12-02 08:00:03 +00:00
GList *logical_monitors = NULL;
monitor-manager: Generate logical monitors from monitors Instead of using crtcs and outputs to generate logical monitors, use the ready made monitor abstraction that hides irrelevant things such as monitor tiling etc. https://bugzilla.gnome.org/show_bug.cgi?id=777732
2016-12-13 03:03:22 +00:00
GList *l;
monitor-manager: Store logical monitors in a GList Instead of storing the logical monitors in an array and having users either look up them in the array given an index or iterate using indices, put it in a GList, and use GList iterators when iterating and alternative API where array indices were previously used. This allows for more liberty regarding the type of the logical monitor. https://bugzilla.gnome.org/show_bug.cgi?id=777732
2016-12-02 08:00:03 +00:00
int monitor_number;
monitor-manager: Generate logical monitors from monitors Instead of using crtcs and outputs to generate logical monitors, use the ready made monitor abstraction that hides irrelevant things such as monitor tiling etc. https://bugzilla.gnome.org/show_bug.cgi?id=777732
2016-12-13 03:03:22 +00:00
MetaLogicalMonitor *primary_logical_monitor = NULL;
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 10:01:15 +00:00
gboolean use_global_scale;
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 08:12:51 +00:00
float global_scale = 0.0;
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 10:01:15 +00:00
MetaMonitorManagerCapability capabilities;
Introduce a new DBus interface for display configuration This new interface will be used by the control center and possibly the settings daemon to configure the screens. It is designed to resemble a simplified XRandR, while still exposing all the quirks of the hardware, so that the panel can limit the user choices appropriately. To do so, MetaMonitorMode needs to track CRTCs, outputs and modes, so the low level objects have been decoupled from the high-level MetaMonitorInfo, which is used by core and API and offers a simplified view of HW, that hides away the details of what is cloned and how. This is still not efficient as it should be, because on every HW change we drop all data structures and rebuild them from scratch (which is not expensive because there aren't many of them, but at least in the XRandR path it involves a few sync X calls) https://bugzilla.gnome.org/show_bug.cgi?id=705670
2013-07-19 12:39:28 +00:00
monitor-manager: Store logical monitors in a GList Instead of storing the logical monitors in an array and having users either look up them in the array given an index or iterate using indices, put it in a GList, and use GList iterators when iterating and alternative API where array indices were previously used. This allows for more liberty regarding the type of the logical monitor. https://bugzilla.gnome.org/show_bug.cgi?id=777732
2016-12-02 08:00:03 +00:00
monitor_number = 0;
Introduce a new DBus interface for display configuration This new interface will be used by the control center and possibly the settings daemon to configure the screens. It is designed to resemble a simplified XRandR, while still exposing all the quirks of the hardware, so that the panel can limit the user choices appropriately. To do so, MetaMonitorMode needs to track CRTCs, outputs and modes, so the low level objects have been decoupled from the high-level MetaMonitorInfo, which is used by core and API and offers a simplified view of HW, that hides away the details of what is cloned and how. This is still not efficient as it should be, because on every HW change we drop all data structures and rebuild them from scratch (which is not expensive because there aren't many of them, but at least in the XRandR path it involves a few sync X calls) https://bugzilla.gnome.org/show_bug.cgi?id=705670
2013-07-19 12:39:28 +00:00
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 10:01:15 +00:00
capabilities = meta_monitor_manager_get_capabilities (manager);
use_global_scale =
!!(capabilities & META_MONITOR_MANAGER_CAPABILITY_GLOBAL_SCALE_REQUIRED);
if (use_global_scale)
{
monitor-manager: Pass config to derive from when updating state When we update state, we might not have set the current config yet (for example if the Xrandr assignment didn't change), so pass the monitors config we should derive from instead of fetching it from the monitor config manager. https://bugzilla.gnome.org/show_bug.cgi?id=787477
2017-09-11 06:10:26 +00:00
if (config)
global_scale = derive_configured_global_scale (manager, 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 10:01:15 +00:00
else
global_scale = derive_calculated_global_scale (manager);
}
monitor-manager: Generate logical monitors from monitors Instead of using crtcs and outputs to generate logical monitors, use the ready made monitor abstraction that hides irrelevant things such as monitor tiling etc. https://bugzilla.gnome.org/show_bug.cgi?id=777732
2016-12-13 03:03:22 +00:00
for (l = manager->monitors; l; l = l->next)
Introduce a new DBus interface for display configuration This new interface will be used by the control center and possibly the settings daemon to configure the screens. It is designed to resemble a simplified XRandR, while still exposing all the quirks of the hardware, so that the panel can limit the user choices appropriately. To do so, MetaMonitorMode needs to track CRTCs, outputs and modes, so the low level objects have been decoupled from the high-level MetaMonitorInfo, which is used by core and API and offers a simplified view of HW, that hides away the details of what is cloned and how. This is still not efficient as it should be, because on every HW change we drop all data structures and rebuild them from scratch (which is not expensive because there aren't many of them, but at least in the XRandR path it involves a few sync X calls) https://bugzilla.gnome.org/show_bug.cgi?id=705670
2013-07-19 12:39:28 +00:00
{
monitor-manager: Generate logical monitors from monitors Instead of using crtcs and outputs to generate logical monitors, use the ready made monitor abstraction that hides irrelevant things such as monitor tiling etc. https://bugzilla.gnome.org/show_bug.cgi?id=777732
2016-12-13 03:03:22 +00:00
MetaMonitor *monitor = l->data;
MetaLogicalMonitor *logical_monitor;
MetaRectangle layout;
Introduce a new DBus interface for display configuration This new interface will be used by the control center and possibly the settings daemon to configure the screens. It is designed to resemble a simplified XRandR, while still exposing all the quirks of the hardware, so that the panel can limit the user choices appropriately. To do so, MetaMonitorMode needs to track CRTCs, outputs and modes, so the low level objects have been decoupled from the high-level MetaMonitorInfo, which is used by core and API and offers a simplified view of HW, that hides away the details of what is cloned and how. This is still not efficient as it should be, because on every HW change we drop all data structures and rebuild them from scratch (which is not expensive because there aren't many of them, but at least in the XRandR path it involves a few sync X calls) https://bugzilla.gnome.org/show_bug.cgi?id=705670
2013-07-19 12:39:28 +00:00
monitor-manager: Generate logical monitors from monitors Instead of using crtcs and outputs to generate logical monitors, use the ready made monitor abstraction that hides irrelevant things such as monitor tiling etc. https://bugzilla.gnome.org/show_bug.cgi?id=777732
2016-12-13 03:03:22 +00:00
if (!meta_monitor_is_active (monitor))
Introduce a new DBus interface for display configuration This new interface will be used by the control center and possibly the settings daemon to configure the screens. It is designed to resemble a simplified XRandR, while still exposing all the quirks of the hardware, so that the panel can limit the user choices appropriately. To do so, MetaMonitorMode needs to track CRTCs, outputs and modes, so the low level objects have been decoupled from the high-level MetaMonitorInfo, which is used by core and API and offers a simplified view of HW, that hides away the details of what is cloned and how. This is still not efficient as it should be, because on every HW change we drop all data structures and rebuild them from scratch (which is not expensive because there aren't many of them, but at least in the XRandR path it involves a few sync X calls) https://bugzilla.gnome.org/show_bug.cgi?id=705670
2013-07-19 12:39:28 +00:00
continue;
monitor-manager: Let the MetaMonitor derive the whole layout Instead of letting MetaMonitor derive the logical monitor size, then using the main monitor for the position, just let MetaMonitor derive the whole layout including the position. This means it can deal with tiled monitors better, for example when the main output (the output always active when the monitor is active) is not the origin output (the output with tile position (0, 0)). https://bugzilla.gnome.org/show_bug.cgi?id=781723
2017-07-12 07:42:20 +00:00
meta_monitor_derive_layout (monitor, &layout);
monitor-manager: Generate logical monitors from monitors Instead of using crtcs and outputs to generate logical monitors, use the ready made monitor abstraction that hides irrelevant things such as monitor tiling etc. https://bugzilla.gnome.org/show_bug.cgi?id=777732
2016-12-13 03:03:22 +00:00
logical_monitor = logical_monitor_from_layout (manager, logical_monitors,
&layout);
if (logical_monitor)
Introduce a new DBus interface for display configuration This new interface will be used by the control center and possibly the settings daemon to configure the screens. It is designed to resemble a simplified XRandR, while still exposing all the quirks of the hardware, so that the panel can limit the user choices appropriately. To do so, MetaMonitorMode needs to track CRTCs, outputs and modes, so the low level objects have been decoupled from the high-level MetaMonitorInfo, which is used by core and API and offers a simplified view of HW, that hides away the details of what is cloned and how. This is still not efficient as it should be, because on every HW change we drop all data structures and rebuild them from scratch (which is not expensive because there aren't many of them, but at least in the XRandR path it involves a few sync X calls) https://bugzilla.gnome.org/show_bug.cgi?id=705670
2013-07-19 12:39:28 +00:00
{
monitor-manager: Generate logical monitors from monitors Instead of using crtcs and outputs to generate logical monitors, use the ready made monitor abstraction that hides irrelevant things such as monitor tiling etc. https://bugzilla.gnome.org/show_bug.cgi?id=777732
2016-12-13 03:03:22 +00:00
meta_logical_monitor_add_monitor (logical_monitor, monitor);
Introduce a new DBus interface for display configuration This new interface will be used by the control center and possibly the settings daemon to configure the screens. It is designed to resemble a simplified XRandR, while still exposing all the quirks of the hardware, so that the panel can limit the user choices appropriately. To do so, MetaMonitorMode needs to track CRTCs, outputs and modes, so the low level objects have been decoupled from the high-level MetaMonitorInfo, which is used by core and API and offers a simplified view of HW, that hides away the details of what is cloned and how. This is still not efficient as it should be, because on every HW change we drop all data structures and rebuild them from scratch (which is not expensive because there aren't many of them, but at least in the XRandR path it involves a few sync X calls) https://bugzilla.gnome.org/show_bug.cgi?id=705670
2013-07-19 12:39:28 +00:00
}
monitor-manager: Generate logical monitors from monitors Instead of using crtcs and outputs to generate logical monitors, use the ready made monitor abstraction that hides irrelevant things such as monitor tiling etc. https://bugzilla.gnome.org/show_bug.cgi?id=777732
2016-12-13 03:03:22 +00:00
else
Introduce a new DBus interface for display configuration This new interface will be used by the control center and possibly the settings daemon to configure the screens. It is designed to resemble a simplified XRandR, while still exposing all the quirks of the hardware, so that the panel can limit the user choices appropriately. To do so, MetaMonitorMode needs to track CRTCs, outputs and modes, so the low level objects have been decoupled from the high-level MetaMonitorInfo, which is used by core and API and offers a simplified view of HW, that hides away the details of what is cloned and how. This is still not efficient as it should be, because on every HW change we drop all data structures and rebuild them from scratch (which is not expensive because there aren't many of them, but at least in the XRandR path it involves a few sync X calls) https://bugzilla.gnome.org/show_bug.cgi?id=705670
2013-07-19 12:39:28 +00:00
{
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 08:12:51 +00:00
float scale;
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 10:01:15 +00:00
if (use_global_scale)
scale = global_scale;
monitor-manager: Pass config to derive from when updating state When we update state, we might not have set the current config yet (for example if the Xrandr assignment didn't change), so pass the monitors config we should derive from instead of fetching it from the monitor config manager. https://bugzilla.gnome.org/show_bug.cgi?id=787477
2017-09-11 06:10:26 +00:00
else if (config)
scale = derive_scale_from_config (manager, config, &layout);
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 10:01:15 +00:00
else
scale = calculate_monitor_scale (manager, monitor);
g_assert (scale > 0);
monitor-manager: Split logical monitor creation Split up logical monitor cration into derived (when derived from current underlying configuration) and non-derived (when creating from a logical monitor configuration). This avoids that type of logic in the logical monitor creation function. https://bugzilla.gnome.org/show_bug.cgi?id=779745
2017-03-07 04:34:38 +00:00
logical_monitor = meta_logical_monitor_new_derived (manager,
monitor,
&layout,
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 10:01:15 +00:00
scale,
monitor-manager: Split logical monitor creation Split up logical monitor cration into derived (when derived from current underlying configuration) and non-derived (when creating from a logical monitor configuration). This avoids that type of logic in the logical monitor creation function. https://bugzilla.gnome.org/show_bug.cgi?id=779745
2017-03-07 04:34:38 +00:00
monitor_number);
monitor-manager: Store logical monitors in a GList Instead of storing the logical monitors in an array and having users either look up them in the array given an index or iterate using indices, put it in a GList, and use GList iterators when iterating and alternative API where array indices were previously used. This allows for more liberty regarding the type of the logical monitor. https://bugzilla.gnome.org/show_bug.cgi?id=777732
2016-12-02 08:00:03 +00:00
logical_monitors = g_list_append (logical_monitors, logical_monitor);
monitor_number++;
Introduce a new DBus interface for display configuration This new interface will be used by the control center and possibly the settings daemon to configure the screens. It is designed to resemble a simplified XRandR, while still exposing all the quirks of the hardware, so that the panel can limit the user choices appropriately. To do so, MetaMonitorMode needs to track CRTCs, outputs and modes, so the low level objects have been decoupled from the high-level MetaMonitorInfo, which is used by core and API and offers a simplified view of HW, that hides away the details of what is cloned and how. This is still not efficient as it should be, because on every HW change we drop all data structures and rebuild them from scratch (which is not expensive because there aren't many of them, but at least in the XRandR path it involves a few sync X calls) https://bugzilla.gnome.org/show_bug.cgi?id=705670
2013-07-19 12:39:28 +00:00
}
monitor-manager: Generate logical monitors from monitors Instead of using crtcs and outputs to generate logical monitors, use the ready made monitor abstraction that hides irrelevant things such as monitor tiling etc. https://bugzilla.gnome.org/show_bug.cgi?id=777732
2016-12-13 03:03:22 +00:00
if (meta_monitor_is_primary (monitor))
primary_logical_monitor = logical_monitor;
Introduce a new DBus interface for display configuration This new interface will be used by the control center and possibly the settings daemon to configure the screens. It is designed to resemble a simplified XRandR, while still exposing all the quirks of the hardware, so that the panel can limit the user choices appropriately. To do so, MetaMonitorMode needs to track CRTCs, outputs and modes, so the low level objects have been decoupled from the high-level MetaMonitorInfo, which is used by core and API and offers a simplified view of HW, that hides away the details of what is cloned and how. This is still not efficient as it should be, because on every HW change we drop all data structures and rebuild them from scratch (which is not expensive because there aren't many of them, but at least in the XRandR path it involves a few sync X calls) https://bugzilla.gnome.org/show_bug.cgi?id=705670
2013-07-19 12:39:28 +00:00
}
monitor-manager: Store logical monitors in a GList Instead of storing the logical monitors in an array and having users either look up them in the array given an index or iterate using indices, put it in a GList, and use GList iterators when iterating and alternative API where array indices were previously used. This allows for more liberty regarding the type of the logical monitor. https://bugzilla.gnome.org/show_bug.cgi?id=777732
2016-12-02 08:00:03 +00:00
manager->logical_monitors = logical_monitors;
backend/x11: add support for setting randr 1.5 monitors This interface allows us to propogate back the constructed monitors to randr using the randr 1.5 protocol. Apps should pick it up from there.
2015-03-31 01:11:12 +00:00
MetaMonitorManager: Track primary monitor by pointer instead of index Instead of keeping an index in an array to keep track of the current primary logical monitor, just keep a pointer instead. https://bugzilla.gnome.org/show_bug.cgi?id=777732
2016-11-28 12:43:27 +00:00
/*
* If no monitor was marked as primary, fall back on marking the first
* logical monitor the primary one.
*/
monitor-manager: Generate logical monitors from monitors Instead of using crtcs and outputs to generate logical monitors, use the ready made monitor abstraction that hides irrelevant things such as monitor tiling etc. https://bugzilla.gnome.org/show_bug.cgi?id=777732
2016-12-13 03:03:22 +00:00
if (!primary_logical_monitor && manager->logical_monitors)
primary_logical_monitor = g_list_first (manager->logical_monitors)->data;
meta_monitor_manager_set_primary_logical_monitor (manager,
primary_logical_monitor);
Introduce a new DBus interface for display configuration This new interface will be used by the control center and possibly the settings daemon to configure the screens. It is designed to resemble a simplified XRandR, while still exposing all the quirks of the hardware, so that the panel can limit the user choices appropriately. To do so, MetaMonitorMode needs to track CRTCs, outputs and modes, so the low level objects have been decoupled from the high-level MetaMonitorInfo, which is used by core and API and offers a simplified view of HW, that hides away the details of what is cloned and how. This is still not efficient as it should be, because on every HW change we drop all data structures and rebuild them from scratch (which is not expensive because there aren't many of them, but at least in the XRandR path it involves a few sync X calls) https://bugzilla.gnome.org/show_bug.cgi?id=705670
2013-07-19 12:39:28 +00:00
}
monitor-manager: Make sure to emit PropertiesChanged for PowerSaveMode We overrode the property for PowerSaveMode, which meant that gdbus's auto-generated PropertiesChanged code wasn't being run. This really confused gnome-rr and gnome-settings-daemon's power plugin about the current DPMS state of the display, since they used their cached PowerSaveMode properties, and never saw a PropertiesChanged being emitted. If a display was on, they set it to off, and then set it back on, the setting back on would never fire, since they thought the display was already off. To fix this, remove our custom property override and just respond to notifications on the object. Namely, this fixes the DPMS management when receiving notifications so that it now properly times out.
2014-09-26 01:39:14 +00:00
static void
power_save_mode_changed (MetaMonitorManager *manager,
GParamSpec *pspec,
gpointer user_data)
{
MetaMonitorManagerClass *klass;
int mode = meta_dbus_display_config_get_power_save_mode (META_DBUS_DISPLAY_CONFIG (manager));
if (mode == META_POWER_SAVE_UNSUPPORTED)
return;
/* If DPMS is unsupported, force the property back. */
if (manager->power_save_mode == META_POWER_SAVE_UNSUPPORTED)
{
meta_dbus_display_config_set_power_save_mode (META_DBUS_DISPLAY_CONFIG (manager), META_POWER_SAVE_UNSUPPORTED);
return;
}
klass = META_MONITOR_MANAGER_GET_CLASS (manager);
if (klass->set_power_save_mode)
klass->set_power_save_mode (manager, mode);
manager->power_save_mode = mode;
}
monitor-manager: Move UpClient signal listening into monitor manager Move the UpClients notify::lid-is-closed signal handling into MetaMonitorManager, and put the getter behind a vfunc. This means Placing it behind a vfunc allows custom backends to implement it differently; for example the test backend can mock the state. https://bugzilla.gnome.org/show_bug.cgi?id=777732
2017-01-10 02:38:06 +00:00
void
meta_monitor_manager_lid_is_closed_changed (MetaMonitorManager *manager)
{
Remove old monitor configuration system Remove the old MetaMonitorConfig system and mark the new one as non-experimental. This also removes the D-Bus property. https://bugzilla.gnome.org/show_bug.cgi?id=777732
2017-03-24 07:36:12 +00:00
meta_monitor_manager_ensure_configured (manager);
monitor-manager: Move UpClient signal listening into monitor manager Move the UpClients notify::lid-is-closed signal handling into MetaMonitorManager, and put the getter behind a vfunc. This means Placing it behind a vfunc allows custom backends to implement it differently; for example the test backend can mock the state. https://bugzilla.gnome.org/show_bug.cgi?id=777732
2017-01-10 02:38:06 +00:00
}
static void
backend: Move lid-is-closed handling to MetaBackend Rather than handle UpClient in both MetaBackend (to reset the idletime when the lid is opened), and in MetaMonitorManager and MetaMonitorConfigManager (to turn the screen under the lid on/off depending on its status), move the ability to get the lid status from UPower or mock it in one place, in MetaBackend.
2018-04-16 18:07:45 +00:00
lid_is_closed_changed (MetaBackend *backend,
gboolean lid_is_closed,
gpointer user_data)
monitor-manager: Move UpClient signal listening into monitor manager Move the UpClients notify::lid-is-closed signal handling into MetaMonitorManager, and put the getter behind a vfunc. This means Placing it behind a vfunc allows custom backends to implement it differently; for example the test backend can mock the state. https://bugzilla.gnome.org/show_bug.cgi?id=777732
2017-01-10 02:38:06 +00:00
{
MetaMonitorManager *manager = user_data;
meta_monitor_manager_lid_is_closed_changed (manager);
}
monitor-config-manager: Handle headless setup gracefully Handle headless setup gracefully by having no logical monitors. This commit only makes the monitor management code deal with it; other areas may still not be able to handle it. https://bugzilla.gnome.org/show_bug.cgi?id=777732
2017-01-12 05:47:54 +00:00
gboolean
meta_monitor_manager_is_headless (MetaMonitorManager *manager)
{
backend: Only try to center pointer when there not headless Don't attempt to center the pointer when there is nothing to center on. https://bugzilla.gnome.org/show_bug.cgi?id=730551
2017-04-12 06:09:58 +00:00
return !manager->logical_monitors;
monitor-config-manager: Handle headless setup gracefully Handle headless setup gracefully by having no logical monitors. This commit only makes the monitor management code deal with it; other areas may still not be able to handle it. https://bugzilla.gnome.org/show_bug.cgi?id=777732
2017-01-12 05:47:54 +00:00
}
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 08:12:51 +00:00
float
monitor-manager: Remove 'scale' from MetaOutput Replace the 'scale' of an output with a vfunc on the MetaMonitorManager class that takes a monitor and a monitor mode which calculates the scale. On X11 this always returns 1, on KMS, the old formula is used. On the dummy and test backends, the already configured values are returned. https://bugzilla.gnome.org/show_bug.cgi?id=777732
2017-01-20 07:07:12 +00:00
meta_monitor_manager_calculate_monitor_mode_scale (MetaMonitorManager *manager,
MetaMonitor *monitor,
MetaMonitorMode *monitor_mode)
{
MetaMonitorManagerClass *manager_class =
META_MONITOR_MANAGER_GET_CLASS (manager);
return manager_class->calculate_monitor_mode_scale (manager,
monitor,
monitor_mode);
}
DisplayConfig: Make supported scales per mode This changes the API to pass supported scales per mode instead of providing a global list. This allows for more flexible scaling scenarious, where a scale compatible with one mode can still be made available even though another mode is incompatible. https://bugzilla.gnome.org/show_bug.cgi?id=765011
2017-06-05 07:59:47 +00:00
float *
meta_monitor_manager_calculate_supported_scales (MetaMonitorManager *manager,
MetaLogicalMonitorLayoutMode layout_mode,
MetaMonitor *monitor,
MetaMonitorMode *monitor_mode,
int *n_supported_scales)
monitor-manager: Add supported scales to D-Bus API Let the configuring client know what scales are supported by the display server. https://bugzilla.gnome.org/show_bug.cgi?id=777732
2017-01-26 09:15:52 +00:00
{
MetaMonitorManagerClass *manager_class =
META_MONITOR_MANAGER_GET_CLASS (manager);
DisplayConfig: Make supported scales per mode This changes the API to pass supported scales per mode instead of providing a global list. This allows for more flexible scaling scenarious, where a scale compatible with one mode can still be made available even though another mode is incompatible. https://bugzilla.gnome.org/show_bug.cgi?id=765011
2017-06-05 07:59:47 +00:00
return manager_class->calculate_supported_scales (manager,
layout_mode,
monitor,
monitor_mode,
n_supported_scales);
monitor-manager: Add supported scales to D-Bus API Let the configuring client know what scales are supported by the display server. https://bugzilla.gnome.org/show_bug.cgi?id=777732
2017-01-26 09:15:52 +00:00
}
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 10:01:15 +00:00
MetaMonitorManagerCapability
DisplayConfig: Add 'properties' to GetCurrentState Adds compositor wide DisplayConfig properties bag, and add a "supports-mirroring" property. https://bugzilla.gnome.org/show_bug.cgi?id=777732
2017-02-07 08:03:43 +00:00
meta_monitor_manager_get_capabilities (MetaMonitorManager *manager)
{
MetaMonitorManagerClass *manager_class =
META_MONITOR_MANAGER_GET_CLASS (manager);
return manager_class->get_capabilities (manager);
}
monitor-manager: Make max screen size optional Make the concept of maximum screen size optional, as it is not necessarily a thing on all systems (e.g. when using the native backend and stage views). The meta_monitor_monitor_get_limits() function is replaced by a meta_monitor_manager_get_max_screen_size() which fails when no screen limit is available. Callers and other users of the previous max screen size fields are updated to deal with the fact that the limit is optional. The new D-Bus API is changed to move it to the properties bag, where its absence means there is no applicable limit. https://bugzilla.gnome.org/show_bug.cgi?id=777732
2017-02-15 08:06:46 +00:00
gboolean
meta_monitor_manager_get_max_screen_size (MetaMonitorManager *manager,
int *max_width,
int *max_height)
{
MetaMonitorManagerClass *manager_class =
META_MONITOR_MANAGER_GET_CLASS (manager);
return manager_class->get_max_screen_size (manager, max_width, max_height);
}
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 10:10:52 +00:00
MetaLogicalMonitorLayoutMode
meta_monitor_manager_get_default_layout_mode (MetaMonitorManager *manager)
{
MetaMonitorManagerClass *manager_class =
META_MONITOR_MANAGER_GET_CLASS (manager);
return manager_class->get_default_layout_mode (manager);
}
monitor-manager: Let backend implementations handle inital config How the initial configuration is done depends on the backend, so let them do it themself. https://bugzilla.gnome.org/show_bug.cgi?id=777732
2017-01-06 05:27:21 +00:00
static void
meta_monitor_manager_ensure_initial_config (MetaMonitorManager *manager)
{
META_MONITOR_MANAGER_GET_CLASS (manager)->ensure_initial_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 06:31:18 +00:00
static gboolean
DisplayConfig: Add new API for configuring monitors Add a new D-Bus API that uses the state from GetCurrentState to configure high level monitors, instead of low level CRTCs and connectors. So far persistent configuration is not implemented, as writing to the configuration store is still not supported. https://bugzilla.gnome.org/show_bug.cgi?id=777732
2017-02-14 11:54:04 +00:00
meta_monitor_manager_apply_monitors_config (MetaMonitorManager *manager,
MetaMonitorsConfig *config,
MetaMonitorsConfigMethod method,
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 06:31:18 +00:00
{
MetaMonitorManagerClass *manager_class =
META_MONITOR_MANAGER_GET_CLASS (manager);
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 07:12:41 +00:00
g_assert (!config ||
!(config->flags & META_MONITORS_CONFIG_FLAG_MIGRATED));
monitor-manager: Always set current config when apply succeeds No reason making any caller do it. https://bugzilla.gnome.org/show_bug.cgi?id=777732
2017-02-24 09:09:19 +00:00
if (!manager_class->apply_monitors_config (manager, config, method, error))
return FALSE;
monitor-manager: Don't set current config if only verifying When verifying if a configuration is applicable, don't set it as current when applying succeeded, or else reverting to a previous configuration doesn't work after having verified. https://bugzilla.gnome.org/show_bug.cgi?id=765011
2017-06-14 10:40:53 +00:00
switch (method)
{
case META_MONITORS_CONFIG_METHOD_TEMPORARY:
case META_MONITORS_CONFIG_METHOD_PERSISTENT:
meta_monitor_config_manager_set_current (manager->config_manager, config);
break;
case META_MONITORS_CONFIG_METHOD_VERIFY:
break;
}
monitor-manager: Always set current config when apply succeeds No reason making any caller do it. https://bugzilla.gnome.org/show_bug.cgi?id=777732
2017-02-24 09:09:19 +00:00
return TRUE;
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 06:31:18 +00:00
}
monitor-manager: Move meta_monitor_manager_ function to right place Move a meta_monitor_manager_ function to meta-monitor-manager.c where it belongs. https://bugzilla.gnome.org/show_bug.cgi?id=777732
2016-12-19 07:56:50 +00:00
gboolean
meta_monitor_manager_has_hotplug_mode_update (MetaMonitorManager *manager)
{
Make MetaOutput a GObject Turn MetaOutput into a GObject and move it to a separate file. This changes the storage format, resulting in changing the API for accessing MetaOutputs from using an array, to using a GList. https://bugzilla.gnome.org/show_bug.cgi?id=785381
2017-03-24 09:35:51 +00:00
GList *l;
monitor-manager: Move meta_monitor_manager_ function to right place Move a meta_monitor_manager_ function to meta-monitor-manager.c where it belongs. https://bugzilla.gnome.org/show_bug.cgi?id=777732
2016-12-19 07:56:50 +00:00
backends: Split out CRTC/output management to MetaGpu In order to eventually support multilpe GPUs with their own connectors, split out related meta data management (i.e. outputs, CRTCs and CRTC modes) into a new MetaGpu GObject. The Xrandr backend always assumes there is always only a single "GPU" as the GPU is abstracted by the X server; only the native backend (aside from the test backend) will eventually see more than one GPU. The Xrandr backend still moves some management to MetaGpuXrandr, in order to behave more similarly to the KMS counterparts. https://bugzilla.gnome.org/show_bug.cgi?id=785381
2017-07-10 10:19:32 +00:00
for (l = manager->gpus; l; l = l->next)
monitor-manager: Move meta_monitor_manager_ function to right place Move a meta_monitor_manager_ function to meta-monitor-manager.c where it belongs. https://bugzilla.gnome.org/show_bug.cgi?id=777732
2016-12-19 07:56:50 +00:00
{
backends: Split out CRTC/output management to MetaGpu In order to eventually support multilpe GPUs with their own connectors, split out related meta data management (i.e. outputs, CRTCs and CRTC modes) into a new MetaGpu GObject. The Xrandr backend always assumes there is always only a single "GPU" as the GPU is abstracted by the X server; only the native backend (aside from the test backend) will eventually see more than one GPU. The Xrandr backend still moves some management to MetaGpuXrandr, in order to behave more similarly to the KMS counterparts. https://bugzilla.gnome.org/show_bug.cgi?id=785381
2017-07-10 10:19:32 +00:00
MetaGpu *gpu = l->data;
monitor-manager: Move meta_monitor_manager_ function to right place Move a meta_monitor_manager_ function to meta-monitor-manager.c where it belongs. https://bugzilla.gnome.org/show_bug.cgi?id=777732
2016-12-19 07:56:50 +00:00
backends: Split out CRTC/output management to MetaGpu In order to eventually support multilpe GPUs with their own connectors, split out related meta data management (i.e. outputs, CRTCs and CRTC modes) into a new MetaGpu GObject. The Xrandr backend always assumes there is always only a single "GPU" as the GPU is abstracted by the X server; only the native backend (aside from the test backend) will eventually see more than one GPU. The Xrandr backend still moves some management to MetaGpuXrandr, in order to behave more similarly to the KMS counterparts. https://bugzilla.gnome.org/show_bug.cgi?id=785381
2017-07-10 10:19:32 +00:00
if (meta_gpu_has_hotplug_mode_update (gpu))
monitor-manager: Move meta_monitor_manager_ function to right place Move a meta_monitor_manager_ function to meta-monitor-manager.c where it belongs. https://bugzilla.gnome.org/show_bug.cgi?id=777732
2016-12-19 07:56:50 +00:00
return TRUE;
}
return FALSE;
}
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-13 03:01:27 +00:00
static gboolean
should_use_stored_config (MetaMonitorManager *manager)
{
MetaMonitorManager: ignore hotplug_mode_update at startup hotplug_mode_update is used (mostly by VMs nowadays, and VMware has implemented it) to inform that modes list (including the preferred one) might change after an uevent. However, when using MetaMonitorConfigManager we should ignore this value at initialization level, or mutter won't restore the configured values at startup. https://bugzilla.gnome.org/show_bug.cgi?id=783073
2017-05-25 05:15:06 +00:00
return (manager->in_init ||
!meta_monitor_manager_has_hotplug_mode_update (manager));
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-13 03:01:27 +00:00
}
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 06:31:18 +00:00
MetaMonitorsConfig *
monitor-manager: Let backend implementations handle inital config How the initial configuration is done depends on the backend, so let them do it themself. https://bugzilla.gnome.org/show_bug.cgi?id=777732
2017-01-06 05:27:21 +00:00
meta_monitor_manager_ensure_configured (MetaMonitorManager *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 06:31:18 +00:00
MetaMonitorsConfig *config = NULL;
GError *error = NULL;
DisplayConfig: Add new API for configuring monitors Add a new D-Bus API that uses the state from GetCurrentState to configure high level monitors, instead of low level CRTCs and connectors. So far persistent configuration is not implemented, as writing to the configuration store is still not supported. https://bugzilla.gnome.org/show_bug.cgi?id=777732
2017-02-14 11:54:04 +00:00
gboolean use_stored_config;
MetaMonitorsConfigMethod method;
MetaMonitorsConfigMethod fallback_method =
META_MONITORS_CONFIG_METHOD_TEMPORARY;
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 06:31:18 +00:00
DisplayConfig: Add new API for configuring monitors Add a new D-Bus API that uses the state from GetCurrentState to configure high level monitors, instead of low level CRTCs and connectors. So far persistent configuration is not implemented, as writing to the configuration store is still not supported. https://bugzilla.gnome.org/show_bug.cgi?id=777732
2017-02-14 11:54:04 +00:00
use_stored_config = should_use_stored_config (manager);
if (use_stored_config)
method = META_MONITORS_CONFIG_METHOD_PERSISTENT;
else
method = META_MONITORS_CONFIG_METHOD_TEMPORARY;
if (use_stored_config)
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-13 03:01:27 +00:00
{
config = meta_monitor_config_manager_get_stored (manager->config_manager);
if (config)
{
DisplayConfig: Add new API for configuring monitors Add a new D-Bus API that uses the state from GetCurrentState to configure high level monitors, instead of low level CRTCs and connectors. So far persistent configuration is not implemented, as writing to the configuration store is still not supported. https://bugzilla.gnome.org/show_bug.cgi?id=777732
2017-02-14 11:54:04 +00:00
if (!meta_monitor_manager_apply_monitors_config (manager,
config,
method,
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-13 03:01:27 +00:00
&error))
{
config = NULL;
g_warning ("Failed to use stored monitor configuration: %s",
error->message);
g_clear_error (&error);
}
else
{
g_object_ref (config);
goto done;
}
}
}
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 07:38:17 +00:00
config = meta_monitor_config_manager_create_suggested (manager->config_manager);
if (config)
{
DisplayConfig: Add new API for configuring monitors Add a new D-Bus API that uses the state from GetCurrentState to configure high level monitors, instead of low level CRTCs and connectors. So far persistent configuration is not implemented, as writing to the configuration store is still not supported. https://bugzilla.gnome.org/show_bug.cgi?id=777732
2017-02-14 11:54:04 +00:00
if (!meta_monitor_manager_apply_monitors_config (manager,
config,
method,
&error))
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 07:38:17 +00:00
{
g_clear_object (&config);
g_warning ("Failed to use suggested monitor configuration: %s",
error->message);
g_clear_error (&error);
}
else
{
goto done;
}
}
monitor-manager: Try to restore previous config before regenerating When opening a laptop lid, one will likely want to restore the configuration one had prior to closing it, so when ensuring monitor configuration, first try to see if the previously set configuration is both complete (all connected monitors are configured) and applicable (it is a valid configuration) and only try to generate a new from scratch if that failed. https://bugzilla.gnome.org/show_bug.cgi?id=777732
2017-08-11 07:21:36 +00:00
config = meta_monitor_config_manager_get_previous (manager->config_manager);
if (config)
{
config = g_object_ref (config);
if (meta_monitor_manager_is_config_complete (manager, config))
{
if (!meta_monitor_manager_apply_monitors_config (manager,
config,
method,
&error))
{
g_warning ("Failed to use suggested monitor configuration: %s",
error->message);
g_clear_error (&error);
}
else
{
goto done;
}
}
g_clear_object (&config);
}
monitor-manager: use MonitorsConfig to track switch_config When constructing MetaMonitorsConfig objects, store which type of switch_config they are for (or UNKNOWN if it is not such type of config). Stop unconditionally setting current_switch_config to UNKNOWN when handling monitors changed events. Instead, set it to the switch_config type stored in the MonitorsConfig in the codepath that updates logical state. In addition to being called in the hotplug case along the same code flow that generates monitors changed events, this is also called in the coldplug case where a secondary monitor was connected before mutter was started. When creating the default linear display config, create it as a switch_config so that internal state gets updated to represent linear mode when this config is used. The previous behaviour of unconditionally resetting current_switch_config to UNKNOWN was breaking the internal state machine for display config switching, causing misbehaviour in gnome-shell's switchMonitor UI when using display switch hotkeys. The lack of internal tracking when the displays are already in the default "Join Displays" linear mode was then causing the first display switch hotkey press to do nothing (it would attempt to select "Join Displays" mode, but that was already active). Fixes: https://gitlab.gnome.org/GNOME/mutter/issues/281 https://gitlab.gnome.org/GNOME/mutter/merge_requests/213
2018-08-30 00:34:53 +00:00
config =
meta_monitor_config_manager_create_for_switch_config (manager->config_manager,
META_MONITOR_SWITCH_CONFIG_ALL_LINEAR);
monitor-config-manager: Handle headless setup gracefully Handle headless setup gracefully by having no logical monitors. This commit only makes the monitor management code deal with it; other areas may still not be able to handle it. https://bugzilla.gnome.org/show_bug.cgi?id=777732
2017-01-12 05:47:54 +00:00
if (config)
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 06:31:18 +00:00
{
DisplayConfig: Add new API for configuring monitors Add a new D-Bus API that uses the state from GetCurrentState to configure high level monitors, instead of low level CRTCs and connectors. So far persistent configuration is not implemented, as writing to the configuration store is still not supported. https://bugzilla.gnome.org/show_bug.cgi?id=777732
2017-02-14 11:54:04 +00:00
if (!meta_monitor_manager_apply_monitors_config (manager,
config,
method,
&error))
monitor-config-manager: Handle headless setup gracefully Handle headless setup gracefully by having no logical monitors. This commit only makes the monitor management code deal with it; other areas may still not be able to handle it. https://bugzilla.gnome.org/show_bug.cgi?id=777732
2017-01-12 05:47:54 +00:00
{
g_clear_object (&config);
monitor-manager: Add back warning messages For some reason "backends: Remove X11 idle-monitor backend" removed unrelated warning messages for when generated monitor configurations that should work didn't, which also made the unit tests fail. This commit adds them back, which also makes the tests pass again.
2018-04-24 13:25:56 +00:00
g_warning ("Failed to use linear monitor configuration: %s",
error->message);
monitor-config-manager: Handle headless setup gracefully Handle headless setup gracefully by having no logical monitors. This commit only makes the monitor management code deal with it; other areas may still not be able to handle it. https://bugzilla.gnome.org/show_bug.cgi?id=777732
2017-01-12 05:47:54 +00:00
g_clear_error (&error);
}
else
{
goto done;
}
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 06:31:18 +00:00
}
config = meta_monitor_config_manager_create_fallback (manager->config_manager);
monitor-config-manager: Handle headless setup gracefully Handle headless setup gracefully by having no logical monitors. This commit only makes the monitor management code deal with it; other areas may still not be able to handle it. https://bugzilla.gnome.org/show_bug.cgi?id=777732
2017-01-12 05:47:54 +00:00
if (config)
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 06:31:18 +00:00
{
DisplayConfig: Add new API for configuring monitors Add a new D-Bus API that uses the state from GetCurrentState to configure high level monitors, instead of low level CRTCs and connectors. So far persistent configuration is not implemented, as writing to the configuration store is still not supported. https://bugzilla.gnome.org/show_bug.cgi?id=777732
2017-02-14 11:54:04 +00:00
if (!meta_monitor_manager_apply_monitors_config (manager,
config,
fallback_method,
&error))
monitor-config-manager: Handle headless setup gracefully Handle headless setup gracefully by having no logical monitors. This commit only makes the monitor management code deal with it; other areas may still not be able to handle it. https://bugzilla.gnome.org/show_bug.cgi?id=777732
2017-01-12 05:47:54 +00:00
{
g_clear_object (&config);
monitor-manager: Add back warning messages For some reason "backends: Remove X11 idle-monitor backend" removed unrelated warning messages for when generated monitor configurations that should work didn't, which also made the unit tests fail. This commit adds them back, which also makes the tests pass again.
2018-04-24 13:25:56 +00:00
g_warning ("Failed to use fallback monitor configuration: %s",
error->message);
monitor-config-manager: Handle headless setup gracefully Handle headless setup gracefully by having no logical monitors. This commit only makes the monitor management code deal with it; other areas may still not be able to handle it. https://bugzilla.gnome.org/show_bug.cgi?id=777732
2017-01-12 05:47:54 +00:00
g_clear_error (&error);
}
else
{
goto done;
}
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 06:31:18 +00:00
}
done:
if (!config)
monitor-config-manager: Handle headless setup gracefully Handle headless setup gracefully by having no logical monitors. This commit only makes the monitor management code deal with it; other areas may still not be able to handle it. https://bugzilla.gnome.org/show_bug.cgi?id=777732
2017-01-12 05:47:54 +00:00
{
DisplayConfig: Add new API for configuring monitors Add a new D-Bus API that uses the state from GetCurrentState to configure high level monitors, instead of low level CRTCs and connectors. So far persistent configuration is not implemented, as writing to the configuration store is still not supported. https://bugzilla.gnome.org/show_bug.cgi?id=777732
2017-02-14 11:54:04 +00:00
meta_monitor_manager_apply_monitors_config (manager,
NULL,
fallback_method,
&error);
monitor-config-manager: Handle headless setup gracefully Handle headless setup gracefully by having no logical monitors. This commit only makes the monitor management code deal with it; other areas may still not be able to handle it. https://bugzilla.gnome.org/show_bug.cgi?id=777732
2017-01-12 05:47:54 +00:00
return NULL;
}
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 06:31:18 +00:00
g_object_unref (config);
return config;
monitor-manager: Let backend implementations handle inital config How the initial configuration is done depends on the backend, so let them do it themself. https://bugzilla.gnome.org/show_bug.cgi?id=777732
2017-01-06 05:27:21 +00:00
}
monitor-manager: Hook MetaOrientationManager to change the config On orientation changes we'll apply the appropriate monitor transform to the current configuration if possible. https://bugzilla.gnome.org/show_bug.cgi?id=781906
2017-04-28 15:53:07 +00:00
static void
orientation_changed (MetaOrientationManager *orientation_manager,
MetaMonitorManager *manager)
{
MetaMonitorTransform transform;
Remove old monitor configuration system Remove the old MetaMonitorConfig system and mark the new one as non-experimental. This also removes the D-Bus property. https://bugzilla.gnome.org/show_bug.cgi?id=777732
2017-03-24 07:36:12 +00:00
GError *error = NULL;
MetaMonitorsConfig *config;
monitor-manager: Hook MetaOrientationManager to change the config On orientation changes we'll apply the appropriate monitor transform to the current configuration if possible. https://bugzilla.gnome.org/show_bug.cgi?id=781906
2017-04-28 15:53:07 +00:00
switch (meta_orientation_manager_get_orientation (orientation_manager))
{
case META_ORIENTATION_NORMAL:
transform = META_MONITOR_TRANSFORM_NORMAL;
break;
case META_ORIENTATION_BOTTOM_UP:
transform = META_MONITOR_TRANSFORM_180;
break;
case META_ORIENTATION_LEFT_UP:
transform = META_MONITOR_TRANSFORM_90;
break;
case META_ORIENTATION_RIGHT_UP:
transform = META_MONITOR_TRANSFORM_270;
break;
case META_ORIENTATION_UNDEFINED:
monitor-manager: Shut up a compiler warning Add a default switch statement to make it clear that 'transform' won't be used uninitialized.
2017-07-14 14:54:53 +00:00
default:
monitor-manager: Hook MetaOrientationManager to change the config On orientation changes we'll apply the appropriate monitor transform to the current configuration if possible. https://bugzilla.gnome.org/show_bug.cgi?id=781906
2017-04-28 15:53:07 +00:00
return;
}
Remove old monitor configuration system Remove the old MetaMonitorConfig system and mark the new one as non-experimental. This also removes the D-Bus property. https://bugzilla.gnome.org/show_bug.cgi?id=777732
2017-03-24 07:36:12 +00:00
config =
meta_monitor_config_manager_create_for_orientation (manager->config_manager,
transform);
if (!config)
return;
monitor-manager: Hook MetaOrientationManager to change the config On orientation changes we'll apply the appropriate monitor transform to the current configuration if possible. https://bugzilla.gnome.org/show_bug.cgi?id=781906
2017-04-28 15:53:07 +00:00
Remove old monitor configuration system Remove the old MetaMonitorConfig system and mark the new one as non-experimental. This also removes the D-Bus property. https://bugzilla.gnome.org/show_bug.cgi?id=777732
2017-03-24 07:36:12 +00:00
if (!meta_monitor_manager_apply_monitors_config (manager,
config,
META_MONITORS_CONFIG_METHOD_TEMPORARY,
&error))
{
g_warning ("Failed to use orientation monitor configuration: %s",
error->message);
g_error_free (error);
monitor-manager: Hook MetaOrientationManager to change the config On orientation changes we'll apply the appropriate monitor transform to the current configuration if possible. https://bugzilla.gnome.org/show_bug.cgi?id=781906
2017-04-28 15:53:07 +00:00
}
Remove old monitor configuration system Remove the old MetaMonitorConfig system and mark the new one as non-experimental. This also removes the D-Bus property. https://bugzilla.gnome.org/show_bug.cgi?id=777732
2017-03-24 07:36:12 +00:00
g_object_unref (config);
monitor-manager: Hook MetaOrientationManager to change the config On orientation changes we'll apply the appropriate monitor transform to the current configuration if possible. https://bugzilla.gnome.org/show_bug.cgi?id=781906
2017-04-28 15:53:07 +00:00
}
monitor-manager: Make the config manager an 'experimental feature' Instead of using a environment variable, add a new 'experimental feature' gsetting keyword "monitor-config-manager" that enables the use of the new MetaMonitorConfigManager. This commit also makes it possible to switch between the two systems without restarting mutter. The D-Bus API is disabled when the experimental feature is not enabled, and clients trying to access it will get a access-denied error in response. A new property 'IsExperimentalApiEnabled' is added to let the D-Bus client know whether it is possible to use the experimental API or not. https://bugzilla.gnome.org/show_bug.cgi?id=777732
2017-03-04 07:30:56 +00:00
static void
backend: Move settings into a new MetaSettings object Introduce MetaSettings and add the settings managed by MetaBackend into the new object. These settings include: experimental-features and UI scaling factor. https://bugzilla.gnome.org/show_bug.cgi?id=777732
2017-04-21 08:40:51 +00:00
experimental_features_changed (MetaSettings *settings,
monitor-manager: Reconfigure when 'scale-monitor-framebuffer' is toggled When the experimental feature 'scale-monitor-framebuffer' is enabled or disabled, reconfigure the monitors. https://bugzilla.gnome.org/show_bug.cgi?id=777732
2017-04-07 13:05:26 +00:00
MetaExperimentalFeature old_experimental_features,
MetaMonitorManager *manager)
monitor-manager: Make the config manager an 'experimental feature' Instead of using a environment variable, add a new 'experimental feature' gsetting keyword "monitor-config-manager" that enables the use of the new MetaMonitorConfigManager. This commit also makes it possible to switch between the two systems without restarting mutter. The D-Bus API is disabled when the experimental feature is not enabled, and clients trying to access it will get a access-denied error in response. A new property 'IsExperimentalApiEnabled' is added to let the D-Bus client know whether it is possible to use the experimental API or not. https://bugzilla.gnome.org/show_bug.cgi?id=777732
2017-03-04 07:30:56 +00:00
{
monitor-manager: Reconfigure when 'scale-monitor-framebuffer' is toggled When the experimental feature 'scale-monitor-framebuffer' is enabled or disabled, reconfigure the monitors. https://bugzilla.gnome.org/show_bug.cgi?id=777732
2017-04-07 13:05:26 +00:00
gboolean was_stage_views_scaled;
gboolean is_stage_views_scaled;
gboolean should_reconfigure = FALSE;
monitor-manager: Make the config manager an 'experimental feature' Instead of using a environment variable, add a new 'experimental feature' gsetting keyword "monitor-config-manager" that enables the use of the new MetaMonitorConfigManager. This commit also makes it possible to switch between the two systems without restarting mutter. The D-Bus API is disabled when the experimental feature is not enabled, and clients trying to access it will get a access-denied error in response. A new property 'IsExperimentalApiEnabled' is added to let the D-Bus client know whether it is possible to use the experimental API or not. https://bugzilla.gnome.org/show_bug.cgi?id=777732
2017-03-04 07:30:56 +00:00
monitor-manager: Reconfigure when 'scale-monitor-framebuffer' is toggled When the experimental feature 'scale-monitor-framebuffer' is enabled or disabled, reconfigure the monitors. https://bugzilla.gnome.org/show_bug.cgi?id=777732
2017-04-07 13:05:26 +00:00
was_stage_views_scaled =
!!(old_experimental_features &
META_EXPERIMENTAL_FEATURE_SCALE_MONITOR_FRAMEBUFFER);
is_stage_views_scaled =
backend: Move settings into a new MetaSettings object Introduce MetaSettings and add the settings managed by MetaBackend into the new object. These settings include: experimental-features and UI scaling factor. https://bugzilla.gnome.org/show_bug.cgi?id=777732
2017-04-21 08:40:51 +00:00
meta_settings_is_experimental_feature_enabled (
settings,
monitor-manager: Reconfigure when 'scale-monitor-framebuffer' is toggled When the experimental feature 'scale-monitor-framebuffer' is enabled or disabled, reconfigure the monitors. https://bugzilla.gnome.org/show_bug.cgi?id=777732
2017-04-07 13:05:26 +00:00
META_EXPERIMENTAL_FEATURE_SCALE_MONITOR_FRAMEBUFFER);
Remove old monitor configuration system Remove the old MetaMonitorConfig system and mark the new one as non-experimental. This also removes the D-Bus property. https://bugzilla.gnome.org/show_bug.cgi?id=777732
2017-03-24 07:36:12 +00:00
if (is_stage_views_scaled != was_stage_views_scaled)
monitor-manager: Reconfigure when 'scale-monitor-framebuffer' is toggled When the experimental feature 'scale-monitor-framebuffer' is enabled or disabled, reconfigure the monitors. https://bugzilla.gnome.org/show_bug.cgi?id=777732
2017-04-07 13:05:26 +00:00
should_reconfigure = TRUE;
if (should_reconfigure)
meta_monitor_manager_on_hotplug (manager);
backend: Move settings into a new MetaSettings object Introduce MetaSettings and add the settings managed by MetaBackend into the new object. These settings include: experimental-features and UI scaling factor. https://bugzilla.gnome.org/show_bug.cgi?id=777732
2017-04-21 08:40:51 +00:00
meta_settings_update_ui_scaling_factor (settings);
monitor-manager: Make the config manager an 'experimental feature' Instead of using a environment variable, add a new 'experimental feature' gsetting keyword "monitor-config-manager" that enables the use of the new MetaMonitorConfigManager. This commit also makes it possible to switch between the two systems without restarting mutter. The D-Bus API is disabled when the experimental feature is not enabled, and clients trying to access it will get a access-denied error in response. A new property 'IsExperimentalApiEnabled' is added to let the D-Bus client know whether it is possible to use the experimental API or not. https://bugzilla.gnome.org/show_bug.cgi?id=777732
2017-03-04 07:30:56 +00:00
}
backends: Split monitor manager creation into create and setup The monitor manager instance was created and setup in one step; at construction. This is problematic if, in the future, the monitor manager creation can fail, as the monitor manager is created quite late. To make it possible to in the future fail creating a monitor manager, create the instance very early when initiating the backend, then on post init backend setup, "setup" the monitor manager state, i.e. read the current state and setup the stage. https://bugzilla.gnome.org/show_bug.cgi?id=785381
2017-07-05 10:06:06 +00:00
void
meta_monitor_manager_setup (MetaMonitorManager *manager)
{
manager->in_init = TRUE;
manager->config_manager = meta_monitor_config_manager_new (manager);
meta_monitor_manager_read_current_state (manager);
meta_monitor_manager_ensure_initial_config (manager);
manager->in_init = FALSE;
}
MonitorManager: split the XRandR parts in a subclass Instead of keeping a forest of if backend else ..., use a subclass and virtual functions to discriminate between XRandR and the dummy backend (which lives in the parent class togheter with the common code) https://bugzilla.gnome.org/show_bug.cgi?id=705670
2013-07-29 11:00:15 +00:00
static void
meta_monitor_manager_constructed (GObject *object)
{
MetaMonitorManager *manager = META_MONITOR_MANAGER (object);
monitor-manager: Keep pointer to backend Instead of accessing the global singleton, keep a pointer to the backend in the MetaMonitorManager struct. https://bugzilla.gnome.org/show_bug.cgi?id=785381
2017-07-10 09:39:07 +00:00
MetaBackend *backend = manager->backend;
backend: Move settings into a new MetaSettings object Introduce MetaSettings and add the settings managed by MetaBackend into the new object. These settings include: experimental-features and UI scaling factor. https://bugzilla.gnome.org/show_bug.cgi?id=777732
2017-04-21 08:40:51 +00:00
MetaSettings *settings = meta_backend_get_settings (backend);
monitor-manager: Move UpClient signal listening into monitor manager Move the UpClients notify::lid-is-closed signal handling into MetaMonitorManager, and put the getter behind a vfunc. This means Placing it behind a vfunc allows custom backends to implement it differently; for example the test backend can mock the state. https://bugzilla.gnome.org/show_bug.cgi?id=777732
2017-01-10 02:38:06 +00:00
monitor-manager: Make the config manager an 'experimental feature' Instead of using a environment variable, add a new 'experimental feature' gsetting keyword "monitor-config-manager" that enables the use of the new MetaMonitorConfigManager. This commit also makes it possible to switch between the two systems without restarting mutter. The D-Bus API is disabled when the experimental feature is not enabled, and clients trying to access it will get a access-denied error in response. A new property 'IsExperimentalApiEnabled' is added to let the D-Bus client know whether it is possible to use the experimental API or not. https://bugzilla.gnome.org/show_bug.cgi?id=777732
2017-03-04 07:30:56 +00:00
manager->experimental_features_changed_handler_id =
backend: Move settings into a new MetaSettings object Introduce MetaSettings and add the settings managed by MetaBackend into the new object. These settings include: experimental-features and UI scaling factor. https://bugzilla.gnome.org/show_bug.cgi?id=777732
2017-04-21 08:40:51 +00:00
g_signal_connect (settings,
monitor-manager: Make the config manager an 'experimental feature' Instead of using a environment variable, add a new 'experimental feature' gsetting keyword "monitor-config-manager" that enables the use of the new MetaMonitorConfigManager. This commit also makes it possible to switch between the two systems without restarting mutter. The D-Bus API is disabled when the experimental feature is not enabled, and clients trying to access it will get a access-denied error in response. A new property 'IsExperimentalApiEnabled' is added to let the D-Bus client know whether it is possible to use the experimental API or not. https://bugzilla.gnome.org/show_bug.cgi?id=777732
2017-03-04 07:30:56 +00:00
"experimental-features-changed",
G_CALLBACK (experimental_features_changed),
manager);
monitor-manager: Make sure to emit PropertiesChanged for PowerSaveMode We overrode the property for PowerSaveMode, which meant that gdbus's auto-generated PropertiesChanged code wasn't being run. This really confused gnome-rr and gnome-settings-daemon's power plugin about the current DPMS state of the display, since they used their cached PowerSaveMode properties, and never saw a PropertiesChanged being emitted. If a display was on, they set it to off, and then set it back on, the setting back on would never fire, since they thought the display was already off. To fix this, remove our custom property override and just respond to notifications on the object. Namely, this fixes the DPMS management when receiving notifications so that it now properly times out.
2014-09-26 01:39:14 +00:00
g_signal_connect_object (manager, "notify::power-save-mode",
G_CALLBACK (power_save_mode_changed), manager, 0);
monitor-manager: Hook MetaOrientationManager to change the config On orientation changes we'll apply the appropriate monitor transform to the current configuration if possible. https://bugzilla.gnome.org/show_bug.cgi?id=781906
2017-04-28 15:53:07 +00:00
g_signal_connect_object (meta_backend_get_orientation_manager (backend),
"orientation-changed",
G_CALLBACK (orientation_changed),
manager, 0);
backend: Move lid-is-closed handling to MetaBackend Rather than handle UpClient in both MetaBackend (to reset the idletime when the lid is opened), and in MetaMonitorManager and MetaMonitorConfigManager (to turn the screen under the lid on/off depending on its status), move the ability to get the lid status from UPower or mock it in one place, in MetaBackend.
2018-04-16 18:07:45 +00:00
g_signal_connect_object (backend,
"lid-is-closed-changed",
G_CALLBACK (lid_is_closed_changed),
manager, 0);
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 16:38:10 +00:00
manager->current_switch_config = META_MONITOR_SWITCH_CONFIG_UNKNOWN;
MonitorConfig: add support for default configurations Activate the presentation bit on new hotplugged monitors, while making a fully extended setup when running for the first time. https://bugzilla.gnome.org/show_bug.cgi?id=705670
2013-07-25 08:57:59 +00:00
MonitorManager: split the XRandR parts in a subclass Instead of keeping a forest of if backend else ..., use a subclass and virtual functions to discriminate between XRandR and the dummy backend (which lives in the parent class togheter with the common code) https://bugzilla.gnome.org/show_bug.cgi?id=705670
2013-07-29 11:00:15 +00:00
initialize_dbus_interface (manager);
Rework and consolidate monitor handling in MetaScreen Consolidate all places that deal with output configuration in MetaScreen, which gets it either from XRandR or from a dummy static configuration. We still need to read the Xinerama config, even when running xwayland, because we need the indices for _NET_WM_FULLSCREEN_MONITORS, but now we do it only when needed. https://bugzilla.gnome.org/show_bug.cgi?id=705670
2013-07-18 11:09:16 +00:00
}
static void
meta_monitor_manager_finalize (GObject *object)
{
MetaMonitorManager *manager = META_MONITOR_MANAGER (object);
backends: Split out CRTC/output management to MetaGpu In order to eventually support multilpe GPUs with their own connectors, split out related meta data management (i.e. outputs, CRTCs and CRTC modes) into a new MetaGpu GObject. The Xrandr backend always assumes there is always only a single "GPU" as the GPU is abstracted by the X server; only the native backend (aside from the test backend) will eventually see more than one GPU. The Xrandr backend still moves some management to MetaGpuXrandr, in order to behave more similarly to the KMS counterparts. https://bugzilla.gnome.org/show_bug.cgi?id=785381
2017-07-10 10:19:32 +00:00
g_list_free_full (manager->gpus, g_object_unref);
Turn MetaLogicalMonitor into a GObject This will make it easier to move various manually managed data and data now in MetaLogicalMonitor into GObject QData fields. https://bugzilla.gnome.org/show_bug.cgi?id=777732
2016-12-02 08:08:59 +00:00
g_list_free_full (manager->logical_monitors, g_object_unref);
Rework and consolidate monitor handling in MetaScreen Consolidate all places that deal with output configuration in MetaScreen, which gets it either from XRandR or from a dummy static configuration. We still need to read the Xinerama config, even when running xwayland, because we need the indices for _NET_WM_FULLSCREEN_MONITORS, but now we do it only when needed. https://bugzilla.gnome.org/show_bug.cgi?id=705670
2013-07-18 11:09:16 +00:00
monitor-manager: Keep pointer to backend Instead of accessing the global singleton, keep a pointer to the backend in the MetaMonitorManager struct. https://bugzilla.gnome.org/show_bug.cgi?id=785381
2017-07-10 09:39:07 +00:00
g_signal_handler_disconnect (manager->backend,
monitor-manager: Make the config manager an 'experimental feature' Instead of using a environment variable, add a new 'experimental feature' gsetting keyword "monitor-config-manager" that enables the use of the new MetaMonitorConfigManager. This commit also makes it possible to switch between the two systems without restarting mutter. The D-Bus API is disabled when the experimental feature is not enabled, and clients trying to access it will get a access-denied error in response. A new property 'IsExperimentalApiEnabled' is added to let the D-Bus client know whether it is possible to use the experimental API or not. https://bugzilla.gnome.org/show_bug.cgi?id=777732
2017-03-04 07:30:56 +00:00
manager->experimental_features_changed_handler_id);
Rework and consolidate monitor handling in MetaScreen Consolidate all places that deal with output configuration in MetaScreen, which gets it either from XRandR or from a dummy static configuration. We still need to read the Xinerama config, even when running xwayland, because we need the indices for _NET_WM_FULLSCREEN_MONITORS, but now we do it only when needed. https://bugzilla.gnome.org/show_bug.cgi?id=705670
2013-07-18 11:09:16 +00:00
G_OBJECT_CLASS (meta_monitor_manager_parent_class)->finalize (object);
}
Introduce a new DBus interface for display configuration This new interface will be used by the control center and possibly the settings daemon to configure the screens. It is designed to resemble a simplified XRandR, while still exposing all the quirks of the hardware, so that the panel can limit the user choices appropriately. To do so, MetaMonitorMode needs to track CRTCs, outputs and modes, so the low level objects have been decoupled from the high-level MetaMonitorInfo, which is used by core and API and offers a simplified view of HW, that hides away the details of what is cloned and how. This is still not efficient as it should be, because on every HW change we drop all data structures and rebuild them from scratch (which is not expensive because there aren't many of them, but at least in the XRandR path it involves a few sync X calls) https://bugzilla.gnome.org/show_bug.cgi?id=705670
2013-07-19 12:39:28 +00:00
static void
meta_monitor_manager_dispose (GObject *object)
{
MetaMonitorManager *manager = META_MONITOR_MANAGER (object);
if (manager->dbus_name_id != 0)
{
g_bus_unown_name (manager->dbus_name_id);
manager->dbus_name_id = 0;
}
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 06:31:18 +00:00
g_clear_object (&manager->config_manager);
Introduce a new DBus interface for display configuration This new interface will be used by the control center and possibly the settings daemon to configure the screens. It is designed to resemble a simplified XRandR, while still exposing all the quirks of the hardware, so that the panel can limit the user choices appropriately. To do so, MetaMonitorMode needs to track CRTCs, outputs and modes, so the low level objects have been decoupled from the high-level MetaMonitorInfo, which is used by core and API and offers a simplified view of HW, that hides away the details of what is cloned and how. This is still not efficient as it should be, because on every HW change we drop all data structures and rebuild them from scratch (which is not expensive because there aren't many of them, but at least in the XRandR path it involves a few sync X calls) https://bugzilla.gnome.org/show_bug.cgi?id=705670
2013-07-19 12:39:28 +00:00
G_OBJECT_CLASS (meta_monitor_manager_parent_class)->dispose (object);
}
monitor-manager: Move default get_edid_file / read_edid to base class These are also used by the native manager.
2014-04-01 14:24:10 +00:00
static GBytes *
meta_monitor_manager_real_read_edid (MetaMonitorManager *manager,
MetaOutput *output)
{
return NULL;
}
static char *
meta_monitor_manager_real_get_edid_file (MetaMonitorManager *manager,
MetaOutput *output)
{
return NULL;
}
monitor-manager: Keep pointer to backend Instead of accessing the global singleton, keep a pointer to the backend in the MetaMonitorManager struct. https://bugzilla.gnome.org/show_bug.cgi?id=785381
2017-07-10 09:39:07 +00:00
static void
meta_monitor_manager_set_property (GObject *object,
guint prop_id,
const GValue *value,
GParamSpec *pspec)
{
MetaMonitorManager *manager = META_MONITOR_MANAGER (object);
switch (prop_id)
{
case PROP_BACKEND:
manager->backend = g_value_get_object (value);
break;
default:
G_OBJECT_WARN_INVALID_PROPERTY_ID (object, prop_id, pspec);
}
}
static void
meta_monitor_manager_get_property (GObject *object,
guint prop_id,
GValue *value,
GParamSpec *pspec)
{
MetaMonitorManager *manager = META_MONITOR_MANAGER (object);
switch (prop_id)
{
case PROP_BACKEND:
g_value_set_object (value, manager->backend);
break;
default:
G_OBJECT_WARN_INVALID_PROPERTY_ID (object, prop_id, pspec);
}
}
Rework and consolidate monitor handling in MetaScreen Consolidate all places that deal with output configuration in MetaScreen, which gets it either from XRandR or from a dummy static configuration. We still need to read the Xinerama config, even when running xwayland, because we need the indices for _NET_WM_FULLSCREEN_MONITORS, but now we do it only when needed. https://bugzilla.gnome.org/show_bug.cgi?id=705670
2013-07-18 11:09:16 +00:00
static void
meta_monitor_manager_class_init (MetaMonitorManagerClass *klass)
{
GObjectClass *object_class = G_OBJECT_CLASS (klass);
MonitorManager: split the XRandR parts in a subclass Instead of keeping a forest of if backend else ..., use a subclass and virtual functions to discriminate between XRandR and the dummy backend (which lives in the parent class togheter with the common code) https://bugzilla.gnome.org/show_bug.cgi?id=705670
2013-07-29 11:00:15 +00:00
object_class->constructed = meta_monitor_manager_constructed;
Introduce a new DBus interface for display configuration This new interface will be used by the control center and possibly the settings daemon to configure the screens. It is designed to resemble a simplified XRandR, while still exposing all the quirks of the hardware, so that the panel can limit the user choices appropriately. To do so, MetaMonitorMode needs to track CRTCs, outputs and modes, so the low level objects have been decoupled from the high-level MetaMonitorInfo, which is used by core and API and offers a simplified view of HW, that hides away the details of what is cloned and how. This is still not efficient as it should be, because on every HW change we drop all data structures and rebuild them from scratch (which is not expensive because there aren't many of them, but at least in the XRandR path it involves a few sync X calls) https://bugzilla.gnome.org/show_bug.cgi?id=705670
2013-07-19 12:39:28 +00:00
object_class->dispose = meta_monitor_manager_dispose;
Rework and consolidate monitor handling in MetaScreen Consolidate all places that deal with output configuration in MetaScreen, which gets it either from XRandR or from a dummy static configuration. We still need to read the Xinerama config, even when running xwayland, because we need the indices for _NET_WM_FULLSCREEN_MONITORS, but now we do it only when needed. https://bugzilla.gnome.org/show_bug.cgi?id=705670
2013-07-18 11:09:16 +00:00
object_class->finalize = meta_monitor_manager_finalize;
monitor-manager: Keep pointer to backend Instead of accessing the global singleton, keep a pointer to the backend in the MetaMonitorManager struct. https://bugzilla.gnome.org/show_bug.cgi?id=785381
2017-07-10 09:39:07 +00:00
object_class->get_property = meta_monitor_manager_get_property;
object_class->set_property = meta_monitor_manager_set_property;
Rework and consolidate monitor handling in MetaScreen Consolidate all places that deal with output configuration in MetaScreen, which gets it either from XRandR or from a dummy static configuration. We still need to read the Xinerama config, even when running xwayland, because we need the indices for _NET_WM_FULLSCREEN_MONITORS, but now we do it only when needed. https://bugzilla.gnome.org/show_bug.cgi?id=705670
2013-07-18 11:09:16 +00:00
monitor-manager: Move default get_edid_file / read_edid to base class These are also used by the native manager.
2014-04-01 14:24:10 +00:00
klass->get_edid_file = meta_monitor_manager_real_get_edid_file;
klass->read_edid = meta_monitor_manager_real_read_edid;
backends: add 'monitors-updated-internal' signal to only update internal state Adding an internal signal and use it to update the internal state before emitting "monitors-changed" which will be repeated by the screen to the world. https://bugzilla.gnome.org/show_bug.cgi?id=788860
2017-10-13 00:14:40 +00:00
signals[MONITORS_CHANGED_INTERNAL] =
g_signal_new ("monitors-changed-internal",
G_TYPE_FROM_CLASS (object_class),
G_SIGNAL_RUN_LAST,
0,
NULL, NULL, NULL,
G_TYPE_NONE, 0);
MetaPlugin: add a UI hook for confirming display changes We want to show a dialog when a display change happens from the control center. To do so, add a new vfunc to MetaPlugin and call it when a configuration change is requested via DBus. https://bugzilla.gnome.org/show_bug.cgi?id=705670
2013-07-29 08:12:24 +00:00
signals[CONFIRM_DISPLAY_CHANGE] =
g_signal_new ("confirm-display-change",
G_TYPE_FROM_CLASS (object_class),
G_SIGNAL_RUN_LAST,
0,
NULL, NULL, NULL,
G_TYPE_NONE, 0);
monitor-manager: Keep pointer to backend Instead of accessing the global singleton, keep a pointer to the backend in the MetaMonitorManager struct. https://bugzilla.gnome.org/show_bug.cgi?id=785381
2017-07-10 09:39:07 +00:00
obj_props[PROP_BACKEND] =
g_param_spec_object ("backend",
"backend",
"MetaBackend",
META_TYPE_BACKEND,
G_PARAM_READWRITE |
G_PARAM_CONSTRUCT_ONLY |
G_PARAM_STATIC_STRINGS);
g_object_class_install_properties (object_class, PROP_LAST, obj_props);
Rework and consolidate monitor handling in MetaScreen Consolidate all places that deal with output configuration in MetaScreen, which gets it either from XRandR or from a dummy static configuration. We still need to read the Xinerama config, even when running xwayland, because we need the indices for _NET_WM_FULLSCREEN_MONITORS, but now we do it only when needed. https://bugzilla.gnome.org/show_bug.cgi?id=705670
2013-07-18 11:09:16 +00:00
}
Introduce a new DBus interface for display configuration This new interface will be used by the control center and possibly the settings daemon to configure the screens. It is designed to resemble a simplified XRandR, while still exposing all the quirks of the hardware, so that the panel can limit the user choices appropriately. To do so, MetaMonitorMode needs to track CRTCs, outputs and modes, so the low level objects have been decoupled from the high-level MetaMonitorInfo, which is used by core and API and offers a simplified view of HW, that hides away the details of what is cloned and how. This is still not efficient as it should be, because on every HW change we drop all data structures and rebuild them from scratch (which is not expensive because there aren't many of them, but at least in the XRandR path it involves a few sync X calls) https://bugzilla.gnome.org/show_bug.cgi?id=705670
2013-07-19 12:39:28 +00:00
static const double known_diagonals[] = {
12.1,
13.3,
15.6
};
static char *
diagonal_to_str (double d)
{
unsigned int i;
for (i = 0; i < G_N_ELEMENTS (known_diagonals); i++)
{
double delta;
delta = fabs(known_diagonals[i] - d);
if (delta < 0.1)
return g_strdup_printf ("%0.1lf\"", known_diagonals[i]);
}
return g_strdup_printf ("%d\"", (int) (d + 0.5));
}
static char *
Monitor: restore correct display name handling Now that we have the right values from the EDID, we can load the PNP database and find the proper vendor name, to show in the control center UI. https://bugzilla.gnome.org/show_bug.cgi?id=705670
2013-08-16 15:32:50 +00:00
make_display_name (MetaMonitorManager *manager,
MetaOutput *output)
Introduce a new DBus interface for display configuration This new interface will be used by the control center and possibly the settings daemon to configure the screens. It is designed to resemble a simplified XRandR, while still exposing all the quirks of the hardware, so that the panel can limit the user choices appropriately. To do so, MetaMonitorMode needs to track CRTCs, outputs and modes, so the low level objects have been decoupled from the high-level MetaMonitorInfo, which is used by core and API and offers a simplified view of HW, that hides away the details of what is cloned and how. This is still not efficient as it should be, because on every HW change we drop all data structures and rebuild them from scratch (which is not expensive because there aren't many of them, but at least in the XRandR path it involves a few sync X calls) https://bugzilla.gnome.org/show_bug.cgi?id=705670
2013-07-19 12:39:28 +00:00
{
Use more g_autofoo throughout mutter
2015-05-30 00:17:34 +00:00
g_autofree char *inches = NULL;
g_autofree char *vendor_name = NULL;
monitor: improve heuristic to determine display output name Under some circumstances, for example when the display controller driver doesn't report back the correct EDID, or under VirtualBox, Mutter returns suboptimal strings for an output display name, leading to funny labels like 'Unknown 0"', or '(null) 0"' in the Settings panel. This commit improves our heuristic in three ways: - we now avoid putting inches in the display name if either dimension is zero - we use the vendor name in case we're not able to lookup its PnP id from the database. Previously we would have passed over '(null)' - as a special edge-case, when neither inches nor vendor are known, we use the string 'Unknown Display' Finally, we make the combined vendor + inches string translatable, as different languages might want to move the size part of the string to a position different than the end. https://bugzilla.gnome.org/show_bug.cgi?id=721674
2014-01-07 02:26:03 +00:00
monitor-manager: Expose output_is_laptop() method We currently duplicate the heuristics of whether an output is considered a laptop or not. Avoid this by sharing a small helper method. https://bugzilla.gnome.org/show_bug.cgi?id=765267
2016-04-21 15:29:44 +00:00
if (meta_output_is_laptop (output))
Use more g_autofoo throughout mutter
2015-05-30 00:17:34 +00:00
return g_strdup (_("Built-in display"));
Monitor: restore correct display name handling Now that we have the right values from the EDID, we can load the PNP database and find the proper vendor name, to show in the control center UI. https://bugzilla.gnome.org/show_bug.cgi?id=705670
2013-08-16 15:32:50 +00:00
monitor: improve heuristic to determine display output name Under some circumstances, for example when the display controller driver doesn't report back the correct EDID, or under VirtualBox, Mutter returns suboptimal strings for an output display name, leading to funny labels like 'Unknown 0"', or '(null) 0"' in the Settings panel. This commit improves our heuristic in three ways: - we now avoid putting inches in the display name if either dimension is zero - we use the vendor name in case we're not able to lookup its PnP id from the database. Previously we would have passed over '(null)' - as a special edge-case, when neither inches nor vendor are known, we use the string 'Unknown Display' Finally, we make the combined vendor + inches string translatable, as different languages might want to move the size part of the string to a position different than the end. https://bugzilla.gnome.org/show_bug.cgi?id=721674
2014-01-07 02:26:03 +00:00
if (output->width_mm > 0 && output->height_mm > 0)
Introduce a new DBus interface for display configuration This new interface will be used by the control center and possibly the settings daemon to configure the screens. It is designed to resemble a simplified XRandR, while still exposing all the quirks of the hardware, so that the panel can limit the user choices appropriately. To do so, MetaMonitorMode needs to track CRTCs, outputs and modes, so the low level objects have been decoupled from the high-level MetaMonitorInfo, which is used by core and API and offers a simplified view of HW, that hides away the details of what is cloned and how. This is still not efficient as it should be, because on every HW change we drop all data structures and rebuild them from scratch (which is not expensive because there aren't many of them, but at least in the XRandR path it involves a few sync X calls) https://bugzilla.gnome.org/show_bug.cgi?id=705670
2013-07-19 12:39:28 +00:00
{
double d = sqrt (output->width_mm * output->width_mm +
output->height_mm * output->height_mm);
monitor: improve heuristic to determine display output name Under some circumstances, for example when the display controller driver doesn't report back the correct EDID, or under VirtualBox, Mutter returns suboptimal strings for an output display name, leading to funny labels like 'Unknown 0"', or '(null) 0"' in the Settings panel. This commit improves our heuristic in three ways: - we now avoid putting inches in the display name if either dimension is zero - we use the vendor name in case we're not able to lookup its PnP id from the database. Previously we would have passed over '(null)' - as a special edge-case, when neither inches nor vendor are known, we use the string 'Unknown Display' Finally, we make the combined vendor + inches string translatable, as different languages might want to move the size part of the string to a position different than the end. https://bugzilla.gnome.org/show_bug.cgi?id=721674
2014-01-07 02:26:03 +00:00
inches = diagonal_to_str (d / 25.4);
}
Monitor: restore correct display name handling Now that we have the right values from the EDID, we can load the PNP database and find the proper vendor name, to show in the control center UI. https://bugzilla.gnome.org/show_bug.cgi?id=705670
2013-08-16 15:32:50 +00:00
monitor: improve heuristic to determine display output name Under some circumstances, for example when the display controller driver doesn't report back the correct EDID, or under VirtualBox, Mutter returns suboptimal strings for an output display name, leading to funny labels like 'Unknown 0"', or '(null) 0"' in the Settings panel. This commit improves our heuristic in three ways: - we now avoid putting inches in the display name if either dimension is zero - we use the vendor name in case we're not able to lookup its PnP id from the database. Previously we would have passed over '(null)' - as a special edge-case, when neither inches nor vendor are known, we use the string 'Unknown Display' Finally, we make the combined vendor + inches string translatable, as different languages might want to move the size part of the string to a position different than the end. https://bugzilla.gnome.org/show_bug.cgi?id=721674
2014-01-07 02:26:03 +00:00
if (g_strcmp0 (output->vendor, "unknown") != 0)
{
if (!manager->pnp_ids)
manager->pnp_ids = gnome_pnp_ids_new ();
Monitor: restore correct display name handling Now that we have the right values from the EDID, we can load the PNP database and find the proper vendor name, to show in the control center UI. https://bugzilla.gnome.org/show_bug.cgi?id=705670
2013-08-16 15:32:50 +00:00
monitor: improve heuristic to determine display output name Under some circumstances, for example when the display controller driver doesn't report back the correct EDID, or under VirtualBox, Mutter returns suboptimal strings for an output display name, leading to funny labels like 'Unknown 0"', or '(null) 0"' in the Settings panel. This commit improves our heuristic in three ways: - we now avoid putting inches in the display name if either dimension is zero - we use the vendor name in case we're not able to lookup its PnP id from the database. Previously we would have passed over '(null)' - as a special edge-case, when neither inches nor vendor are known, we use the string 'Unknown Display' Finally, we make the combined vendor + inches string translatable, as different languages might want to move the size part of the string to a position different than the end. https://bugzilla.gnome.org/show_bug.cgi?id=721674
2014-01-07 02:26:03 +00:00
vendor_name = gnome_pnp_ids_get_pnp_id (manager->pnp_ids,
output->vendor);
Monitor: restore correct display name handling Now that we have the right values from the EDID, we can load the PNP database and find the proper vendor name, to show in the control center UI. https://bugzilla.gnome.org/show_bug.cgi?id=705670
2013-08-16 15:32:50 +00:00
monitor: improve heuristic to determine display output name Under some circumstances, for example when the display controller driver doesn't report back the correct EDID, or under VirtualBox, Mutter returns suboptimal strings for an output display name, leading to funny labels like 'Unknown 0"', or '(null) 0"' in the Settings panel. This commit improves our heuristic in three ways: - we now avoid putting inches in the display name if either dimension is zero - we use the vendor name in case we're not able to lookup its PnP id from the database. Previously we would have passed over '(null)' - as a special edge-case, when neither inches nor vendor are known, we use the string 'Unknown Display' Finally, we make the combined vendor + inches string translatable, as different languages might want to move the size part of the string to a position different than the end. https://bugzilla.gnome.org/show_bug.cgi?id=721674
2014-01-07 02:26:03 +00:00
if (!vendor_name)
vendor_name = g_strdup (output->vendor);
}
else
{
if (inches != NULL)
vendor_name = g_strdup (_("Unknown"));
Monitor: restore correct display name handling Now that we have the right values from the EDID, we can load the PNP database and find the proper vendor name, to show in the control center UI. https://bugzilla.gnome.org/show_bug.cgi?id=705670
2013-08-16 15:32:50 +00:00
else
monitor: improve heuristic to determine display output name Under some circumstances, for example when the display controller driver doesn't report back the correct EDID, or under VirtualBox, Mutter returns suboptimal strings for an output display name, leading to funny labels like 'Unknown 0"', or '(null) 0"' in the Settings panel. This commit improves our heuristic in three ways: - we now avoid putting inches in the display name if either dimension is zero - we use the vendor name in case we're not able to lookup its PnP id from the database. Previously we would have passed over '(null)' - as a special edge-case, when neither inches nor vendor are known, we use the string 'Unknown Display' Finally, we make the combined vendor + inches string translatable, as different languages might want to move the size part of the string to a position different than the end. https://bugzilla.gnome.org/show_bug.cgi?id=721674
2014-01-07 02:26:03 +00:00
vendor_name = g_strdup (_("Unknown Display"));
}
Introduce a new DBus interface for display configuration This new interface will be used by the control center and possibly the settings daemon to configure the screens. It is designed to resemble a simplified XRandR, while still exposing all the quirks of the hardware, so that the panel can limit the user choices appropriately. To do so, MetaMonitorMode needs to track CRTCs, outputs and modes, so the low level objects have been decoupled from the high-level MetaMonitorInfo, which is used by core and API and offers a simplified view of HW, that hides away the details of what is cloned and how. This is still not efficient as it should be, because on every HW change we drop all data structures and rebuild them from scratch (which is not expensive because there aren't many of them, but at least in the XRandR path it involves a few sync X calls) https://bugzilla.gnome.org/show_bug.cgi?id=705670
2013-07-19 12:39:28 +00:00
monitor: improve heuristic to determine display output name Under some circumstances, for example when the display controller driver doesn't report back the correct EDID, or under VirtualBox, Mutter returns suboptimal strings for an output display name, leading to funny labels like 'Unknown 0"', or '(null) 0"' in the Settings panel. This commit improves our heuristic in three ways: - we now avoid putting inches in the display name if either dimension is zero - we use the vendor name in case we're not able to lookup its PnP id from the database. Previously we would have passed over '(null)' - as a special edge-case, when neither inches nor vendor are known, we use the string 'Unknown Display' Finally, we make the combined vendor + inches string translatable, as different languages might want to move the size part of the string to a position different than the end. https://bugzilla.gnome.org/show_bug.cgi?id=721674
2014-01-07 02:26:03 +00:00
if (inches != NULL)
{
/* TRANSLATORS: this is a monitor vendor name, followed by a
* size in inches, like 'Dell 15"'
*/
Use more g_autofoo throughout mutter
2015-05-30 00:17:34 +00:00
return g_strdup_printf (_("%s %s"), vendor_name, inches);
Introduce a new DBus interface for display configuration This new interface will be used by the control center and possibly the settings daemon to configure the screens. It is designed to resemble a simplified XRandR, while still exposing all the quirks of the hardware, so that the panel can limit the user choices appropriately. To do so, MetaMonitorMode needs to track CRTCs, outputs and modes, so the low level objects have been decoupled from the high-level MetaMonitorInfo, which is used by core and API and offers a simplified view of HW, that hides away the details of what is cloned and how. This is still not efficient as it should be, because on every HW change we drop all data structures and rebuild them from scratch (which is not expensive because there aren't many of them, but at least in the XRandR path it involves a few sync X calls) https://bugzilla.gnome.org/show_bug.cgi?id=705670
2013-07-19 12:39:28 +00:00
}
else
{
Use more g_autofoo throughout mutter
2015-05-30 00:17:34 +00:00
return g_strdup (vendor_name);
Introduce a new DBus interface for display configuration This new interface will be used by the control center and possibly the settings daemon to configure the screens. It is designed to resemble a simplified XRandR, while still exposing all the quirks of the hardware, so that the panel can limit the user choices appropriately. To do so, MetaMonitorMode needs to track CRTCs, outputs and modes, so the low level objects have been decoupled from the high-level MetaMonitorInfo, which is used by core and API and offers a simplified view of HW, that hides away the details of what is cloned and how. This is still not efficient as it should be, because on every HW change we drop all data structures and rebuild them from scratch (which is not expensive because there aren't many of them, but at least in the XRandR path it involves a few sync X calls) https://bugzilla.gnome.org/show_bug.cgi?id=705670
2013-07-19 12:39:28 +00:00
}
}
monitor-manager: Add a connector-type property This is so gnome-settings-daemon
2014-12-30 00:18:24 +00:00
static const char *
get_connector_type_name (MetaConnectorType connector_type)
{
switch (connector_type)
{
case META_CONNECTOR_TYPE_Unknown: return "Unknown";
case META_CONNECTOR_TYPE_VGA: return "VGA";
case META_CONNECTOR_TYPE_DVII: return "DVII";
case META_CONNECTOR_TYPE_DVID: return "DVID";
case META_CONNECTOR_TYPE_DVIA: return "DVIA";
case META_CONNECTOR_TYPE_Composite: return "Composite";
case META_CONNECTOR_TYPE_SVIDEO: return "SVIDEO";
case META_CONNECTOR_TYPE_LVDS: return "LVDS";
case META_CONNECTOR_TYPE_Component: return "Component";
case META_CONNECTOR_TYPE_9PinDIN: return "9PinDIN";
case META_CONNECTOR_TYPE_DisplayPort: return "DisplayPort";
case META_CONNECTOR_TYPE_HDMIA: return "HDMIA";
case META_CONNECTOR_TYPE_HDMIB: return "HDMIB";
case META_CONNECTOR_TYPE_TV: return "TV";
case META_CONNECTOR_TYPE_eDP: return "eDP";
case META_CONNECTOR_TYPE_VIRTUAL: return "VIRTUAL";
case META_CONNECTOR_TYPE_DSI: return "DSI";
default: g_assert_not_reached ();
}
}
backends: Split out CRTC/output management to MetaGpu In order to eventually support multilpe GPUs with their own connectors, split out related meta data management (i.e. outputs, CRTCs and CRTC modes) into a new MetaGpu GObject. The Xrandr backend always assumes there is always only a single "GPU" as the GPU is abstracted by the X server; only the native backend (aside from the test backend) will eventually see more than one GPU. The Xrandr backend still moves some management to MetaGpuXrandr, in order to behave more similarly to the KMS counterparts. https://bugzilla.gnome.org/show_bug.cgi?id=785381
2017-07-10 10:19:32 +00:00
static GList *
combine_gpu_lists (MetaMonitorManager *manager,
GList * (*list_getter) (MetaGpu *gpu))
{
GList *list = NULL;
GList *l;
for (l = manager->gpus; l; l = l->next)
{
MetaGpu *gpu = l->data;
list = g_list_concat (list, g_list_copy (list_getter (gpu)));
}
return list;
}
Introduce a new DBus interface for display configuration This new interface will be used by the control center and possibly the settings daemon to configure the screens. It is designed to resemble a simplified XRandR, while still exposing all the quirks of the hardware, so that the panel can limit the user choices appropriately. To do so, MetaMonitorMode needs to track CRTCs, outputs and modes, so the low level objects have been decoupled from the high-level MetaMonitorInfo, which is used by core and API and offers a simplified view of HW, that hides away the details of what is cloned and how. This is still not efficient as it should be, because on every HW change we drop all data structures and rebuild them from scratch (which is not expensive because there aren't many of them, but at least in the XRandR path it involves a few sync X calls) https://bugzilla.gnome.org/show_bug.cgi?id=705670
2013-07-19 12:39:28 +00:00
static gboolean
MonitorManager: inherit directly from DisplayConfig instead of handling signals This way we can handle properties too. https://bugzilla.gnome.org/show_bug.cgi?id=705670
2013-07-23 17:32:17 +00:00
meta_monitor_manager_handle_get_resources (MetaDBusDisplayConfig *skeleton,
GDBusMethodInvocation *invocation)
Introduce a new DBus interface for display configuration This new interface will be used by the control center and possibly the settings daemon to configure the screens. It is designed to resemble a simplified XRandR, while still exposing all the quirks of the hardware, so that the panel can limit the user choices appropriately. To do so, MetaMonitorMode needs to track CRTCs, outputs and modes, so the low level objects have been decoupled from the high-level MetaMonitorInfo, which is used by core and API and offers a simplified view of HW, that hides away the details of what is cloned and how. This is still not efficient as it should be, because on every HW change we drop all data structures and rebuild them from scratch (which is not expensive because there aren't many of them, but at least in the XRandR path it involves a few sync X calls) https://bugzilla.gnome.org/show_bug.cgi?id=705670
2013-07-19 12:39:28 +00:00
{
MonitorManager: inherit directly from DisplayConfig instead of handling signals This way we can handle properties too. https://bugzilla.gnome.org/show_bug.cgi?id=705670
2013-07-23 17:32:17 +00:00
MetaMonitorManager *manager = META_MONITOR_MANAGER (skeleton);
MonitorManager: add EDID properties to the output DBus description Add "edid-file", if we have one (in the KMS case, where we can point people to the right sysfs file), or "edid" with inline data. These are needed by colord to build the default ICC profile for uncalibrated displays. https://bugzilla.gnome.org/show_bug.cgi?id=705670
2013-08-08 11:32:05 +00:00
MetaMonitorManagerClass *manager_class = META_MONITOR_MANAGER_GET_CLASS (skeleton);
backends: Split out CRTC/output management to MetaGpu In order to eventually support multilpe GPUs with their own connectors, split out related meta data management (i.e. outputs, CRTCs and CRTC modes) into a new MetaGpu GObject. The Xrandr backend always assumes there is always only a single "GPU" as the GPU is abstracted by the X server; only the native backend (aside from the test backend) will eventually see more than one GPU. The Xrandr backend still moves some management to MetaGpuXrandr, in order to behave more similarly to the KMS counterparts. https://bugzilla.gnome.org/show_bug.cgi?id=785381
2017-07-10 10:19:32 +00:00
GList *combined_modes;
GList *combined_outputs;
GList *combined_crtcs;
Introduce a new DBus interface for display configuration This new interface will be used by the control center and possibly the settings daemon to configure the screens. It is designed to resemble a simplified XRandR, while still exposing all the quirks of the hardware, so that the panel can limit the user choices appropriately. To do so, MetaMonitorMode needs to track CRTCs, outputs and modes, so the low level objects have been decoupled from the high-level MetaMonitorInfo, which is used by core and API and offers a simplified view of HW, that hides away the details of what is cloned and how. This is still not efficient as it should be, because on every HW change we drop all data structures and rebuild them from scratch (which is not expensive because there aren't many of them, but at least in the XRandR path it involves a few sync X calls) https://bugzilla.gnome.org/show_bug.cgi?id=705670
2013-07-19 12:39:28 +00:00
GVariantBuilder crtc_builder, output_builder, mode_builder;
Make MetaOutput a GObject Turn MetaOutput into a GObject and move it to a separate file. This changes the storage format, resulting in changing the API for accessing MetaOutputs from using an array, to using a GList. https://bugzilla.gnome.org/show_bug.cgi?id=785381
2017-03-24 09:35:51 +00:00
GList *l;
Introduce a new DBus interface for display configuration This new interface will be used by the control center and possibly the settings daemon to configure the screens. It is designed to resemble a simplified XRandR, while still exposing all the quirks of the hardware, so that the panel can limit the user choices appropriately. To do so, MetaMonitorMode needs to track CRTCs, outputs and modes, so the low level objects have been decoupled from the high-level MetaMonitorInfo, which is used by core and API and offers a simplified view of HW, that hides away the details of what is cloned and how. This is still not efficient as it should be, because on every HW change we drop all data structures and rebuild them from scratch (which is not expensive because there aren't many of them, but at least in the XRandR path it involves a few sync X calls) https://bugzilla.gnome.org/show_bug.cgi?id=705670
2013-07-19 12:39:28 +00:00
unsigned int i, j;
monitor-manager: Make max screen size optional Make the concept of maximum screen size optional, as it is not necessarily a thing on all systems (e.g. when using the native backend and stage views). The meta_monitor_monitor_get_limits() function is replaced by a meta_monitor_manager_get_max_screen_size() which fails when no screen limit is available. Callers and other users of the previous max screen size fields are updated to deal with the fact that the limit is optional. The new D-Bus API is changed to move it to the properties bag, where its absence means there is no applicable limit. https://bugzilla.gnome.org/show_bug.cgi?id=777732
2017-02-15 08:06:46 +00:00
int max_screen_width;
int max_screen_height;
Introduce a new DBus interface for display configuration This new interface will be used by the control center and possibly the settings daemon to configure the screens. It is designed to resemble a simplified XRandR, while still exposing all the quirks of the hardware, so that the panel can limit the user choices appropriately. To do so, MetaMonitorMode needs to track CRTCs, outputs and modes, so the low level objects have been decoupled from the high-level MetaMonitorInfo, which is used by core and API and offers a simplified view of HW, that hides away the details of what is cloned and how. This is still not efficient as it should be, because on every HW change we drop all data structures and rebuild them from scratch (which is not expensive because there aren't many of them, but at least in the XRandR path it involves a few sync X calls) https://bugzilla.gnome.org/show_bug.cgi?id=705670
2013-07-19 12:39:28 +00:00
backends: Split out CRTC/output management to MetaGpu In order to eventually support multilpe GPUs with their own connectors, split out related meta data management (i.e. outputs, CRTCs and CRTC modes) into a new MetaGpu GObject. The Xrandr backend always assumes there is always only a single "GPU" as the GPU is abstracted by the X server; only the native backend (aside from the test backend) will eventually see more than one GPU. The Xrandr backend still moves some management to MetaGpuXrandr, in order to behave more similarly to the KMS counterparts. https://bugzilla.gnome.org/show_bug.cgi?id=785381
2017-07-10 10:19:32 +00:00
combined_modes = combine_gpu_lists (manager, meta_gpu_get_modes);
combined_outputs = combine_gpu_lists (manager, meta_gpu_get_outputs);
combined_crtcs = combine_gpu_lists (manager, meta_gpu_get_crtcs);
Introduce a new DBus interface for display configuration This new interface will be used by the control center and possibly the settings daemon to configure the screens. It is designed to resemble a simplified XRandR, while still exposing all the quirks of the hardware, so that the panel can limit the user choices appropriately. To do so, MetaMonitorMode needs to track CRTCs, outputs and modes, so the low level objects have been decoupled from the high-level MetaMonitorInfo, which is used by core and API and offers a simplified view of HW, that hides away the details of what is cloned and how. This is still not efficient as it should be, because on every HW change we drop all data structures and rebuild them from scratch (which is not expensive because there aren't many of them, but at least in the XRandR path it involves a few sync X calls) https://bugzilla.gnome.org/show_bug.cgi?id=705670
2013-07-19 12:39:28 +00:00
g_variant_builder_init (&crtc_builder, G_VARIANT_TYPE ("a(uxiiiiiuaua{sv})"));
Extend the DBus XRandR protocol to expose cloning restriction Turns out that even if two outputs say that they can be controlled by a given CRTC, you can't configure them in the same CRTC unless they are marked as "possible clones" one of the other. This can further restrict the configuration options, so we need to expose this limitation in the DBus API. https://bugzilla.gnome.org/show_bug.cgi?id=705670
2013-07-19 16:47:01 +00:00
g_variant_builder_init (&output_builder, G_VARIANT_TYPE ("a(uxiausauaua{sv})"));
backends: Add flags to MetaMonitorMode And export them in the DBus API since they're useful for gnome-control-center. https://bugzilla.gnome.org/show_bug.cgi?id=763832
2015-04-21 15:49:55 +00:00
g_variant_builder_init (&mode_builder, G_VARIANT_TYPE ("a(uxuudu)"));
Introduce a new DBus interface for display configuration This new interface will be used by the control center and possibly the settings daemon to configure the screens. It is designed to resemble a simplified XRandR, while still exposing all the quirks of the hardware, so that the panel can limit the user choices appropriately. To do so, MetaMonitorMode needs to track CRTCs, outputs and modes, so the low level objects have been decoupled from the high-level MetaMonitorInfo, which is used by core and API and offers a simplified view of HW, that hides away the details of what is cloned and how. This is still not efficient as it should be, because on every HW change we drop all data structures and rebuild them from scratch (which is not expensive because there aren't many of them, but at least in the XRandR path it involves a few sync X calls) https://bugzilla.gnome.org/show_bug.cgi?id=705670
2013-07-19 12:39:28 +00:00
backends: Split out CRTC/output management to MetaGpu In order to eventually support multilpe GPUs with their own connectors, split out related meta data management (i.e. outputs, CRTCs and CRTC modes) into a new MetaGpu GObject. The Xrandr backend always assumes there is always only a single "GPU" as the GPU is abstracted by the X server; only the native backend (aside from the test backend) will eventually see more than one GPU. The Xrandr backend still moves some management to MetaGpuXrandr, in order to behave more similarly to the KMS counterparts. https://bugzilla.gnome.org/show_bug.cgi?id=785381
2017-07-10 10:19:32 +00:00
for (l = combined_crtcs, i = 0; l; l = l->next, i++)
Introduce a new DBus interface for display configuration This new interface will be used by the control center and possibly the settings daemon to configure the screens. It is designed to resemble a simplified XRandR, while still exposing all the quirks of the hardware, so that the panel can limit the user choices appropriately. To do so, MetaMonitorMode needs to track CRTCs, outputs and modes, so the low level objects have been decoupled from the high-level MetaMonitorInfo, which is used by core and API and offers a simplified view of HW, that hides away the details of what is cloned and how. This is still not efficient as it should be, because on every HW change we drop all data structures and rebuild them from scratch (which is not expensive because there aren't many of them, but at least in the XRandR path it involves a few sync X calls) https://bugzilla.gnome.org/show_bug.cgi?id=705670
2013-07-19 12:39:28 +00:00
{
monitor-manager: Make MetaCrtc a GObject Turn MetaCrtc into a GObject and move it to a separate file. This changes the storage format, resulting in changing the API for accessing MetaCrtcs from using an array, to using a GList. https://bugzilla.gnome.org/show_bug.cgi?id=785381
2017-03-28 04:35:19 +00:00
MetaCrtc *crtc = l->data;
Introduce a new DBus interface for display configuration This new interface will be used by the control center and possibly the settings daemon to configure the screens. It is designed to resemble a simplified XRandR, while still exposing all the quirks of the hardware, so that the panel can limit the user choices appropriately. To do so, MetaMonitorMode needs to track CRTCs, outputs and modes, so the low level objects have been decoupled from the high-level MetaMonitorInfo, which is used by core and API and offers a simplified view of HW, that hides away the details of what is cloned and how. This is still not efficient as it should be, because on every HW change we drop all data structures and rebuild them from scratch (which is not expensive because there aren't many of them, but at least in the XRandR path it involves a few sync X calls) https://bugzilla.gnome.org/show_bug.cgi?id=705670
2013-07-19 12:39:28 +00:00
GVariantBuilder transforms;
monitor-manager: Turn MetaCrtcMode into a GObject Convert MetaCrtcMode from a plain struct to a GObject. This changes the storage format, and also the API, as the API was dependent on the storage format. https://bugzilla.gnome.org/show_bug.cgi?id=785381
2017-03-28 08:52:15 +00:00
int current_mode_index;
Introduce a new DBus interface for display configuration This new interface will be used by the control center and possibly the settings daemon to configure the screens. It is designed to resemble a simplified XRandR, while still exposing all the quirks of the hardware, so that the panel can limit the user choices appropriately. To do so, MetaMonitorMode needs to track CRTCs, outputs and modes, so the low level objects have been decoupled from the high-level MetaMonitorInfo, which is used by core and API and offers a simplified view of HW, that hides away the details of what is cloned and how. This is still not efficient as it should be, because on every HW change we drop all data structures and rebuild them from scratch (which is not expensive because there aren't many of them, but at least in the XRandR path it involves a few sync X calls) https://bugzilla.gnome.org/show_bug.cgi?id=705670
2013-07-19 12:39:28 +00:00
g_variant_builder_init (&transforms, G_VARIANT_TYPE ("au"));
monitor: Don't use wl_output_transform in our APIs Invent our own API so we can build without Wayland headers.
2014-07-10 21:39:47 +00:00
for (j = 0; j <= META_MONITOR_TRANSFORM_FLIPPED_270; j++)
MonitorManager: fix handling of output transform Read the current transform from XRandR, and expose the transforms that are really supported on the bus. The dummy backend now advertises all transforms, since it doesn't actually apply them. https://bugzilla.gnome.org/show_bug.cgi?id=705670
2013-07-24 08:01:57 +00:00
if (crtc->all_transforms & (1 << j))
g_variant_builder_add (&transforms, "u", j);
Introduce a new DBus interface for display configuration This new interface will be used by the control center and possibly the settings daemon to configure the screens. It is designed to resemble a simplified XRandR, while still exposing all the quirks of the hardware, so that the panel can limit the user choices appropriately. To do so, MetaMonitorMode needs to track CRTCs, outputs and modes, so the low level objects have been decoupled from the high-level MetaMonitorInfo, which is used by core and API and offers a simplified view of HW, that hides away the details of what is cloned and how. This is still not efficient as it should be, because on every HW change we drop all data structures and rebuild them from scratch (which is not expensive because there aren't many of them, but at least in the XRandR path it involves a few sync X calls) https://bugzilla.gnome.org/show_bug.cgi?id=705670
2013-07-19 12:39:28 +00:00
monitor-manager: Turn MetaCrtcMode into a GObject Convert MetaCrtcMode from a plain struct to a GObject. This changes the storage format, and also the API, as the API was dependent on the storage format. https://bugzilla.gnome.org/show_bug.cgi?id=785381
2017-03-28 08:52:15 +00:00
if (crtc->current_mode)
backends: Split out CRTC/output management to MetaGpu In order to eventually support multilpe GPUs with their own connectors, split out related meta data management (i.e. outputs, CRTCs and CRTC modes) into a new MetaGpu GObject. The Xrandr backend always assumes there is always only a single "GPU" as the GPU is abstracted by the X server; only the native backend (aside from the test backend) will eventually see more than one GPU. The Xrandr backend still moves some management to MetaGpuXrandr, in order to behave more similarly to the KMS counterparts. https://bugzilla.gnome.org/show_bug.cgi?id=785381
2017-07-10 10:19:32 +00:00
current_mode_index = g_list_index (combined_modes, crtc->current_mode);
monitor-manager: Turn MetaCrtcMode into a GObject Convert MetaCrtcMode from a plain struct to a GObject. This changes the storage format, and also the API, as the API was dependent on the storage format. https://bugzilla.gnome.org/show_bug.cgi?id=785381
2017-03-28 08:52:15 +00:00
else
current_mode_index = -1;
Introduce a new DBus interface for display configuration This new interface will be used by the control center and possibly the settings daemon to configure the screens. It is designed to resemble a simplified XRandR, while still exposing all the quirks of the hardware, so that the panel can limit the user choices appropriately. To do so, MetaMonitorMode needs to track CRTCs, outputs and modes, so the low level objects have been decoupled from the high-level MetaMonitorInfo, which is used by core and API and offers a simplified view of HW, that hides away the details of what is cloned and how. This is still not efficient as it should be, because on every HW change we drop all data structures and rebuild them from scratch (which is not expensive because there aren't many of them, but at least in the XRandR path it involves a few sync X calls) https://bugzilla.gnome.org/show_bug.cgi?id=705670
2013-07-19 12:39:28 +00:00
g_variant_builder_add (&crtc_builder, "(uxiiiiiuaua{sv})",
i, /* ID */
MonitorManager: make sure to pass the right sizes to vararg functions A gulong is not enough to get 64 bits in all arches, so we must cast it, or we can corrupt the stack. This was downstream bug bugzilla.redhat.com/show_bug.cgi?id=1002055 https://bugzilla.gnome.org/show_bug.cgi?id=707267
2013-09-02 07:29:26 +00:00
(gint64)crtc->crtc_id,
Introduce a new DBus interface for display configuration This new interface will be used by the control center and possibly the settings daemon to configure the screens. It is designed to resemble a simplified XRandR, while still exposing all the quirks of the hardware, so that the panel can limit the user choices appropriately. To do so, MetaMonitorMode needs to track CRTCs, outputs and modes, so the low level objects have been decoupled from the high-level MetaMonitorInfo, which is used by core and API and offers a simplified view of HW, that hides away the details of what is cloned and how. This is still not efficient as it should be, because on every HW change we drop all data structures and rebuild them from scratch (which is not expensive because there aren't many of them, but at least in the XRandR path it involves a few sync X calls) https://bugzilla.gnome.org/show_bug.cgi?id=705670
2013-07-19 12:39:28 +00:00
(int)crtc->rect.x,
(int)crtc->rect.y,
(int)crtc->rect.width,
(int)crtc->rect.height,
monitor-manager: Turn MetaCrtcMode into a GObject Convert MetaCrtcMode from a plain struct to a GObject. This changes the storage format, and also the API, as the API was dependent on the storage format. https://bugzilla.gnome.org/show_bug.cgi?id=785381
2017-03-28 08:52:15 +00:00
current_mode_index,
MonitorManager: make sure to pass the right sizes to vararg functions A gulong is not enough to get 64 bits in all arches, so we must cast it, or we can corrupt the stack. This was downstream bug bugzilla.redhat.com/show_bug.cgi?id=1002055 https://bugzilla.gnome.org/show_bug.cgi?id=707267
2013-09-02 07:29:26 +00:00
(guint32)crtc->transform,
Introduce a new DBus interface for display configuration This new interface will be used by the control center and possibly the settings daemon to configure the screens. It is designed to resemble a simplified XRandR, while still exposing all the quirks of the hardware, so that the panel can limit the user choices appropriately. To do so, MetaMonitorMode needs to track CRTCs, outputs and modes, so the low level objects have been decoupled from the high-level MetaMonitorInfo, which is used by core and API and offers a simplified view of HW, that hides away the details of what is cloned and how. This is still not efficient as it should be, because on every HW change we drop all data structures and rebuild them from scratch (which is not expensive because there aren't many of them, but at least in the XRandR path it involves a few sync X calls) https://bugzilla.gnome.org/show_bug.cgi?id=705670
2013-07-19 12:39:28 +00:00
&transforms,
NULL /* properties */);
}
monitor-manager: fix output ids returned by GetResources Output ID is set equal to 'i' later in the loop. But 'i' was never incremented, so all outputs were getting the same ID (equal to the number of CRTCs, because 'i' was reused from the previous loop). (cherry picked from commit 23c3f8bb18db499d196f1024732ef3234b44f59c)
2018-04-07 19:40:30 +00:00
for (l = combined_outputs, i = 0; l; l = l->next, i++)
Introduce a new DBus interface for display configuration This new interface will be used by the control center and possibly the settings daemon to configure the screens. It is designed to resemble a simplified XRandR, while still exposing all the quirks of the hardware, so that the panel can limit the user choices appropriately. To do so, MetaMonitorMode needs to track CRTCs, outputs and modes, so the low level objects have been decoupled from the high-level MetaMonitorInfo, which is used by core and API and offers a simplified view of HW, that hides away the details of what is cloned and how. This is still not efficient as it should be, because on every HW change we drop all data structures and rebuild them from scratch (which is not expensive because there aren't many of them, but at least in the XRandR path it involves a few sync X calls) https://bugzilla.gnome.org/show_bug.cgi?id=705670
2013-07-19 12:39:28 +00:00
{
Make MetaOutput a GObject Turn MetaOutput into a GObject and move it to a separate file. This changes the storage format, resulting in changing the API for accessing MetaOutputs from using an array, to using a GList. https://bugzilla.gnome.org/show_bug.cgi?id=785381
2017-03-24 09:35:51 +00:00
MetaOutput *output = l->data;
Extend the DBus XRandR protocol to expose cloning restriction Turns out that even if two outputs say that they can be controlled by a given CRTC, you can't configure them in the same CRTC unless they are marked as "possible clones" one of the other. This can further restrict the configuration options, so we need to expose this limitation in the DBus API. https://bugzilla.gnome.org/show_bug.cgi?id=705670
2013-07-19 16:47:01 +00:00
GVariantBuilder crtcs, modes, clones, properties;
MonitorManager: add EDID properties to the output DBus description Add "edid-file", if we have one (in the KMS case, where we can point people to the right sysfs file), or "edid" with inline data. These are needed by colord to build the default ICC profile for uncalibrated displays. https://bugzilla.gnome.org/show_bug.cgi?id=705670
2013-08-08 11:32:05 +00:00
GBytes *edid;
char *edid_file;
backends: Move MetaOutput::crtc field into private struct No functional changes. This is only done so that changes to reference counting can done more reliably. https://bugzilla.gnome.org/show_bug.cgi?id=786929
2017-11-03 10:25:30 +00:00
MetaCrtc *crtc;
monitor-manager: Make MetaCrtc a GObject Turn MetaCrtc into a GObject and move it to a separate file. This changes the storage format, resulting in changing the API for accessing MetaCrtcs from using an array, to using a GList. https://bugzilla.gnome.org/show_bug.cgi?id=785381
2017-03-28 04:35:19 +00:00
int crtc_index;
Introduce a new DBus interface for display configuration This new interface will be used by the control center and possibly the settings daemon to configure the screens. It is designed to resemble a simplified XRandR, while still exposing all the quirks of the hardware, so that the panel can limit the user choices appropriately. To do so, MetaMonitorMode needs to track CRTCs, outputs and modes, so the low level objects have been decoupled from the high-level MetaMonitorInfo, which is used by core and API and offers a simplified view of HW, that hides away the details of what is cloned and how. This is still not efficient as it should be, because on every HW change we drop all data structures and rebuild them from scratch (which is not expensive because there aren't many of them, but at least in the XRandR path it involves a few sync X calls) https://bugzilla.gnome.org/show_bug.cgi?id=705670
2013-07-19 12:39:28 +00:00
g_variant_builder_init (&crtcs, G_VARIANT_TYPE ("au"));
for (j = 0; j < output->n_possible_crtcs; j++)
monitor-manager: Make MetaCrtc a GObject Turn MetaCrtc into a GObject and move it to a separate file. This changes the storage format, resulting in changing the API for accessing MetaCrtcs from using an array, to using a GList. https://bugzilla.gnome.org/show_bug.cgi?id=785381
2017-03-28 04:35:19 +00:00
{
MetaCrtc *possible_crtc = output->possible_crtcs[j];
unsigned possible_crtc_index;
backends: Split out CRTC/output management to MetaGpu In order to eventually support multilpe GPUs with their own connectors, split out related meta data management (i.e. outputs, CRTCs and CRTC modes) into a new MetaGpu GObject. The Xrandr backend always assumes there is always only a single "GPU" as the GPU is abstracted by the X server; only the native backend (aside from the test backend) will eventually see more than one GPU. The Xrandr backend still moves some management to MetaGpuXrandr, in order to behave more similarly to the KMS counterparts. https://bugzilla.gnome.org/show_bug.cgi?id=785381
2017-07-10 10:19:32 +00:00
possible_crtc_index = g_list_index (combined_crtcs, possible_crtc);
monitor-manager: Make MetaCrtc a GObject Turn MetaCrtc into a GObject and move it to a separate file. This changes the storage format, resulting in changing the API for accessing MetaCrtcs from using an array, to using a GList. https://bugzilla.gnome.org/show_bug.cgi?id=785381
2017-03-28 04:35:19 +00:00
g_variant_builder_add (&crtcs, "u", possible_crtc_index);
}
Introduce a new DBus interface for display configuration This new interface will be used by the control center and possibly the settings daemon to configure the screens. It is designed to resemble a simplified XRandR, while still exposing all the quirks of the hardware, so that the panel can limit the user choices appropriately. To do so, MetaMonitorMode needs to track CRTCs, outputs and modes, so the low level objects have been decoupled from the high-level MetaMonitorInfo, which is used by core and API and offers a simplified view of HW, that hides away the details of what is cloned and how. This is still not efficient as it should be, because on every HW change we drop all data structures and rebuild them from scratch (which is not expensive because there aren't many of them, but at least in the XRandR path it involves a few sync X calls) https://bugzilla.gnome.org/show_bug.cgi?id=705670
2013-07-19 12:39:28 +00:00
g_variant_builder_init (&modes, G_VARIANT_TYPE ("au"));
for (j = 0; j < output->n_modes; j++)
monitor-manager: Turn MetaCrtcMode into a GObject Convert MetaCrtcMode from a plain struct to a GObject. This changes the storage format, and also the API, as the API was dependent on the storage format. https://bugzilla.gnome.org/show_bug.cgi?id=785381
2017-03-28 08:52:15 +00:00
{
unsigned mode_index;
backends: Split out CRTC/output management to MetaGpu In order to eventually support multilpe GPUs with their own connectors, split out related meta data management (i.e. outputs, CRTCs and CRTC modes) into a new MetaGpu GObject. The Xrandr backend always assumes there is always only a single "GPU" as the GPU is abstracted by the X server; only the native backend (aside from the test backend) will eventually see more than one GPU. The Xrandr backend still moves some management to MetaGpuXrandr, in order to behave more similarly to the KMS counterparts. https://bugzilla.gnome.org/show_bug.cgi?id=785381
2017-07-10 10:19:32 +00:00
mode_index = g_list_index (combined_modes, output->modes[j]);
monitor-manager: Turn MetaCrtcMode into a GObject Convert MetaCrtcMode from a plain struct to a GObject. This changes the storage format, and also the API, as the API was dependent on the storage format. https://bugzilla.gnome.org/show_bug.cgi?id=785381
2017-03-28 08:52:15 +00:00
g_variant_builder_add (&modes, "u", mode_index);
}
Introduce a new DBus interface for display configuration This new interface will be used by the control center and possibly the settings daemon to configure the screens. It is designed to resemble a simplified XRandR, while still exposing all the quirks of the hardware, so that the panel can limit the user choices appropriately. To do so, MetaMonitorMode needs to track CRTCs, outputs and modes, so the low level objects have been decoupled from the high-level MetaMonitorInfo, which is used by core and API and offers a simplified view of HW, that hides away the details of what is cloned and how. This is still not efficient as it should be, because on every HW change we drop all data structures and rebuild them from scratch (which is not expensive because there aren't many of them, but at least in the XRandR path it involves a few sync X calls) https://bugzilla.gnome.org/show_bug.cgi?id=705670
2013-07-19 12:39:28 +00:00
Extend the DBus XRandR protocol to expose cloning restriction Turns out that even if two outputs say that they can be controlled by a given CRTC, you can't configure them in the same CRTC unless they are marked as "possible clones" one of the other. This can further restrict the configuration options, so we need to expose this limitation in the DBus API. https://bugzilla.gnome.org/show_bug.cgi?id=705670
2013-07-19 16:47:01 +00:00
g_variant_builder_init (&clones, G_VARIANT_TYPE ("au"));
for (j = 0; j < output->n_possible_clones; j++)
Make MetaOutput a GObject Turn MetaOutput into a GObject and move it to a separate file. This changes the storage format, resulting in changing the API for accessing MetaOutputs from using an array, to using a GList. https://bugzilla.gnome.org/show_bug.cgi?id=785381
2017-03-24 09:35:51 +00:00
{
unsigned int possible_clone_index;
backends: Split out CRTC/output management to MetaGpu In order to eventually support multilpe GPUs with their own connectors, split out related meta data management (i.e. outputs, CRTCs and CRTC modes) into a new MetaGpu GObject. The Xrandr backend always assumes there is always only a single "GPU" as the GPU is abstracted by the X server; only the native backend (aside from the test backend) will eventually see more than one GPU. The Xrandr backend still moves some management to MetaGpuXrandr, in order to behave more similarly to the KMS counterparts. https://bugzilla.gnome.org/show_bug.cgi?id=785381
2017-07-10 10:19:32 +00:00
possible_clone_index = g_list_index (combined_outputs,
Make MetaOutput a GObject Turn MetaOutput into a GObject and move it to a separate file. This changes the storage format, resulting in changing the API for accessing MetaOutputs from using an array, to using a GList. https://bugzilla.gnome.org/show_bug.cgi?id=785381
2017-03-24 09:35:51 +00:00
output->possible_clones[j]);
g_variant_builder_add (&clones, "u", possible_clone_index);
}
Extend the DBus XRandR protocol to expose cloning restriction Turns out that even if two outputs say that they can be controlled by a given CRTC, you can't configure them in the same CRTC unless they are marked as "possible clones" one of the other. This can further restrict the configuration options, so we need to expose this limitation in the DBus API. https://bugzilla.gnome.org/show_bug.cgi?id=705670
2013-07-19 16:47:01 +00:00
Introduce a new DBus interface for display configuration This new interface will be used by the control center and possibly the settings daemon to configure the screens. It is designed to resemble a simplified XRandR, while still exposing all the quirks of the hardware, so that the panel can limit the user choices appropriately. To do so, MetaMonitorMode needs to track CRTCs, outputs and modes, so the low level objects have been decoupled from the high-level MetaMonitorInfo, which is used by core and API and offers a simplified view of HW, that hides away the details of what is cloned and how. This is still not efficient as it should be, because on every HW change we drop all data structures and rebuild them from scratch (which is not expensive because there aren't many of them, but at least in the XRandR path it involves a few sync X calls) https://bugzilla.gnome.org/show_bug.cgi?id=705670
2013-07-19 12:39:28 +00:00
g_variant_builder_init (&properties, G_VARIANT_TYPE ("a{sv}"));
g_variant_builder_add (&properties, "{sv}", "vendor",
g_variant_new_string (output->vendor));
g_variant_builder_add (&properties, "{sv}", "product",
g_variant_new_string (output->product));
g_variant_builder_add (&properties, "{sv}", "serial",
g_variant_new_string (output->serial));
MonitorManager: extend the API with physical sizes These will be needed in the new display panel designs to show the diagonal length and physical aspect ratio. https://bugzilla.gnome.org/show_bug.cgi?id=706322
2013-08-19 15:37:24 +00:00
g_variant_builder_add (&properties, "{sv}", "width-mm",
g_variant_new_int32 (output->width_mm));
g_variant_builder_add (&properties, "{sv}", "height-mm",
g_variant_new_int32 (output->height_mm));
Introduce a new DBus interface for display configuration This new interface will be used by the control center and possibly the settings daemon to configure the screens. It is designed to resemble a simplified XRandR, while still exposing all the quirks of the hardware, so that the panel can limit the user choices appropriately. To do so, MetaMonitorMode needs to track CRTCs, outputs and modes, so the low level objects have been decoupled from the high-level MetaMonitorInfo, which is used by core and API and offers a simplified view of HW, that hides away the details of what is cloned and how. This is still not efficient as it should be, because on every HW change we drop all data structures and rebuild them from scratch (which is not expensive because there aren't many of them, but at least in the XRandR path it involves a few sync X calls) https://bugzilla.gnome.org/show_bug.cgi?id=705670
2013-07-19 12:39:28 +00:00
g_variant_builder_add (&properties, "{sv}", "display-name",
Monitor: restore correct display name handling Now that we have the right values from the EDID, we can load the PNP database and find the proper vendor name, to show in the control center UI. https://bugzilla.gnome.org/show_bug.cgi?id=705670
2013-08-16 15:32:50 +00:00
g_variant_new_take_string (make_display_name (manager, output)));
MonitorManager: add support for backlight GnomeRR needs that too. The backlight is exported as a normalized 0-100 value, or -1 if not supported. Clamping to HW limits is handled by the backend. Changing backlight uses a different method call, to avoid recomputing the full display configuration every time the user presses the backlight keys. https://bugzilla.gnome.org/show_bug.cgi?id=705670
2013-07-25 13:06:09 +00:00
g_variant_builder_add (&properties, "{sv}", "backlight",
g_variant_new_int32 (output->backlight));
monitor: expose min-backlight-step Expose min-backlight-step so that gnome-settings-daemon can support backlights with less than 10 steps without mutter normalizing the brightness back to its original value https://bugzilla.gnome.org/show_bug.cgi?id=710380
2013-10-17 15:05:59 +00:00
g_variant_builder_add (&properties, "{sv}", "min-backlight-step",
g_variant_new_int32 ((output->backlight_max - output->backlight_min) ?
100 / (output->backlight_max - output->backlight_min) : -1));
Introduce a new DBus interface for display configuration This new interface will be used by the control center and possibly the settings daemon to configure the screens. It is designed to resemble a simplified XRandR, while still exposing all the quirks of the hardware, so that the panel can limit the user choices appropriately. To do so, MetaMonitorMode needs to track CRTCs, outputs and modes, so the low level objects have been decoupled from the high-level MetaMonitorInfo, which is used by core and API and offers a simplified view of HW, that hides away the details of what is cloned and how. This is still not efficient as it should be, because on every HW change we drop all data structures and rebuild them from scratch (which is not expensive because there aren't many of them, but at least in the XRandR path it involves a few sync X calls) https://bugzilla.gnome.org/show_bug.cgi?id=705670
2013-07-19 12:39:28 +00:00
g_variant_builder_add (&properties, "{sv}", "primary",
g_variant_new_boolean (output->is_primary));
g_variant_builder_add (&properties, "{sv}", "presentation",
g_variant_new_boolean (output->is_presentation));
monitor-manager: Add a connector-type property This is so gnome-settings-daemon
2014-12-30 00:18:24 +00:00
g_variant_builder_add (&properties, "{sv}", "connector-type",
g_variant_new_string (get_connector_type_name (output->connector_type)));
MonitorManager: Add support for overscan compensation Some DRM drivers have added a consistent set of properties that allow compensating for the overscan that some TVs do, without the user being able to disable.
2014-04-16 08:20:55 +00:00
g_variant_builder_add (&properties, "{sv}", "underscanning",
g_variant_new_boolean (output->is_underscanning));
monitor-manager: add a property to discover if underscan is supported So that clients such as the control center can decide to hide an underscanning checkbutton when the output does not support it. Support in the KMS / native backend to come later...
2015-07-02 00:42:46 +00:00
g_variant_builder_add (&properties, "{sv}", "supports-underscanning",
g_variant_new_boolean (output->supports_underscanning));
Introduce a new DBus interface for display configuration This new interface will be used by the control center and possibly the settings daemon to configure the screens. It is designed to resemble a simplified XRandR, while still exposing all the quirks of the hardware, so that the panel can limit the user choices appropriately. To do so, MetaMonitorMode needs to track CRTCs, outputs and modes, so the low level objects have been decoupled from the high-level MetaMonitorInfo, which is used by core and API and offers a simplified view of HW, that hides away the details of what is cloned and how. This is still not efficient as it should be, because on every HW change we drop all data structures and rebuild them from scratch (which is not expensive because there aren't many of them, but at least in the XRandR path it involves a few sync X calls) https://bugzilla.gnome.org/show_bug.cgi?id=705670
2013-07-19 12:39:28 +00:00
MonitorManager: add EDID properties to the output DBus description Add "edid-file", if we have one (in the KMS case, where we can point people to the right sysfs file), or "edid" with inline data. These are needed by colord to build the default ICC profile for uncalibrated displays. https://bugzilla.gnome.org/show_bug.cgi?id=705670
2013-08-08 11:32:05 +00:00
edid_file = manager_class->get_edid_file (manager, output);
if (edid_file)
{
g_variant_builder_add (&properties, "{sv}", "edid-file",
g_variant_new_take_string (edid_file));
}
else
{
edid = manager_class->read_edid (manager, output);
if (edid)
{
g_variant_builder_add (&properties, "{sv}", "edid",
g_variant_new_from_bytes (G_VARIANT_TYPE ("ay"),
edid, TRUE));
g_bytes_unref (edid);
}
}
monitors: adds expose tile info as a property over dbus interface This just adds 8 uint32s as a property to the dbus protocol. This will be used by gnome-desktop to get the tile info.
2015-03-31 00:44:16 +00:00
if (output->tile_info.group_id)
{
g_variant_builder_add (&properties, "{sv}", "tile",
g_variant_new ("(uuuuuuuu)",
output->tile_info.group_id,
output->tile_info.flags,
output->tile_info.max_h_tiles,
output->tile_info.max_v_tiles,
output->tile_info.loc_h_tile,
output->tile_info.loc_v_tile,
output->tile_info.tile_w,
output->tile_info.tile_h));
}
backends: Move MetaOutput::crtc field into private struct No functional changes. This is only done so that changes to reference counting can done more reliably. https://bugzilla.gnome.org/show_bug.cgi?id=786929
2017-11-03 10:25:30 +00:00
crtc = meta_output_get_assigned_crtc (output);
crtc_index = crtc ? g_list_index (combined_crtcs, crtc) : -1;
Extend the DBus XRandR protocol to expose cloning restriction Turns out that even if two outputs say that they can be controlled by a given CRTC, you can't configure them in the same CRTC unless they are marked as "possible clones" one of the other. This can further restrict the configuration options, so we need to expose this limitation in the DBus API. https://bugzilla.gnome.org/show_bug.cgi?id=705670
2013-07-19 16:47:01 +00:00
g_variant_builder_add (&output_builder, "(uxiausauaua{sv})",
Introduce a new DBus interface for display configuration This new interface will be used by the control center and possibly the settings daemon to configure the screens. It is designed to resemble a simplified XRandR, while still exposing all the quirks of the hardware, so that the panel can limit the user choices appropriately. To do so, MetaMonitorMode needs to track CRTCs, outputs and modes, so the low level objects have been decoupled from the high-level MetaMonitorInfo, which is used by core and API and offers a simplified view of HW, that hides away the details of what is cloned and how. This is still not efficient as it should be, because on every HW change we drop all data structures and rebuild them from scratch (which is not expensive because there aren't many of them, but at least in the XRandR path it involves a few sync X calls) https://bugzilla.gnome.org/show_bug.cgi?id=705670
2013-07-19 12:39:28 +00:00
i, /* ID */
monitor-manager: Rename output_id to winsys_id The output_id is more of an opaque identifier for the monitor, based on its underlying ID from the windowing system. Since we also use the term "output_id" for the output's index, rename our use of the opaque cookie "output_id" to "winsys_id".
2014-07-01 17:23:05 +00:00
(gint64)output->winsys_id,
monitor-manager: Make MetaCrtc a GObject Turn MetaCrtc into a GObject and move it to a separate file. This changes the storage format, resulting in changing the API for accessing MetaCrtcs from using an array, to using a GList. https://bugzilla.gnome.org/show_bug.cgi?id=785381
2017-03-28 04:35:19 +00:00
crtc_index,
Introduce a new DBus interface for display configuration This new interface will be used by the control center and possibly the settings daemon to configure the screens. It is designed to resemble a simplified XRandR, while still exposing all the quirks of the hardware, so that the panel can limit the user choices appropriately. To do so, MetaMonitorMode needs to track CRTCs, outputs and modes, so the low level objects have been decoupled from the high-level MetaMonitorInfo, which is used by core and API and offers a simplified view of HW, that hides away the details of what is cloned and how. This is still not efficient as it should be, because on every HW change we drop all data structures and rebuild them from scratch (which is not expensive because there aren't many of them, but at least in the XRandR path it involves a few sync X calls) https://bugzilla.gnome.org/show_bug.cgi?id=705670
2013-07-19 12:39:28 +00:00
&crtcs,
output->name,
&modes,
Extend the DBus XRandR protocol to expose cloning restriction Turns out that even if two outputs say that they can be controlled by a given CRTC, you can't configure them in the same CRTC unless they are marked as "possible clones" one of the other. This can further restrict the configuration options, so we need to expose this limitation in the DBus API. https://bugzilla.gnome.org/show_bug.cgi?id=705670
2013-07-19 16:47:01 +00:00
&clones,
Introduce a new DBus interface for display configuration This new interface will be used by the control center and possibly the settings daemon to configure the screens. It is designed to resemble a simplified XRandR, while still exposing all the quirks of the hardware, so that the panel can limit the user choices appropriately. To do so, MetaMonitorMode needs to track CRTCs, outputs and modes, so the low level objects have been decoupled from the high-level MetaMonitorInfo, which is used by core and API and offers a simplified view of HW, that hides away the details of what is cloned and how. This is still not efficient as it should be, because on every HW change we drop all data structures and rebuild them from scratch (which is not expensive because there aren't many of them, but at least in the XRandR path it involves a few sync X calls) https://bugzilla.gnome.org/show_bug.cgi?id=705670
2013-07-19 12:39:28 +00:00
&properties);
}
backends: Split out CRTC/output management to MetaGpu In order to eventually support multilpe GPUs with their own connectors, split out related meta data management (i.e. outputs, CRTCs and CRTC modes) into a new MetaGpu GObject. The Xrandr backend always assumes there is always only a single "GPU" as the GPU is abstracted by the X server; only the native backend (aside from the test backend) will eventually see more than one GPU. The Xrandr backend still moves some management to MetaGpuXrandr, in order to behave more similarly to the KMS counterparts. https://bugzilla.gnome.org/show_bug.cgi?id=785381
2017-07-10 10:19:32 +00:00
for (l = combined_modes, i = 0; l; l = l->next, i++)
Introduce a new DBus interface for display configuration This new interface will be used by the control center and possibly the settings daemon to configure the screens. It is designed to resemble a simplified XRandR, while still exposing all the quirks of the hardware, so that the panel can limit the user choices appropriately. To do so, MetaMonitorMode needs to track CRTCs, outputs and modes, so the low level objects have been decoupled from the high-level MetaMonitorInfo, which is used by core and API and offers a simplified view of HW, that hides away the details of what is cloned and how. This is still not efficient as it should be, because on every HW change we drop all data structures and rebuild them from scratch (which is not expensive because there aren't many of them, but at least in the XRandR path it involves a few sync X calls) https://bugzilla.gnome.org/show_bug.cgi?id=705670
2013-07-19 12:39:28 +00:00
{
monitor-manager: Turn MetaCrtcMode into a GObject Convert MetaCrtcMode from a plain struct to a GObject. This changes the storage format, and also the API, as the API was dependent on the storage format. https://bugzilla.gnome.org/show_bug.cgi?id=785381
2017-03-28 08:52:15 +00:00
MetaCrtcMode *mode = l->data;
Introduce a new DBus interface for display configuration This new interface will be used by the control center and possibly the settings daemon to configure the screens. It is designed to resemble a simplified XRandR, while still exposing all the quirks of the hardware, so that the panel can limit the user choices appropriately. To do so, MetaMonitorMode needs to track CRTCs, outputs and modes, so the low level objects have been decoupled from the high-level MetaMonitorInfo, which is used by core and API and offers a simplified view of HW, that hides away the details of what is cloned and how. This is still not efficient as it should be, because on every HW change we drop all data structures and rebuild them from scratch (which is not expensive because there aren't many of them, but at least in the XRandR path it involves a few sync X calls) https://bugzilla.gnome.org/show_bug.cgi?id=705670
2013-07-19 12:39:28 +00:00
backends: Add flags to MetaMonitorMode And export them in the DBus API since they're useful for gnome-control-center. https://bugzilla.gnome.org/show_bug.cgi?id=763832
2015-04-21 15:49:55 +00:00
g_variant_builder_add (&mode_builder, "(uxuudu)",
Introduce a new DBus interface for display configuration This new interface will be used by the control center and possibly the settings daemon to configure the screens. It is designed to resemble a simplified XRandR, while still exposing all the quirks of the hardware, so that the panel can limit the user choices appropriately. To do so, MetaMonitorMode needs to track CRTCs, outputs and modes, so the low level objects have been decoupled from the high-level MetaMonitorInfo, which is used by core and API and offers a simplified view of HW, that hides away the details of what is cloned and how. This is still not efficient as it should be, because on every HW change we drop all data structures and rebuild them from scratch (which is not expensive because there aren't many of them, but at least in the XRandR path it involves a few sync X calls) https://bugzilla.gnome.org/show_bug.cgi?id=705670
2013-07-19 12:39:28 +00:00
i, /* ID */
MonitorManager: make sure to pass the right sizes to vararg functions A gulong is not enough to get 64 bits in all arches, so we must cast it, or we can corrupt the stack. This was downstream bug bugzilla.redhat.com/show_bug.cgi?id=1002055 https://bugzilla.gnome.org/show_bug.cgi?id=707267
2013-09-02 07:29:26 +00:00
(gint64)mode->mode_id,
(guint32)mode->width,
(guint32)mode->height,
backends: Add flags to MetaMonitorMode And export them in the DBus API since they're useful for gnome-control-center. https://bugzilla.gnome.org/show_bug.cgi?id=763832
2015-04-21 15:49:55 +00:00
(double)mode->refresh_rate,
(guint32)mode->flags);
Introduce a new DBus interface for display configuration This new interface will be used by the control center and possibly the settings daemon to configure the screens. It is designed to resemble a simplified XRandR, while still exposing all the quirks of the hardware, so that the panel can limit the user choices appropriately. To do so, MetaMonitorMode needs to track CRTCs, outputs and modes, so the low level objects have been decoupled from the high-level MetaMonitorInfo, which is used by core and API and offers a simplified view of HW, that hides away the details of what is cloned and how. This is still not efficient as it should be, because on every HW change we drop all data structures and rebuild them from scratch (which is not expensive because there aren't many of them, but at least in the XRandR path it involves a few sync X calls) https://bugzilla.gnome.org/show_bug.cgi?id=705670
2013-07-19 12:39:28 +00:00
}
monitor-manager: Make max screen size optional Make the concept of maximum screen size optional, as it is not necessarily a thing on all systems (e.g. when using the native backend and stage views). The meta_monitor_monitor_get_limits() function is replaced by a meta_monitor_manager_get_max_screen_size() which fails when no screen limit is available. Callers and other users of the previous max screen size fields are updated to deal with the fact that the limit is optional. The new D-Bus API is changed to move it to the properties bag, where its absence means there is no applicable limit. https://bugzilla.gnome.org/show_bug.cgi?id=777732
2017-02-15 08:06:46 +00:00
if (!meta_monitor_manager_get_max_screen_size (manager,
&max_screen_width,
&max_screen_height))
{
/* No max screen size, just send something large */
max_screen_width = 65535;
max_screen_height = 65535;
}
Introduce a new DBus interface for display configuration This new interface will be used by the control center and possibly the settings daemon to configure the screens. It is designed to resemble a simplified XRandR, while still exposing all the quirks of the hardware, so that the panel can limit the user choices appropriately. To do so, MetaMonitorMode needs to track CRTCs, outputs and modes, so the low level objects have been decoupled from the high-level MetaMonitorInfo, which is used by core and API and offers a simplified view of HW, that hides away the details of what is cloned and how. This is still not efficient as it should be, because on every HW change we drop all data structures and rebuild them from scratch (which is not expensive because there aren't many of them, but at least in the XRandR path it involves a few sync X calls) https://bugzilla.gnome.org/show_bug.cgi?id=705670
2013-07-19 12:39:28 +00:00
meta_dbus_display_config_complete_get_resources (skeleton,
invocation,
manager->serial,
g_variant_builder_end (&crtc_builder),
g_variant_builder_end (&output_builder),
DisplayConfig: add the write side of the API Implement ApplyConfiguration in terms of XRandR calls. Error checking is done before actually committing the configuration. If mutter is using one of the other monitor config backends, an error is reported and nothing happens. https://bugzilla.gnome.org/show_bug.cgi?id=705670
2013-07-22 11:31:10 +00:00
g_variant_builder_end (&mode_builder),
monitor-manager: Make max screen size optional Make the concept of maximum screen size optional, as it is not necessarily a thing on all systems (e.g. when using the native backend and stage views). The meta_monitor_monitor_get_limits() function is replaced by a meta_monitor_manager_get_max_screen_size() which fails when no screen limit is available. Callers and other users of the previous max screen size fields are updated to deal with the fact that the limit is optional. The new D-Bus API is changed to move it to the properties bag, where its absence means there is no applicable limit. https://bugzilla.gnome.org/show_bug.cgi?id=777732
2017-02-15 08:06:46 +00:00
max_screen_width,
max_screen_height);
backends: Split out CRTC/output management to MetaGpu In order to eventually support multilpe GPUs with their own connectors, split out related meta data management (i.e. outputs, CRTCs and CRTC modes) into a new MetaGpu GObject. The Xrandr backend always assumes there is always only a single "GPU" as the GPU is abstracted by the X server; only the native backend (aside from the test backend) will eventually see more than one GPU. The Xrandr backend still moves some management to MetaGpuXrandr, in order to behave more similarly to the KMS counterparts. https://bugzilla.gnome.org/show_bug.cgi?id=785381
2017-07-10 10:19:32 +00:00
g_list_free (combined_modes);
g_list_free (combined_outputs);
g_list_free (combined_crtcs);
DisplayConfig: add the write side of the API Implement ApplyConfiguration in terms of XRandR calls. Error checking is done before actually committing the configuration. If mutter is using one of the other monitor config backends, an error is reported and nothing happens. https://bugzilla.gnome.org/show_bug.cgi?id=705670
2013-07-22 11:31:10 +00:00
return TRUE;
}
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 09:20:07 +00:00
static void
restore_previous_config (MetaMonitorManager *manager)
{
MetaMonitorsConfig *previous_config;
GError *error = NULL;
previous_config =
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 07:16:15 +00:00
meta_monitor_config_manager_pop_previous (manager->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 09:20:07 +00:00
if (previous_config)
{
MetaMonitorsConfigMethod method;
method = META_MONITORS_CONFIG_METHOD_TEMPORARY;
if (meta_monitor_manager_apply_monitors_config (manager,
previous_config,
method,
&error))
{
g_object_unref (previous_config);
return;
}
else
{
g_object_unref (previous_config);
g_warning ("Failed to restore previous configuration: %s",
error->message);
g_error_free (error);
}
}
meta_monitor_manager_ensure_configured (manager);
}
monitor-manager: add API to get the display configuration timeout Instead of hardcoding this into two different places, add an API so that gnome-shell can fetch it. https://bugzilla.gnome.org/show_bug.cgi?id=767805
2014-08-21 00:07:13 +00:00
gint
meta_monitor_manager_get_display_configuration_timeout (void)
{
return DEFAULT_DISPLAY_CONFIGURATION_TIMEOUT;
}
MonitorManager: add support for persistent monitor configurations Add a new object, MetaMonitorConfig, that takes care of converting between the logical configurations stored in monitors.xml and the HW resources exposed by MonitorManager. This commit includes loading and saving of configurations, but still missing is the actual CRTC assignments and a default configuration when none is found in the file. https://bugzilla.gnome.org/show_bug.cgi?id=705670
2013-07-24 13:35:47 +00:00
static gboolean
save_config_timeout (gpointer user_data)
{
MetaMonitorManager *manager = user_data;
Remove old monitor configuration system Remove the old MetaMonitorConfig system and mark the new one as non-experimental. This also removes the D-Bus property. https://bugzilla.gnome.org/show_bug.cgi?id=777732
2017-03-24 07:36:12 +00:00
restore_previous_config (manager);
MetaPlugin: add a UI hook for confirming display changes We want to show a dialog when a display change happens from the control center. To do so, add a new vfunc to MetaPlugin and call it when a configuration change is requested via DBus. https://bugzilla.gnome.org/show_bug.cgi?id=705670
2013-07-29 08:12:24 +00:00
manager->persistent_timeout_id = 0;
Remove old monitor configuration system Remove the old MetaMonitorConfig system and mark the new one as non-experimental. This also removes the D-Bus property. https://bugzilla.gnome.org/show_bug.cgi?id=777732
2017-03-24 07:36:12 +00:00
MonitorManager: add support for persistent monitor configurations Add a new object, MetaMonitorConfig, that takes care of converting between the logical configurations stored in monitors.xml and the HW resources exposed by MonitorManager. This commit includes loading and saving of configurations, but still missing is the actual CRTC assignments and a default configuration when none is found in the file. https://bugzilla.gnome.org/show_bug.cgi?id=705670
2013-07-24 13:35:47 +00:00
return G_SOURCE_REMOVE;
}
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 09:20:07 +00:00
static void
cancel_persistent_confirmation (MetaMonitorManager *manager)
{
g_source_remove (manager->persistent_timeout_id);
manager->persistent_timeout_id = 0;
}
static void
Remove old monitor configuration system Remove the old MetaMonitorConfig system and mark the new one as non-experimental. This also removes the D-Bus property. https://bugzilla.gnome.org/show_bug.cgi?id=777732
2017-03-24 07:36:12 +00:00
request_persistent_confirmation (MetaMonitorManager *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 09:20:07 +00:00
{
monitor-manager: add API to get the display configuration timeout Instead of hardcoding this into two different places, add an API so that gnome-shell can fetch it. https://bugzilla.gnome.org/show_bug.cgi?id=767805
2014-08-21 00:07:13 +00:00
manager->persistent_timeout_id = g_timeout_add_seconds (meta_monitor_manager_get_display_configuration_timeout (),
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 09:20:07 +00:00
save_config_timeout,
manager);
g_source_set_name_by_id (manager->persistent_timeout_id,
"[mutter] save_config_timeout");
g_signal_emit (manager, signals[CONFIRM_DISPLAY_CHANGE], 0);
}
DisplayConfig: Add new API for getting current state Add a D-Bus method for getting the current monitor and logical monitor state. Currently does not contain information about transforms or any limitations (such as limited CRTCs and cloning). https://bugzilla.gnome.org/show_bug.cgi?id=777732
2017-01-20 08:55:43 +00:00
#define META_DISPLAY_CONFIG_MODE_FLAGS_PREFERRED (1 << 0)
#define META_DISPLAY_CONFIG_MODE_FLAGS_CURRENT (1 << 1)
DisplayConfig: Replace mode 'u' flags with 'a{sv}' property bag To be more flexible without having to change any D-Bus type signatures in the future, replace the 'uint' flags value (currently determining whether a mode is current and/or preferred) with a variant lookup table. The keys 'is-current' (b) and 'is-preferred' (b) replace the existing flags. https://bugzilla.gnome.org/show_bug.cgi?id=765011
2017-06-14 04:17:31 +00:00
#define MODE_FORMAT "(siiddada{sv})"
DisplayConfig: Add new API for getting current state Add a D-Bus method for getting the current monitor and logical monitor state. Currently does not contain information about transforms or any limitations (such as limited CRTCs and cloning). https://bugzilla.gnome.org/show_bug.cgi?id=777732
2017-01-20 08:55:43 +00:00
#define MODES_FORMAT "a" MODE_FORMAT
#define MONITOR_SPEC_FORMAT "(ssss)"
#define MONITOR_FORMAT "(" MONITOR_SPEC_FORMAT MODES_FORMAT "a{sv})"
#define MONITORS_FORMAT "a" MONITOR_FORMAT
#define LOGICAL_MONITOR_MONITORS_FORMAT "a" MONITOR_SPEC_FORMAT
DisplayConfig: Add logical monitor transforms Add the transform as a logical monitor parameter, both when getting the current state and applying a new configuration. The transform is defined to be identical to MetaMonitorTransform. https://bugzilla.gnome.org/show_bug.cgi?id=777732
2017-03-21 06:29:32 +00:00
#define LOGICAL_MONITOR_FORMAT "(iidub" LOGICAL_MONITOR_MONITORS_FORMAT "a{sv})"
DisplayConfig: Add new API for getting current state Add a D-Bus method for getting the current monitor and logical monitor state. Currently does not contain information about transforms or any limitations (such as limited CRTCs and cloning). https://bugzilla.gnome.org/show_bug.cgi?id=777732
2017-01-20 08:55:43 +00:00
#define LOGICAL_MONITORS_FORMAT "a" LOGICAL_MONITOR_FORMAT
static gboolean
meta_monitor_manager_handle_get_current_state (MetaDBusDisplayConfig *skeleton,
GDBusMethodInvocation *invocation)
{
MetaMonitorManager *manager = META_MONITOR_MANAGER (skeleton);
DisplayConfig: Add 'legacy-ui-scaling-factor' property We have this value in mutter; lets share it so that for example gnome-settings-daemon doesn't have to calculate it itself. https://bugzilla.gnome.org/show_bug.cgi?id=788820
2017-10-11 09:59:04 +00:00
MetaSettings *settings = meta_backend_get_settings (manager->backend);
DisplayConfig: Add new API for getting current state Add a D-Bus method for getting the current monitor and logical monitor state. Currently does not contain information about transforms or any limitations (such as limited CRTCs and cloning). https://bugzilla.gnome.org/show_bug.cgi?id=777732
2017-01-20 08:55:43 +00:00
GVariantBuilder monitors_builder;
GVariantBuilder logical_monitors_builder;
DisplayConfig: Add 'properties' to GetCurrentState Adds compositor wide DisplayConfig properties bag, and add a "supports-mirroring" property. https://bugzilla.gnome.org/show_bug.cgi?id=777732
2017-02-07 08:03:43 +00:00
GVariantBuilder properties_builder;
DisplayConfig: Add new API for getting current state Add a D-Bus method for getting the current monitor and logical monitor state. Currently does not contain information about transforms or any limitations (such as limited CRTCs and cloning). https://bugzilla.gnome.org/show_bug.cgi?id=777732
2017-01-20 08:55:43 +00:00
GList *l;
monitor-manager: Add supported scales to D-Bus API Let the configuring client know what scales are supported by the display server. https://bugzilla.gnome.org/show_bug.cgi?id=777732
2017-01-26 09:15:52 +00:00
int i;
DisplayConfig: Add 'properties' to GetCurrentState Adds compositor wide DisplayConfig properties bag, and add a "supports-mirroring" property. https://bugzilla.gnome.org/show_bug.cgi?id=777732
2017-02-07 08:03:43 +00:00
MetaMonitorManagerCapability capabilities;
DisplayConfig: Add 'legacy-ui-scaling-factor' property We have this value in mutter; lets share it so that for example gnome-settings-daemon doesn't have to calculate it itself. https://bugzilla.gnome.org/show_bug.cgi?id=788820
2017-10-11 09:59:04 +00:00
int ui_scaling_factor;
monitor-manager: Make max screen size optional Make the concept of maximum screen size optional, as it is not necessarily a thing on all systems (e.g. when using the native backend and stage views). The meta_monitor_monitor_get_limits() function is replaced by a meta_monitor_manager_get_max_screen_size() which fails when no screen limit is available. Callers and other users of the previous max screen size fields are updated to deal with the fact that the limit is optional. The new D-Bus API is changed to move it to the properties bag, where its absence means there is no applicable limit. https://bugzilla.gnome.org/show_bug.cgi?id=777732
2017-02-15 08:06:46 +00:00
int max_screen_width, max_screen_height;
DisplayConfig: Add new API for getting current state Add a D-Bus method for getting the current monitor and logical monitor state. Currently does not contain information about transforms or any limitations (such as limited CRTCs and cloning). https://bugzilla.gnome.org/show_bug.cgi?id=777732
2017-01-20 08:55:43 +00:00
g_variant_builder_init (&monitors_builder,
G_VARIANT_TYPE (MONITORS_FORMAT));
g_variant_builder_init (&logical_monitors_builder,
G_VARIANT_TYPE (LOGICAL_MONITORS_FORMAT));
for (l = manager->monitors; l; l = l->next)
{
MetaMonitor *monitor = l->data;
MetaMonitorSpec *monitor_spec = meta_monitor_get_spec (monitor);
MetaMonitorMode *current_mode;
MetaMonitorMode *preferred_mode;
GVariantBuilder modes_builder;
DisplayConfig: Add 'properties' to GetCurrentState Adds compositor wide DisplayConfig properties bag, and add a "supports-mirroring" property. https://bugzilla.gnome.org/show_bug.cgi?id=777732
2017-02-07 08:03:43 +00:00
GVariantBuilder monitor_properties_builder;
DisplayConfig: Add new API for getting current state Add a D-Bus method for getting the current monitor and logical monitor state. Currently does not contain information about transforms or any limitations (such as limited CRTCs and cloning). https://bugzilla.gnome.org/show_bug.cgi?id=777732
2017-01-20 08:55:43 +00:00
GList *k;
DisplayConfig: Add "is_builtin" monitor property Add a per-monitor property allowing the application to determine whether the monitor is builtin or not, e.g. a laptop panel. https://bugzilla.gnome.org/show_bug.cgi?id=777732
2017-03-23 15:33:34 +00:00
gboolean is_builtin;
DisplayConfig: Add display-name monitor property This is the same property as the one associated with an output in GetResources. https://bugzilla.gnome.org/show_bug.cgi?id=777732
2017-04-06 05:13:20 +00:00
MetaOutput *main_output;
char *display_name;
DisplayConfig: Add new API for getting current state Add a D-Bus method for getting the current monitor and logical monitor state. Currently does not contain information about transforms or any limitations (such as limited CRTCs and cloning). https://bugzilla.gnome.org/show_bug.cgi?id=777732
2017-01-20 08:55:43 +00:00
current_mode = meta_monitor_get_current_mode (monitor);
preferred_mode = meta_monitor_get_preferred_mode (monitor);
g_variant_builder_init (&modes_builder, G_VARIANT_TYPE (MODES_FORMAT));
for (k = meta_monitor_get_modes (monitor); k; k = k->next)
{
MetaMonitorMode *monitor_mode = k->data;
DisplayConfig: Make supported scales per mode This changes the API to pass supported scales per mode instead of providing a global list. This allows for more flexible scaling scenarious, where a scale compatible with one mode can still be made available even though another mode is incompatible. https://bugzilla.gnome.org/show_bug.cgi?id=765011
2017-06-05 07:59:47 +00:00
GVariantBuilder supported_scales_builder;
DisplayConfig: Specify mode ID string instead of mode spec To be able to add more modes types that happen to have the same resolution and refresh rate, change the API to specify modes using an ID string. The ID string is temporary, and only works for associating a mode for the monitor instance that it was part of. https://bugzilla.gnome.org/show_bug.cgi?id=765011
2017-06-14 04:04:09 +00:00
const char *mode_id;
int mode_width, mode_height;
float refresh_rate;
DisplayConfig: Make supported scales per mode This changes the API to pass supported scales per mode instead of providing a global list. This allows for more flexible scaling scenarious, where a scale compatible with one mode can still be made available even though another mode is incompatible. https://bugzilla.gnome.org/show_bug.cgi?id=765011
2017-06-05 07:59:47 +00:00
float preferred_scale;
float *supported_scales;
int n_supported_scales;
DisplayConfig: Replace mode 'u' flags with 'a{sv}' property bag To be more flexible without having to change any D-Bus type signatures in the future, replace the 'uint' flags value (currently determining whether a mode is current and/or preferred) with a variant lookup table. The keys 'is-current' (b) and 'is-preferred' (b) replace the existing flags. https://bugzilla.gnome.org/show_bug.cgi?id=765011
2017-06-14 04:17:31 +00:00
GVariantBuilder mode_properties_builder;
DisplayConfig: Add support for interlaced modes Differentiate between non-interlaced and interlaced modes. This is done by appending an "i" after the resolution part of the mode ID, and adding a 'is-interlaced' (b) property to the mode properties. https://bugzilla.gnome.org/show_bug.cgi?id=765011
2017-06-14 06:41:13 +00:00
MetaCrtcModeFlag mode_flags;
DisplayConfig: Add new API for getting current state Add a D-Bus method for getting the current monitor and logical monitor state. Currently does not contain information about transforms or any limitations (such as limited CRTCs and cloning). https://bugzilla.gnome.org/show_bug.cgi?id=777732
2017-01-20 08:55:43 +00:00
monitor-manager: Filter out low screen resolutions Avoid exporting through org.gnome.Mutter.DisplayConfig.GetCurrentState excessively-low screen resolutions setting both a minimum width and a minimum height. GetCurrentState is e.g. used by Gnome Control Center to build a list of selectable resolutions. Fixes: https://bugzilla.gnome.org/show_bug.cgi?id=793223
2018-07-16 16:09:40 +00:00
if (!meta_monitor_mode_should_be_advertised (monitor_mode))
continue;
DisplayConfig: Specify mode ID string instead of mode spec To be able to add more modes types that happen to have the same resolution and refresh rate, change the API to specify modes using an ID string. The ID string is temporary, and only works for associating a mode for the monitor instance that it was part of. https://bugzilla.gnome.org/show_bug.cgi?id=765011
2017-06-14 04:04:09 +00:00
mode_id = meta_monitor_mode_get_id (monitor_mode);
meta_monitor_mode_get_resolution (monitor_mode,
&mode_width, &mode_height);
monitor-manager: Filter out low screen resolutions Avoid exporting through org.gnome.Mutter.DisplayConfig.GetCurrentState excessively-low screen resolutions setting both a minimum width and a minimum height. GetCurrentState is e.g. used by Gnome Control Center to build a list of selectable resolutions. Fixes: https://bugzilla.gnome.org/show_bug.cgi?id=793223
2018-07-16 16:09:40 +00:00
DisplayConfig: Specify mode ID string instead of mode spec To be able to add more modes types that happen to have the same resolution and refresh rate, change the API to specify modes using an ID string. The ID string is temporary, and only works for associating a mode for the monitor instance that it was part of. https://bugzilla.gnome.org/show_bug.cgi?id=765011
2017-06-14 04:04:09 +00:00
refresh_rate = meta_monitor_mode_get_refresh_rate (monitor_mode);
DisplayConfig: Add new API for getting current state Add a D-Bus method for getting the current monitor and logical monitor state. Currently does not contain information about transforms or any limitations (such as limited CRTCs and cloning). https://bugzilla.gnome.org/show_bug.cgi?id=777732
2017-01-20 08:55:43 +00:00
preferred_scale =
meta_monitor_manager_calculate_monitor_mode_scale (manager,
monitor,
monitor_mode);
DisplayConfig: Make supported scales per mode This changes the API to pass supported scales per mode instead of providing a global list. This allows for more flexible scaling scenarious, where a scale compatible with one mode can still be made available even though another mode is incompatible. https://bugzilla.gnome.org/show_bug.cgi?id=765011
2017-06-05 07:59:47 +00:00
g_variant_builder_init (&supported_scales_builder,
G_VARIANT_TYPE ("ad"));
supported_scales =
meta_monitor_manager_calculate_supported_scales (manager,
manager->layout_mode,
monitor,
monitor_mode,
&n_supported_scales);
for (i = 0; i < n_supported_scales; i++)
g_variant_builder_add (&supported_scales_builder, "d",
(double) supported_scales[i]);
g_free (supported_scales);
DisplayConfig: Add support for interlaced modes Differentiate between non-interlaced and interlaced modes. This is done by appending an "i" after the resolution part of the mode ID, and adding a 'is-interlaced' (b) property to the mode properties. https://bugzilla.gnome.org/show_bug.cgi?id=765011
2017-06-14 06:41:13 +00:00
mode_flags = meta_monitor_mode_get_flags (monitor_mode);
DisplayConfig: Replace mode 'u' flags with 'a{sv}' property bag To be more flexible without having to change any D-Bus type signatures in the future, replace the 'uint' flags value (currently determining whether a mode is current and/or preferred) with a variant lookup table. The keys 'is-current' (b) and 'is-preferred' (b) replace the existing flags. https://bugzilla.gnome.org/show_bug.cgi?id=765011
2017-06-14 04:17:31 +00:00
g_variant_builder_init (&mode_properties_builder,
G_VARIANT_TYPE ("a{sv}"));
DisplayConfig: Add new API for getting current state Add a D-Bus method for getting the current monitor and logical monitor state. Currently does not contain information about transforms or any limitations (such as limited CRTCs and cloning). https://bugzilla.gnome.org/show_bug.cgi?id=777732
2017-01-20 08:55:43 +00:00
if (monitor_mode == current_mode)
DisplayConfig: Replace mode 'u' flags with 'a{sv}' property bag To be more flexible without having to change any D-Bus type signatures in the future, replace the 'uint' flags value (currently determining whether a mode is current and/or preferred) with a variant lookup table. The keys 'is-current' (b) and 'is-preferred' (b) replace the existing flags. https://bugzilla.gnome.org/show_bug.cgi?id=765011
2017-06-14 04:17:31 +00:00
g_variant_builder_add (&mode_properties_builder, "{sv}",
"is-current",
g_variant_new_boolean (TRUE));
DisplayConfig: Add new API for getting current state Add a D-Bus method for getting the current monitor and logical monitor state. Currently does not contain information about transforms or any limitations (such as limited CRTCs and cloning). https://bugzilla.gnome.org/show_bug.cgi?id=777732
2017-01-20 08:55:43 +00:00
if (monitor_mode == preferred_mode)
DisplayConfig: Replace mode 'u' flags with 'a{sv}' property bag To be more flexible without having to change any D-Bus type signatures in the future, replace the 'uint' flags value (currently determining whether a mode is current and/or preferred) with a variant lookup table. The keys 'is-current' (b) and 'is-preferred' (b) replace the existing flags. https://bugzilla.gnome.org/show_bug.cgi?id=765011
2017-06-14 04:17:31 +00:00
g_variant_builder_add (&mode_properties_builder, "{sv}",
"is-preferred",
g_variant_new_boolean (TRUE));
DisplayConfig: Add support for interlaced modes Differentiate between non-interlaced and interlaced modes. This is done by appending an "i" after the resolution part of the mode ID, and adding a 'is-interlaced' (b) property to the mode properties. https://bugzilla.gnome.org/show_bug.cgi?id=765011
2017-06-14 06:41:13 +00:00
if (mode_flags & META_CRTC_MODE_FLAG_INTERLACE)
g_variant_builder_add (&mode_properties_builder, "{sv}",
"is-interlaced",
g_variant_new_boolean (TRUE));
DisplayConfig: Add new API for getting current state Add a D-Bus method for getting the current monitor and logical monitor state. Currently does not contain information about transforms or any limitations (such as limited CRTCs and cloning). https://bugzilla.gnome.org/show_bug.cgi?id=777732
2017-01-20 08:55:43 +00:00
g_variant_builder_add (&modes_builder, MODE_FORMAT,
DisplayConfig: Specify mode ID string instead of mode spec To be able to add more modes types that happen to have the same resolution and refresh rate, change the API to specify modes using an ID string. The ID string is temporary, and only works for associating a mode for the monitor instance that it was part of. https://bugzilla.gnome.org/show_bug.cgi?id=765011
2017-06-14 04:04:09 +00:00
mode_id,
mode_width,
mode_height,
refresh_rate,
monitor-manager: Make scale floats in D-Bus API We don't want to limit ourself to whole integers for configuration, as that'd mean it wouldn't be able to provide configurations for fractional scalings. Thus, change scales to be referred to as floats instead of ints. https://bugzilla.gnome.org/show_bug.cgi?id=777732
2017-01-26 07:33:12 +00:00
(double) preferred_scale,
DisplayConfig: Make supported scales per mode This changes the API to pass supported scales per mode instead of providing a global list. This allows for more flexible scaling scenarious, where a scale compatible with one mode can still be made available even though another mode is incompatible. https://bugzilla.gnome.org/show_bug.cgi?id=765011
2017-06-05 07:59:47 +00:00
&supported_scales_builder,
DisplayConfig: Replace mode 'u' flags with 'a{sv}' property bag To be more flexible without having to change any D-Bus type signatures in the future, replace the 'uint' flags value (currently determining whether a mode is current and/or preferred) with a variant lookup table. The keys 'is-current' (b) and 'is-preferred' (b) replace the existing flags. https://bugzilla.gnome.org/show_bug.cgi?id=765011
2017-06-14 04:17:31 +00:00
&mode_properties_builder);
DisplayConfig: Add new API for getting current state Add a D-Bus method for getting the current monitor and logical monitor state. Currently does not contain information about transforms or any limitations (such as limited CRTCs and cloning). https://bugzilla.gnome.org/show_bug.cgi?id=777732
2017-01-20 08:55:43 +00:00
}
DisplayConfig: Add 'properties' to GetCurrentState Adds compositor wide DisplayConfig properties bag, and add a "supports-mirroring" property. https://bugzilla.gnome.org/show_bug.cgi?id=777732
2017-02-07 08:03:43 +00:00
g_variant_builder_init (&monitor_properties_builder,
G_VARIANT_TYPE ("a{sv}"));
DisplayConfig: Add an optional 'is_underscanning' monitor property Add a 'is_underscanning' entry to the properties map, if the monitor supports underscanning. The client should assume a monitor does not support underscanning if no property was added. https://bugzilla.gnome.org/show_bug.cgi?id=777732
2017-01-23 09:59:43 +00:00
if (meta_monitor_supports_underscanning (monitor))
{
gboolean is_underscanning = meta_monitor_is_underscanning (monitor);
DisplayConfig: Add 'properties' to GetCurrentState Adds compositor wide DisplayConfig properties bag, and add a "supports-mirroring" property. https://bugzilla.gnome.org/show_bug.cgi?id=777732
2017-02-07 08:03:43 +00:00
g_variant_builder_add (&monitor_properties_builder, "{sv}",
DisplayConfig: Make naming convention consistent Always use hyphens as delimit words in property keys. Underscore to delimit words in method arguments. https://bugzilla.gnome.org/show_bug.cgi?id=777732
2017-04-06 05:09:28 +00:00
"is-underscanning",
DisplayConfig: Add an optional 'is_underscanning' monitor property Add a 'is_underscanning' entry to the properties map, if the monitor supports underscanning. The client should assume a monitor does not support underscanning if no property was added. https://bugzilla.gnome.org/show_bug.cgi?id=777732
2017-01-23 09:59:43 +00:00
g_variant_new_boolean (is_underscanning));
}
DisplayConfig: Add "is_builtin" monitor property Add a per-monitor property allowing the application to determine whether the monitor is builtin or not, e.g. a laptop panel. https://bugzilla.gnome.org/show_bug.cgi?id=777732
2017-03-23 15:33:34 +00:00
is_builtin = meta_monitor_is_laptop_panel (monitor);
g_variant_builder_add (&monitor_properties_builder, "{sv}",
DisplayConfig: Make naming convention consistent Always use hyphens as delimit words in property keys. Underscore to delimit words in method arguments. https://bugzilla.gnome.org/show_bug.cgi?id=777732
2017-04-06 05:09:28 +00:00
"is-builtin",
DisplayConfig: Add "is_builtin" monitor property Add a per-monitor property allowing the application to determine whether the monitor is builtin or not, e.g. a laptop panel. https://bugzilla.gnome.org/show_bug.cgi?id=777732
2017-03-23 15:33:34 +00:00
g_variant_new_boolean (is_builtin));
DisplayConfig: Add display-name monitor property This is the same property as the one associated with an output in GetResources. https://bugzilla.gnome.org/show_bug.cgi?id=777732
2017-04-06 05:13:20 +00:00
main_output = meta_monitor_get_main_output (monitor);
display_name = make_display_name (manager, main_output);
g_variant_builder_add (&monitor_properties_builder, "{sv}",
"display-name",
g_variant_new_take_string (display_name));
DisplayConfig: Add new API for getting current state Add a D-Bus method for getting the current monitor and logical monitor state. Currently does not contain information about transforms or any limitations (such as limited CRTCs and cloning). https://bugzilla.gnome.org/show_bug.cgi?id=777732
2017-01-20 08:55:43 +00:00
g_variant_builder_add (&monitors_builder, MONITOR_FORMAT,
monitor_spec->connector,
monitor_spec->vendor,
monitor_spec->product,
monitor_spec->serial,
&modes_builder,
DisplayConfig: Add 'properties' to GetCurrentState Adds compositor wide DisplayConfig properties bag, and add a "supports-mirroring" property. https://bugzilla.gnome.org/show_bug.cgi?id=777732
2017-02-07 08:03:43 +00:00
&monitor_properties_builder);
DisplayConfig: Add new API for getting current state Add a D-Bus method for getting the current monitor and logical monitor state. Currently does not contain information about transforms or any limitations (such as limited CRTCs and cloning). https://bugzilla.gnome.org/show_bug.cgi?id=777732
2017-01-20 08:55:43 +00:00
}
for (l = manager->logical_monitors; l; l = l->next)
{
MetaLogicalMonitor *logical_monitor = l->data;
GVariantBuilder logical_monitor_monitors_builder;
GList *k;
g_variant_builder_init (&logical_monitor_monitors_builder,
G_VARIANT_TYPE (LOGICAL_MONITOR_MONITORS_FORMAT));
for (k = logical_monitor->monitors; k; k = k->next)
{
MetaMonitor *monitor = k->data;
MetaMonitorSpec *monitor_spec = meta_monitor_get_spec (monitor);
g_variant_builder_add (&logical_monitor_monitors_builder,
MONITOR_SPEC_FORMAT,
monitor_spec->connector,
monitor_spec->vendor,
monitor_spec->product,
monitor_spec->serial);
}
g_variant_builder_add (&logical_monitors_builder,
LOGICAL_MONITOR_FORMAT,
logical_monitor->rect.x,
logical_monitor->rect.y,
monitor-manager: Make scale floats in D-Bus API We don't want to limit ourself to whole integers for configuration, as that'd mean it wouldn't be able to provide configurations for fractional scalings. Thus, change scales to be referred to as floats instead of ints. https://bugzilla.gnome.org/show_bug.cgi?id=777732
2017-01-26 07:33:12 +00:00
(double) logical_monitor->scale,
DisplayConfig: Add logical monitor transforms Add the transform as a logical monitor parameter, both when getting the current state and applying a new configuration. The transform is defined to be identical to MetaMonitorTransform. https://bugzilla.gnome.org/show_bug.cgi?id=777732
2017-03-21 06:29:32 +00:00
logical_monitor->transform,
DisplayConfig: Add new API for getting current state Add a D-Bus method for getting the current monitor and logical monitor state. Currently does not contain information about transforms or any limitations (such as limited CRTCs and cloning). https://bugzilla.gnome.org/show_bug.cgi?id=777732
2017-01-20 08:55:43 +00:00
logical_monitor->is_primary,
DisplayConfig: Group logical monitor parameters a bit better Move around the parameters, just to put the always-there fields before the monitor array and property box. https://bugzilla.gnome.org/show_bug.cgi?id=777732
2017-02-14 10:31:05 +00:00
&logical_monitor_monitors_builder,
DisplayConfig: Add new API for getting current state Add a D-Bus method for getting the current monitor and logical monitor state. Currently does not contain information about transforms or any limitations (such as limited CRTCs and cloning). https://bugzilla.gnome.org/show_bug.cgi?id=777732
2017-01-20 08:55:43 +00:00
NULL);
}
DisplayConfig: Add 'properties' to GetCurrentState Adds compositor wide DisplayConfig properties bag, and add a "supports-mirroring" property. https://bugzilla.gnome.org/show_bug.cgi?id=777732
2017-02-07 08:03:43 +00:00
g_variant_builder_init (&properties_builder, G_VARIANT_TYPE ("a{sv}"));
capabilities = meta_monitor_manager_get_capabilities (manager);
if ((capabilities & META_MONITOR_MANAGER_CAPABILITY_MIRRORING) == 0)
{
g_variant_builder_add (&properties_builder, "{sv}",
"supports-mirroring",
g_variant_new_boolean (FALSE));
}
DisplayConfig: Add 'supports-changing-layout-mode' property This property may be used by a client to determine whether it is allowed to change the layout mode. https://bugzilla.gnome.org/show_bug.cgi?id=777732
2017-04-06 06:00:06 +00:00
g_variant_builder_add (&properties_builder, "{sv}",
"layout-mode",
g_variant_new_uint32 (manager->layout_mode));
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 10:10:52 +00:00
if (capabilities & META_MONITOR_MANAGER_CAPABILITY_LAYOUT_MODE)
{
g_variant_builder_add (&properties_builder, "{sv}",
DisplayConfig: Add 'supports-changing-layout-mode' property This property may be used by a client to determine whether it is allowed to change the layout mode. https://bugzilla.gnome.org/show_bug.cgi?id=777732
2017-04-06 06:00:06 +00:00
"supports-changing-layout-mode",
g_variant_new_boolean (TRUE));
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 10:10:52 +00:00
}
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 10:01:15 +00:00
if (capabilities & META_MONITOR_MANAGER_CAPABILITY_GLOBAL_SCALE_REQUIRED)
{
g_variant_builder_add (&properties_builder, "{sv}",
"global-scale-required",
g_variant_new_boolean (TRUE));
}
DisplayConfig: Add 'legacy-ui-scaling-factor' property We have this value in mutter; lets share it so that for example gnome-settings-daemon doesn't have to calculate it itself. https://bugzilla.gnome.org/show_bug.cgi?id=788820
2017-10-11 09:59:04 +00:00
ui_scaling_factor = meta_settings_get_ui_scaling_factor (settings);
g_variant_builder_add (&properties_builder, "{sv}",
"legacy-ui-scaling-factor",
g_variant_new_int32 (ui_scaling_factor));
monitor-manager: Make max screen size optional Make the concept of maximum screen size optional, as it is not necessarily a thing on all systems (e.g. when using the native backend and stage views). The meta_monitor_monitor_get_limits() function is replaced by a meta_monitor_manager_get_max_screen_size() which fails when no screen limit is available. Callers and other users of the previous max screen size fields are updated to deal with the fact that the limit is optional. The new D-Bus API is changed to move it to the properties bag, where its absence means there is no applicable limit. https://bugzilla.gnome.org/show_bug.cgi?id=777732
2017-02-15 08:06:46 +00:00
if (meta_monitor_manager_get_max_screen_size (manager,
&max_screen_width,
&max_screen_height))
{
GVariantBuilder max_screen_size_builder;
g_variant_builder_init (&max_screen_size_builder,
G_VARIANT_TYPE ("(ii)"));
g_variant_builder_add (&max_screen_size_builder, "i",
max_screen_width);
g_variant_builder_add (&max_screen_size_builder, "i",
max_screen_height);
g_variant_builder_add (&properties_builder, "{sv}",
DisplayConfig: Make naming convention consistent Always use hyphens as delimit words in property keys. Underscore to delimit words in method arguments. https://bugzilla.gnome.org/show_bug.cgi?id=777732
2017-04-06 05:09:28 +00:00
"max-screen-size",
monitor-manager: Make max screen size optional Make the concept of maximum screen size optional, as it is not necessarily a thing on all systems (e.g. when using the native backend and stage views). The meta_monitor_monitor_get_limits() function is replaced by a meta_monitor_manager_get_max_screen_size() which fails when no screen limit is available. Callers and other users of the previous max screen size fields are updated to deal with the fact that the limit is optional. The new D-Bus API is changed to move it to the properties bag, where its absence means there is no applicable limit. https://bugzilla.gnome.org/show_bug.cgi?id=777732
2017-02-15 08:06:46 +00:00
g_variant_builder_end (&max_screen_size_builder));
}
DisplayConfig: Add new API for getting current state Add a D-Bus method for getting the current monitor and logical monitor state. Currently does not contain information about transforms or any limitations (such as limited CRTCs and cloning). https://bugzilla.gnome.org/show_bug.cgi?id=777732
2017-01-20 08:55:43 +00:00
meta_dbus_display_config_complete_get_current_state (
skeleton,
invocation,
manager->serial,
g_variant_builder_end (&monitors_builder),
g_variant_builder_end (&logical_monitors_builder),
DisplayConfig: Add 'properties' to GetCurrentState Adds compositor wide DisplayConfig properties bag, and add a "supports-mirroring" property. https://bugzilla.gnome.org/show_bug.cgi?id=777732
2017-02-07 08:03:43 +00:00
g_variant_builder_end (&properties_builder));
DisplayConfig: Add new API for getting current state Add a D-Bus method for getting the current monitor and logical monitor state. Currently does not contain information about transforms or any limitations (such as limited CRTCs and cloning). https://bugzilla.gnome.org/show_bug.cgi?id=777732
2017-01-20 08:55:43 +00:00
return TRUE;
}
#undef MODE_FORMAT
#undef MODES_FORMAT
#undef MONITOR_SPEC_FORMAT
#undef MONITOR_FORMAT
#undef MONITORS_FORMAT
#undef LOGICAL_MONITOR_MONITORS_FORMAT
#undef LOGICAL_MONITOR_FORMAT
#undef LOGICAL_MONITORS_FORMAT
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 09:20:59 +00:00
gboolean
meta_monitor_manager_is_scale_supported (MetaMonitorManager *manager,
MetaLogicalMonitorLayoutMode layout_mode,
DisplayConfig: Make supported scales per mode This changes the API to pass supported scales per mode instead of providing a global list. This allows for more flexible scaling scenarious, where a scale compatible with one mode can still be made available even though another mode is incompatible. https://bugzilla.gnome.org/show_bug.cgi?id=765011
2017-06-05 07:59:47 +00:00
MetaMonitor *monitor,
MetaMonitorMode *monitor_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 09:20:59 +00:00
float scale)
DisplayConfig: Add new API for configuring monitors Add a new D-Bus API that uses the state from GetCurrentState to configure high level monitors, instead of low level CRTCs and connectors. So far persistent configuration is not implemented, as writing to the configuration store is still not supported. https://bugzilla.gnome.org/show_bug.cgi?id=777732
2017-02-14 11:54:04 +00:00
{
DisplayConfig: Make supported scales per mode This changes the API to pass supported scales per mode instead of providing a global list. This allows for more flexible scaling scenarious, where a scale compatible with one mode can still be made available even though another mode is incompatible. https://bugzilla.gnome.org/show_bug.cgi?id=765011
2017-06-05 07:59:47 +00:00
g_autofree float *supported_scales = NULL;
DisplayConfig: Add new API for configuring monitors Add a new D-Bus API that uses the state from GetCurrentState to configure high level monitors, instead of low level CRTCs and connectors. So far persistent configuration is not implemented, as writing to the configuration store is still not supported. https://bugzilla.gnome.org/show_bug.cgi?id=777732
2017-02-14 11:54:04 +00:00
int n_supported_scales;
int i;
DisplayConfig: Make supported scales per mode This changes the API to pass supported scales per mode instead of providing a global list. This allows for more flexible scaling scenarious, where a scale compatible with one mode can still be made available even though another mode is incompatible. https://bugzilla.gnome.org/show_bug.cgi?id=765011
2017-06-05 07:59:47 +00:00
supported_scales =
meta_monitor_manager_calculate_supported_scales (manager,
layout_mode,
monitor,
monitor_mode,
&n_supported_scales);
DisplayConfig: Add new API for configuring monitors Add a new D-Bus API that uses the state from GetCurrentState to configure high level monitors, instead of low level CRTCs and connectors. So far persistent configuration is not implemented, as writing to the configuration store is still not supported. https://bugzilla.gnome.org/show_bug.cgi?id=777732
2017-02-14 11:54:04 +00:00
for (i = 0; i < n_supported_scales; i++)
{
if (supported_scales[i] == scale)
return TRUE;
}
return FALSE;
}
static gboolean
meta_monitor_manager_is_config_applicable (MetaMonitorManager *manager,
MetaMonitorsConfig *config,
GError **error)
{
GList *l;
for (l = config->logical_monitor_configs; l; l = l->next)
{
MetaLogicalMonitorConfig *logical_monitor_config = l->data;
float scale = logical_monitor_config->scale;
GList *k;
for (k = logical_monitor_config->monitor_configs; k; k = k->next)
{
MetaMonitorConfig *monitor_config = k->data;
MetaMonitorSpec *monitor_spec = monitor_config->monitor_spec;
MetaMonitorModeSpec *mode_spec = monitor_config->mode_spec;
MetaMonitor *monitor;
MetaMonitorMode *monitor_mode;
monitor = meta_monitor_manager_get_monitor_from_spec (manager,
monitor_spec);
if (!monitor)
{
g_set_error (error, G_IO_ERROR, G_IO_ERROR_FAILED,
"Specified monitor not found");
return FALSE;
}
monitor_mode = meta_monitor_get_mode_from_spec (monitor, mode_spec);
if (!monitor_mode)
{
g_set_error (error, G_IO_ERROR, G_IO_ERROR_FAILED,
"Specified monitor mode not available");
return FALSE;
}
DisplayConfig: Make supported scales per mode This changes the API to pass supported scales per mode instead of providing a global list. This allows for more flexible scaling scenarious, where a scale compatible with one mode can still be made available even though another mode is incompatible. https://bugzilla.gnome.org/show_bug.cgi?id=765011
2017-06-05 07:59:47 +00:00
if (!meta_monitor_manager_is_scale_supported (manager,
config->layout_mode,
monitor,
monitor_mode,
scale))
{
g_set_error (error, G_IO_ERROR, G_IO_ERROR_FAILED,
"Scale not supported by backend");
return FALSE;
}
monitor-manager: Refuse to activate closed laptop panels 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
2017-11-14 17:10:55 +00:00
if (meta_monitor_is_laptop_panel (monitor) &&
backend: Move lid-is-closed handling to MetaBackend Rather than handle UpClient in both MetaBackend (to reset the idletime when the lid is opened), and in MetaMonitorManager and MetaMonitorConfigManager (to turn the screen under the lid on/off depending on its status), move the ability to get the lid status from UPower or mock it in one place, in MetaBackend.
2018-04-16 18:07:45 +00:00
meta_backend_is_lid_closed (manager->backend))
monitor-manager: Refuse to activate closed laptop panels 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
2017-11-14 17:10:55 +00:00
{
g_set_error (error, G_IO_ERROR, G_IO_ERROR_FAILED,
"Refusing to activate a closed laptop panel");
return FALSE;
}
DisplayConfig: Add new API for configuring monitors Add a new D-Bus API that uses the state from GetCurrentState to configure high level monitors, instead of low level CRTCs and connectors. So far persistent configuration is not implemented, as writing to the configuration store is still not supported. https://bugzilla.gnome.org/show_bug.cgi?id=777732
2017-02-14 11:54:04 +00:00
}
}
return TRUE;
}
monitor-manager: Try to restore previous config before regenerating When opening a laptop lid, one will likely want to restore the configuration one had prior to closing it, so when ensuring monitor configuration, first try to see if the previously set configuration is both complete (all connected monitors are configured) and applicable (it is a valid configuration) and only try to generate a new from scratch if that failed. https://bugzilla.gnome.org/show_bug.cgi?id=777732
2017-08-11 07:21:36 +00:00
static gboolean
meta_monitor_manager_is_config_complete (MetaMonitorManager *manager,
MetaMonitorsConfig *config)
{
monitor-manager: Compare keys when checking whether a config is complete 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
2017-11-03 08:03:23 +00:00
MetaMonitorsConfigKey *current_state_key;
gboolean is_config_complete;
monitor-manager: Try to restore previous config before regenerating When opening a laptop lid, one will likely want to restore the configuration one had prior to closing it, so when ensuring monitor configuration, first try to see if the previously set configuration is both complete (all connected monitors are configured) and applicable (it is a valid configuration) and only try to generate a new from scratch if that failed. https://bugzilla.gnome.org/show_bug.cgi?id=777732
2017-08-11 07:21:36 +00:00
monitor-manager: Compare keys when checking whether a config is complete 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
2017-11-03 08:03:23 +00:00
current_state_key =
meta_create_monitors_config_key_for_current_state (manager);
if (!current_state_key)
return FALSE;
monitor-manager: Try to restore previous config before regenerating When opening a laptop lid, one will likely want to restore the configuration one had prior to closing it, so when ensuring monitor configuration, first try to see if the previously set configuration is both complete (all connected monitors are configured) and applicable (it is a valid configuration) and only try to generate a new from scratch if that failed. https://bugzilla.gnome.org/show_bug.cgi?id=777732
2017-08-11 07:21:36 +00:00
monitor-manager: Compare keys when checking whether a config is complete 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
2017-11-03 08:03:23 +00:00
is_config_complete = meta_monitors_config_key_equal (current_state_key,
config->key);
meta_monitors_config_key_free (current_state_key);
monitor-manager: Try to restore previous config before regenerating When opening a laptop lid, one will likely want to restore the configuration one had prior to closing it, so when ensuring monitor configuration, first try to see if the previously set configuration is both complete (all connected monitors are configured) and applicable (it is a valid configuration) and only try to generate a new from scratch if that failed. https://bugzilla.gnome.org/show_bug.cgi?id=777732
2017-08-11 07:21:36 +00:00
monitor-manager: Compare keys when checking whether a config is complete 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
2017-11-03 08:03:23 +00:00
if (!is_config_complete)
monitor-manager: Try to restore previous config before regenerating When opening a laptop lid, one will likely want to restore the configuration one had prior to closing it, so when ensuring monitor configuration, first try to see if the previously set configuration is both complete (all connected monitors are configured) and applicable (it is a valid configuration) and only try to generate a new from scratch if that failed. https://bugzilla.gnome.org/show_bug.cgi?id=777732
2017-08-11 07:21:36 +00:00
return FALSE;
return meta_monitor_manager_is_config_applicable (manager, config, NULL);
}
DisplayConfig: Specify mode ID string instead of mode spec To be able to add more modes types that happen to have the same resolution and refresh rate, change the API to specify modes using an ID string. The ID string is temporary, and only works for associating a mode for the monitor instance that it was part of. https://bugzilla.gnome.org/show_bug.cgi?id=765011
2017-06-14 04:04:09 +00:00
static MetaMonitor *
find_monitor_from_connector (MetaMonitorManager *manager,
char *connector)
DisplayConfig: Add new API for configuring monitors Add a new D-Bus API that uses the state from GetCurrentState to configure high level monitors, instead of low level CRTCs and connectors. So far persistent configuration is not implemented, as writing to the configuration store is still not supported. https://bugzilla.gnome.org/show_bug.cgi?id=777732
2017-02-14 11:54:04 +00:00
{
GList *monitors;
GList *l;
DisplayConfig: Specify mode ID string instead of mode spec To be able to add more modes types that happen to have the same resolution and refresh rate, change the API to specify modes using an ID string. The ID string is temporary, and only works for associating a mode for the monitor instance that it was part of. https://bugzilla.gnome.org/show_bug.cgi?id=765011
2017-06-14 04:04:09 +00:00
if (!connector)
return NULL;
DisplayConfig: Add new API for configuring monitors Add a new D-Bus API that uses the state from GetCurrentState to configure high level monitors, instead of low level CRTCs and connectors. So far persistent configuration is not implemented, as writing to the configuration store is still not supported. https://bugzilla.gnome.org/show_bug.cgi?id=777732
2017-02-14 11:54:04 +00:00
monitors = meta_monitor_manager_get_monitors (manager);
for (l = monitors; l; l = l->next)
{
MetaMonitor *monitor = l->data;
MetaMonitorSpec *monitor_spec = meta_monitor_get_spec (monitor);
if (g_str_equal (connector, monitor_spec->connector))
DisplayConfig: Specify mode ID string instead of mode spec To be able to add more modes types that happen to have the same resolution and refresh rate, change the API to specify modes using an ID string. The ID string is temporary, and only works for associating a mode for the monitor instance that it was part of. https://bugzilla.gnome.org/show_bug.cgi?id=765011
2017-06-14 04:04:09 +00:00
return monitor;
DisplayConfig: Add new API for configuring monitors Add a new D-Bus API that uses the state from GetCurrentState to configure high level monitors, instead of low level CRTCs and connectors. So far persistent configuration is not implemented, as writing to the configuration store is still not supported. https://bugzilla.gnome.org/show_bug.cgi?id=777732
2017-02-14 11:54:04 +00:00
}
return NULL;
}
DisplayConfig: Specify mode ID string instead of mode spec To be able to add more modes types that happen to have the same resolution and refresh rate, change the API to specify modes using an ID string. The ID string is temporary, and only works for associating a mode for the monitor instance that it was part of. https://bugzilla.gnome.org/show_bug.cgi?id=765011
2017-06-14 04:04:09 +00:00
#define MONITOR_CONFIG_FORMAT "(ssa{sv})"
DisplayConfig: Add new API for configuring monitors Add a new D-Bus API that uses the state from GetCurrentState to configure high level monitors, instead of low level CRTCs and connectors. So far persistent configuration is not implemented, as writing to the configuration store is still not supported. https://bugzilla.gnome.org/show_bug.cgi?id=777732
2017-02-14 11:54:04 +00:00
#define MONITOR_CONFIGS_FORMAT "a" MONITOR_CONFIG_FORMAT
DisplayConfig: Add logical monitor transforms Add the transform as a logical monitor parameter, both when getting the current state and applying a new configuration. The transform is defined to be identical to MetaMonitorTransform. https://bugzilla.gnome.org/show_bug.cgi?id=777732
2017-03-21 06:29:32 +00:00
#define LOGICAL_MONITOR_CONFIG_FORMAT "(iidub" MONITOR_CONFIGS_FORMAT ")"
DisplayConfig: Add new API for configuring monitors Add a new D-Bus API that uses the state from GetCurrentState to configure high level monitors, instead of low level CRTCs and connectors. So far persistent configuration is not implemented, as writing to the configuration store is still not supported. https://bugzilla.gnome.org/show_bug.cgi?id=777732
2017-02-14 11:54:04 +00:00
static MetaMonitorConfig *
create_monitor_config_from_variant (MetaMonitorManager *manager,
GVariant *monitor_config_variant,
GError **error)
{
MetaMonitorConfig *monitor_config = NULL;
DisplayConfig: Specify mode ID string instead of mode spec To be able to add more modes types that happen to have the same resolution and refresh rate, change the API to specify modes using an ID string. The ID string is temporary, and only works for associating a mode for the monitor instance that it was part of. https://bugzilla.gnome.org/show_bug.cgi?id=765011
2017-06-14 04:04:09 +00:00
g_autofree char *connector = NULL;
g_autofree char *mode_id = NULL;
MetaMonitorMode *monitor_mode;
MetaMonitor *monitor;
DisplayConfig: Add new API for configuring monitors Add a new D-Bus API that uses the state from GetCurrentState to configure high level monitors, instead of low level CRTCs and connectors. So far persistent configuration is not implemented, as writing to the configuration store is still not supported. https://bugzilla.gnome.org/show_bug.cgi?id=777732
2017-02-14 11:54:04 +00:00
MetaMonitorSpec *monitor_spec;
MetaMonitorModeSpec *monitor_mode_spec;
DisplayConfig: Specify mode ID string instead of mode spec To be able to add more modes types that happen to have the same resolution and refresh rate, change the API to specify modes using an ID string. The ID string is temporary, and only works for associating a mode for the monitor instance that it was part of. https://bugzilla.gnome.org/show_bug.cgi?id=765011
2017-06-14 04:04:09 +00:00
g_autoptr (GVariant) properties_variant = NULL;
DisplayConfig: Add new API for configuring monitors Add a new D-Bus API that uses the state from GetCurrentState to configure high level monitors, instead of low level CRTCs and connectors. So far persistent configuration is not implemented, as writing to the configuration store is still not supported. https://bugzilla.gnome.org/show_bug.cgi?id=777732
2017-02-14 11:54:04 +00:00
gboolean enable_underscanning = FALSE;
DisplayConfig: Specify mode ID string instead of mode spec To be able to add more modes types that happen to have the same resolution and refresh rate, change the API to specify modes using an ID string. The ID string is temporary, and only works for associating a mode for the monitor instance that it was part of. https://bugzilla.gnome.org/show_bug.cgi?id=765011
2017-06-14 04:04:09 +00:00
g_variant_get (monitor_config_variant, "(ss@a{sv})",
DisplayConfig: Add new API for configuring monitors Add a new D-Bus API that uses the state from GetCurrentState to configure high level monitors, instead of low level CRTCs and connectors. So far persistent configuration is not implemented, as writing to the configuration store is still not supported. https://bugzilla.gnome.org/show_bug.cgi?id=777732
2017-02-14 11:54:04 +00:00
&connector,
DisplayConfig: Specify mode ID string instead of mode spec To be able to add more modes types that happen to have the same resolution and refresh rate, change the API to specify modes using an ID string. The ID string is temporary, and only works for associating a mode for the monitor instance that it was part of. https://bugzilla.gnome.org/show_bug.cgi?id=765011
2017-06-14 04:04:09 +00:00
&mode_id,
DisplayConfig: Add new API for configuring monitors Add a new D-Bus API that uses the state from GetCurrentState to configure high level monitors, instead of low level CRTCs and connectors. So far persistent configuration is not implemented, as writing to the configuration store is still not supported. https://bugzilla.gnome.org/show_bug.cgi?id=777732
2017-02-14 11:54:04 +00:00
&properties_variant);
DisplayConfig: Specify mode ID string instead of mode spec To be able to add more modes types that happen to have the same resolution and refresh rate, change the API to specify modes using an ID string. The ID string is temporary, and only works for associating a mode for the monitor instance that it was part of. https://bugzilla.gnome.org/show_bug.cgi?id=765011
2017-06-14 04:04:09 +00:00
monitor = find_monitor_from_connector (manager, connector);
if (!monitor)
DisplayConfig: Add new API for configuring monitors Add a new D-Bus API that uses the state from GetCurrentState to configure high level monitors, instead of low level CRTCs and connectors. So far persistent configuration is not implemented, as writing to the configuration store is still not supported. https://bugzilla.gnome.org/show_bug.cgi?id=777732
2017-02-14 11:54:04 +00:00
{
g_set_error (error, G_IO_ERROR, G_IO_ERROR_FAILED,
"Invalid connector '%s' specified", connector);
return NULL;
}
DisplayConfig: Specify mode ID string instead of mode spec To be able to add more modes types that happen to have the same resolution and refresh rate, change the API to specify modes using an ID string. The ID string is temporary, and only works for associating a mode for the monitor instance that it was part of. https://bugzilla.gnome.org/show_bug.cgi?id=765011
2017-06-14 04:04:09 +00:00
monitor_mode = meta_monitor_get_mode_from_id (monitor, mode_id);
if (!monitor_mode)
DisplayConfig: Add new API for configuring monitors Add a new D-Bus API that uses the state from GetCurrentState to configure high level monitors, instead of low level CRTCs and connectors. So far persistent configuration is not implemented, as writing to the configuration store is still not supported. https://bugzilla.gnome.org/show_bug.cgi?id=777732
2017-02-14 11:54:04 +00:00
{
DisplayConfig: Specify mode ID string instead of mode spec To be able to add more modes types that happen to have the same resolution and refresh rate, change the API to specify modes using an ID string. The ID string is temporary, and only works for associating a mode for the monitor instance that it was part of. https://bugzilla.gnome.org/show_bug.cgi?id=765011
2017-06-14 04:04:09 +00:00
g_set_error (error, G_IO_ERROR, G_IO_ERROR_FAILED,
"Invalid mode '%s' specified", mode_id);
DisplayConfig: Add new API for configuring monitors Add a new D-Bus API that uses the state from GetCurrentState to configure high level monitors, instead of low level CRTCs and connectors. So far persistent configuration is not implemented, as writing to the configuration store is still not supported. https://bugzilla.gnome.org/show_bug.cgi?id=777732
2017-02-14 11:54:04 +00:00
return NULL;
}
g_variant_lookup (properties_variant, "underscanning", "b", &enable_underscanning);
DisplayConfig: Specify mode ID string instead of mode spec To be able to add more modes types that happen to have the same resolution and refresh rate, change the API to specify modes using an ID string. The ID string is temporary, and only works for associating a mode for the monitor instance that it was part of. https://bugzilla.gnome.org/show_bug.cgi?id=765011
2017-06-14 04:04:09 +00:00
monitor_spec = meta_monitor_spec_clone (meta_monitor_get_spec (monitor));
monitor_mode_spec = g_new0 (MetaMonitorModeSpec, 1);
*monitor_mode_spec = *meta_monitor_mode_get_spec (monitor_mode);
DisplayConfig: Add new API for configuring monitors Add a new D-Bus API that uses the state from GetCurrentState to configure high level monitors, instead of low level CRTCs and connectors. So far persistent configuration is not implemented, as writing to the configuration store is still not supported. https://bugzilla.gnome.org/show_bug.cgi?id=777732
2017-02-14 11:54:04 +00:00
monitor_config = g_new0 (MetaMonitorConfig, 1);
*monitor_config = (MetaMonitorConfig) {
.monitor_spec = monitor_spec,
.mode_spec = monitor_mode_spec,
.enable_underscanning = enable_underscanning
};
return monitor_config;
}
static gboolean
monitor-manager: Find the supported scales from one passed When passing scales over D-Bus, we'll loose some precision. To set the correct scale, use the configured scale and look up the one actually supported by the monitor mode, and use that. To match the supported one with the configured one, the difference must be within rounding error range. https://bugzilla.gnome.org/show_bug.cgi?id=765011
2017-06-07 09:39:58 +00:00
find_monitor_mode_scale (MetaMonitorManager *manager,
MetaLogicalMonitorLayoutMode layout_mode,
MetaMonitorConfig *monitor_config,
float scale,
float *out_scale,
GError **error)
DisplayConfig: Add new API for configuring monitors Add a new D-Bus API that uses the state from GetCurrentState to configure high level monitors, instead of low level CRTCs and connectors. So far persistent configuration is not implemented, as writing to the configuration store is still not supported. https://bugzilla.gnome.org/show_bug.cgi?id=777732
2017-02-14 11:54:04 +00:00
{
monitor-manager: Find the supported scales from one passed When passing scales over D-Bus, we'll loose some precision. To set the correct scale, use the configured scale and look up the one actually supported by the monitor mode, and use that. To match the supported one with the configured one, the difference must be within rounding error range. https://bugzilla.gnome.org/show_bug.cgi?id=765011
2017-06-07 09:39:58 +00:00
MetaMonitorSpec *monitor_spec;
MetaMonitor *monitor;
MetaMonitorModeSpec *monitor_mode_spec;
MetaMonitorMode *monitor_mode;
g_autofree float *supported_scales = NULL;
int n_supported_scales;
int i;
DisplayConfig: Add new API for configuring monitors Add a new D-Bus API that uses the state from GetCurrentState to configure high level monitors, instead of low level CRTCs and connectors. So far persistent configuration is not implemented, as writing to the configuration store is still not supported. https://bugzilla.gnome.org/show_bug.cgi?id=777732
2017-02-14 11:54:04 +00:00
monitor-manager: Find the supported scales from one passed When passing scales over D-Bus, we'll loose some precision. To set the correct scale, use the configured scale and look up the one actually supported by the monitor mode, and use that. To match the supported one with the configured one, the difference must be within rounding error range. https://bugzilla.gnome.org/show_bug.cgi?id=765011
2017-06-07 09:39:58 +00:00
monitor_spec = monitor_config->monitor_spec;
monitor = meta_monitor_manager_get_monitor_from_spec (manager,
monitor_spec);
if (!monitor)
DisplayConfig: Add new API for configuring monitors Add a new D-Bus API that uses the state from GetCurrentState to configure high level monitors, instead of low level CRTCs and connectors. So far persistent configuration is not implemented, as writing to the configuration store is still not supported. https://bugzilla.gnome.org/show_bug.cgi?id=777732
2017-02-14 11:54:04 +00:00
{
g_set_error (error, G_IO_ERROR, G_IO_ERROR_FAILED,
monitor-manager: Find the supported scales from one passed When passing scales over D-Bus, we'll loose some precision. To set the correct scale, use the configured scale and look up the one actually supported by the monitor mode, and use that. To match the supported one with the configured one, the difference must be within rounding error range. https://bugzilla.gnome.org/show_bug.cgi?id=765011
2017-06-07 09:39:58 +00:00
"Monitor not found");
DisplayConfig: Add new API for configuring monitors Add a new D-Bus API that uses the state from GetCurrentState to configure high level monitors, instead of low level CRTCs and connectors. So far persistent configuration is not implemented, as writing to the configuration store is still not supported. https://bugzilla.gnome.org/show_bug.cgi?id=777732
2017-02-14 11:54:04 +00:00
return FALSE;
}
monitor-manager: Find the supported scales from one passed When passing scales over D-Bus, we'll loose some precision. To set the correct scale, use the configured scale and look up the one actually supported by the monitor mode, and use that. To match the supported one with the configured one, the difference must be within rounding error range. https://bugzilla.gnome.org/show_bug.cgi?id=765011
2017-06-07 09:39:58 +00:00
monitor_mode_spec = monitor_config->mode_spec;
monitor_mode = meta_monitor_get_mode_from_spec (monitor,
monitor_mode_spec);
if (!monitor_mode)
{
g_set_error (error, G_IO_ERROR, G_IO_ERROR_FAILED,
"Monitor mode not found");
return FALSE;
}
supported_scales =
meta_monitor_manager_calculate_supported_scales (manager, layout_mode,
monitor, monitor_mode,
&n_supported_scales);
for (i = 0; i < n_supported_scales; i++)
{
float supported_scale = supported_scales[i];
if (fabsf (supported_scale - scale) < FLT_EPSILON)
{
*out_scale = supported_scale;
return TRUE;
}
}
g_set_error (error, G_IO_ERROR, G_IO_ERROR_FAILED,
"Scale %g not valid for resolution %dx%d",
scale,
monitor_mode_spec->width,
monitor_mode_spec->height);
return FALSE;
}
static gboolean
derive_logical_monitor_size (MetaMonitorConfig *monitor_config,
int *out_width,
int *out_height,
float scale,
MetaMonitorTransform transform,
MetaLogicalMonitorLayoutMode layout_mode,
GError **error)
{
int width, height;
DisplayConfig: Add new API for configuring monitors Add a new D-Bus API that uses the state from GetCurrentState to configure high level monitors, instead of low level CRTCs and connectors. So far persistent configuration is not implemented, as writing to the configuration store is still not supported. https://bugzilla.gnome.org/show_bug.cgi?id=777732
2017-02-14 11:54:04 +00:00
DisplayConfig: Add logical monitor transforms Add the transform as a logical monitor parameter, both when getting the current state and applying a new configuration. The transform is defined to be identical to MetaMonitorTransform. https://bugzilla.gnome.org/show_bug.cgi?id=777732
2017-03-21 06:29:32 +00:00
if (meta_monitor_transform_is_rotated (transform))
{
width = monitor_config->mode_spec->height;
height = monitor_config->mode_spec->width;
}
else
{
width = monitor_config->mode_spec->width;
height = monitor_config->mode_spec->height;
}
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 10:10:52 +00:00
switch (layout_mode)
{
case META_LOGICAL_MONITOR_LAYOUT_MODE_LOGICAL:
monitor-config: Handle fractional scale precision loss When calculating sizes given some size and a fractional logical monitor scale with precision loss, round the result of the floating point calculation to the closest integer, as otherwise we might end up with result smaller by 1 if there was a loss of precision when calculating the scale. https://bugzilla.gnome.org/show_bug.cgi?id=765011
2017-06-09 07:51:14 +00:00
width = roundf (width / scale);
height = roundf (height / scale);
DisplayConfig: Add logical monitor transforms Add the transform as a logical monitor parameter, both when getting the current state and applying a new configuration. The transform is defined to be identical to MetaMonitorTransform. https://bugzilla.gnome.org/show_bug.cgi?id=777732
2017-03-21 06:29:32 +00:00
break;
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 10:10:52 +00:00
case META_LOGICAL_MONITOR_LAYOUT_MODE_PHYSICAL:
DisplayConfig: Add logical monitor transforms Add the transform as a logical monitor parameter, both when getting the current state and applying a new configuration. The transform is defined to be identical to MetaMonitorTransform. https://bugzilla.gnome.org/show_bug.cgi?id=777732
2017-03-21 06:29:32 +00:00
break;
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 10:10:52 +00:00
}
DisplayConfig: Add logical monitor transforms Add the transform as a logical monitor parameter, both when getting the current state and applying a new configuration. The transform is defined to be identical to MetaMonitorTransform. https://bugzilla.gnome.org/show_bug.cgi?id=777732
2017-03-21 06:29:32 +00:00
*out_width = width;
*out_height = height;
return TRUE;
DisplayConfig: Add new API for configuring monitors Add a new D-Bus API that uses the state from GetCurrentState to configure high level monitors, instead of low level CRTCs and connectors. So far persistent configuration is not implemented, as writing to the configuration store is still not supported. https://bugzilla.gnome.org/show_bug.cgi?id=777732
2017-02-14 11:54:04 +00:00
}
static MetaLogicalMonitorConfig *
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 10:10:52 +00:00
create_logical_monitor_config_from_variant (MetaMonitorManager *manager,
GVariant *logical_monitor_config_variant,
MetaLogicalMonitorLayoutMode layout_mode,
GError **error)
DisplayConfig: Add new API for configuring monitors Add a new D-Bus API that uses the state from GetCurrentState to configure high level monitors, instead of low level CRTCs and connectors. So far persistent configuration is not implemented, as writing to the configuration store is still not supported. https://bugzilla.gnome.org/show_bug.cgi?id=777732
2017-02-14 11:54:04 +00:00
{
MetaLogicalMonitorConfig *logical_monitor_config;
int x, y, width, height;
monitor-manager: Find the supported scales from one passed When passing scales over D-Bus, we'll loose some precision. To set the correct scale, use the configured scale and look up the one actually supported by the monitor mode, and use that. To match the supported one with the configured one, the difference must be within rounding error range. https://bugzilla.gnome.org/show_bug.cgi?id=765011
2017-06-07 09:39:58 +00:00
double scale_d;
float scale;
DisplayConfig: Add logical monitor transforms Add the transform as a logical monitor parameter, both when getting the current state and applying a new configuration. The transform is defined to be identical to MetaMonitorTransform. https://bugzilla.gnome.org/show_bug.cgi?id=777732
2017-03-21 06:29:32 +00:00
MetaMonitorTransform transform;
DisplayConfig: Add new API for configuring monitors Add a new D-Bus API that uses the state from GetCurrentState to configure high level monitors, instead of low level CRTCs and connectors. So far persistent configuration is not implemented, as writing to the configuration store is still not supported. https://bugzilla.gnome.org/show_bug.cgi?id=777732
2017-02-14 11:54:04 +00:00
gboolean is_primary;
GVariantIter *monitor_configs_iter;
GList *monitor_configs = NULL;
monitor-manager: Find the supported scales from one passed When passing scales over D-Bus, we'll loose some precision. To set the correct scale, use the configured scale and look up the one actually supported by the monitor mode, and use that. To match the supported one with the configured one, the difference must be within rounding error range. https://bugzilla.gnome.org/show_bug.cgi?id=765011
2017-06-07 09:39:58 +00:00
MetaMonitorConfig *monitor_config;
DisplayConfig: Add new API for configuring monitors Add a new D-Bus API that uses the state from GetCurrentState to configure high level monitors, instead of low level CRTCs and connectors. So far persistent configuration is not implemented, as writing to the configuration store is still not supported. https://bugzilla.gnome.org/show_bug.cgi?id=777732
2017-02-14 11:54:04 +00:00
g_variant_get (logical_monitor_config_variant, LOGICAL_MONITOR_CONFIG_FORMAT,
&x,
&y,
monitor-manager: Find the supported scales from one passed When passing scales over D-Bus, we'll loose some precision. To set the correct scale, use the configured scale and look up the one actually supported by the monitor mode, and use that. To match the supported one with the configured one, the difference must be within rounding error range. https://bugzilla.gnome.org/show_bug.cgi?id=765011
2017-06-07 09:39:58 +00:00
&scale_d,
DisplayConfig: Add logical monitor transforms Add the transform as a logical monitor parameter, both when getting the current state and applying a new configuration. The transform is defined to be identical to MetaMonitorTransform. https://bugzilla.gnome.org/show_bug.cgi?id=777732
2017-03-21 06:29:32 +00:00
&transform,
DisplayConfig: Add new API for configuring monitors Add a new D-Bus API that uses the state from GetCurrentState to configure high level monitors, instead of low level CRTCs and connectors. So far persistent configuration is not implemented, as writing to the configuration store is still not supported. https://bugzilla.gnome.org/show_bug.cgi?id=777732
2017-02-14 11:54:04 +00:00
&is_primary,
&monitor_configs_iter);
monitor-manager: Find the supported scales from one passed When passing scales over D-Bus, we'll loose some precision. To set the correct scale, use the configured scale and look up the one actually supported by the monitor mode, and use that. To match the supported one with the configured one, the difference must be within rounding error range. https://bugzilla.gnome.org/show_bug.cgi?id=765011
2017-06-07 09:39:58 +00:00
scale = (float) scale_d;
DisplayConfig: Add new API for configuring monitors Add a new D-Bus API that uses the state from GetCurrentState to configure high level monitors, instead of low level CRTCs and connectors. So far persistent configuration is not implemented, as writing to the configuration store is still not supported. https://bugzilla.gnome.org/show_bug.cgi?id=777732
2017-02-14 11:54:04 +00:00
while (TRUE)
{
GVariant *monitor_config_variant =
g_variant_iter_next_value (monitor_configs_iter);
MetaMonitorConfig *monitor_config;
if (!monitor_config_variant)
break;
monitor_config =
create_monitor_config_from_variant (manager,
monitor_config_variant, error);
backends: Unref variants obtained from g_variant_iter_get_next_value() Those are being leaked. https://bugzilla.gnome.org/show_bug.cgi?id=789553
2017-10-27 10:27:00 +00:00
g_variant_unref (monitor_config_variant);
DisplayConfig: Add new API for configuring monitors Add a new D-Bus API that uses the state from GetCurrentState to configure high level monitors, instead of low level CRTCs and connectors. So far persistent configuration is not implemented, as writing to the configuration store is still not supported. https://bugzilla.gnome.org/show_bug.cgi?id=777732
2017-02-14 11:54:04 +00:00
if (!monitor_config)
goto err;
if (!meta_verify_monitor_config (monitor_config, error))
{
meta_monitor_config_free (monitor_config);
goto err;
}
monitor_configs = g_list_append (monitor_configs, monitor_config);
}
g_variant_iter_free (monitor_configs_iter);
monitor-manager: Find the supported scales from one passed When passing scales over D-Bus, we'll loose some precision. To set the correct scale, use the configured scale and look up the one actually supported by the monitor mode, and use that. To match the supported one with the configured one, the difference must be within rounding error range. https://bugzilla.gnome.org/show_bug.cgi?id=765011
2017-06-07 09:39:58 +00:00
if (!monitor_configs)
{
g_set_error (error, G_IO_ERROR, G_IO_ERROR_FAILED,
"Empty logical monitor");
goto err;
}
monitor_config = monitor_configs->data;
if (!find_monitor_mode_scale (manager,
layout_mode,
monitor_config,
scale,
&scale,
error))
goto err;
if (!derive_logical_monitor_size (monitor_config, &width, &height,
DisplayConfig: Add logical monitor transforms Add the transform as a logical monitor parameter, both when getting the current state and applying a new configuration. The transform is defined to be identical to MetaMonitorTransform. https://bugzilla.gnome.org/show_bug.cgi?id=777732
2017-03-21 06:29:32 +00:00
scale, transform, layout_mode, error))
DisplayConfig: Add new API for configuring monitors Add a new D-Bus API that uses the state from GetCurrentState to configure high level monitors, instead of low level CRTCs and connectors. So far persistent configuration is not implemented, as writing to the configuration store is still not supported. https://bugzilla.gnome.org/show_bug.cgi?id=777732
2017-02-14 11:54:04 +00:00
goto err;
logical_monitor_config = g_new0 (MetaLogicalMonitorConfig, 1);
*logical_monitor_config = (MetaLogicalMonitorConfig) {
.layout = {
.x = x,
.y = y,
.width = width,
.height = height
},
DisplayConfig: Add logical monitor transforms Add the transform as a logical monitor parameter, both when getting the current state and applying a new configuration. The transform is defined to be identical to MetaMonitorTransform. https://bugzilla.gnome.org/show_bug.cgi?id=777732
2017-03-21 06:29:32 +00:00
.transform = 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 08:12:51 +00:00
.scale = scale,
DisplayConfig: Add new API for configuring monitors Add a new D-Bus API that uses the state from GetCurrentState to configure high level monitors, instead of low level CRTCs and connectors. So far persistent configuration is not implemented, as writing to the configuration store is still not supported. https://bugzilla.gnome.org/show_bug.cgi?id=777732
2017-02-14 11:54:04 +00:00
.is_primary = is_primary,
.monitor_configs = 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 10:10:52 +00:00
if (!meta_verify_logical_monitor_config (logical_monitor_config,
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 09:20:59 +00:00
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 10:10:52 +00:00
error))
DisplayConfig: Add new API for configuring monitors Add a new D-Bus API that uses the state from GetCurrentState to configure high level monitors, instead of low level CRTCs and connectors. So far persistent configuration is not implemented, as writing to the configuration store is still not supported. https://bugzilla.gnome.org/show_bug.cgi?id=777732
2017-02-14 11:54:04 +00:00
{
meta_logical_monitor_config_free (logical_monitor_config);
return NULL;
}
return logical_monitor_config;
err:
g_list_free_full (monitor_configs, (GDestroyNotify) meta_monitor_config_free);
return NULL;
}
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 10:10:52 +00:00
static gboolean
is_valid_layout_mode (MetaLogicalMonitorLayoutMode layout_mode)
{
switch (layout_mode)
{
case META_LOGICAL_MONITOR_LAYOUT_MODE_LOGICAL:
case META_LOGICAL_MONITOR_LAYOUT_MODE_PHYSICAL:
return TRUE;
}
return FALSE;
}
DisplayConfig: Add new API for configuring monitors Add a new D-Bus API that uses the state from GetCurrentState to configure high level monitors, instead of low level CRTCs and connectors. So far persistent configuration is not implemented, as writing to the configuration store is still not supported. https://bugzilla.gnome.org/show_bug.cgi?id=777732
2017-02-14 11:54:04 +00:00
static gboolean
meta_monitor_manager_handle_apply_monitors_config (MetaDBusDisplayConfig *skeleton,
GDBusMethodInvocation *invocation,
guint serial,
guint method,
GVariant *logical_monitor_configs_variant,
GVariant *properties_variant)
{
MetaMonitorManager *manager = META_MONITOR_MANAGER (skeleton);
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 10:10:52 +00:00
MetaMonitorManagerCapability capabilities;
GVariant *layout_mode_variant = NULL;
MetaLogicalMonitorLayoutMode layout_mode;
DisplayConfig: Add new API for configuring monitors Add a new D-Bus API that uses the state from GetCurrentState to configure high level monitors, instead of low level CRTCs and connectors. So far persistent configuration is not implemented, as writing to the configuration store is still not supported. https://bugzilla.gnome.org/show_bug.cgi?id=777732
2017-02-14 11:54:04 +00:00
GVariantIter logical_monitor_configs_iter;
MetaMonitorsConfig *config;
GList *logical_monitor_configs = NULL;
GError *error = NULL;
if (serial != manager->serial)
{
g_dbus_method_invocation_return_error (invocation, G_DBUS_ERROR,
G_DBUS_ERROR_ACCESS_DENIED,
"The requested configuration is based on stale information");
return TRUE;
}
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 10:10:52 +00:00
capabilities = meta_monitor_manager_get_capabilities (manager);
if (properties_variant)
layout_mode_variant = g_variant_lookup_value (properties_variant,
"layout-mode",
G_VARIANT_TYPE ("u"));
if (layout_mode_variant &&
capabilities & META_MONITOR_MANAGER_CAPABILITY_LAYOUT_MODE)
{
g_variant_get (layout_mode_variant, "u", &layout_mode);
}
else if (!layout_mode_variant)
{
layout_mode =
meta_monitor_manager_get_default_layout_mode (manager);
}
else
{
g_dbus_method_invocation_return_error (invocation, G_DBUS_ERROR,
G_DBUS_ERROR_INVALID_ARGS,
"Can't set layout mode");
return TRUE;
}
if (!is_valid_layout_mode (layout_mode))
{
g_dbus_method_invocation_return_error (invocation, G_DBUS_ERROR,
G_DBUS_ERROR_ACCESS_DENIED,
"Invalid layout mode specified");
return TRUE;
}
DisplayConfig: Add new API for configuring monitors Add a new D-Bus API that uses the state from GetCurrentState to configure high level monitors, instead of low level CRTCs and connectors. So far persistent configuration is not implemented, as writing to the configuration store is still not supported. https://bugzilla.gnome.org/show_bug.cgi?id=777732
2017-02-14 11:54:04 +00:00
g_variant_iter_init (&logical_monitor_configs_iter,
logical_monitor_configs_variant);
while (TRUE)
{
GVariant *logical_monitor_config_variant =
g_variant_iter_next_value (&logical_monitor_configs_iter);
MetaLogicalMonitorConfig *logical_monitor_config;
if (!logical_monitor_config_variant)
break;
logical_monitor_config =
create_logical_monitor_config_from_variant (manager,
logical_monitor_config_variant,
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 10:10:52 +00:00
layout_mode,
DisplayConfig: Add new API for configuring monitors Add a new D-Bus API that uses the state from GetCurrentState to configure high level monitors, instead of low level CRTCs and connectors. So far persistent configuration is not implemented, as writing to the configuration store is still not supported. https://bugzilla.gnome.org/show_bug.cgi?id=777732
2017-02-14 11:54:04 +00:00
&error);
backends: Unref variants obtained from g_variant_iter_get_next_value() Those are being leaked. https://bugzilla.gnome.org/show_bug.cgi?id=789553
2017-10-27 10:27:00 +00:00
g_variant_unref (logical_monitor_config_variant);
DisplayConfig: Add new API for configuring monitors Add a new D-Bus API that uses the state from GetCurrentState to configure high level monitors, instead of low level CRTCs and connectors. So far persistent configuration is not implemented, as writing to the configuration store is still not supported. https://bugzilla.gnome.org/show_bug.cgi?id=777732
2017-02-14 11:54:04 +00:00
if (!logical_monitor_config)
{
g_dbus_method_invocation_return_error (invocation, G_DBUS_ERROR,
G_DBUS_ERROR_INVALID_ARGS,
monitor-manager: Fix format-security gcc warnings
2017-04-12 14:26:21 +00:00
"%s", error->message);
DisplayConfig: Add new API for configuring monitors Add a new D-Bus API that uses the state from GetCurrentState to configure high level monitors, instead of low level CRTCs and connectors. So far persistent configuration is not implemented, as writing to the configuration store is still not supported. https://bugzilla.gnome.org/show_bug.cgi?id=777732
2017-02-14 11:54:04 +00:00
g_error_free (error);
g_list_free_full (logical_monitor_configs,
(GDestroyNotify) meta_logical_monitor_config_free);
return TRUE;
}
logical_monitor_configs = g_list_append (logical_monitor_configs,
logical_monitor_config);
}
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-09-28 15:34:33 +00:00
config = meta_monitors_config_new (manager,
logical_monitor_configs,
layout_mode,
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 07:12:41 +00:00
META_MONITORS_CONFIG_FLAG_NONE);
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 10:01:15 +00:00
if (!meta_verify_monitors_config (config, manager, &error))
DisplayConfig: Add new API for configuring monitors Add a new D-Bus API that uses the state from GetCurrentState to configure high level monitors, instead of low level CRTCs and connectors. So far persistent configuration is not implemented, as writing to the configuration store is still not supported. https://bugzilla.gnome.org/show_bug.cgi?id=777732
2017-02-14 11:54:04 +00:00
{
g_dbus_method_invocation_return_error (invocation, G_DBUS_ERROR,
G_DBUS_ERROR_INVALID_ARGS,
monitor-manager: Fix format-security gcc warnings
2017-04-12 14:26:21 +00:00
"%s", error->message);
DisplayConfig: Add new API for configuring monitors Add a new D-Bus API that uses the state from GetCurrentState to configure high level monitors, instead of low level CRTCs and connectors. So far persistent configuration is not implemented, as writing to the configuration store is still not supported. https://bugzilla.gnome.org/show_bug.cgi?id=777732
2017-02-14 11:54:04 +00:00
g_error_free (error);
g_object_unref (config);
return TRUE;
}
if (!meta_monitor_manager_is_config_applicable (manager, config, &error))
{
g_dbus_method_invocation_return_error (invocation, G_DBUS_ERROR,
G_DBUS_ERROR_INVALID_ARGS,
monitor-manager: Fix format-security gcc warnings
2017-04-12 14:26:21 +00:00
"%s", error->message);
DisplayConfig: Add new API for configuring monitors Add a new D-Bus API that uses the state from GetCurrentState to configure high level monitors, instead of low level CRTCs and connectors. So far persistent configuration is not implemented, as writing to the configuration store is still not supported. https://bugzilla.gnome.org/show_bug.cgi?id=777732
2017-02-14 11:54:04 +00:00
g_error_free (error);
g_object_unref (config);
return TRUE;
}
monitor-manager: Don't cancel confirm dialog on verifying When another D-Bus call that just tries to verify a configuration is made, don't cancel any active monitor configuration dialog, as doing so would effectively confirm queried configuration. https://bugzilla.gnome.org/show_bug.cgi?id=786023
2017-08-11 06:59:44 +00:00
if (manager->persistent_timeout_id &&
method != META_MONITORS_CONFIG_METHOD_VERIFY)
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 09:20:07 +00:00
cancel_persistent_confirmation (manager);
DisplayConfig: Add new API for configuring monitors Add a new D-Bus API that uses the state from GetCurrentState to configure high level monitors, instead of low level CRTCs and connectors. So far persistent configuration is not implemented, as writing to the configuration store is still not supported. https://bugzilla.gnome.org/show_bug.cgi?id=777732
2017-02-14 11:54:04 +00:00
if (!meta_monitor_manager_apply_monitors_config (manager,
config,
method,
&error))
{
g_dbus_method_invocation_return_error (invocation, G_DBUS_ERROR,
G_DBUS_ERROR_INVALID_ARGS,
monitor-manager: Fix format-security gcc warnings
2017-04-12 14:26:21 +00:00
"%s", error->message);
DisplayConfig: Add new API for configuring monitors Add a new D-Bus API that uses the state from GetCurrentState to configure high level monitors, instead of low level CRTCs and connectors. So far persistent configuration is not implemented, as writing to the configuration store is still not supported. https://bugzilla.gnome.org/show_bug.cgi?id=777732
2017-02-14 11:54:04 +00:00
g_error_free (error);
g_object_unref (config);
return TRUE;
}
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 09:20:07 +00:00
if (method == META_MONITORS_CONFIG_METHOD_PERSISTENT)
Remove old monitor configuration system Remove the old MetaMonitorConfig system and mark the new one as non-experimental. This also removes the D-Bus property. https://bugzilla.gnome.org/show_bug.cgi?id=777732
2017-03-24 07:36:12 +00:00
request_persistent_confirmation (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 09:20:07 +00:00
DisplayConfig: Add new API for configuring monitors Add a new D-Bus API that uses the state from GetCurrentState to configure high level monitors, instead of low level CRTCs and connectors. So far persistent configuration is not implemented, as writing to the configuration store is still not supported. https://bugzilla.gnome.org/show_bug.cgi?id=777732
2017-02-14 11:54:04 +00:00
meta_dbus_display_config_complete_apply_monitors_config (skeleton, invocation);
return TRUE;
}
#undef MONITOR_MODE_SPEC_FORMAT
#undef MONITOR_CONFIG_FORMAT
#undef MONITOR_CONFIGS_FORMAT
#undef LOGICAL_MONITOR_CONFIG_FORMAT
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 09:20:07 +00:00
static void
confirm_configuration (MetaMonitorManager *manager,
gboolean confirmed)
{
if (confirmed)
meta_monitor_config_manager_save_current (manager->config_manager);
else
restore_previous_config (manager);
}
MetaPlugin: add a UI hook for confirming display changes We want to show a dialog when a display change happens from the control center. To do so, add a new vfunc to MetaPlugin and call it when a configuration change is requested via DBus. https://bugzilla.gnome.org/show_bug.cgi?id=705670
2013-07-29 08:12:24 +00:00
void
meta_monitor_manager_confirm_configuration (MetaMonitorManager *manager,
gboolean ok)
{
if (!manager->persistent_timeout_id)
{
/* too late */
return;
}
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 09:20:07 +00:00
cancel_persistent_confirmation (manager);
Remove old monitor configuration system Remove the old MetaMonitorConfig system and mark the new one as non-experimental. This also removes the D-Bus property. https://bugzilla.gnome.org/show_bug.cgi?id=777732
2017-03-24 07:36:12 +00:00
confirm_configuration (manager, ok);
MetaPlugin: add a UI hook for confirming display changes We want to show a dialog when a display change happens from the control center. To do so, add a new vfunc to MetaPlugin and call it when a configuration change is requested via DBus. https://bugzilla.gnome.org/show_bug.cgi?id=705670
2013-07-29 08:12:24 +00:00
}
MonitorManager: add support for backlight GnomeRR needs that too. The backlight is exported as a normalized 0-100 value, or -1 if not supported. Clamping to HW limits is handled by the backend. Changing backlight uses a different method call, to avoid recomputing the full display configuration every time the user presses the backlight keys. https://bugzilla.gnome.org/show_bug.cgi?id=705670
2013-07-25 13:06:09 +00:00
static gboolean
meta_monitor_manager_handle_change_backlight (MetaDBusDisplayConfig *skeleton,
GDBusMethodInvocation *invocation,
guint serial,
monitor-manager: Rename output_id to output_index The term "output_id" is already used as an opaque ID.
2014-07-01 17:00:36 +00:00
guint output_index,
MonitorManager: add support for backlight GnomeRR needs that too. The backlight is exported as a normalized 0-100 value, or -1 if not supported. Clamping to HW limits is handled by the backend. Changing backlight uses a different method call, to avoid recomputing the full display configuration every time the user presses the backlight keys. https://bugzilla.gnome.org/show_bug.cgi?id=705670
2013-07-25 13:06:09 +00:00
gint value)
{
MetaMonitorManager *manager = META_MONITOR_MANAGER (skeleton);
backends: Split out CRTC/output management to MetaGpu In order to eventually support multilpe GPUs with their own connectors, split out related meta data management (i.e. outputs, CRTCs and CRTC modes) into a new MetaGpu GObject. The Xrandr backend always assumes there is always only a single "GPU" as the GPU is abstracted by the X server; only the native backend (aside from the test backend) will eventually see more than one GPU. The Xrandr backend still moves some management to MetaGpuXrandr, in order to behave more similarly to the KMS counterparts. https://bugzilla.gnome.org/show_bug.cgi?id=785381
2017-07-10 10:19:32 +00:00
GList *combined_outputs;
MonitorManager: add support for backlight GnomeRR needs that too. The backlight is exported as a normalized 0-100 value, or -1 if not supported. Clamping to HW limits is handled by the backend. Changing backlight uses a different method call, to avoid recomputing the full display configuration every time the user presses the backlight keys. https://bugzilla.gnome.org/show_bug.cgi?id=705670
2013-07-25 13:06:09 +00:00
MetaOutput *output;
if (serial != manager->serial)
{
g_dbus_method_invocation_return_error (invocation, G_DBUS_ERROR,
G_DBUS_ERROR_ACCESS_DENIED,
"The requested configuration is based on stale information");
return TRUE;
}
backends: Split out CRTC/output management to MetaGpu In order to eventually support multilpe GPUs with their own connectors, split out related meta data management (i.e. outputs, CRTCs and CRTC modes) into a new MetaGpu GObject. The Xrandr backend always assumes there is always only a single "GPU" as the GPU is abstracted by the X server; only the native backend (aside from the test backend) will eventually see more than one GPU. The Xrandr backend still moves some management to MetaGpuXrandr, in order to behave more similarly to the KMS counterparts. https://bugzilla.gnome.org/show_bug.cgi?id=785381
2017-07-10 10:19:32 +00:00
combined_outputs = combine_gpu_lists (manager, meta_gpu_get_outputs);
if (output_index >= g_list_length (combined_outputs))
MonitorManager: add support for backlight GnomeRR needs that too. The backlight is exported as a normalized 0-100 value, or -1 if not supported. Clamping to HW limits is handled by the backend. Changing backlight uses a different method call, to avoid recomputing the full display configuration every time the user presses the backlight keys. https://bugzilla.gnome.org/show_bug.cgi?id=705670
2013-07-25 13:06:09 +00:00
{
backends: Split out CRTC/output management to MetaGpu In order to eventually support multilpe GPUs with their own connectors, split out related meta data management (i.e. outputs, CRTCs and CRTC modes) into a new MetaGpu GObject. The Xrandr backend always assumes there is always only a single "GPU" as the GPU is abstracted by the X server; only the native backend (aside from the test backend) will eventually see more than one GPU. The Xrandr backend still moves some management to MetaGpuXrandr, in order to behave more similarly to the KMS counterparts. https://bugzilla.gnome.org/show_bug.cgi?id=785381
2017-07-10 10:19:32 +00:00
g_list_free (combined_outputs);
MonitorManager: add support for backlight GnomeRR needs that too. The backlight is exported as a normalized 0-100 value, or -1 if not supported. Clamping to HW limits is handled by the backend. Changing backlight uses a different method call, to avoid recomputing the full display configuration every time the user presses the backlight keys. https://bugzilla.gnome.org/show_bug.cgi?id=705670
2013-07-25 13:06:09 +00:00
g_dbus_method_invocation_return_error (invocation, G_DBUS_ERROR,
G_DBUS_ERROR_INVALID_ARGS,
"Invalid output id");
return TRUE;
}
backends: Split out CRTC/output management to MetaGpu In order to eventually support multilpe GPUs with their own connectors, split out related meta data management (i.e. outputs, CRTCs and CRTC modes) into a new MetaGpu GObject. The Xrandr backend always assumes there is always only a single "GPU" as the GPU is abstracted by the X server; only the native backend (aside from the test backend) will eventually see more than one GPU. The Xrandr backend still moves some management to MetaGpuXrandr, in order to behave more similarly to the KMS counterparts. https://bugzilla.gnome.org/show_bug.cgi?id=785381
2017-07-10 10:19:32 +00:00
output = g_list_nth_data (combined_outputs, output_index);
g_list_free (combined_outputs);
MonitorManager: add support for backlight GnomeRR needs that too. The backlight is exported as a normalized 0-100 value, or -1 if not supported. Clamping to HW limits is handled by the backend. Changing backlight uses a different method call, to avoid recomputing the full display configuration every time the user presses the backlight keys. https://bugzilla.gnome.org/show_bug.cgi?id=705670
2013-07-25 13:06:09 +00:00
if (value < 0 || value > 100)
{
g_dbus_method_invocation_return_error (invocation, G_DBUS_ERROR,
G_DBUS_ERROR_INVALID_ARGS,
"Invalid backlight value");
return TRUE;
}
if (output->backlight == -1 ||
(output->backlight_min == 0 && output->backlight_max == 0))
{
g_dbus_method_invocation_return_error (invocation, G_DBUS_ERROR,
G_DBUS_ERROR_INVALID_ARGS,
"Output does not support changing backlight");
return TRUE;
}
MonitorManager: split the XRandR parts in a subclass Instead of keeping a forest of if backend else ..., use a subclass and virtual functions to discriminate between XRandR and the dummy backend (which lives in the parent class togheter with the common code) https://bugzilla.gnome.org/show_bug.cgi?id=705670
2013-07-29 11:00:15 +00:00
META_MONITOR_MANAGER_GET_CLASS (manager)->change_backlight (manager, output, value);
MonitorManager: add support for backlight GnomeRR needs that too. The backlight is exported as a normalized 0-100 value, or -1 if not supported. Clamping to HW limits is handled by the backend. Changing backlight uses a different method call, to avoid recomputing the full display configuration every time the user presses the backlight keys. https://bugzilla.gnome.org/show_bug.cgi?id=705670
2013-07-25 13:06:09 +00:00
MonitorManager: return the new backlight after changing Modify the interface of ChangeBacklight to return the new value, to account for rounding to HW limits. https://bugzilla.gnome.org/show_bug.cgi?id=706729
2013-08-26 15:27:33 +00:00
meta_dbus_display_config_complete_change_backlight (skeleton, invocation, output->backlight);
MonitorManager: add support for backlight GnomeRR needs that too. The backlight is exported as a normalized 0-100 value, or -1 if not supported. Clamping to HW limits is handled by the backend. Changing backlight uses a different method call, to avoid recomputing the full display configuration every time the user presses the backlight keys. https://bugzilla.gnome.org/show_bug.cgi?id=705670
2013-07-25 13:06:09 +00:00
return TRUE;
}
MonitorManager: add gamma support Add GetCrtcGamma() and SetCrtcGamma(), that wrap the similarly named XRandR API. These are used by GnomeRR inside the color plugin of the control center (and may go away if the color plugin decides to do something different under wayland) https://bugzilla.gnome.org/show_bug.cgi?id=705670
2013-07-26 13:57:34 +00:00
static gboolean
meta_monitor_manager_handle_get_crtc_gamma (MetaDBusDisplayConfig *skeleton,
GDBusMethodInvocation *invocation,
guint serial,
guint crtc_id)
{
MetaMonitorManager *manager = META_MONITOR_MANAGER (skeleton);
MonitorManager: split the XRandR parts in a subclass Instead of keeping a forest of if backend else ..., use a subclass and virtual functions to discriminate between XRandR and the dummy backend (which lives in the parent class togheter with the common code) https://bugzilla.gnome.org/show_bug.cgi?id=705670
2013-07-29 11:00:15 +00:00
MetaMonitorManagerClass *klass;
backends: Split out CRTC/output management to MetaGpu In order to eventually support multilpe GPUs with their own connectors, split out related meta data management (i.e. outputs, CRTCs and CRTC modes) into a new MetaGpu GObject. The Xrandr backend always assumes there is always only a single "GPU" as the GPU is abstracted by the X server; only the native backend (aside from the test backend) will eventually see more than one GPU. The Xrandr backend still moves some management to MetaGpuXrandr, in order to behave more similarly to the KMS counterparts. https://bugzilla.gnome.org/show_bug.cgi?id=785381
2017-07-10 10:19:32 +00:00
GList *combined_crtcs;
monitor-manager: Rename MetaCRTC(Info) to MetaCrtc(Info) Change to follow the naming convention used everywhere else. This means changing CRTC to Crtc even though it is an abbreviation. https://bugzilla.gnome.org/show_bug.cgi?id=777732
2016-12-08 04:15:28 +00:00
MetaCrtc *crtc;
MonitorManager: add gamma support Add GetCrtcGamma() and SetCrtcGamma(), that wrap the similarly named XRandR API. These are used by GnomeRR inside the color plugin of the control center (and may go away if the color plugin decides to do something different under wayland) https://bugzilla.gnome.org/show_bug.cgi?id=705670
2013-07-26 13:57:34 +00:00
gsize size;
unsigned short *red;
unsigned short *green;
unsigned short *blue;
GBytes *red_bytes, *green_bytes, *blue_bytes;
GVariant *red_v, *green_v, *blue_v;
if (serial != manager->serial)
{
g_dbus_method_invocation_return_error (invocation, G_DBUS_ERROR,
G_DBUS_ERROR_ACCESS_DENIED,
"The requested configuration is based on stale information");
return TRUE;
}
backends: Split out CRTC/output management to MetaGpu In order to eventually support multilpe GPUs with their own connectors, split out related meta data management (i.e. outputs, CRTCs and CRTC modes) into a new MetaGpu GObject. The Xrandr backend always assumes there is always only a single "GPU" as the GPU is abstracted by the X server; only the native backend (aside from the test backend) will eventually see more than one GPU. The Xrandr backend still moves some management to MetaGpuXrandr, in order to behave more similarly to the KMS counterparts. https://bugzilla.gnome.org/show_bug.cgi?id=785381
2017-07-10 10:19:32 +00:00
combined_crtcs = combine_gpu_lists (manager, meta_gpu_get_crtcs);
if (crtc_id >= g_list_length (combined_crtcs))
MonitorManager: add gamma support Add GetCrtcGamma() and SetCrtcGamma(), that wrap the similarly named XRandR API. These are used by GnomeRR inside the color plugin of the control center (and may go away if the color plugin decides to do something different under wayland) https://bugzilla.gnome.org/show_bug.cgi?id=705670
2013-07-26 13:57:34 +00:00
{
backends: Split out CRTC/output management to MetaGpu In order to eventually support multilpe GPUs with their own connectors, split out related meta data management (i.e. outputs, CRTCs and CRTC modes) into a new MetaGpu GObject. The Xrandr backend always assumes there is always only a single "GPU" as the GPU is abstracted by the X server; only the native backend (aside from the test backend) will eventually see more than one GPU. The Xrandr backend still moves some management to MetaGpuXrandr, in order to behave more similarly to the KMS counterparts. https://bugzilla.gnome.org/show_bug.cgi?id=785381
2017-07-10 10:19:32 +00:00
g_list_free (combined_crtcs);
MonitorManager: add gamma support Add GetCrtcGamma() and SetCrtcGamma(), that wrap the similarly named XRandR API. These are used by GnomeRR inside the color plugin of the control center (and may go away if the color plugin decides to do something different under wayland) https://bugzilla.gnome.org/show_bug.cgi?id=705670
2013-07-26 13:57:34 +00:00
g_dbus_method_invocation_return_error (invocation, G_DBUS_ERROR,
G_DBUS_ERROR_INVALID_ARGS,
"Invalid crtc id");
return TRUE;
}
monitor-manager: Make MetaCrtc a GObject Turn MetaCrtc into a GObject and move it to a separate file. This changes the storage format, resulting in changing the API for accessing MetaCrtcs from using an array, to using a GList. https://bugzilla.gnome.org/show_bug.cgi?id=785381
2017-03-28 04:35:19 +00:00
backends: Split out CRTC/output management to MetaGpu In order to eventually support multilpe GPUs with their own connectors, split out related meta data management (i.e. outputs, CRTCs and CRTC modes) into a new MetaGpu GObject. The Xrandr backend always assumes there is always only a single "GPU" as the GPU is abstracted by the X server; only the native backend (aside from the test backend) will eventually see more than one GPU. The Xrandr backend still moves some management to MetaGpuXrandr, in order to behave more similarly to the KMS counterparts. https://bugzilla.gnome.org/show_bug.cgi?id=785381
2017-07-10 10:19:32 +00:00
crtc = g_list_nth_data (combined_crtcs, crtc_id);
g_list_free (combined_crtcs);
MonitorManager: add gamma support Add GetCrtcGamma() and SetCrtcGamma(), that wrap the similarly named XRandR API. These are used by GnomeRR inside the color plugin of the control center (and may go away if the color plugin decides to do something different under wayland) https://bugzilla.gnome.org/show_bug.cgi?id=705670
2013-07-26 13:57:34 +00:00
MonitorManager: split the XRandR parts in a subclass Instead of keeping a forest of if backend else ..., use a subclass and virtual functions to discriminate between XRandR and the dummy backend (which lives in the parent class togheter with the common code) https://bugzilla.gnome.org/show_bug.cgi?id=705670
2013-07-29 11:00:15 +00:00
klass = META_MONITOR_MANAGER_GET_CLASS (manager);
if (klass->get_crtc_gamma)
klass->get_crtc_gamma (manager, crtc, &size, &red, &green, &blue);
MonitorManager: add gamma support Add GetCrtcGamma() and SetCrtcGamma(), that wrap the similarly named XRandR API. These are used by GnomeRR inside the color plugin of the control center (and may go away if the color plugin decides to do something different under wayland) https://bugzilla.gnome.org/show_bug.cgi?id=705670
2013-07-26 13:57:34 +00:00
else
MonitorManager: split the XRandR parts in a subclass Instead of keeping a forest of if backend else ..., use a subclass and virtual functions to discriminate between XRandR and the dummy backend (which lives in the parent class togheter with the common code) https://bugzilla.gnome.org/show_bug.cgi?id=705670
2013-07-29 11:00:15 +00:00
{
size = 0;
red = green = blue = NULL;
}
MonitorManager: add gamma support Add GetCrtcGamma() and SetCrtcGamma(), that wrap the similarly named XRandR API. These are used by GnomeRR inside the color plugin of the control center (and may go away if the color plugin decides to do something different under wayland) https://bugzilla.gnome.org/show_bug.cgi?id=705670
2013-07-26 13:57:34 +00:00
red_bytes = g_bytes_new_take (red, size * sizeof (unsigned short));
green_bytes = g_bytes_new_take (green, size * sizeof (unsigned short));
blue_bytes = g_bytes_new_take (blue, size * sizeof (unsigned short));
red_v = g_variant_new_from_bytes (G_VARIANT_TYPE ("aq"), red_bytes, TRUE);
green_v = g_variant_new_from_bytes (G_VARIANT_TYPE ("aq"), green_bytes, TRUE);
blue_v = g_variant_new_from_bytes (G_VARIANT_TYPE ("aq"), blue_bytes, TRUE);
meta_dbus_display_config_complete_get_crtc_gamma (skeleton, invocation,
red_v, green_v, blue_v);
g_bytes_unref (red_bytes);
g_bytes_unref (green_bytes);
g_bytes_unref (blue_bytes);
return TRUE;
}
static gboolean
meta_monitor_manager_handle_set_crtc_gamma (MetaDBusDisplayConfig *skeleton,
GDBusMethodInvocation *invocation,
guint serial,
guint crtc_id,
GVariant *red_v,
GVariant *green_v,
GVariant *blue_v)
{
MetaMonitorManager *manager = META_MONITOR_MANAGER (skeleton);
MonitorManager: split the XRandR parts in a subclass Instead of keeping a forest of if backend else ..., use a subclass and virtual functions to discriminate between XRandR and the dummy backend (which lives in the parent class togheter with the common code) https://bugzilla.gnome.org/show_bug.cgi?id=705670
2013-07-29 11:00:15 +00:00
MetaMonitorManagerClass *klass;
backends: Split out CRTC/output management to MetaGpu In order to eventually support multilpe GPUs with their own connectors, split out related meta data management (i.e. outputs, CRTCs and CRTC modes) into a new MetaGpu GObject. The Xrandr backend always assumes there is always only a single "GPU" as the GPU is abstracted by the X server; only the native backend (aside from the test backend) will eventually see more than one GPU. The Xrandr backend still moves some management to MetaGpuXrandr, in order to behave more similarly to the KMS counterparts. https://bugzilla.gnome.org/show_bug.cgi?id=785381
2017-07-10 10:19:32 +00:00
GList *combined_crtcs;
monitor-manager: Rename MetaCRTC(Info) to MetaCrtc(Info) Change to follow the naming convention used everywhere else. This means changing CRTC to Crtc even though it is an abbreviation. https://bugzilla.gnome.org/show_bug.cgi?id=777732
2016-12-08 04:15:28 +00:00
MetaCrtc *crtc;
MonitorManager: add gamma support Add GetCrtcGamma() and SetCrtcGamma(), that wrap the similarly named XRandR API. These are used by GnomeRR inside the color plugin of the control center (and may go away if the color plugin decides to do something different under wayland) https://bugzilla.gnome.org/show_bug.cgi?id=705670
2013-07-26 13:57:34 +00:00
gsize size, dummy;
unsigned short *red;
unsigned short *green;
unsigned short *blue;
GBytes *red_bytes, *green_bytes, *blue_bytes;
if (serial != manager->serial)
{
g_dbus_method_invocation_return_error (invocation, G_DBUS_ERROR,
G_DBUS_ERROR_ACCESS_DENIED,
"The requested configuration is based on stale information");
return TRUE;
}
backends: Split out CRTC/output management to MetaGpu In order to eventually support multilpe GPUs with their own connectors, split out related meta data management (i.e. outputs, CRTCs and CRTC modes) into a new MetaGpu GObject. The Xrandr backend always assumes there is always only a single "GPU" as the GPU is abstracted by the X server; only the native backend (aside from the test backend) will eventually see more than one GPU. The Xrandr backend still moves some management to MetaGpuXrandr, in order to behave more similarly to the KMS counterparts. https://bugzilla.gnome.org/show_bug.cgi?id=785381
2017-07-10 10:19:32 +00:00
combined_crtcs = combine_gpu_lists (manager, meta_gpu_get_crtcs);
if (crtc_id >= g_list_length (combined_crtcs))
MonitorManager: add gamma support Add GetCrtcGamma() and SetCrtcGamma(), that wrap the similarly named XRandR API. These are used by GnomeRR inside the color plugin of the control center (and may go away if the color plugin decides to do something different under wayland) https://bugzilla.gnome.org/show_bug.cgi?id=705670
2013-07-26 13:57:34 +00:00
{
backends: Split out CRTC/output management to MetaGpu In order to eventually support multilpe GPUs with their own connectors, split out related meta data management (i.e. outputs, CRTCs and CRTC modes) into a new MetaGpu GObject. The Xrandr backend always assumes there is always only a single "GPU" as the GPU is abstracted by the X server; only the native backend (aside from the test backend) will eventually see more than one GPU. The Xrandr backend still moves some management to MetaGpuXrandr, in order to behave more similarly to the KMS counterparts. https://bugzilla.gnome.org/show_bug.cgi?id=785381
2017-07-10 10:19:32 +00:00
g_list_free (combined_crtcs);
MonitorManager: add gamma support Add GetCrtcGamma() and SetCrtcGamma(), that wrap the similarly named XRandR API. These are used by GnomeRR inside the color plugin of the control center (and may go away if the color plugin decides to do something different under wayland) https://bugzilla.gnome.org/show_bug.cgi?id=705670
2013-07-26 13:57:34 +00:00
g_dbus_method_invocation_return_error (invocation, G_DBUS_ERROR,
G_DBUS_ERROR_INVALID_ARGS,
"Invalid crtc id");
return TRUE;
}
monitor-manager: Make MetaCrtc a GObject Turn MetaCrtc into a GObject and move it to a separate file. This changes the storage format, resulting in changing the API for accessing MetaCrtcs from using an array, to using a GList. https://bugzilla.gnome.org/show_bug.cgi?id=785381
2017-03-28 04:35:19 +00:00
backends: Split out CRTC/output management to MetaGpu In order to eventually support multilpe GPUs with their own connectors, split out related meta data management (i.e. outputs, CRTCs and CRTC modes) into a new MetaGpu GObject. The Xrandr backend always assumes there is always only a single "GPU" as the GPU is abstracted by the X server; only the native backend (aside from the test backend) will eventually see more than one GPU. The Xrandr backend still moves some management to MetaGpuXrandr, in order to behave more similarly to the KMS counterparts. https://bugzilla.gnome.org/show_bug.cgi?id=785381
2017-07-10 10:19:32 +00:00
crtc = g_list_nth_data (combined_crtcs, crtc_id);
g_list_free (combined_crtcs);
MonitorManager: add gamma support Add GetCrtcGamma() and SetCrtcGamma(), that wrap the similarly named XRandR API. These are used by GnomeRR inside the color plugin of the control center (and may go away if the color plugin decides to do something different under wayland) https://bugzilla.gnome.org/show_bug.cgi?id=705670
2013-07-26 13:57:34 +00:00
red_bytes = g_variant_get_data_as_bytes (red_v);
green_bytes = g_variant_get_data_as_bytes (green_v);
blue_bytes = g_variant_get_data_as_bytes (blue_v);
size = g_bytes_get_size (red_bytes) / sizeof (unsigned short);
red = (unsigned short*) g_bytes_get_data (red_bytes, &dummy);
green = (unsigned short*) g_bytes_get_data (green_bytes, &dummy);
blue = (unsigned short*) g_bytes_get_data (blue_bytes, &dummy);
MonitorManager: split the XRandR parts in a subclass Instead of keeping a forest of if backend else ..., use a subclass and virtual functions to discriminate between XRandR and the dummy backend (which lives in the parent class togheter with the common code) https://bugzilla.gnome.org/show_bug.cgi?id=705670
2013-07-29 11:00:15 +00:00
klass = META_MONITOR_MANAGER_GET_CLASS (manager);
if (klass->set_crtc_gamma)
klass->set_crtc_gamma (manager, crtc, size, red, green, blue);
MonitorManager: add gamma support Add GetCrtcGamma() and SetCrtcGamma(), that wrap the similarly named XRandR API. These are used by GnomeRR inside the color plugin of the control center (and may go away if the color plugin decides to do something different under wayland) https://bugzilla.gnome.org/show_bug.cgi?id=705670
2013-07-26 13:57:34 +00:00
meta_dbus_display_config_complete_set_crtc_gamma (skeleton, invocation);
g_bytes_unref (red_bytes);
g_bytes_unref (green_bytes);
g_bytes_unref (blue_bytes);
return TRUE;
}
MonitorManager: inherit directly from DisplayConfig instead of handling signals This way we can handle properties too. https://bugzilla.gnome.org/show_bug.cgi?id=705670
2013-07-23 17:32:17 +00:00
static void
meta_monitor_manager_display_config_init (MetaDBusDisplayConfigIface *iface)
{
iface->handle_get_resources = meta_monitor_manager_handle_get_resources;
MonitorManager: add support for backlight GnomeRR needs that too. The backlight is exported as a normalized 0-100 value, or -1 if not supported. Clamping to HW limits is handled by the backend. Changing backlight uses a different method call, to avoid recomputing the full display configuration every time the user presses the backlight keys. https://bugzilla.gnome.org/show_bug.cgi?id=705670
2013-07-25 13:06:09 +00:00
iface->handle_change_backlight = meta_monitor_manager_handle_change_backlight;
MonitorManager: add gamma support Add GetCrtcGamma() and SetCrtcGamma(), that wrap the similarly named XRandR API. These are used by GnomeRR inside the color plugin of the control center (and may go away if the color plugin decides to do something different under wayland) https://bugzilla.gnome.org/show_bug.cgi?id=705670
2013-07-26 13:57:34 +00:00
iface->handle_get_crtc_gamma = meta_monitor_manager_handle_get_crtc_gamma;
iface->handle_set_crtc_gamma = meta_monitor_manager_handle_set_crtc_gamma;
DisplayConfig: Add new API for getting current state Add a D-Bus method for getting the current monitor and logical monitor state. Currently does not contain information about transforms or any limitations (such as limited CRTCs and cloning). https://bugzilla.gnome.org/show_bug.cgi?id=777732
2017-01-20 08:55:43 +00:00
iface->handle_get_current_state = meta_monitor_manager_handle_get_current_state;
DisplayConfig: Add new API for configuring monitors Add a new D-Bus API that uses the state from GetCurrentState to configure high level monitors, instead of low level CRTCs and connectors. So far persistent configuration is not implemented, as writing to the configuration store is still not supported. https://bugzilla.gnome.org/show_bug.cgi?id=777732
2017-02-14 11:54:04 +00:00
iface->handle_apply_monitors_config = meta_monitor_manager_handle_apply_monitors_config;
MonitorManager: inherit directly from DisplayConfig instead of handling signals This way we can handle properties too. https://bugzilla.gnome.org/show_bug.cgi?id=705670
2013-07-23 17:32:17 +00:00
}
Introduce a new DBus interface for display configuration This new interface will be used by the control center and possibly the settings daemon to configure the screens. It is designed to resemble a simplified XRandR, while still exposing all the quirks of the hardware, so that the panel can limit the user choices appropriately. To do so, MetaMonitorMode needs to track CRTCs, outputs and modes, so the low level objects have been decoupled from the high-level MetaMonitorInfo, which is used by core and API and offers a simplified view of HW, that hides away the details of what is cloned and how. This is still not efficient as it should be, because on every HW change we drop all data structures and rebuild them from scratch (which is not expensive because there aren't many of them, but at least in the XRandR path it involves a few sync X calls) https://bugzilla.gnome.org/show_bug.cgi?id=705670
2013-07-19 12:39:28 +00:00
static void
on_bus_acquired (GDBusConnection *connection,
const char *name,
gpointer user_data)
{
MetaMonitorManager *manager = user_data;
MonitorManager: inherit directly from DisplayConfig instead of handling signals This way we can handle properties too. https://bugzilla.gnome.org/show_bug.cgi?id=705670
2013-07-23 17:32:17 +00:00
g_dbus_interface_skeleton_export (G_DBUS_INTERFACE_SKELETON (manager),
Introduce a new DBus interface for display configuration This new interface will be used by the control center and possibly the settings daemon to configure the screens. It is designed to resemble a simplified XRandR, while still exposing all the quirks of the hardware, so that the panel can limit the user choices appropriately. To do so, MetaMonitorMode needs to track CRTCs, outputs and modes, so the low level objects have been decoupled from the high-level MetaMonitorInfo, which is used by core and API and offers a simplified view of HW, that hides away the details of what is cloned and how. This is still not efficient as it should be, because on every HW change we drop all data structures and rebuild them from scratch (which is not expensive because there aren't many of them, but at least in the XRandR path it involves a few sync X calls) https://bugzilla.gnome.org/show_bug.cgi?id=705670
2013-07-19 12:39:28 +00:00
connection,
"/org/gnome/Mutter/DisplayConfig",
NULL);
}
static void
on_name_acquired (GDBusConnection *connection,
const char *name,
gpointer user_data)
{
meta_topic (META_DEBUG_DBUS, "Acquired name %s\n", name);
}
static void
on_name_lost (GDBusConnection *connection,
const char *name,
gpointer user_data)
{
meta_topic (META_DEBUG_DBUS, "Lost or failed to acquire name %s\n", name);
}
static void
initialize_dbus_interface (MetaMonitorManager *manager)
{
manager->dbus_name_id = g_bus_own_name (G_BUS_TYPE_SESSION,
"org.gnome.Mutter.DisplayConfig",
G_BUS_NAME_OWNER_FLAGS_ALLOW_REPLACEMENT |
(meta_get_replace_current_wm () ?
G_BUS_NAME_OWNER_FLAGS_REPLACE : 0),
on_bus_acquired,
on_name_acquired,
on_name_lost,
g_object_ref (manager),
g_object_unref);
}
monitor-manager: Expose MetaMonitorManager to introspection This just exposes the type and the singleton getter necessary to make it available to introspection. We'll expose more functionality as it becomes needed. https://bugzilla.gnome.org/show_bug.cgi?id=743745
2015-01-30 13:51:18 +00:00
/**
* meta_monitor_manager_get:
*
* Accessor for the singleton MetaMonitorManager.
*
* Returns: (transfer none): The only #MetaMonitorManager there is.
*/
Rework and consolidate monitor handling in MetaScreen Consolidate all places that deal with output configuration in MetaScreen, which gets it either from XRandR or from a dummy static configuration. We still need to read the Xinerama config, even when running xwayland, because we need the indices for _NET_WM_FULLSCREEN_MONITORS, but now we do it only when needed. https://bugzilla.gnome.org/show_bug.cgi?id=705670
2013-07-18 11:09:16 +00:00
MetaMonitorManager *
meta_monitor_manager_get (void)
{
backends: Move MonitorManager creation to MetaBackend as well
2014-04-21 23:41:11 +00:00
MetaBackend *backend = meta_get_backend ();
Rework and consolidate monitor handling in MetaScreen Consolidate all places that deal with output configuration in MetaScreen, which gets it either from XRandR or from a dummy static configuration. We still need to read the Xinerama config, even when running xwayland, because we need the indices for _NET_WM_FULLSCREEN_MONITORS, but now we do it only when needed. https://bugzilla.gnome.org/show_bug.cgi?id=705670
2013-07-18 11:09:16 +00:00
backends: Move MonitorManager creation to MetaBackend as well
2014-04-21 23:41:11 +00:00
return meta_backend_get_monitor_manager (backend);
Rework and consolidate monitor handling in MetaScreen Consolidate all places that deal with output configuration in MetaScreen, which gets it either from XRandR or from a dummy static configuration. We still need to read the Xinerama config, even when running xwayland, because we need the indices for _NET_WM_FULLSCREEN_MONITORS, but now we do it only when needed. https://bugzilla.gnome.org/show_bug.cgi?id=705670
2013-07-18 11:09:16 +00:00
}
MetaScreen: Remove redundant copy of logical monitors array It was just pointer to the actual list; having to synchronize a list of logical monitors with the actual monitors managed by the backend is unnecessary. https://bugzilla.gnome.org/show_bug.cgi?id=777732
2016-11-28 12:11:24 +00:00
int
meta_monitor_manager_get_num_logical_monitors (MetaMonitorManager *manager)
{
monitor-manager: Store logical monitors in a GList Instead of storing the logical monitors in an array and having users either look up them in the array given an index or iterate using indices, put it in a GList, and use GList iterators when iterating and alternative API where array indices were previously used. This allows for more liberty regarding the type of the logical monitor. https://bugzilla.gnome.org/show_bug.cgi?id=777732
2016-12-02 08:00:03 +00:00
return g_list_length (manager->logical_monitors);
MetaScreen: Remove redundant copy of logical monitors array It was just pointer to the actual list; having to synchronize a list of logical monitors with the actual monitors managed by the backend is unnecessary. https://bugzilla.gnome.org/show_bug.cgi?id=777732
2016-11-28 12:11:24 +00:00
}
monitor-manager: Store logical monitors in a GList Instead of storing the logical monitors in an array and having users either look up them in the array given an index or iterate using indices, put it in a GList, and use GList iterators when iterating and alternative API where array indices were previously used. This allows for more liberty regarding the type of the logical monitor. https://bugzilla.gnome.org/show_bug.cgi?id=777732
2016-12-02 08:00:03 +00:00
GList *
meta_monitor_manager_get_logical_monitors (MetaMonitorManager *manager)
Rework and consolidate monitor handling in MetaScreen Consolidate all places that deal with output configuration in MetaScreen, which gets it either from XRandR or from a dummy static configuration. We still need to read the Xinerama config, even when running xwayland, because we need the indices for _NET_WM_FULLSCREEN_MONITORS, but now we do it only when needed. https://bugzilla.gnome.org/show_bug.cgi?id=705670
2013-07-18 11:09:16 +00:00
{
Rename MetaMonitorInfo MetaLogicalMonitor In preparation for further refactorizations, rename the MetaMonitorInfo struct to MetaLogicalMonitor. Eventually, part of MetaLogicalMonitor will be split into a MetaMonitor type. https://bugzilla.gnome.org/show_bug.cgi?id=777732
2016-11-25 06:31:38 +00:00
return manager->logical_monitors;
Rework and consolidate monitor handling in MetaScreen Consolidate all places that deal with output configuration in MetaScreen, which gets it either from XRandR or from a dummy static configuration. We still need to read the Xinerama config, even when running xwayland, because we need the indices for _NET_WM_FULLSCREEN_MONITORS, but now we do it only when needed. https://bugzilla.gnome.org/show_bug.cgi?id=705670
2013-07-18 11:09:16 +00:00
}
MetaMonitorManager: Add API turning monitor index into logical monitor This is the current equivalent of looking up the logical monitor in the logical monitor array using the number, but eventually that will be deprecated, and before that done differently, so add a temporary helper for the places that has not been ported yet. https://bugzilla.gnome.org/show_bug.cgi?id=777732
2016-11-29 03:46:41 +00:00
MetaLogicalMonitor *
meta_monitor_manager_get_logical_monitor_from_number (MetaMonitorManager *manager,
int number)
{
monitor-manager: use g_return_val_if_fail if trying to fetch an invalid monitor https://bugzilla.gnome.org/show_bug.cgi?id=788860
2017-10-13 05:10:22 +00:00
g_return_val_if_fail ((unsigned int) number < g_list_length (manager->logical_monitors), NULL);
MetaMonitorManager: Add API turning monitor index into logical monitor This is the current equivalent of looking up the logical monitor in the logical monitor array using the number, but eventually that will be deprecated, and before that done differently, so add a temporary helper for the places that has not been ported yet. https://bugzilla.gnome.org/show_bug.cgi?id=777732
2016-11-29 03:46:41 +00:00
monitor-manager: Store logical monitors in a GList Instead of storing the logical monitors in an array and having users either look up them in the array given an index or iterate using indices, put it in a GList, and use GList iterators when iterating and alternative API where array indices were previously used. This allows for more liberty regarding the type of the logical monitor. https://bugzilla.gnome.org/show_bug.cgi?id=777732
2016-12-02 08:00:03 +00:00
return g_list_nth (manager->logical_monitors, number)->data;
MetaMonitorManager: Add API turning monitor index into logical monitor This is the current equivalent of looking up the logical monitor in the logical monitor array using the number, but eventually that will be deprecated, and before that done differently, so add a temporary helper for the places that has not been ported yet. https://bugzilla.gnome.org/show_bug.cgi?id=777732
2016-11-29 03:46:41 +00:00
}
MetaMonitorManager: Track primary monitor by pointer instead of index Instead of keeping an index in an array to keep track of the current primary logical monitor, just keep a pointer instead. https://bugzilla.gnome.org/show_bug.cgi?id=777732
2016-11-28 12:43:27 +00:00
MetaLogicalMonitor *
meta_monitor_manager_get_primary_logical_monitor (MetaMonitorManager *manager)
{
return manager->primary_logical_monitor;
}
monitor-manager: Use MetaMonitor to check laptop panel status Instead of looking at the current configuration, just find the MetaMonitor of the laptop display panel and check the currest status directly. https://bugzilla.gnome.org/show_bug.cgi?id=777732
2016-12-19 06:58:44 +00:00
static MetaMonitor *
find_monitor (MetaMonitorManager *monitor_manager,
gboolean (*match_func) (MetaMonitor *monitor))
{
GList *monitors;
GList *l;
monitors = meta_monitor_manager_get_monitors (monitor_manager);
for (l = monitors; l; l = l->next)
{
MetaMonitor *monitor = l->data;
if (match_func (monitor))
return monitor;
}
return NULL;
}
monitor-manager: Add API to find primary monitor https://bugzilla.gnome.org/show_bug.cgi?id=777732
2016-12-21 04:38:13 +00:00
MetaMonitor *
meta_monitor_manager_get_primary_monitor (MetaMonitorManager *manager)
{
return find_monitor (manager, meta_monitor_is_primary);
}
monitor-manager: Use MetaMonitor to check laptop panel status Instead of looking at the current configuration, just find the MetaMonitor of the laptop display panel and check the currest status directly. https://bugzilla.gnome.org/show_bug.cgi?id=777732
2016-12-19 06:58:44 +00:00
MetaMonitor *
meta_monitor_manager_get_laptop_panel (MetaMonitorManager *manager)
{
return find_monitor (manager, meta_monitor_is_laptop_panel);
}
monitor-manager: Find active monitor when deriving global scale When deriving the global scale directly from the current hardware state (as done when using the X11 backend) we are inspecting the logical state they had prior to the most recent hot plug. That means that a primary monitor might have been disabled, and a new primary monitor may not have been assigned yet. Stop assuming a primary monitor has an active mode before having reconstructed the logical state by finding some active monitor if the old primary monitor was disabled. This avoids a crash when trying to derive the global scale from a disabled monitor. Closes: https://gitlab.gnome.org/GNOME/mutter/issues/130
2018-04-25 08:43:11 +00:00
static MetaMonitor *
meta_monitor_manager_get_active_monitor (MetaMonitorManager *manager)
{
return find_monitor (manager, meta_monitor_is_active);
}
monitor-manager: Add helper for getting monitor from connector This will be used later. https://bugzilla.gnome.org/show_bug.cgi?id=784199
2017-06-21 05:44:06 +00:00
MetaMonitor *
meta_monitor_manager_get_monitor_from_connector (MetaMonitorManager *manager,
const char *connector)
{
GList *l;
for (l = manager->monitors; l; l = l->next)
{
MetaMonitor *monitor = l->data;
if (g_str_equal (meta_monitor_get_connector (monitor),
connector))
return monitor;
}
return NULL;
}
monitor-manager: Add API to get monitor from monitor spec https://bugzilla.gnome.org/show_bug.cgi?id=777732
2016-12-21 04:41:53 +00:00
MetaMonitor *
meta_monitor_manager_get_monitor_from_spec (MetaMonitorManager *manager,
MetaMonitorSpec *monitor_spec)
{
GList *l;
for (l = manager->monitors; l; l = l->next)
{
MetaMonitor *monitor = l->data;
if (meta_monitor_spec_equals (meta_monitor_get_spec (monitor),
monitor_spec))
return monitor;
}
return NULL;
}
Put logical monitor grid lookup API in MetaMonitorManager Don't falsely assume the screen has anything to do with the monitor grid, and thus move the related API to MetaMonitorManager. https://bugzilla.gnome.org/show_bug.cgi?id=777732
2016-11-30 02:49:00 +00:00
MetaLogicalMonitor *
meta_monitor_manager_get_logical_monitor_at (MetaMonitorManager *manager,
monitor-manager: Make logical monitor from point API take floats Change meta_monitor_manager_get_logical_monitor_at() to use floats, replace users of meta_monitor_manager_get_monitor_at_point() to use the API that returns a logical monitor and remove the now unused function. https://bugzilla.gnome.org/show_bug.cgi?id=777732
2016-12-01 07:37:32 +00:00
float x,
float y)
Put logical monitor grid lookup API in MetaMonitorManager Don't falsely assume the screen has anything to do with the monitor grid, and thus move the related API to MetaMonitorManager. https://bugzilla.gnome.org/show_bug.cgi?id=777732
2016-11-30 02:49:00 +00:00
{
monitor-manager: Store logical monitors in a GList Instead of storing the logical monitors in an array and having users either look up them in the array given an index or iterate using indices, put it in a GList, and use GList iterators when iterating and alternative API where array indices were previously used. This allows for more liberty regarding the type of the logical monitor. https://bugzilla.gnome.org/show_bug.cgi?id=777732
2016-12-02 08:00:03 +00:00
GList *l;
Put logical monitor grid lookup API in MetaMonitorManager Don't falsely assume the screen has anything to do with the monitor grid, and thus move the related API to MetaMonitorManager. https://bugzilla.gnome.org/show_bug.cgi?id=777732
2016-11-30 02:49:00 +00:00
monitor-manager: Store logical monitors in a GList Instead of storing the logical monitors in an array and having users either look up them in the array given an index or iterate using indices, put it in a GList, and use GList iterators when iterating and alternative API where array indices were previously used. This allows for more liberty regarding the type of the logical monitor. https://bugzilla.gnome.org/show_bug.cgi?id=777732
2016-12-02 08:00:03 +00:00
for (l = manager->logical_monitors; l; l = l->next)
Put logical monitor grid lookup API in MetaMonitorManager Don't falsely assume the screen has anything to do with the monitor grid, and thus move the related API to MetaMonitorManager. https://bugzilla.gnome.org/show_bug.cgi?id=777732
2016-11-30 02:49:00 +00:00
{
monitor-manager: Store logical monitors in a GList Instead of storing the logical monitors in an array and having users either look up them in the array given an index or iterate using indices, put it in a GList, and use GList iterators when iterating and alternative API where array indices were previously used. This allows for more liberty regarding the type of the logical monitor. https://bugzilla.gnome.org/show_bug.cgi?id=777732
2016-12-02 08:00:03 +00:00
MetaLogicalMonitor *logical_monitor = l->data;
if (POINT_IN_RECT (x, y, logical_monitor->rect))
return logical_monitor;
Put logical monitor grid lookup API in MetaMonitorManager Don't falsely assume the screen has anything to do with the monitor grid, and thus move the related API to MetaMonitorManager. https://bugzilla.gnome.org/show_bug.cgi?id=777732
2016-11-30 02:49:00 +00:00
}
return NULL;
}
Move more logical monitor getters from the screen to the monitor manager Turning a rectangle into a logical monitor also has nothing to do with the screen (MetaScreen) so move it to MetaMonitorManager which has that information. https://bugzilla.gnome.org/show_bug.cgi?id=777732
2016-12-01 04:52:07 +00:00
MetaLogicalMonitor *
meta_monitor_manager_get_logical_monitor_from_rect (MetaMonitorManager *manager,
MetaRectangle *rect)
{
MetaLogicalMonitor *best_logical_monitor;
int best_logical_monitor_area;
monitor-manager: Store logical monitors in a GList Instead of storing the logical monitors in an array and having users either look up them in the array given an index or iterate using indices, put it in a GList, and use GList iterators when iterating and alternative API where array indices were previously used. This allows for more liberty regarding the type of the logical monitor. https://bugzilla.gnome.org/show_bug.cgi?id=777732
2016-12-02 08:00:03 +00:00
GList *l;
Move more logical monitor getters from the screen to the monitor manager Turning a rectangle into a logical monitor also has nothing to do with the screen (MetaScreen) so move it to MetaMonitorManager which has that information. https://bugzilla.gnome.org/show_bug.cgi?id=777732
2016-12-01 04:52:07 +00:00
best_logical_monitor = NULL;
best_logical_monitor_area = 0;
monitor-manager: Store logical monitors in a GList Instead of storing the logical monitors in an array and having users either look up them in the array given an index or iterate using indices, put it in a GList, and use GList iterators when iterating and alternative API where array indices were previously used. This allows for more liberty regarding the type of the logical monitor. https://bugzilla.gnome.org/show_bug.cgi?id=777732
2016-12-02 08:00:03 +00:00
for (l = manager->logical_monitors; l; l = l->next)
Move more logical monitor getters from the screen to the monitor manager Turning a rectangle into a logical monitor also has nothing to do with the screen (MetaScreen) so move it to MetaMonitorManager which has that information. https://bugzilla.gnome.org/show_bug.cgi?id=777732
2016-12-01 04:52:07 +00:00
{
monitor-manager: Store logical monitors in a GList Instead of storing the logical monitors in an array and having users either look up them in the array given an index or iterate using indices, put it in a GList, and use GList iterators when iterating and alternative API where array indices were previously used. This allows for more liberty regarding the type of the logical monitor. https://bugzilla.gnome.org/show_bug.cgi?id=777732
2016-12-02 08:00:03 +00:00
MetaLogicalMonitor *logical_monitor = l->data;
Move more logical monitor getters from the screen to the monitor manager Turning a rectangle into a logical monitor also has nothing to do with the screen (MetaScreen) so move it to MetaMonitorManager which has that information. https://bugzilla.gnome.org/show_bug.cgi?id=777732
2016-12-01 04:52:07 +00:00
MetaRectangle intersection;
int intersection_area;
if (!meta_rectangle_intersect (&logical_monitor->rect,
rect,
&intersection))
continue;
intersection_area = meta_rectangle_area (&intersection);
if (intersection_area > best_logical_monitor_area)
{
best_logical_monitor = logical_monitor;
best_logical_monitor_area = intersection_area;
}
}
if (!best_logical_monitor && (rect->width == 0 || rect->height == 0))
best_logical_monitor =
meta_monitor_manager_get_logical_monitor_at (manager, rect->x, rect->y);
if (!best_logical_monitor)
best_logical_monitor = manager->primary_logical_monitor;
return best_logical_monitor;
}
Move logical monitor neighbor API into monitor manager Move the last piece of monitor grid getter API to the monitor manager away from MetaScreen. The public facing API are still there, but are thin wrappers around the MetaMonitorManager API. https://bugzilla.gnome.org/show_bug.cgi?id=777732
2016-12-01 07:15:52 +00:00
MetaLogicalMonitor *
Move monitor management API to MetaDisplay This includes changing various users to use MetaDisplay directly, who used MetaScreen only for this before. https://bugzilla.gnome.org/show_bug.cgi?id=759538
2017-08-26 19:22:34 +00:00
meta_monitor_manager_get_logical_monitor_neighbor (MetaMonitorManager *manager,
MetaLogicalMonitor *logical_monitor,
MetaDisplayDirection direction)
Move logical monitor neighbor API into monitor manager Move the last piece of monitor grid getter API to the monitor manager away from MetaScreen. The public facing API are still there, but are thin wrappers around the MetaMonitorManager API. https://bugzilla.gnome.org/show_bug.cgi?id=777732
2016-12-01 07:15:52 +00:00
{
monitor-manager: Store logical monitors in a GList Instead of storing the logical monitors in an array and having users either look up them in the array given an index or iterate using indices, put it in a GList, and use GList iterators when iterating and alternative API where array indices were previously used. This allows for more liberty regarding the type of the logical monitor. https://bugzilla.gnome.org/show_bug.cgi?id=777732
2016-12-02 08:00:03 +00:00
GList *l;
Move logical monitor neighbor API into monitor manager Move the last piece of monitor grid getter API to the monitor manager away from MetaScreen. The public facing API are still there, but are thin wrappers around the MetaMonitorManager API. https://bugzilla.gnome.org/show_bug.cgi?id=777732
2016-12-01 07:15:52 +00:00
monitor-manager: Store logical monitors in a GList Instead of storing the logical monitors in an array and having users either look up them in the array given an index or iterate using indices, put it in a GList, and use GList iterators when iterating and alternative API where array indices were previously used. This allows for more liberty regarding the type of the logical monitor. https://bugzilla.gnome.org/show_bug.cgi?id=777732
2016-12-02 08:00:03 +00:00
for (l = manager->logical_monitors; l; l = l->next)
Move logical monitor neighbor API into monitor manager Move the last piece of monitor grid getter API to the monitor manager away from MetaScreen. The public facing API are still there, but are thin wrappers around the MetaMonitorManager API. https://bugzilla.gnome.org/show_bug.cgi?id=777732
2016-12-01 07:15:52 +00:00
{
monitor-manager: Store logical monitors in a GList Instead of storing the logical monitors in an array and having users either look up them in the array given an index or iterate using indices, put it in a GList, and use GList iterators when iterating and alternative API where array indices were previously used. This allows for more liberty regarding the type of the logical monitor. https://bugzilla.gnome.org/show_bug.cgi?id=777732
2016-12-02 08:00:03 +00:00
MetaLogicalMonitor *other = l->data;
Move logical monitor neighbor API into monitor manager Move the last piece of monitor grid getter API to the monitor manager away from MetaScreen. The public facing API are still there, but are thin wrappers around the MetaMonitorManager API. https://bugzilla.gnome.org/show_bug.cgi?id=777732
2016-12-01 07:15:52 +00:00
backends: Refactor MetaScreenDirection guessing into separate function Make it a helper MetaLogicalMonitor API, and use it on the MetaMonitorManager. https://bugzilla.gnome.org/show_bug.cgi?id=778119
2017-03-24 14:46:32 +00:00
if (meta_logical_monitor_has_neighbor (logical_monitor, other, direction))
return other;
Move logical monitor neighbor API into monitor manager Move the last piece of monitor grid getter API to the monitor manager away from MetaScreen. The public facing API are still there, but are thin wrappers around the MetaMonitorManager API. https://bugzilla.gnome.org/show_bug.cgi?id=777732
2016-12-01 07:15:52 +00:00
}
return NULL;
}
monitor-manager: Generate a monitor abstraction from outputs and crtcs Generate a set of "monitors" abstracting the physical concepts. Each monitor is built up of one or more outputs; multiple outputs being tiled monitors. Logical monitors will later be built from these. https://bugzilla.gnome.org/show_bug.cgi?id=777732
2016-12-13 02:53:38 +00:00
GList *
meta_monitor_manager_get_monitors (MetaMonitorManager *manager)
{
return manager->monitors;
}
backends: Split out CRTC/output management to MetaGpu In order to eventually support multilpe GPUs with their own connectors, split out related meta data management (i.e. outputs, CRTCs and CRTC modes) into a new MetaGpu GObject. The Xrandr backend always assumes there is always only a single "GPU" as the GPU is abstracted by the X server; only the native backend (aside from the test backend) will eventually see more than one GPU. The Xrandr backend still moves some management to MetaGpuXrandr, in order to behave more similarly to the KMS counterparts. https://bugzilla.gnome.org/show_bug.cgi?id=785381
2017-07-10 10:19:32 +00:00
void
meta_monitor_manager_add_gpu (MetaMonitorManager *manager,
MetaGpu *gpu)
Rework and consolidate monitor handling in MetaScreen Consolidate all places that deal with output configuration in MetaScreen, which gets it either from XRandR or from a dummy static configuration. We still need to read the Xinerama config, even when running xwayland, because we need the indices for _NET_WM_FULLSCREEN_MONITORS, but now we do it only when needed. https://bugzilla.gnome.org/show_bug.cgi?id=705670
2013-07-18 11:09:16 +00:00
{
backends: Split out CRTC/output management to MetaGpu In order to eventually support multilpe GPUs with their own connectors, split out related meta data management (i.e. outputs, CRTCs and CRTC modes) into a new MetaGpu GObject. The Xrandr backend always assumes there is always only a single "GPU" as the GPU is abstracted by the X server; only the native backend (aside from the test backend) will eventually see more than one GPU. The Xrandr backend still moves some management to MetaGpuXrandr, in order to behave more similarly to the KMS counterparts. https://bugzilla.gnome.org/show_bug.cgi?id=785381
2017-07-10 10:19:32 +00:00
manager->gpus = g_list_append (manager->gpus, gpu);
Rework and consolidate monitor handling in MetaScreen Consolidate all places that deal with output configuration in MetaScreen, which gets it either from XRandR or from a dummy static configuration. We still need to read the Xinerama config, even when running xwayland, because we need the indices for _NET_WM_FULLSCREEN_MONITORS, but now we do it only when needed. https://bugzilla.gnome.org/show_bug.cgi?id=705670
2013-07-18 11:09:16 +00:00
}
monitor-manager: Make MetaCrtc a GObject Turn MetaCrtc into a GObject and move it to a separate file. This changes the storage format, resulting in changing the API for accessing MetaCrtcs from using an array, to using a GList. https://bugzilla.gnome.org/show_bug.cgi?id=785381
2017-03-28 04:35:19 +00:00
GList *
backends: Split out CRTC/output management to MetaGpu In order to eventually support multilpe GPUs with their own connectors, split out related meta data management (i.e. outputs, CRTCs and CRTC modes) into a new MetaGpu GObject. The Xrandr backend always assumes there is always only a single "GPU" as the GPU is abstracted by the X server; only the native backend (aside from the test backend) will eventually see more than one GPU. The Xrandr backend still moves some management to MetaGpuXrandr, in order to behave more similarly to the KMS counterparts. https://bugzilla.gnome.org/show_bug.cgi?id=785381
2017-07-10 10:19:32 +00:00
meta_monitor_manager_get_gpus (MetaMonitorManager *manager)
monitor-manager: Make MetaCrtc a GObject Turn MetaCrtc into a GObject and move it to a separate file. This changes the storage format, resulting in changing the API for accessing MetaCrtcs from using an array, to using a GList. https://bugzilla.gnome.org/show_bug.cgi?id=785381
2017-03-28 04:35:19 +00:00
{
backends: Split out CRTC/output management to MetaGpu In order to eventually support multilpe GPUs with their own connectors, split out related meta data management (i.e. outputs, CRTCs and CRTC modes) into a new MetaGpu GObject. The Xrandr backend always assumes there is always only a single "GPU" as the GPU is abstracted by the X server; only the native backend (aside from the test backend) will eventually see more than one GPU. The Xrandr backend still moves some management to MetaGpuXrandr, in order to behave more similarly to the KMS counterparts. https://bugzilla.gnome.org/show_bug.cgi?id=785381
2017-07-10 10:19:32 +00:00
return manager->gpus;
monitor-manager: Make MetaCrtc a GObject Turn MetaCrtc into a GObject and move it to a separate file. This changes the storage format, resulting in changing the API for accessing MetaCrtcs from using an array, to using a GList. https://bugzilla.gnome.org/show_bug.cgi?id=785381
2017-03-28 04:35:19 +00:00
}
Rework and consolidate monitor handling in MetaScreen Consolidate all places that deal with output configuration in MetaScreen, which gets it either from XRandR or from a dummy static configuration. We still need to read the Xinerama config, even when running xwayland, because we need the indices for _NET_WM_FULLSCREEN_MONITORS, but now we do it only when needed. https://bugzilla.gnome.org/show_bug.cgi?id=705670
2013-07-18 11:09:16 +00:00
void
Reverse handling of XRandR events between Screen and MonitorManager Now MonitorManager does its own handling of XRandR events, which means we no longer handle ConfigureNotify on the root window. MetaScreen reacts to MonitorManager::monitor-changed and updates its internal state, including the new size. This paves the way for doing display configuration using only the dummy backend, which would allow testing wl_output interfaces. https://bugzilla.gnome.org/show_bug.cgi?id=705670
2013-07-22 16:57:12 +00:00
meta_monitor_manager_get_screen_size (MetaMonitorManager *manager,
int *width,
int *height)
{
*width = manager->screen_width;
*height = manager->screen_height;
}
monitor-manager: Generate a monitor abstraction from outputs and crtcs Generate a set of "monitors" abstracting the physical concepts. Each monitor is built up of one or more outputs; multiple outputs being tiled monitors. Logical monitors will later be built from these. https://bugzilla.gnome.org/show_bug.cgi?id=777732
2016-12-13 02:53:38 +00:00
static void
rebuild_monitors (MetaMonitorManager *manager)
{
Make MetaOutput a GObject Turn MetaOutput into a GObject and move it to a separate file. This changes the storage format, resulting in changing the API for accessing MetaOutputs from using an array, to using a GList. https://bugzilla.gnome.org/show_bug.cgi?id=785381
2017-03-24 09:35:51 +00:00
GList *l;
monitor-manager: Generate a monitor abstraction from outputs and crtcs Generate a set of "monitors" abstracting the physical concepts. Each monitor is built up of one or more outputs; multiple outputs being tiled monitors. Logical monitors will later be built from these. https://bugzilla.gnome.org/show_bug.cgi?id=777732
2016-12-13 02:53:38 +00:00
if (manager->monitors)
{
g_list_free_full (manager->monitors, g_object_unref);
manager->monitors = NULL;
}
backends: Split out CRTC/output management to MetaGpu In order to eventually support multilpe GPUs with their own connectors, split out related meta data management (i.e. outputs, CRTCs and CRTC modes) into a new MetaGpu GObject. The Xrandr backend always assumes there is always only a single "GPU" as the GPU is abstracted by the X server; only the native backend (aside from the test backend) will eventually see more than one GPU. The Xrandr backend still moves some management to MetaGpuXrandr, in order to behave more similarly to the KMS counterparts. https://bugzilla.gnome.org/show_bug.cgi?id=785381
2017-07-10 10:19:32 +00:00
for (l = manager->gpus; l; l = l->next)
monitor-manager: Generate a monitor abstraction from outputs and crtcs Generate a set of "monitors" abstracting the physical concepts. Each monitor is built up of one or more outputs; multiple outputs being tiled monitors. Logical monitors will later be built from these. https://bugzilla.gnome.org/show_bug.cgi?id=777732
2016-12-13 02:53:38 +00:00
{
backends: Split out CRTC/output management to MetaGpu In order to eventually support multilpe GPUs with their own connectors, split out related meta data management (i.e. outputs, CRTCs and CRTC modes) into a new MetaGpu GObject. The Xrandr backend always assumes there is always only a single "GPU" as the GPU is abstracted by the X server; only the native backend (aside from the test backend) will eventually see more than one GPU. The Xrandr backend still moves some management to MetaGpuXrandr, in order to behave more similarly to the KMS counterparts. https://bugzilla.gnome.org/show_bug.cgi?id=785381
2017-07-10 10:19:32 +00:00
MetaGpu *gpu = l->data;
GList *k;
monitor-manager: Generate a monitor abstraction from outputs and crtcs Generate a set of "monitors" abstracting the physical concepts. Each monitor is built up of one or more outputs; multiple outputs being tiled monitors. Logical monitors will later be built from these. https://bugzilla.gnome.org/show_bug.cgi?id=777732
2016-12-13 02:53:38 +00:00
backends: Split out CRTC/output management to MetaGpu In order to eventually support multilpe GPUs with their own connectors, split out related meta data management (i.e. outputs, CRTCs and CRTC modes) into a new MetaGpu GObject. The Xrandr backend always assumes there is always only a single "GPU" as the GPU is abstracted by the X server; only the native backend (aside from the test backend) will eventually see more than one GPU. The Xrandr backend still moves some management to MetaGpuXrandr, in order to behave more similarly to the KMS counterparts. https://bugzilla.gnome.org/show_bug.cgi?id=785381
2017-07-10 10:19:32 +00:00
for (k = meta_gpu_get_outputs (gpu); k; k = k->next)
monitor-manager: Generate a monitor abstraction from outputs and crtcs Generate a set of "monitors" abstracting the physical concepts. Each monitor is built up of one or more outputs; multiple outputs being tiled monitors. Logical monitors will later be built from these. https://bugzilla.gnome.org/show_bug.cgi?id=777732
2016-12-13 02:53:38 +00:00
{
backends: Split out CRTC/output management to MetaGpu In order to eventually support multilpe GPUs with their own connectors, split out related meta data management (i.e. outputs, CRTCs and CRTC modes) into a new MetaGpu GObject. The Xrandr backend always assumes there is always only a single "GPU" as the GPU is abstracted by the X server; only the native backend (aside from the test backend) will eventually see more than one GPU. The Xrandr backend still moves some management to MetaGpuXrandr, in order to behave more similarly to the KMS counterparts. https://bugzilla.gnome.org/show_bug.cgi?id=785381
2017-07-10 10:19:32 +00:00
MetaOutput *output = k->data;
if (output->tile_info.group_id)
{
if (is_main_tiled_monitor_output (output))
{
MetaMonitorTiled *monitor_tiled;
monitor_tiled = meta_monitor_tiled_new (gpu, output);
manager->monitors = g_list_append (manager->monitors,
monitor_tiled);
}
}
else
monitor-manager: Generate a monitor abstraction from outputs and crtcs Generate a set of "monitors" abstracting the physical concepts. Each monitor is built up of one or more outputs; multiple outputs being tiled monitors. Logical monitors will later be built from these. https://bugzilla.gnome.org/show_bug.cgi?id=777732
2016-12-13 02:53:38 +00:00
{
backends: Split out CRTC/output management to MetaGpu In order to eventually support multilpe GPUs with their own connectors, split out related meta data management (i.e. outputs, CRTCs and CRTC modes) into a new MetaGpu GObject. The Xrandr backend always assumes there is always only a single "GPU" as the GPU is abstracted by the X server; only the native backend (aside from the test backend) will eventually see more than one GPU. The Xrandr backend still moves some management to MetaGpuXrandr, in order to behave more similarly to the KMS counterparts. https://bugzilla.gnome.org/show_bug.cgi?id=785381
2017-07-10 10:19:32 +00:00
MetaMonitorNormal *monitor_normal;
monitor-manager: Generate a monitor abstraction from outputs and crtcs Generate a set of "monitors" abstracting the physical concepts. Each monitor is built up of one or more outputs; multiple outputs being tiled monitors. Logical monitors will later be built from these. https://bugzilla.gnome.org/show_bug.cgi?id=777732
2016-12-13 02:53:38 +00:00
backends: Split out CRTC/output management to MetaGpu In order to eventually support multilpe GPUs with their own connectors, split out related meta data management (i.e. outputs, CRTCs and CRTC modes) into a new MetaGpu GObject. The Xrandr backend always assumes there is always only a single "GPU" as the GPU is abstracted by the X server; only the native backend (aside from the test backend) will eventually see more than one GPU. The Xrandr backend still moves some management to MetaGpuXrandr, in order to behave more similarly to the KMS counterparts. https://bugzilla.gnome.org/show_bug.cgi?id=785381
2017-07-10 10:19:32 +00:00
monitor_normal = meta_monitor_normal_new (gpu, output);
monitor-manager: Generate a monitor abstraction from outputs and crtcs Generate a set of "monitors" abstracting the physical concepts. Each monitor is built up of one or more outputs; multiple outputs being tiled monitors. Logical monitors will later be built from these. https://bugzilla.gnome.org/show_bug.cgi?id=777732
2016-12-13 02:53:38 +00:00
manager->monitors = g_list_append (manager->monitors,
backends: Split out CRTC/output management to MetaGpu In order to eventually support multilpe GPUs with their own connectors, split out related meta data management (i.e. outputs, CRTCs and CRTC modes) into a new MetaGpu GObject. The Xrandr backend always assumes there is always only a single "GPU" as the GPU is abstracted by the X server; only the native backend (aside from the test backend) will eventually see more than one GPU. The Xrandr backend still moves some management to MetaGpuXrandr, in order to behave more similarly to the KMS counterparts. https://bugzilla.gnome.org/show_bug.cgi?id=785381
2017-07-10 10:19:32 +00:00
monitor_normal);
monitor-manager: Generate a monitor abstraction from outputs and crtcs Generate a set of "monitors" abstracting the physical concepts. Each monitor is built up of one or more outputs; multiple outputs being tiled monitors. Logical monitors will later be built from these. https://bugzilla.gnome.org/show_bug.cgi?id=777732
2016-12-13 02:53:38 +00:00
}
}
}
}
monitor-manager: Make tiled Xrandr monitors based on monitors Don't deal with adding/removing tiled Xrandr monitors in the generic backend, but leave it to the Xrandr backend. The tiled monitor will itself notify the backend when such a monitor is added and removed. Tiled Xrandr monitors are now based no MetaMonitor instead of MetaLogicalMonitor. This means that mirrored tiled monitors will now be represented correctly. https://bugzilla.gnome.org/show_bug.cgi?id=777732
2016-12-13 10:58:22 +00:00
void
meta_monitor_manager_tiled_monitor_added (MetaMonitorManager *manager,
MetaMonitor *monitor)
{
MetaMonitorManagerClass *manager_class =
META_MONITOR_MANAGER_GET_CLASS (manager);
if (manager_class->tiled_monitor_added)
manager_class->tiled_monitor_added (manager, monitor);
}
void
meta_monitor_manager_tiled_monitor_removed (MetaMonitorManager *manager,
MetaMonitor *monitor)
{
MetaMonitorManagerClass *manager_class =
META_MONITOR_MANAGER_GET_CLASS (manager);
if (manager_class->tiled_monitor_removed)
manager_class->tiled_monitor_removed (manager, monitor);
}
monitor-manager: Expose whether the backend handles a transform Expose via a new API whether the transform on a logical monitor is handled by the backend. This was previously only exposed only in the native backend. This will be used to emulate not supporting transforms in the backend in the nested backend. https://bugzilla.gnome.org/show_bug.cgi?id=779745
2017-03-08 08:05:00 +00:00
gboolean
meta_monitor_manager_is_transform_handled (MetaMonitorManager *manager,
MetaCrtc *crtc,
MetaMonitorTransform transform)
{
MetaMonitorManagerClass *manager_class =
META_MONITOR_MANAGER_GET_CLASS (manager);
return manager_class->is_transform_handled (manager, crtc, transform);
}
monitor-manager: Simplify reading the current configuration Make a wrapper in MetaMonitorManager that handles freeing the existing configuration for us.
2014-10-12 20:35:55 +00:00
void
monitor-manager: Rename read_current_config to read_current_state The function meta_monitor_manager_read_current_config() was renamed to meta_monitor_manager_read_current_state() as it does not read any configuration, but reads the current state as described by the backend. https://bugzilla.gnome.org/show_bug.cgi?id=777732
2016-12-19 07:46:31 +00:00
meta_monitor_manager_read_current_state (MetaMonitorManager *manager)
monitor-manager: Simplify reading the current configuration Make a wrapper in MetaMonitorManager that handles freeing the existing configuration for us.
2014-10-12 20:35:55 +00:00
{
backends: Split out CRTC/output management to MetaGpu In order to eventually support multilpe GPUs with their own connectors, split out related meta data management (i.e. outputs, CRTCs and CRTC modes) into a new MetaGpu GObject. The Xrandr backend always assumes there is always only a single "GPU" as the GPU is abstracted by the X server; only the native backend (aside from the test backend) will eventually see more than one GPU. The Xrandr backend still moves some management to MetaGpuXrandr, in order to behave more similarly to the KMS counterparts. https://bugzilla.gnome.org/show_bug.cgi?id=785381
2017-07-10 10:19:32 +00:00
GList *l;
monitor-manager: Simplify reading the current configuration Make a wrapper in MetaMonitorManager that handles freeing the existing configuration for us.
2014-10-12 20:35:55 +00:00
manager->serial++;
backends: Split out CRTC/output management to MetaGpu In order to eventually support multilpe GPUs with their own connectors, split out related meta data management (i.e. outputs, CRTCs and CRTC modes) into a new MetaGpu GObject. The Xrandr backend always assumes there is always only a single "GPU" as the GPU is abstracted by the X server; only the native backend (aside from the test backend) will eventually see more than one GPU. The Xrandr backend still moves some management to MetaGpuXrandr, in order to behave more similarly to the KMS counterparts. https://bugzilla.gnome.org/show_bug.cgi?id=785381
2017-07-10 10:19:32 +00:00
for (l = manager->gpus; l; l = l->next)
{
MetaGpu *gpu = l->data;
GError *error = NULL;
monitor-manager: Generate a monitor abstraction from outputs and crtcs Generate a set of "monitors" abstracting the physical concepts. Each monitor is built up of one or more outputs; multiple outputs being tiled monitors. Logical monitors will later be built from these. https://bugzilla.gnome.org/show_bug.cgi?id=777732
2016-12-13 02:53:38 +00:00
backends: Split out CRTC/output management to MetaGpu In order to eventually support multilpe GPUs with their own connectors, split out related meta data management (i.e. outputs, CRTCs and CRTC modes) into a new MetaGpu GObject. The Xrandr backend always assumes there is always only a single "GPU" as the GPU is abstracted by the X server; only the native backend (aside from the test backend) will eventually see more than one GPU. The Xrandr backend still moves some management to MetaGpuXrandr, in order to behave more similarly to the KMS counterparts. https://bugzilla.gnome.org/show_bug.cgi?id=785381
2017-07-10 10:19:32 +00:00
if (!meta_gpu_read_current (gpu, &error))
{
g_warning ("Failed to read current KMS state: %s", error->message);
g_clear_error (&error);
}
}
rebuild_monitors (manager);
monitor-manager: Simplify reading the current configuration Make a wrapper in MetaMonitorManager that handles freeing the existing configuration for us.
2014-10-12 20:35:55 +00:00
}
monitor-manager: Let backend implementations handle inital config How the initial configuration is done depends on the backend, so let them do it themself. https://bugzilla.gnome.org/show_bug.cgi?id=777732
2017-01-06 05:27:21 +00:00
static void
meta_monitor_manager_notify_monitors_changed (MetaMonitorManager *manager)
{
monitor-manager: Keep pointer to backend Instead of accessing the global singleton, keep a pointer to the backend in the MetaMonitorManager struct. https://bugzilla.gnome.org/show_bug.cgi?id=785381
2017-07-10 09:39:07 +00:00
meta_backend_monitors_changed (manager->backend);
backends: add 'monitors-updated-internal' signal to only update internal state Adding an internal signal and use it to update the internal state before emitting "monitors-changed" which will be repeated by the screen to the world. https://bugzilla.gnome.org/show_bug.cgi?id=788860
2017-10-13 00:14:40 +00:00
g_signal_emit (manager, signals[MONITORS_CHANGED_INTERNAL], 0);
monitor-manager: Let backend implementations handle inital config How the initial configuration is done depends on the backend, so let them do it themself. https://bugzilla.gnome.org/show_bug.cgi?id=777732
2017-01-06 05:27:21 +00:00
g_signal_emit_by_name (manager, "monitors-changed");
}
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 06:31:18 +00:00
static void
set_logical_monitor_modes (MetaMonitorManager *manager,
MetaLogicalMonitorConfig *logical_monitor_config)
{
GList *l;
for (l = logical_monitor_config->monitor_configs; l; l = l->next)
{
MetaMonitorConfig *monitor_config = l->data;
MetaMonitorSpec *monitor_spec;
MetaMonitor *monitor;
MetaMonitorModeSpec *monitor_mode_spec;
MetaMonitorMode *monitor_mode;
monitor_spec = monitor_config->monitor_spec;
monitor = meta_monitor_manager_get_monitor_from_spec (manager,
monitor_spec);
monitor_mode_spec = monitor_config->mode_spec;
monitor_mode = meta_monitor_get_mode_from_spec (monitor,
monitor_mode_spec);
meta_monitor_set_current_mode (monitor, monitor_mode);
}
}
static void
meta_monitor_manager_update_monitor_modes (MetaMonitorManager *manager,
MetaMonitorsConfig *config)
{
monitor-config-manager: Handle headless setup gracefully Handle headless setup gracefully by having no logical monitors. This commit only makes the monitor management code deal with it; other areas may still not be able to handle it. https://bugzilla.gnome.org/show_bug.cgi?id=777732
2017-01-12 05:47:54 +00:00
GList *logical_monitor_configs;
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 06:31:18 +00:00
GList *l;
monitor-manager: Update the monitor mode state before the logical state This means we can use up to date monitor mode data when generating the logical state. https://bugzilla.gnome.org/show_bug.cgi?id=777732
2017-01-20 06:56:34 +00:00
g_list_foreach (manager->monitors,
(GFunc) meta_monitor_set_current_mode,
NULL);
monitor-config-manager: Handle headless setup gracefully Handle headless setup gracefully by having no logical monitors. This commit only makes the monitor management code deal with it; other areas may still not be able to handle it. https://bugzilla.gnome.org/show_bug.cgi?id=777732
2017-01-12 05:47:54 +00:00
logical_monitor_configs = config ? config->logical_monitor_configs : NULL;
for (l = logical_monitor_configs; l; l = l->next)
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 06:31:18 +00:00
{
MetaLogicalMonitorConfig *logical_monitor_config = l->data;
set_logical_monitor_modes (manager, logical_monitor_config);
}
}
void
meta_monitor_manager_update_logical_state (MetaMonitorManager *manager,
MetaMonitorsConfig *config)
{
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 10:10:52 +00:00
if (config)
monitor-manager: use MonitorsConfig to track switch_config When constructing MetaMonitorsConfig objects, store which type of switch_config they are for (or UNKNOWN if it is not such type of config). Stop unconditionally setting current_switch_config to UNKNOWN when handling monitors changed events. Instead, set it to the switch_config type stored in the MonitorsConfig in the codepath that updates logical state. In addition to being called in the hotplug case along the same code flow that generates monitors changed events, this is also called in the coldplug case where a secondary monitor was connected before mutter was started. When creating the default linear display config, create it as a switch_config so that internal state gets updated to represent linear mode when this config is used. The previous behaviour of unconditionally resetting current_switch_config to UNKNOWN was breaking the internal state machine for display config switching, causing misbehaviour in gnome-shell's switchMonitor UI when using display switch hotkeys. The lack of internal tracking when the displays are already in the default "Join Displays" linear mode was then causing the first display switch hotkey press to do nothing (it would attempt to select "Join Displays" mode, but that was already active). Fixes: https://gitlab.gnome.org/GNOME/mutter/issues/281 https://gitlab.gnome.org/GNOME/mutter/merge_requests/213
2018-08-30 00:34:53 +00:00
{
manager->layout_mode = config->layout_mode;
manager->current_switch_config =
meta_monitors_config_get_switch_config (config);
}
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 10:10:52 +00:00
else
monitor-manager: use MonitorsConfig to track switch_config When constructing MetaMonitorsConfig objects, store which type of switch_config they are for (or UNKNOWN if it is not such type of config). Stop unconditionally setting current_switch_config to UNKNOWN when handling monitors changed events. Instead, set it to the switch_config type stored in the MonitorsConfig in the codepath that updates logical state. In addition to being called in the hotplug case along the same code flow that generates monitors changed events, this is also called in the coldplug case where a secondary monitor was connected before mutter was started. When creating the default linear display config, create it as a switch_config so that internal state gets updated to represent linear mode when this config is used. The previous behaviour of unconditionally resetting current_switch_config to UNKNOWN was breaking the internal state machine for display config switching, causing misbehaviour in gnome-shell's switchMonitor UI when using display switch hotkeys. The lack of internal tracking when the displays are already in the default "Join Displays" linear mode was then causing the first display switch hotkey press to do nothing (it would attempt to select "Join Displays" mode, but that was already active). Fixes: https://gitlab.gnome.org/GNOME/mutter/issues/281 https://gitlab.gnome.org/GNOME/mutter/merge_requests/213
2018-08-30 00:34:53 +00:00
{
manager->layout_mode =
meta_monitor_manager_get_default_layout_mode (manager);
manager->current_switch_config = META_MONITOR_SWITCH_CONFIG_UNKNOWN;
}
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 10:10:52 +00:00
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 06:31:18 +00:00
meta_monitor_manager_rebuild_logical_monitors (manager, config);
}
void
meta_monitor_manager_rebuild (MetaMonitorManager *manager,
MetaMonitorsConfig *config)
{
GList *old_logical_monitors;
monitor-manager: Update the monitor mode state before the logical state This means we can use up to date monitor mode data when generating the logical state. https://bugzilla.gnome.org/show_bug.cgi?id=777732
2017-01-20 06:56:34 +00:00
meta_monitor_manager_update_monitor_modes (manager, config);
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 06:31:18 +00:00
if (manager->in_init)
return;
old_logical_monitors = manager->logical_monitors;
meta_monitor_manager_update_logical_state (manager, config);
meta_monitor_manager_notify_monitors_changed (manager);
g_list_free_full (old_logical_monitors, g_object_unref);
}
monitor: Track current monitor mode Track what monitor mode is the current. This is derived from the mode of the corresponding CRTC's. https://bugzilla.gnome.org/show_bug.cgi?id=777732
2016-12-22 07:22:13 +00:00
static void
meta_monitor_manager_update_monitor_modes_derived (MetaMonitorManager *manager)
{
GList *l;
for (l = manager->monitors; l; l = l->next)
{
MetaMonitor *monitor = l->data;
meta_monitor_derive_current_mode (monitor);
}
}
monitor-manager: Let backend implementations handle inital config How the initial configuration is done depends on the backend, so let them do it themself. https://bugzilla.gnome.org/show_bug.cgi?id=777732
2017-01-06 05:27:21 +00:00
void
monitor-manager: Pass config to derive from when updating state When we update state, we might not have set the current config yet (for example if the Xrandr assignment didn't change), so pass the monitors config we should derive from instead of fetching it from the monitor config manager. https://bugzilla.gnome.org/show_bug.cgi?id=787477
2017-09-11 06:10:26 +00:00
meta_monitor_manager_update_logical_state_derived (MetaMonitorManager *manager,
MetaMonitorsConfig *config)
monitor-manager: Let backend implementations handle inital config How the initial configuration is done depends on the backend, so let them do it themself. https://bugzilla.gnome.org/show_bug.cgi?id=777732
2017-01-06 05:27:21 +00:00
{
monitor-manager: use MonitorsConfig to track switch_config When constructing MetaMonitorsConfig objects, store which type of switch_config they are for (or UNKNOWN if it is not such type of config). Stop unconditionally setting current_switch_config to UNKNOWN when handling monitors changed events. Instead, set it to the switch_config type stored in the MonitorsConfig in the codepath that updates logical state. In addition to being called in the hotplug case along the same code flow that generates monitors changed events, this is also called in the coldplug case where a secondary monitor was connected before mutter was started. When creating the default linear display config, create it as a switch_config so that internal state gets updated to represent linear mode when this config is used. The previous behaviour of unconditionally resetting current_switch_config to UNKNOWN was breaking the internal state machine for display config switching, causing misbehaviour in gnome-shell's switchMonitor UI when using display switch hotkeys. The lack of internal tracking when the displays are already in the default "Join Displays" linear mode was then causing the first display switch hotkey press to do nothing (it would attempt to select "Join Displays" mode, but that was already active). Fixes: https://gitlab.gnome.org/GNOME/mutter/issues/281 https://gitlab.gnome.org/GNOME/mutter/merge_requests/213
2018-08-30 00:34:53 +00:00
if (config)
manager->current_switch_config =
meta_monitors_config_get_switch_config (config);
else
manager->current_switch_config = META_MONITOR_SWITCH_CONFIG_UNKNOWN;
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 10:10:52 +00:00
manager->layout_mode = META_LOGICAL_MONITOR_LAYOUT_MODE_PHYSICAL;
monitor-manager: Pass config to derive from when updating state When we update state, we might not have set the current config yet (for example if the Xrandr assignment didn't change), so pass the monitors config we should derive from instead of fetching it from the monitor config manager. https://bugzilla.gnome.org/show_bug.cgi?id=787477
2017-09-11 06:10:26 +00:00
meta_monitor_manager_rebuild_logical_monitors_derived (manager, config);
monitor-manager: Let backend implementations handle inital config How the initial configuration is done depends on the backend, so let them do it themself. https://bugzilla.gnome.org/show_bug.cgi?id=777732
2017-01-06 05:27:21 +00:00
}
MonitorXrandr: check the event timestamps before reconfiguring If, checking the event timestamps, we see that a new configuration was explicitly requested by an another XRandR client, don't proceed to apply the intended configuration again, even if looking at the EDIDs it appears that the outputs changed. This works around some buggy Xorg drivers (qxl, vbox) that generate a new serial number everytime the user resizes the host window. https://bugzilla.gnome.org/show_bug.cgi?id=706735
2013-09-02 13:04:05 +00:00
void
monitor-manager: Pass config to derive from when updating state When we update state, we might not have set the current config yet (for example if the Xrandr assignment didn't change), so pass the monitors config we should derive from instead of fetching it from the monitor config manager. https://bugzilla.gnome.org/show_bug.cgi?id=787477
2017-09-11 06:10:26 +00:00
meta_monitor_manager_rebuild_derived (MetaMonitorManager *manager,
MetaMonitorsConfig *config)
DisplayConfig: make the dummy backend writable Add a number of dummy outputs and modes to the dummy backend, and implement the writing bits. The only visible effect is that you can change the screen size, which resizes the output window. https://bugzilla.gnome.org/show_bug.cgi?id=705670
2013-07-23 08:07:52 +00:00
{
monitor-manager: Store logical monitors in a GList Instead of storing the logical monitors in an array and having users either look up them in the array given an index or iterate using indices, put it in a GList, and use GList iterators when iterating and alternative API where array indices were previously used. This allows for more liberty regarding the type of the logical monitor. https://bugzilla.gnome.org/show_bug.cgi?id=777732
2016-12-02 08:00:03 +00:00
GList *old_logical_monitors;
Revert "monitor-manager: Remove needless code" It turns out that this was wrong because MetaWindow->monitor points to the old monitor infos and they are needed to position windows in the new configuration which happens in a monitors-changed handler. This reverts commit e1704acda4688074a0a7fd31005a96a28a551c1c.
2014-10-23 14:31:09 +00:00
monitor-manager: Update the monitor mode state before the logical state This means we can use up to date monitor mode data when generating the logical state. https://bugzilla.gnome.org/show_bug.cgi?id=777732
2017-01-20 06:56:34 +00:00
meta_monitor_manager_update_monitor_modes_derived (manager);
MonitorConfig: add support for default configurations Activate the presentation bit on new hotplugged monitors, while making a fully extended setup when running for the first time. https://bugzilla.gnome.org/show_bug.cgi?id=705670
2013-07-25 08:57:59 +00:00
if (manager->in_init)
return;
monitor-manager: Store logical monitors in a GList Instead of storing the logical monitors in an array and having users either look up them in the array given an index or iterate using indices, put it in a GList, and use GList iterators when iterating and alternative API where array indices were previously used. This allows for more liberty regarding the type of the logical monitor. https://bugzilla.gnome.org/show_bug.cgi?id=777732
2016-12-02 08:00:03 +00:00
old_logical_monitors = manager->logical_monitors;
monitor-manager: Pass config to derive from when updating state When we update state, we might not have set the current config yet (for example if the Xrandr assignment didn't change), so pass the monitors config we should derive from instead of fetching it from the monitor config manager. https://bugzilla.gnome.org/show_bug.cgi?id=787477
2017-09-11 06:10:26 +00:00
meta_monitor_manager_update_logical_state_derived (manager, config);
backend: Ensure the backend gets notified of monitor state having changed Being a listener to a signal, it is inconvenient to enforce order of execution between different signal listeners. If there are things in the backend that should be updated before various other signal handlers, make sure so is done by emitting the signal after having explicitly notified the backend. https://bugzilla.gnome.org/show_bug.cgi?id=768976
2016-07-06 07:27:45 +00:00
monitor-manager: Let backend implementations handle inital config How the initial configuration is done depends on the backend, so let them do it themself. https://bugzilla.gnome.org/show_bug.cgi?id=777732
2017-01-06 05:27:21 +00:00
meta_monitor_manager_notify_monitors_changed (manager);
Revert "monitor-manager: Remove needless code" It turns out that this was wrong because MetaWindow->monitor points to the old monitor infos and they are needed to position windows in the new configuration which happens in a monitors-changed handler. This reverts commit e1704acda4688074a0a7fd31005a96a28a551c1c.
2014-10-23 14:31:09 +00:00
Turn MetaLogicalMonitor into a GObject This will make it easier to move various manually managed data and data now in MetaLogicalMonitor into GObject QData fields. https://bugzilla.gnome.org/show_bug.cgi?id=777732
2016-12-02 08:08:59 +00:00
g_list_free_full (old_logical_monitors, g_object_unref);
DisplayConfig: make the dummy backend writable Add a number of dummy outputs and modes to the dummy backend, and implement the writing bits. The only visible effect is that you can change the screen size, which resizes the output window. https://bugzilla.gnome.org/show_bug.cgi?id=705670
2013-07-23 08:07:52 +00:00
}
monitor-manager: Put the common hotplug code in a common path as well So we can reuse it in the KMS backend.
2014-10-12 22:13:15 +00:00
backends: Make KMS EDID information equal to X11's EDID parsing has been refactored to a common meta_output_parse_edid() function, which ensures the extracted information is the same on both KMS and X11 backend, so it can be used consistently on eg. settings values. https://bugzilla.gnome.org/show_bug.cgi?id=742882
2015-01-04 20:24:05 +00:00
void
monitor-manager: Fix output variable naming Fix the last case of using the variable name "meta_output" for a MetaOutput. https://bugzilla.gnome.org/show_bug.cgi?id=777732
2017-03-24 09:18:20 +00:00
meta_output_parse_edid (MetaOutput *output,
backends: Make KMS EDID information equal to X11's EDID parsing has been refactored to a common meta_output_parse_edid() function, which ensures the extracted information is the same on both KMS and X11 backend, so it can be used consistently on eg. settings values. https://bugzilla.gnome.org/show_bug.cgi?id=742882
2015-01-04 20:24:05 +00:00
GBytes *edid)
{
MonitorInfo *parsed_edid;
gsize len;
monitor-manager: Initialize MetaOutput even when we can't get the EDID Otherwise we'll crash later when building a MetaConfiguration. https://bugzilla.gnome.org/show_bug.cgi?id=743412
2015-01-23 16:32:21 +00:00
if (!edid)
goto out;
backends: Make KMS EDID information equal to X11's EDID parsing has been refactored to a common meta_output_parse_edid() function, which ensures the extracted information is the same on both KMS and X11 backend, so it can be used consistently on eg. settings values. https://bugzilla.gnome.org/show_bug.cgi?id=742882
2015-01-04 20:24:05 +00:00
parsed_edid = decode_edid (g_bytes_get_data (edid, &len));
if (parsed_edid)
{
monitor-manager: Fix output variable naming Fix the last case of using the variable name "meta_output" for a MetaOutput. https://bugzilla.gnome.org/show_bug.cgi?id=777732
2017-03-24 09:18:20 +00:00
output->vendor = g_strndup (parsed_edid->manufacturer_code, 4);
if (!g_utf8_validate (output->vendor, -1, NULL))
g_clear_pointer (&output->vendor, g_free);
backends/monitor-manager: Validate EDID strings Some monitors return a bunch of bytes on their display descriptor which aren't valid utf8 and thus we fail to serialize them later on for the DisplayConfig DBus API. Let's fall back to the stringified product code and serial number in that case. https://bugzilla.gnome.org/show_bug.cgi?id=752673
2015-07-16 16:41:36 +00:00
monitor-manager: Fix output variable naming Fix the last case of using the variable name "meta_output" for a MetaOutput. https://bugzilla.gnome.org/show_bug.cgi?id=777732
2017-03-24 09:18:20 +00:00
output->product = g_strndup (parsed_edid->dsc_product_name, 14);
if (!g_utf8_validate (output->product, -1, NULL) ||
output->product[0] == '\0')
backends/monitor-manager: Validate EDID strings Some monitors return a bunch of bytes on their display descriptor which aren't valid utf8 and thus we fail to serialize them later on for the DisplayConfig DBus API. Let's fall back to the stringified product code and serial number in that case. https://bugzilla.gnome.org/show_bug.cgi?id=752673
2015-07-16 16:41:36 +00:00
{
monitor-manager: Fix output variable naming Fix the last case of using the variable name "meta_output" for a MetaOutput. https://bugzilla.gnome.org/show_bug.cgi?id=777732
2017-03-24 09:18:20 +00:00
g_clear_pointer (&output->product, g_free);
output->product = g_strdup_printf ("0x%04x", (unsigned) parsed_edid->product_code);
backends/monitor-manager: Validate EDID strings Some monitors return a bunch of bytes on their display descriptor which aren't valid utf8 and thus we fail to serialize them later on for the DisplayConfig DBus API. Let's fall back to the stringified product code and serial number in that case. https://bugzilla.gnome.org/show_bug.cgi?id=752673
2015-07-16 16:41:36 +00:00
}
monitor-manager: Fix output variable naming Fix the last case of using the variable name "meta_output" for a MetaOutput. https://bugzilla.gnome.org/show_bug.cgi?id=777732
2017-03-24 09:18:20 +00:00
output->serial = g_strndup (parsed_edid->dsc_serial_number, 14);
if (!g_utf8_validate (output->serial, -1, NULL) ||
output->serial[0] == '\0')
backends/monitor-manager: Validate EDID strings Some monitors return a bunch of bytes on their display descriptor which aren't valid utf8 and thus we fail to serialize them later on for the DisplayConfig DBus API. Let's fall back to the stringified product code and serial number in that case. https://bugzilla.gnome.org/show_bug.cgi?id=752673
2015-07-16 16:41:36 +00:00
{
monitor-manager: Fix output variable naming Fix the last case of using the variable name "meta_output" for a MetaOutput. https://bugzilla.gnome.org/show_bug.cgi?id=777732
2017-03-24 09:18:20 +00:00
g_clear_pointer (&output->serial, g_free);
output->serial = g_strdup_printf ("0x%08x", parsed_edid->serial_number);
backends/monitor-manager: Validate EDID strings Some monitors return a bunch of bytes on their display descriptor which aren't valid utf8 and thus we fail to serialize them later on for the DisplayConfig DBus API. Let's fall back to the stringified product code and serial number in that case. https://bugzilla.gnome.org/show_bug.cgi?id=752673
2015-07-16 16:41:36 +00:00
}
backends: Make KMS EDID information equal to X11's EDID parsing has been refactored to a common meta_output_parse_edid() function, which ensures the extracted information is the same on both KMS and X11 backend, so it can be used consistently on eg. settings values. https://bugzilla.gnome.org/show_bug.cgi?id=742882
2015-01-04 20:24:05 +00:00
g_free (parsed_edid);
}
monitor-manager: Initialize MetaOutput even when we can't get the EDID Otherwise we'll crash later when building a MetaConfiguration. https://bugzilla.gnome.org/show_bug.cgi?id=743412
2015-01-23 16:32:21 +00:00
out:
monitor-manager: Fix output variable naming Fix the last case of using the variable name "meta_output" for a MetaOutput. https://bugzilla.gnome.org/show_bug.cgi?id=777732
2017-03-24 09:18:20 +00:00
if (!output->vendor)
output->vendor = g_strdup ("unknown");
if (!output->product)
output->product = g_strdup ("unknown");
if (!output->serial)
output->serial = g_strdup ("unknown");
backends: Make KMS EDID information equal to X11's EDID parsing has been refactored to a common meta_output_parse_edid() function, which ensures the extracted information is the same on both KMS and X11 backend, so it can be used consistently on eg. settings values. https://bugzilla.gnome.org/show_bug.cgi?id=742882
2015-01-04 20:24:05 +00:00
}
monitor-manager: Expose output_is_laptop() method We currently duplicate the heuristics of whether an output is considered a laptop or not. Avoid this by sharing a small helper method. https://bugzilla.gnome.org/show_bug.cgi?id=765267
2016-04-21 15:29:44 +00:00
gboolean
meta_output_is_laptop (MetaOutput *output)
{
/* FIXME: extend with better heuristics */
switch (output->connector_type)
{
case META_CONNECTOR_TYPE_eDP:
case META_CONNECTOR_TYPE_LVDS:
monitor-config: Update laptop heuristics to match GnomeRROutput gnome-desktop's GnomeRROutput class has heuristics to classify a display as builtin similar to our own[0]. The two heuristics don't quite match though, so different core components can end up with a different view on the current display configuration. Minimize that risk by adding a couple of rules that bring the two heuristics closer together. [0] https://git.gnome.org/browse/gnome-desktop/tree/libgnome-desktop/gnome-rr.c#n1674 https://bugzilla.gnome.org/show_bug.cgi?id=765267
2016-04-20 17:10:18 +00:00
case META_CONNECTOR_TYPE_DSI:
monitor-manager: Expose output_is_laptop() method We currently duplicate the heuristics of whether an output is considered a laptop or not. Avoid this by sharing a small helper method. https://bugzilla.gnome.org/show_bug.cgi?id=765267
2016-04-21 15:29:44 +00:00
return TRUE;
default:
return FALSE;
}
}
monitor-manager: Move configuration paths behind 'legacy' functions In preparation of replacing the configuration system with one working with high level monitors instead of low level outputs etc, move configuarion handling code into obviously named function (containing the word 'legacy'. https://bugzilla.gnome.org/show_bug.cgi?id=777732
2016-12-19 07:22:07 +00:00
void
meta_monitor_manager_on_hotplug (MetaMonitorManager *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 06:31:18 +00:00
meta_monitor_manager_ensure_configured (manager);
monitor-manager: Put the common hotplug code in a common path as well So we can reuse it in the KMS backend.
2014-10-12 22:13:15 +00:00
}
monitor-manager: Add method to find an output matrix This will be useful to determine input device matrices for touchscreens and tablets. https://bugzilla.gnome.org/show_bug.cgi?id=739397
2014-12-11 17:14:00 +00:00
static gboolean
calculate_viewport_matrix (MetaMonitorManager *manager,
input-settings: Use logical monitors instead of outputs A MetaOutput is a connector, not exactly a monitor or a region on the stage; for example tiled monitors are split up into multiple outputs, and for what is used in input settings, that makes no sense. Change this to use logical monitors instead of outputs. https://bugzilla.gnome.org/show_bug.cgi?id=779745
2017-03-07 04:20:14 +00:00
MetaLogicalMonitor *logical_monitor,
monitor-manager: Add method to find an output matrix This will be useful to determine input device matrices for touchscreens and tablets. https://bugzilla.gnome.org/show_bug.cgi?id=739397
2014-12-11 17:14:00 +00:00
gfloat viewport[6])
{
gfloat x, y, width, height;
input-settings: Use logical monitors instead of outputs A MetaOutput is a connector, not exactly a monitor or a region on the stage; for example tiled monitors are split up into multiple outputs, and for what is used in input settings, that makes no sense. Change this to use logical monitors instead of outputs. https://bugzilla.gnome.org/show_bug.cgi?id=779745
2017-03-07 04:20:14 +00:00
x = (float) logical_monitor->rect.x / manager->screen_width;
y = (float) logical_monitor->rect.y / manager->screen_height;
width = (float) logical_monitor->rect.width / manager->screen_width;
height = (float) logical_monitor->rect.height / manager->screen_height;
monitor-manager: Add method to find an output matrix This will be useful to determine input device matrices for touchscreens and tablets. https://bugzilla.gnome.org/show_bug.cgi?id=739397
2014-12-11 17:14:00 +00:00
viewport[0] = width;
viewport[1] = 0.0f;
viewport[2] = x;
viewport[3] = 0.0f;
viewport[4] = height;
viewport[5] = y;
return TRUE;
}
static inline void
multiply_matrix (float a[6],
float b[6],
float res[6])
{
res[0] = a[0] * b[0] + a[1] * b[3];
res[1] = a[0] * b[1] + a[1] * b[4];
res[2] = a[0] * b[2] + a[1] * b[5] + a[2];
res[3] = a[3] * b[0] + a[4] * b[3];
res[4] = a[3] * b[1] + a[4] * b[4];
res[5] = a[3] * b[2] + a[4] * b[5] + a[5];
}
gboolean
meta_monitor_manager_get_monitor_matrix (MetaMonitorManager *manager,
monitor-manager: Take panel orientation into account when getting input matrix If a LCD panel has a non normal orientation (mounted upside-down or 90 degrees rotated) then the kernel will report touchscreen coordinates with the origin matching the native (e.g. upside down) coordinates of the panel. Since we transparently rotate the image on the panel to correct for the non normal panel-orientation, we must apply the same transform to input coordinates to keep the aligned. https://bugzilla.gnome.org/show_bug.cgi?id=782294
2017-10-06 11:41:49 +00:00
MetaMonitor *monitor,
input-settings: Use logical monitors instead of outputs A MetaOutput is a connector, not exactly a monitor or a region on the stage; for example tiled monitors are split up into multiple outputs, and for what is used in input settings, that makes no sense. Change this to use logical monitors instead of outputs. https://bugzilla.gnome.org/show_bug.cgi?id=779745
2017-03-07 04:20:14 +00:00
MetaLogicalMonitor *logical_monitor,
monitor-manager: Add method to find an output matrix This will be useful to determine input device matrices for touchscreens and tablets. https://bugzilla.gnome.org/show_bug.cgi?id=739397
2014-12-11 17:14:00 +00:00
gfloat matrix[6])
{
input-settings: Use logical monitors instead of outputs A MetaOutput is a connector, not exactly a monitor or a region on the stage; for example tiled monitors are split up into multiple outputs, and for what is used in input settings, that makes no sense. Change this to use logical monitors instead of outputs. https://bugzilla.gnome.org/show_bug.cgi?id=779745
2017-03-07 04:20:14 +00:00
MetaMonitorTransform transform;
monitor-manager: Add method to find an output matrix This will be useful to determine input device matrices for touchscreens and tablets. https://bugzilla.gnome.org/show_bug.cgi?id=739397
2014-12-11 17:14:00 +00:00
gfloat viewport[9];
input-settings: Use logical monitors instead of outputs A MetaOutput is a connector, not exactly a monitor or a region on the stage; for example tiled monitors are split up into multiple outputs, and for what is used in input settings, that makes no sense. Change this to use logical monitors instead of outputs. https://bugzilla.gnome.org/show_bug.cgi?id=779745
2017-03-07 04:20:14 +00:00
if (!calculate_viewport_matrix (manager, logical_monitor, viewport))
monitor-manager: Add method to find an output matrix This will be useful to determine input device matrices for touchscreens and tablets. https://bugzilla.gnome.org/show_bug.cgi?id=739397
2014-12-11 17:14:00 +00:00
return FALSE;
monitor-manager: Take panel orientation into account when getting input matrix If a LCD panel has a non normal orientation (mounted upside-down or 90 degrees rotated) then the kernel will report touchscreen coordinates with the origin matching the native (e.g. upside down) coordinates of the panel. Since we transparently rotate the image on the panel to correct for the non normal panel-orientation, we must apply the same transform to input coordinates to keep the aligned. https://bugzilla.gnome.org/show_bug.cgi?id=782294
2017-10-06 11:41:49 +00:00
/* Get transform corrected for LCD panel-orientation. */
logical-monitor: Track whether the logical monitor is transformed Keep track of the logical monitor transform. When a logical monitor is transformed, all of its monitors are also transformed in the same way. A logical monitor can either be transformed on the CRTC level, or using an offscreen intermediate buffer. In both cases will the logical monitor be transformed, but only in the latter will the view be transformed. MetaCrtcs::transform currently does not represent whether the CRTC is configured to be transformed or not; only when the backend can handle it does it correctly correspond to the actual CRTC configuration. This is intended to change with MetaMonitorConfigManager. https://bugzilla.gnome.org/show_bug.cgi?id=777732
2017-03-17 08:33:18 +00:00
transform = logical_monitor->transform;
monitor-manager: Take panel orientation into account when getting input matrix If a LCD panel has a non normal orientation (mounted upside-down or 90 degrees rotated) then the kernel will report touchscreen coordinates with the origin matching the native (e.g. upside down) coordinates of the panel. Since we transparently rotate the image on the panel to correct for the non normal panel-orientation, we must apply the same transform to input coordinates to keep the aligned. https://bugzilla.gnome.org/show_bug.cgi?id=782294
2017-10-06 11:41:49 +00:00
transform = meta_monitor_logical_to_crtc_transform (monitor, transform);
input-settings: Use logical monitors instead of outputs A MetaOutput is a connector, not exactly a monitor or a region on the stage; for example tiled monitors are split up into multiple outputs, and for what is used in input settings, that makes no sense. Change this to use logical monitors instead of outputs. https://bugzilla.gnome.org/show_bug.cgi?id=779745
2017-03-07 04:20:14 +00:00
multiply_matrix (viewport, transform_matrices[transform],
monitor-manager: Add method to find an output matrix This will be useful to determine input device matrices for touchscreens and tablets. https://bugzilla.gnome.org/show_bug.cgi?id=739397
2014-12-11 17:14:00 +00:00
matrix);
return TRUE;
}
monitor-manager: Expose a method to get a monitor from an output This method will be used by gnome-shell to resolve an output ID (exposed from the org.gnome.Mutter.DisplayConfig DBus API) to a logical monitor. https://bugzilla.gnome.org/show_bug.cgi?id=743745
2015-01-30 13:54:09 +00:00
monitor-manager: Add public API to get logical monitor from connector This adds a function to be used by gnome-shell to get the logical monitor given a connector name. For now, use the same index integer method to reference a logical monitor, but this should be revisited by providing a better API later. https://bugzilla.gnome.org/show_bug.cgi?id=777732
2017-04-06 05:15:45 +00:00
/**
* meta_monitor_manager_get_monitor_for_connector:
* @manager: A #MetaMonitorManager
* @connector: A valid connector name
*
* Returns: The monitor index or -1 if @id isn't valid or the connector
* isn't associated with a logical monitor.
*/
gint
meta_monitor_manager_get_monitor_for_connector (MetaMonitorManager *manager,
const char *connector)
{
GList *l;
for (l = manager->monitors; l; l = l->next)
{
MetaMonitor *monitor = l->data;
monitor-manager: Check active monitors when looking for logical monitor An inactive monitor will not be assigned to a logical monitor, so don't try to match against those. This avoids a dereferencing a NULL when the main output of an inactive monitor doesn't have an assigned CRTC. https://bugzilla.gnome.org/show_bug.cgi?id=777732
2017-04-07 15:41:23 +00:00
if (meta_monitor_is_active (monitor) &&
g_str_equal (connector, meta_monitor_get_connector (monitor)))
backends: Move MetaOutput::crtc field into private struct No functional changes. This is only done so that changes to reference counting can done more reliably. https://bugzilla.gnome.org/show_bug.cgi?id=786929
2017-11-03 10:25:30 +00:00
return meta_monitor_get_logical_monitor (monitor)->number;
monitor-manager: Add public API to get logical monitor from connector This adds a function to be used by gnome-shell to get the logical monitor given a connector name. For now, use the same index integer method to reference a logical monitor, but this should be revisited by providing a better API later. https://bugzilla.gnome.org/show_bug.cgi?id=777732
2017-04-06 05:15:45 +00:00
}
return -1;
}
monitor-manager: Add get_is_builtin_display_on() Wrap the existing laptop_display_is_on() method in a public function that gnome-shell can use to query whether a builtin output is present and enabled. https://bugzilla.gnome.org/show_bug.cgi?id=765267
2016-04-20 18:00:45 +00:00
gboolean
meta_monitor_manager_get_is_builtin_display_on (MetaMonitorManager *manager)
{
monitor-manager: Use MetaMonitor to check laptop panel status Instead of looking at the current configuration, just find the MetaMonitor of the laptop display panel and check the currest status directly. https://bugzilla.gnome.org/show_bug.cgi?id=777732
2016-12-19 06:58:44 +00:00
MetaMonitor *laptop_panel;
monitor-manager: Add get_is_builtin_display_on() Wrap the existing laptop_display_is_on() method in a public function that gnome-shell can use to query whether a builtin output is present and enabled. https://bugzilla.gnome.org/show_bug.cgi?id=765267
2016-04-20 18:00:45 +00:00
g_return_val_if_fail (META_IS_MONITOR_MANAGER (manager), FALSE);
monitor-manager: Use MetaMonitor to check laptop panel status Instead of looking at the current configuration, just find the MetaMonitor of the laptop display panel and check the currest status directly. https://bugzilla.gnome.org/show_bug.cgi?id=777732
2016-12-19 06:58:44 +00:00
laptop_panel = meta_monitor_manager_get_laptop_panel (manager);
if (!laptop_panel)
return FALSE;
return meta_monitor_is_active (laptop_panel);
monitor-manager: Add get_is_builtin_display_on() Wrap the existing laptop_display_is_on() method in a public function that gnome-shell can use to query whether a builtin output is present and enabled. https://bugzilla.gnome.org/show_bug.cgi?id=765267
2016-04-20 18:00:45 +00:00
}
meta-monitor-manager: Add API to rotate the current configuration This will allows us to support the XF86RotateWindows key present on some laptops directly in mutter. https://bugzilla.gnome.org/show_bug.cgi?id=781906
2017-05-04 12:25:47 +00:00
void
meta_monitor_manager_rotate_monitor (MetaMonitorManager *manager)
{
Remove old monitor configuration system Remove the old MetaMonitorConfig system and mark the new one as non-experimental. This also removes the D-Bus property. https://bugzilla.gnome.org/show_bug.cgi?id=777732
2017-03-24 07:36:12 +00:00
GError *error = NULL;
MetaMonitorsConfig *config =
meta_monitor_config_manager_create_for_rotate_monitor (manager->config_manager);
meta-monitor-manager: Add API to rotate the current configuration This will allows us to support the XF86RotateWindows key present on some laptops directly in mutter. https://bugzilla.gnome.org/show_bug.cgi?id=781906
2017-05-04 12:25:47 +00:00
Remove old monitor configuration system Remove the old MetaMonitorConfig system and mark the new one as non-experimental. This also removes the D-Bus property. https://bugzilla.gnome.org/show_bug.cgi?id=777732
2017-03-24 07:36:12 +00:00
if (!config)
return;
meta-monitor-manager: Add API to rotate the current configuration This will allows us to support the XF86RotateWindows key present on some laptops directly in mutter. https://bugzilla.gnome.org/show_bug.cgi?id=781906
2017-05-04 12:25:47 +00:00
Remove old monitor configuration system Remove the old MetaMonitorConfig system and mark the new one as non-experimental. This also removes the D-Bus property. https://bugzilla.gnome.org/show_bug.cgi?id=777732
2017-03-24 07:36:12 +00:00
if (!meta_monitor_manager_apply_monitors_config (manager,
config,
META_MONITORS_CONFIG_METHOD_TEMPORARY,
&error))
{
g_warning ("Failed to use rotate monitor configuration: %s",
error->message);
g_error_free (error);
meta-monitor-manager: Add API to rotate the current configuration This will allows us to support the XF86RotateWindows key present on some laptops directly in mutter. https://bugzilla.gnome.org/show_bug.cgi?id=781906
2017-05-04 12:25:47 +00:00
}
Remove old monitor configuration system Remove the old MetaMonitorConfig system and mark the new one as non-experimental. This also removes the D-Bus property. https://bugzilla.gnome.org/show_bug.cgi?id=777732
2017-03-24 07:36:12 +00:00
g_object_unref (config);
meta-monitor-manager: Add API to rotate the current configuration This will allows us to support the XF86RotateWindows key present on some laptops directly in mutter. https://bugzilla.gnome.org/show_bug.cgi?id=781906
2017-05-04 12:25:47 +00:00
}
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 16:38:10 +00:00
void
meta_monitor_manager_switch_config (MetaMonitorManager *manager,
MetaMonitorSwitchConfigType config_type)
{
Remove old monitor configuration system Remove the old MetaMonitorConfig system and mark the new one as non-experimental. This also removes the D-Bus property. https://bugzilla.gnome.org/show_bug.cgi?id=777732
2017-03-24 07:36:12 +00:00
GError *error = NULL;
MetaMonitorsConfig *config;
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 16:38:10 +00:00
g_return_if_fail (config_type != META_MONITOR_SWITCH_CONFIG_UNKNOWN);
Remove old monitor configuration system Remove the old MetaMonitorConfig system and mark the new one as non-experimental. This also removes the D-Bus property. https://bugzilla.gnome.org/show_bug.cgi?id=777732
2017-03-24 07:36:12 +00:00
config =
meta_monitor_config_manager_create_for_switch_config (manager->config_manager,
config_type);
if (!config)
return;
if (!meta_monitor_manager_apply_monitors_config (manager,
config,
META_MONITORS_CONFIG_METHOD_TEMPORARY,
&error))
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 16:38:10 +00:00
{
Remove old monitor configuration system Remove the old MetaMonitorConfig system and mark the new one as non-experimental. This also removes the D-Bus property. https://bugzilla.gnome.org/show_bug.cgi?id=777732
2017-03-24 07:36:12 +00:00
g_warning ("Failed to use switch monitor configuration: %s",
error->message);
g_error_free (error);
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 16:38:10 +00:00
}
else
{
Remove old monitor configuration system Remove the old MetaMonitorConfig system and mark the new one as non-experimental. This also removes the D-Bus property. https://bugzilla.gnome.org/show_bug.cgi?id=777732
2017-03-24 07:36:12 +00:00
manager->current_switch_config = config_type;
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 16:38:10 +00:00
}
Remove old monitor configuration system Remove the old MetaMonitorConfig system and mark the new one as non-experimental. This also removes the D-Bus property. https://bugzilla.gnome.org/show_bug.cgi?id=777732
2017-03-24 07:36:12 +00:00
g_object_unref (config);
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 16:38:10 +00:00
}
gboolean
meta_monitor_manager_can_switch_config (MetaMonitorManager *manager)
{
backend: Move lid-is-closed handling to MetaBackend Rather than handle UpClient in both MetaBackend (to reset the idletime when the lid is opened), and in MetaMonitorManager and MetaMonitorConfigManager (to turn the screen under the lid on/off depending on its status), move the ability to get the lid status from UPower or mock it in one place, in MetaBackend.
2018-04-16 18:07:45 +00:00
return (!meta_backend_is_lid_closed (manager->backend) &&
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 16:38:10 +00:00
g_list_length (manager->monitors) > 1);
}
MetaMonitorSwitchConfigType
meta_monitor_manager_get_switch_config (MetaMonitorManager *manager)
{
return manager->current_switch_config;
}
monitor-manager: Pass config to derive from when updating state When we update state, we might not have set the current config yet (for example if the Xrandr assignment didn't change), so pass the monitors config we should derive from instead of fetching it from the monitor config manager. https://bugzilla.gnome.org/show_bug.cgi?id=787477
2017-09-11 06:10:26 +00:00
MetaMonitorConfigManager *
meta_monitor_manager_get_config_manager (MetaMonitorManager *manager)
{
return manager->config_manager;
}
Copy permalink