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

3253 lines
106 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
*/
Add some gtk-doc comments.
2018-10-19 07:15:54 +00:00
/**
* SECTION:meta-monitor-manager
* @title: MetaMonitorManager
* @short_description: A manager for multiple monitors
*
* #MetaMonitorManager is an abstract class which contains methods to handle
* multiple monitors (both #MetaMonitor and #MetaLogicalMonitor) and GPU's
* (#MetaGpu). Its functions include reading and/or changing the current
* configuration and available capabiliies.
*
* The #MetaMonitorManager also provides the "org.gnome.Mutter.DisplayConfig"
* DBus service, so apps like GNOME Settings can use this functionality.
*/
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
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"
meta: Move private defines to a private header These defines are unused outside of mutter, and actually not desirable to export. Move them to a private header. https://gitlab.gnome.org/GNOME/mutter/merge_requests/859
2019-10-15 10:56:26 +00:00
#include "core/main-private.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 "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,
backends: Centralize panel autorotation in a DisplayConfig property Instead of having everyone check net.hadess.SensorProxy themselves, have this all controlled by the MetaOrientationManager, and proxied everywhere else via a readonly property in org.gnome.Mutter.DisplayConfig. We want to attach more complex policies here, and it seems better to centralize the handling of the autorotation feature rather than implementing policy changes all over the place. https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1311
2020-06-11 16:15:22 +00:00
PROP_PANEL_ORIENTATION_MANAGED,
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
PROP_LAST
};
static GParamSpec *obj_props[PROP_LAST];
Use a consistent style for enum braces https://gitlab.gnome.org/GNOME/mutter/merge_requests/361
2018-12-19 08:04:25 +00:00
enum
{
MonitorManager: Use composition instead of inheriting from dbus skeleton MonitorManager was inheriting from MetaDBusDisplayConfigSkeleton, this was causing introspection to see this like a GDBus skeleton object exposing to clients methods that were not required. Also, this required us to export meta_dbus_* symbols to the library, while these should be actually private. So, make MetaMonitorManager to be just a simple GObject holding a skeleton instance, and connect to its signals reusing most of the code with just few minor changes. https://gitlab.gnome.org/GNOME/mutter/merge_requests/395
2019-01-23 01:49:26 +00:00
MONITORS_CHANGED,
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,
MonitorManager: Use composition instead of inheriting from dbus skeleton MonitorManager was inheriting from MetaDBusDisplayConfigSkeleton, this was causing introspection to see this like a GDBus skeleton object exposing to clients methods that were not required. Also, this required us to export meta_dbus_* symbols to the library, while these should be actually private. So, make MetaMonitorManager to be just a simple GObject holding a skeleton instance, and connect to its signals reusing most of the code with just few minor changes. https://gitlab.gnome.org/GNOME/mutter/merge_requests/395
2019-01-23 01:49:26 +00:00
POWER_SAVE_MODE_CHANGED,
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];
monitor-manager: Clean up DPMS state tracking DPMS is configured from a bit all over the place: via D-Bus, via X11 and when reading the current KMS state. Each of these places did it slightly differently, directly poking at the field in MetaMonitorManager. To make things a bit more managable, move the field into a new MetaMonitorManagerPrivate, and add helpers to get and set the current value. Prior to this, there were for example situations where the DPMS setting was changed, but without signal listeners being notified about it. https://gitlab.gnome.org/GNOME/mutter/merge_requests/506
2019-01-11 13:45:44 +00:00
typedef struct _MetaMonitorManagerPrivate
{
MetaPowerSave power_save_mode;
monitor-manager: Ignore tablet-mode-switch on initial config of native portrait mode panels Many tablets have a native portrait mode panel, yet come with a keyboard dock, where the device gets docked in landscape mode. To avoid the display being on its side when mutter starts while the tablet is docked, we need to take the accelerometer reported orientation into account even if there is a tablet-mode-switch which indicates that the device is NOT in tablet-mode (because it is docked). Add special handling for the first time the "orientation-changed" signal gets signalled by the orientation-manager, which happens after it has successfully claimed the accelerometer with iio-sensor-proxy. The added special handling of the initial "orientation-changed" signal does a number of checks: 1. panel_orientation_managed is false because of the tablet-mode-switch and not because of other reasons. 2. The device has a native portrait mode panel (and thus likely needs rotation to display the image the right way up when docked). If all these checks succeed then it continues with creating a new monitors-config based on the orientation ignoring the panel_orientation_managed value (for the initial/first "orientation-changed" signal only). https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1506
2020-10-15 14:09:04 +00:00
gboolean initial_orient_change_done;
monitor-manager: Clean up DPMS state tracking DPMS is configured from a bit all over the place: via D-Bus, via X11 and when reading the current KMS state. Each of these places did it slightly differently, directly poking at the field in MetaMonitorManager. To make things a bit more managable, move the field into a new MetaMonitorManagerPrivate, and add helpers to get and set the current value. Prior to this, there were for example situations where the DPMS setting was changed, but without signal listeners being notified about it. https://gitlab.gnome.org/GNOME/mutter/merge_requests/506
2019-01-11 13:45:44 +00:00
} MetaMonitorManagerPrivate;
G_DEFINE_TYPE_WITH_PRIVATE (MetaMonitorManager, meta_monitor_manager,
G_TYPE_OBJECT)
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);
MonitorManager: Use composition instead of inheriting from dbus skeleton MonitorManager was inheriting from MetaDBusDisplayConfigSkeleton, this was causing introspection to see this like a GDBus skeleton object exposing to clients methods that were not required. Also, this required us to export meta_dbus_* symbols to the library, while these should be actually private. So, make MetaMonitorManager to be just a simple GObject holding a skeleton instance, and connect to its signals reusing most of the code with just few minor changes. https://gitlab.gnome.org/GNOME/mutter/merge_requests/395
2019-01-23 01:49:26 +00:00
static void monitor_manager_setup_dbus_config_handlers (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: Clean up DPMS state tracking DPMS is configured from a bit all over the place: via D-Bus, via X11 and when reading the current KMS state. Each of these places did it slightly differently, directly poking at the field in MetaMonitorManager. To make things a bit more managable, move the field into a new MetaMonitorManagerPrivate, and add helpers to get and set the current value. Prior to this, there were for example situations where the DPMS setting was changed, but without signal listeners being notified about it. https://gitlab.gnome.org/GNOME/mutter/merge_requests/506
2019-01-11 13:45:44 +00:00
static void
meta_monitor_manager_real_read_current_state (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)
{
output: Move output info to MetaOutputInfo struct The output info is established during construction and will stay the same for the lifetime of the MetaOutput object. Moving it out of the main struct enables us to eventually clean up the MetaOutput type inheritence to use proper GObject types. https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1287
2020-02-26 08:45:07 +00:00
const MetaOutputInfo *output_info = meta_output_get_info (output);
return (output_info->tile_info.loc_h_tile == 0 &&
output_info->tile_info.loc_v_tile == 0);
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
}
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: Clean up DPMS state tracking DPMS is configured from a bit all over the place: via D-Bus, via X11 and when reading the current KMS state. Each of these places did it slightly differently, directly poking at the field in MetaMonitorManager. To make things a bit more managable, move the field into a new MetaMonitorManagerPrivate, and add helpers to get and set the current value. Prior to this, there were for example situations where the DPMS setting was changed, but without signal listeners being notified about it. https://gitlab.gnome.org/GNOME/mutter/merge_requests/506
2019-01-11 13:45:44 +00:00
void
meta_monitor_manager_power_save_mode_changed (MetaMonitorManager *manager,
MetaPowerSave mode)
{
MetaMonitorManagerPrivate *priv =
meta_monitor_manager_get_instance_private (manager);
monitor-manager: Don't notify unchanged power save mode Since 4cae9b5b1132, and indirectly before that as well, the MetaMonitorManager::power-save-mode-changed is emitted even when the power save mode didn't actually change. On Wayland, this causes a mode set and therefore a stuttering. It became more proeminent with the transactional KMS code. Only emit 'power-save-mode-changed' when the power save mode actually changed. https://gitlab.gnome.org/GNOME/mutter/merge_requests/674
2019-07-06 23:23:57 +00:00
if (priv->power_save_mode == mode)
return;
monitor-manager: Clean up DPMS state tracking DPMS is configured from a bit all over the place: via D-Bus, via X11 and when reading the current KMS state. Each of these places did it slightly differently, directly poking at the field in MetaMonitorManager. To make things a bit more managable, move the field into a new MetaMonitorManagerPrivate, and add helpers to get and set the current value. Prior to this, there were for example situations where the DPMS setting was changed, but without signal listeners being notified about it. https://gitlab.gnome.org/GNOME/mutter/merge_requests/506
2019-01-11 13:45:44 +00:00
priv->power_save_mode = mode;
g_signal_emit (manager, signals[POWER_SAVE_MODE_CHANGED], 0);
}
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)
{
monitor-manager: Clean up DPMS state tracking DPMS is configured from a bit all over the place: via D-Bus, via X11 and when reading the current KMS state. Each of these places did it slightly differently, directly poking at the field in MetaMonitorManager. To make things a bit more managable, move the field into a new MetaMonitorManagerPrivate, and add helpers to get and set the current value. Prior to this, there were for example situations where the DPMS setting was changed, but without signal listeners being notified about it. https://gitlab.gnome.org/GNOME/mutter/merge_requests/506
2019-01-11 13:45:44 +00:00
MetaMonitorManagerPrivate *priv =
meta_monitor_manager_get_instance_private (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
MetaMonitorManagerClass *klass;
MonitorManager: Use composition instead of inheriting from dbus skeleton MonitorManager was inheriting from MetaDBusDisplayConfigSkeleton, this was causing introspection to see this like a GDBus skeleton object exposing to clients methods that were not required. Also, this required us to export meta_dbus_* symbols to the library, while these should be actually private. So, make MetaMonitorManager to be just a simple GObject holding a skeleton instance, and connect to its signals reusing most of the code with just few minor changes. https://gitlab.gnome.org/GNOME/mutter/merge_requests/395
2019-01-23 01:49:26 +00:00
int mode = meta_dbus_display_config_get_power_save_mode (manager->display_config);
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
if (mode == META_POWER_SAVE_UNSUPPORTED)
return;
/* If DPMS is unsupported, force the property back. */
monitor-manager: Clean up DPMS state tracking DPMS is configured from a bit all over the place: via D-Bus, via X11 and when reading the current KMS state. Each of these places did it slightly differently, directly poking at the field in MetaMonitorManager. To make things a bit more managable, move the field into a new MetaMonitorManagerPrivate, and add helpers to get and set the current value. Prior to this, there were for example situations where the DPMS setting was changed, but without signal listeners being notified about it. https://gitlab.gnome.org/GNOME/mutter/merge_requests/506
2019-01-11 13:45:44 +00:00
if (priv->power_save_mode == META_POWER_SAVE_UNSUPPORTED)
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
{
MonitorManager: Use composition instead of inheriting from dbus skeleton MonitorManager was inheriting from MetaDBusDisplayConfigSkeleton, this was causing introspection to see this like a GDBus skeleton object exposing to clients methods that were not required. Also, this required us to export meta_dbus_* symbols to the library, while these should be actually private. So, make MetaMonitorManager to be just a simple GObject holding a skeleton instance, and connect to its signals reusing most of the code with just few minor changes. https://gitlab.gnome.org/GNOME/mutter/merge_requests/395
2019-01-23 01:49:26 +00:00
meta_dbus_display_config_set_power_save_mode (manager->display_config, META_POWER_SAVE_UNSUPPORTED);
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
return;
}
klass = META_MONITOR_MANAGER_GET_CLASS (manager);
if (klass->set_power_save_mode)
klass->set_power_save_mode (manager, mode);
monitor-manager: Clean up DPMS state tracking DPMS is configured from a bit all over the place: via D-Bus, via X11 and when reading the current KMS state. Each of these places did it slightly differently, directly poking at the field in MetaMonitorManager. To make things a bit more managable, move the field into a new MetaMonitorManagerPrivate, and add helpers to get and set the current value. Prior to this, there were for example situations where the DPMS setting was changed, but without signal listeners being notified about it. https://gitlab.gnome.org/GNOME/mutter/merge_requests/506
2019-01-11 13:45:44 +00:00
meta_monitor_manager_power_save_mode_changed (manager, mode);
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
}
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);
}
Add some gtk-doc comments.
2018-10-19 07:15:54 +00:00
/**
* meta_monitor_manager_is_headless:
* @manager: A #MetaMonitorManager object
*
* Returns whether the monitor manager is headless, i.e. without
* any #MetaLogicalMonitor<!-- -->s attached to it.
*
* Returns: %TRUE if no monitors are attached, %FALSE otherwise.
*/
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 *
monitor: Fix indentation style on calculate_supported_scales and friends https://gitlab.gnome.org/GNOME/mutter/merge_requests/488
2019-03-08 18:03:57 +00:00
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
}
Add some gtk-doc comments.
2018-10-19 07:15:54 +00:00
/**
* meta_monitor_manager_get_capabilities:
* @manager: A #MetaMonitorManager object
*
* Queries the capabilities of the monitor manager.
*
* Returns: #MetaMonitorManagerCapability flags representing the capabilities.
*/
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)
{
backend: Move GPU ownership from the monitor manager to the backend Lets work towards making MetaMonitorManager about managing monitors, and not about managing GPUs. This changes other units to keep a pointer to the backend instead of a monitor manager, in case their ownership changed, or their main usage of the monitor manager was to look up GPUs. https://gitlab.gnome.org/GNOME/mutter/issues/548 https://gitlab.gnome.org/GNOME/mutter/merge_requests/525
2019-01-11 14:35:42 +00:00
GList *gpus;
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
backend: Move GPU ownership from the monitor manager to the backend Lets work towards making MetaMonitorManager about managing monitors, and not about managing GPUs. This changes other units to keep a pointer to the backend instead of a monitor manager, in case their ownership changed, or their main usage of the monitor manager was to look up GPUs. https://gitlab.gnome.org/GNOME/mutter/issues/548 https://gitlab.gnome.org/GNOME/mutter/merge_requests/525
2019-01-11 14:35:42 +00:00
gpus = meta_backend_get_gpus (manager->backend);
for (l = 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: Don't use switch-config when ensuring configuration Switch-configs are only to be used in certain circumstances (see meta_monitor_manager_can_switch_config()) so when ensuring configuration and attempting to create a linear configuration, use the linear configuration constructor function directly without going via the switch config method, otherwise we might incorrectly fall back to the fallback configuration (only enable primary monitor). This is a regression introduced by 6267732bec97773. Fixes: https://gitlab.gnome.org/GNOME/mutter/issues/342
2018-10-11 13:16:26 +00:00
config = meta_monitor_config_manager_create_linear (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,
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
monitor-manager: Add a handle_orientation_change helper function Move the bulk of orientation_changed to a new handle_orientation_change helper function. This is a preparation patch for further orientation handling related changes. https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1506
2020-10-15 10:21:05 +00:00
handle_orientation_change (MetaOrientationManager *orientation_manager,
MetaMonitorManager *manager)
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
{
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: Ignore tablet-mode-switch on initial config of native portrait mode panels Many tablets have a native portrait mode panel, yet come with a keyboard dock, where the device gets docked in landscape mode. To avoid the display being on its side when mutter starts while the tablet is docked, we need to take the accelerometer reported orientation into account even if there is a tablet-mode-switch which indicates that the device is NOT in tablet-mode (because it is docked). Add special handling for the first time the "orientation-changed" signal gets signalled by the orientation-manager, which happens after it has successfully claimed the accelerometer with iio-sensor-proxy. The added special handling of the initial "orientation-changed" signal does a number of checks: 1. panel_orientation_managed is false because of the tablet-mode-switch and not because of other reasons. 2. The device has a native portrait mode panel (and thus likely needs rotation to display the image the right way up when docked). If all these checks succeed then it continues with creating a new monitors-config based on the orientation ignoring the panel_orientation_managed value (for the initial/first "orientation-changed" signal only). https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1506
2020-10-15 14:09:04 +00:00
/*
* Special case for tablets with a native portrait mode and a keyboard dock,
* where the device gets docked in landscape mode. For this combo to work
* properly with mutter starting while the tablet is docked, we need to take
* the accelerometer reported orientation into account (at mutter startup)
* even if there is a tablet-mode-switch which indicates that the device is
* NOT in tablet-mode (because it is docked).
*/
static gboolean
handle_initial_orientation_change (MetaOrientationManager *orientation_manager,
MetaMonitorManager *manager)
{
ClutterBackend *clutter_backend;
ClutterSeat *seat;
MetaMonitor *monitor;
MetaMonitorMode *mode;
int width, height;
clutter_backend = meta_backend_get_clutter_backend (manager->backend);
seat = clutter_backend_get_default_seat (clutter_backend);
/*
* This is a workaround to ignore the tablet mode switch on the initial config
* of devices with a native portrait mode panel. The touchscreen and
* accelerometer requirements for applying the orientation must still be met.
*/
if (!clutter_seat_has_touchscreen (seat) ||
!meta_orientation_manager_has_accelerometer (orientation_manager))
return FALSE;
/* Check for a portrait mode panel */
monitor = meta_monitor_manager_get_laptop_panel (manager);
if (!monitor)
return FALSE;
mode = meta_monitor_get_preferred_mode (monitor);
meta_monitor_mode_get_resolution (mode, &width, &height);
if (width > height)
return FALSE;
handle_orientation_change (orientation_manager, manager);
return TRUE;
}
monitor-manager: Add a handle_orientation_change helper function Move the bulk of orientation_changed to a new handle_orientation_change helper function. This is a preparation patch for further orientation handling related changes. https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1506
2020-10-15 10:21:05 +00:00
static void
orientation_changed (MetaOrientationManager *orientation_manager,
MetaMonitorManager *manager)
{
monitor-manager: Ignore tablet-mode-switch on initial config of native portrait mode panels Many tablets have a native portrait mode panel, yet come with a keyboard dock, where the device gets docked in landscape mode. To avoid the display being on its side when mutter starts while the tablet is docked, we need to take the accelerometer reported orientation into account even if there is a tablet-mode-switch which indicates that the device is NOT in tablet-mode (because it is docked). Add special handling for the first time the "orientation-changed" signal gets signalled by the orientation-manager, which happens after it has successfully claimed the accelerometer with iio-sensor-proxy. The added special handling of the initial "orientation-changed" signal does a number of checks: 1. panel_orientation_managed is false because of the tablet-mode-switch and not because of other reasons. 2. The device has a native portrait mode panel (and thus likely needs rotation to display the image the right way up when docked). If all these checks succeed then it continues with creating a new monitors-config based on the orientation ignoring the panel_orientation_managed value (for the initial/first "orientation-changed" signal only). https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1506
2020-10-15 14:09:04 +00:00
MetaMonitorManagerPrivate *priv =
meta_monitor_manager_get_instance_private (manager);
if (!priv->initial_orient_change_done)
{
priv->initial_orient_change_done = TRUE;
if (handle_initial_orientation_change (orientation_manager, manager))
return;
}
monitor-manager: Add a handle_orientation_change helper function Move the bulk of orientation_changed to a new handle_orientation_change helper function. This is a preparation patch for further orientation handling related changes. https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1506
2020-10-15 10:21:05 +00:00
if (!manager->panel_orientation_managed)
return;
handle_orientation_change (orientation_manager, 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
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: Centralize panel autorotation in a DisplayConfig property Instead of having everyone check net.hadess.SensorProxy themselves, have this all controlled by the MetaOrientationManager, and proxied everywhere else via a readonly property in org.gnome.Mutter.DisplayConfig. We want to attach more complex policies here, and it seems better to centralize the handling of the autorotation feature rather than implementing policy changes all over the place. https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1311
2020-06-11 16:15:22 +00:00
static void
update_panel_orientation_managed (MetaMonitorManager *manager)
{
MetaOrientationManager *orientation_manager;
backends: Hook ClutterSeat::touch-mode to PanelOrientationManaged We only want the panel autorotation to happen if the laptop has an accelerometer, and is in tablet mode. Regular laptop mode should lock the orientation, and let it be configured manually. https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1311
2020-06-11 16:18:37 +00:00
ClutterBackend *clutter_backend;
ClutterSeat *seat;
backends: Centralize panel autorotation in a DisplayConfig property Instead of having everyone check net.hadess.SensorProxy themselves, have this all controlled by the MetaOrientationManager, and proxied everywhere else via a readonly property in org.gnome.Mutter.DisplayConfig. We want to attach more complex policies here, and it seems better to centralize the handling of the autorotation feature rather than implementing policy changes all over the place. https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1311
2020-06-11 16:15:22 +00:00
gboolean panel_orientation_managed;
backends: Hook ClutterSeat::touch-mode to PanelOrientationManaged We only want the panel autorotation to happen if the laptop has an accelerometer, and is in tablet mode. Regular laptop mode should lock the orientation, and let it be configured manually. https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1311
2020-06-11 16:18:37 +00:00
clutter_backend = meta_backend_get_clutter_backend (manager->backend);
seat = clutter_backend_get_default_seat (clutter_backend);
backends: Centralize panel autorotation in a DisplayConfig property Instead of having everyone check net.hadess.SensorProxy themselves, have this all controlled by the MetaOrientationManager, and proxied everywhere else via a readonly property in org.gnome.Mutter.DisplayConfig. We want to attach more complex policies here, and it seems better to centralize the handling of the autorotation feature rather than implementing policy changes all over the place. https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1311
2020-06-11 16:15:22 +00:00
orientation_manager = meta_backend_get_orientation_manager (manager->backend);
panel_orientation_managed =
backends: Hook ClutterSeat::touch-mode to PanelOrientationManaged We only want the panel autorotation to happen if the laptop has an accelerometer, and is in tablet mode. Regular laptop mode should lock the orientation, and let it be configured manually. https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1311
2020-06-11 16:18:37 +00:00
(clutter_seat_get_touch_mode (seat) &&
meta_orientation_manager_has_accelerometer (orientation_manager));
backends: Centralize panel autorotation in a DisplayConfig property Instead of having everyone check net.hadess.SensorProxy themselves, have this all controlled by the MetaOrientationManager, and proxied everywhere else via a readonly property in org.gnome.Mutter.DisplayConfig. We want to attach more complex policies here, and it seems better to centralize the handling of the autorotation feature rather than implementing policy changes all over the place. https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1311
2020-06-11 16:15:22 +00:00
if (manager->panel_orientation_managed == panel_orientation_managed)
return;
manager->panel_orientation_managed = panel_orientation_managed;
g_object_notify_by_pspec (G_OBJECT (manager),
obj_props[PROP_PANEL_ORIENTATION_MANAGED]);
meta_dbus_display_config_set_panel_orientation_managed (manager->display_config,
manager->panel_orientation_managed);
monitor-manager: Update orientation based config when panel_orientation_managed changes The orientation reported by the orientation_manager may have changed while panel_orientation_managed was false. So when panel_orientation_managed changes to true we should re-check the orientation. This fixes the orientation not being correct when e.g. taking a 360 degree hinges 2-in-1 in clamshell mode (so landscape orientation) and then folding it into tablet mode while holding it in portrait orientation. https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1506
2020-10-15 10:22:53 +00:00
/* The orientation may have changed while it was unmanaged */
if (panel_orientation_managed)
handle_orientation_change (orientation_manager, manager);
backends: Centralize panel autorotation in a DisplayConfig property Instead of having everyone check net.hadess.SensorProxy themselves, have this all controlled by the MetaOrientationManager, and proxied everywhere else via a readonly property in org.gnome.Mutter.DisplayConfig. We want to attach more complex policies here, and it seems better to centralize the handling of the autorotation feature rather than implementing policy changes all over the place. https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1311
2020-06-11 16:15:22 +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
MonitorManager: Use composition instead of inheriting from dbus skeleton MonitorManager was inheriting from MetaDBusDisplayConfigSkeleton, this was causing introspection to see this like a GDBus skeleton object exposing to clients methods that were not required. Also, this required us to export meta_dbus_* symbols to the library, while these should be actually private. So, make MetaMonitorManager to be just a simple GObject holding a skeleton instance, and connect to its signals reusing most of the code with just few minor changes. https://gitlab.gnome.org/GNOME/mutter/merge_requests/395
2019-01-23 01:49:26 +00:00
manager->display_config = meta_dbus_display_config_skeleton_new ();
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);
MonitorManager: Use composition instead of inheriting from dbus skeleton MonitorManager was inheriting from MetaDBusDisplayConfigSkeleton, this was causing introspection to see this like a GDBus skeleton object exposing to clients methods that were not required. Also, this required us to export meta_dbus_* symbols to the library, while these should be actually private. So, make MetaMonitorManager to be just a simple GObject holding a skeleton instance, and connect to its signals reusing most of the code with just few minor changes. https://gitlab.gnome.org/GNOME/mutter/merge_requests/395
2019-01-23 01:49:26 +00:00
monitor_manager_setup_dbus_config_handlers (manager);
g_signal_connect_object (manager->display_config, "notify::power-save-mode",
G_CALLBACK (power_save_mode_changed), manager,
G_CONNECT_SWAPPED);
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
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);
backends: Centralize panel autorotation in a DisplayConfig property Instead of having everyone check net.hadess.SensorProxy themselves, have this all controlled by the MetaOrientationManager, and proxied everywhere else via a readonly property in org.gnome.Mutter.DisplayConfig. We want to attach more complex policies here, and it seems better to centralize the handling of the autorotation feature rather than implementing policy changes all over the place. https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1311
2020-06-11 16:15:22 +00:00
g_signal_connect_object (meta_backend_get_orientation_manager (backend),
"notify::has-accelerometer",
G_CALLBACK (update_panel_orientation_managed), manager,
G_CONNECT_SWAPPED);
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);
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
cleanup: Use g_clear_signal_handler() where possible This is inspired by 98892391d764d1cf where the usage of `g_signal_handler_disconnect()` without resetting the corresponding handler id later resulted in a bug. Using `g_clear_signal_handler()` makes sure we avoid similar bugs and is almost always the better alternative. We use it for new code, let's clean up the old code to also use it. A further benefit is that it can get called even if the passed id is 0, allowing us to remove a lot of now unnessecary checks, and the fact that `g_clear_signal_handler()` checks for the right type size, forcing us to clean up all places where we used `guint` instead of `gulong`. No functional changes intended here and all changes should be trivial, thus bundled in one big commit. https://gitlab.gnome.org/GNOME/mutter/merge_requests/940
2019-11-16 00:25:52 +00:00
g_clear_signal_handler (&manager->experimental_features_changed_handler_id,
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
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;
}
MonitorManager: Use composition instead of inheriting from dbus skeleton MonitorManager was inheriting from MetaDBusDisplayConfigSkeleton, this was causing introspection to see this like a GDBus skeleton object exposing to clients methods that were not required. Also, this required us to export meta_dbus_* symbols to the library, while these should be actually private. So, make MetaMonitorManager to be just a simple GObject holding a skeleton instance, and connect to its signals reusing most of the code with just few minor changes. https://gitlab.gnome.org/GNOME/mutter/merge_requests/395
2019-01-23 01:49:26 +00:00
g_clear_object (&manager->display_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
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;
}
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;
backends: Centralize panel autorotation in a DisplayConfig property Instead of having everyone check net.hadess.SensorProxy themselves, have this all controlled by the MetaOrientationManager, and proxied everywhere else via a readonly property in org.gnome.Mutter.DisplayConfig. We want to attach more complex policies here, and it seems better to centralize the handling of the autorotation feature rather than implementing policy changes all over the place. https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1311
2020-06-11 16:15:22 +00:00
case PROP_PANEL_ORIENTATION_MANAGED:
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
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;
backends: Centralize panel autorotation in a DisplayConfig property Instead of having everyone check net.hadess.SensorProxy themselves, have this all controlled by the MetaOrientationManager, and proxied everywhere else via a readonly property in org.gnome.Mutter.DisplayConfig. We want to attach more complex policies here, and it seems better to centralize the handling of the autorotation feature rather than implementing policy changes all over the place. https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1311
2020-06-11 16:15:22 +00:00
case PROP_PANEL_ORIENTATION_MANAGED:
g_value_set_boolean (value, manager->panel_orientation_managed);
break;
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
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->read_edid = meta_monitor_manager_real_read_edid;
monitor-manager: Clean up DPMS state tracking DPMS is configured from a bit all over the place: via D-Bus, via X11 and when reading the current KMS state. Each of these places did it slightly differently, directly poking at the field in MetaMonitorManager. To make things a bit more managable, move the field into a new MetaMonitorManagerPrivate, and add helpers to get and set the current value. Prior to this, there were for example situations where the DPMS setting was changed, but without signal listeners being notified about it. https://gitlab.gnome.org/GNOME/mutter/merge_requests/506
2019-01-11 13:45:44 +00:00
klass->read_current_state = meta_monitor_manager_real_read_current_state;
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
MonitorManager: Use composition instead of inheriting from dbus skeleton MonitorManager was inheriting from MetaDBusDisplayConfigSkeleton, this was causing introspection to see this like a GDBus skeleton object exposing to clients methods that were not required. Also, this required us to export meta_dbus_* symbols to the library, while these should be actually private. So, make MetaMonitorManager to be just a simple GObject holding a skeleton instance, and connect to its signals reusing most of the code with just few minor changes. https://gitlab.gnome.org/GNOME/mutter/merge_requests/395
2019-01-23 01:49:26 +00:00
signals[MONITORS_CHANGED] =
g_signal_new ("monitors-changed",
G_TYPE_FROM_CLASS (object_class),
G_SIGNAL_RUN_LAST,
0,
NULL, NULL, NULL,
G_TYPE_NONE, 0);
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);
MonitorManager: Use composition instead of inheriting from dbus skeleton MonitorManager was inheriting from MetaDBusDisplayConfigSkeleton, this was causing introspection to see this like a GDBus skeleton object exposing to clients methods that were not required. Also, this required us to export meta_dbus_* symbols to the library, while these should be actually private. So, make MetaMonitorManager to be just a simple GObject holding a skeleton instance, and connect to its signals reusing most of the code with just few minor changes. https://gitlab.gnome.org/GNOME/mutter/merge_requests/395
2019-01-23 01:49:26 +00:00
signals[POWER_SAVE_MODE_CHANGED] =
g_signal_new ("power-save-mode-changed",
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);
backends: Centralize panel autorotation in a DisplayConfig property Instead of having everyone check net.hadess.SensorProxy themselves, have this all controlled by the MetaOrientationManager, and proxied everywhere else via a readonly property in org.gnome.Mutter.DisplayConfig. We want to attach more complex policies here, and it seems better to centralize the handling of the autorotation feature rather than implementing policy changes all over the place. https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1311
2020-06-11 16:15:22 +00:00
obj_props[PROP_PANEL_ORIENTATION_MANAGED] =
g_param_spec_boolean ("panel-orientation-managed",
"Panel orientation managed",
"Panel orientation is managed",
FALSE,
G_PARAM_READABLE |
G_PARAM_EXPLICIT_NOTIFY |
G_PARAM_STATIC_STRINGS);
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_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
}
monitor-manager: Don't use wacky physical dimensions in display name
2018-09-24 07:48:37 +00:00
gboolean
meta_monitor_has_aspect_as_size (MetaMonitor *monitor)
{
int width_mm;
int height_mm;
meta_monitor_get_physical_dimensions (monitor, &width_mm, &height_mm);
monitor-manager: Add yet another wacky "physical dimension"
2018-09-24 07:50:27 +00:00
return (width_mm == 1600 && height_mm == 900) ||
(width_mm == 1600 && height_mm == 1000) ||
(width_mm == 160 && height_mm == 90) ||
monitor-manager: Don't use wacky physical dimensions in display name
2018-09-24 07:48:37 +00:00
(width_mm == 160 && height_mm == 100) ||
(width_mm == 16 && height_mm == 9) ||
(width_mm == 16 && height_mm == 10);
}
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 ();
}
Fix builds with G_DISABLE_ASSERT Commit 25f416c13db added additional compilation warnings, including -Werror=return-type. There are several places where this results in build failures if `g_assert_not_reached()` is disabled at compile time and the compiler misses a return value. https://gitlab.gnome.org/GNOME/mutter/issues/447
2019-01-24 23:47:44 +00:00
return NULL;
monitor-manager: Add a connector-type property This is so gnome-settings-daemon
2014-12-30 00:18:24 +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
static GList *
combine_gpu_lists (MetaMonitorManager *manager,
GList * (*list_getter) (MetaGpu *gpu))
{
backend: Move GPU ownership from the monitor manager to the backend Lets work towards making MetaMonitorManager about managing monitors, and not about managing GPUs. This changes other units to keep a pointer to the backend instead of a monitor manager, in case their ownership changed, or their main usage of the monitor manager was to look up GPUs. https://gitlab.gnome.org/GNOME/mutter/issues/548 https://gitlab.gnome.org/GNOME/mutter/merge_requests/525
2019-01-11 14:35:42 +00:00
GList *gpus;
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 *list = NULL;
GList *l;
backend: Move GPU ownership from the monitor manager to the backend Lets work towards making MetaMonitorManager about managing monitors, and not about managing GPUs. This changes other units to keep a pointer to the backend instead of a monitor manager, in case their ownership changed, or their main usage of the monitor manager was to look up GPUs. https://gitlab.gnome.org/GNOME/mutter/issues/548 https://gitlab.gnome.org/GNOME/mutter/merge_requests/525
2019-01-11 14:35:42 +00:00
gpus = meta_backend_get_gpus (manager->backend);
for (l = gpus; l; l = l->next)
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;
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,
MonitorManager: Use composition instead of inheriting from dbus skeleton MonitorManager was inheriting from MetaDBusDisplayConfigSkeleton, this was causing introspection to see this like a GDBus skeleton object exposing to clients methods that were not required. Also, this required us to export meta_dbus_* symbols to the library, while these should be actually private. So, make MetaMonitorManager to be just a simple GObject holding a skeleton instance, and connect to its signals reusing most of the code with just few minor changes. https://gitlab.gnome.org/GNOME/mutter/merge_requests/395
2019-01-23 01:49:26 +00:00
GDBusMethodInvocation *invocation,
MetaMonitorManager *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
{
MonitorManager: Use composition instead of inheriting from dbus skeleton MonitorManager was inheriting from MetaDBusDisplayConfigSkeleton, this was causing introspection to see this like a GDBus skeleton object exposing to clients methods that were not required. Also, this required us to export meta_dbus_* symbols to the library, while these should be actually private. So, make MetaMonitorManager to be just a simple GObject holding a skeleton instance, and connect to its signals reusing most of the code with just few minor changes. https://gitlab.gnome.org/GNOME/mutter/merge_requests/395
2019-01-23 01:49:26 +00:00
MetaMonitorManagerClass *manager_class = META_MONITOR_MANAGER_GET_CLASS (manager);
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;
crtc: Move MetaCrtcConfig field to instance private Last piece before MetCrtc can be made a derivable type. https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1287
2020-02-26 09:37:53 +00:00
const MetaCrtcConfig *crtc_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
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++)
crtc: Move all_transforms field into instance private Now set as a property during construction. Only actually set by the Xrandr backend, as it's the only one currently not supporting all transforms, which is the default. While at it, move the 'ALL_TRANFORMS' macro to meta-monitor-tranforms.h. https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1287
2020-02-26 09:14:52 +00:00
{
if (meta_crtc_get_all_transforms (crtc) & (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
crtc: Move MetaCrtcConfig field to instance private Last piece before MetCrtc can be made a derivable type. https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1287
2020-02-26 09:37:53 +00:00
crtc_config = meta_crtc_get_config (crtc);
crtc: Move configured state to separate struct To make it more reliable to distinguish between values that are read from the backend implementation (which is likely to be irrelevant for anything but the backend implementation), split out those values (e.g. layout). This changes the meaning of what was MetaCrtc::rect, to a MetaCrtcConfig::layout which is the layout the CRTC has in the global coordinate space. https://gitlab.gnome.org/GNOME/mutter/merge_requests/1042
2020-01-14 21:34:44 +00:00
if (crtc_config)
{
int current_mode_index;
current_mode_index = g_list_index (combined_modes, crtc_config->mode);
g_variant_builder_add (&crtc_builder, "(uxiiiiiuaua{sv})",
i, /* ID */
crtc: Move CRTC id field into instance private Set during construction, retrieved using helper. https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1287
2020-02-25 10:34:43 +00:00
(int64_t) meta_crtc_get_id (crtc),
crtc: Move configured state to separate struct To make it more reliable to distinguish between values that are read from the backend implementation (which is likely to be irrelevant for anything but the backend implementation), split out those values (e.g. layout). This changes the meaning of what was MetaCrtc::rect, to a MetaCrtcConfig::layout which is the layout the CRTC has in the global coordinate space. https://gitlab.gnome.org/GNOME/mutter/merge_requests/1042
2020-01-14 21:34:44 +00:00
(int) roundf (crtc_config->layout.origin.x),
(int) roundf (crtc_config->layout.origin.y),
(int) roundf (crtc_config->layout.size.width),
(int) roundf (crtc_config->layout.size.height),
current_mode_index,
(uint32_t) crtc_config->transform,
&transforms,
NULL /* properties */);
}
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
crtc: Move configured state to separate struct To make it more reliable to distinguish between values that are read from the backend implementation (which is likely to be irrelevant for anything but the backend implementation), split out those values (e.g. layout). This changes the meaning of what was MetaCrtc::rect, to a MetaCrtcConfig::layout which is the layout the CRTC has in the global coordinate space. https://gitlab.gnome.org/GNOME/mutter/merge_requests/1042
2020-01-14 21:34:44 +00:00
{
g_variant_builder_add (&crtc_builder, "(uxiiiiiuaua{sv})",
i, /* ID */
crtc: Move CRTC id field into instance private Set during construction, retrieved using helper. https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1287
2020-02-25 10:34:43 +00:00
(int64_t) meta_crtc_get_id (crtc),
crtc: Move configured state to separate struct To make it more reliable to distinguish between values that are read from the backend implementation (which is likely to be irrelevant for anything but the backend implementation), split out those values (e.g. layout). This changes the meaning of what was MetaCrtc::rect, to a MetaCrtcConfig::layout which is the layout the CRTC has in the global coordinate space. https://gitlab.gnome.org/GNOME/mutter/merge_requests/1042
2020-01-14 21:34:44 +00:00
0,
0,
0,
0,
-1,
(uint32_t) META_MONITOR_TRANSFORM_NORMAL,
&transforms,
NULL /* properties */);
}
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: 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;
output: Move output info to MetaOutputInfo struct The output info is established during construction and will stay the same for the lifetime of the MetaOutput object. Moving it out of the main struct enables us to eventually clean up the MetaOutput type inheritence to use proper GObject types. https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1287
2020-02-26 08:45:07 +00:00
const MetaOutputInfo *output_info = meta_output_get_info (output);
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;
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;
output: Move output info to MetaOutputInfo struct The output info is established during construction and will stay the same for the lifetime of the MetaOutput object. Moving it out of the main struct enables us to eventually clean up the MetaOutput type inheritence to use proper GObject types. https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1287
2020-02-26 08:45:07 +00:00
int backlight;
int min_backlight_step;
gboolean is_primary;
gboolean is_presentation;
const char * connector_type_name;
gboolean is_underscanning;
gboolean 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
g_variant_builder_init (&crtcs, G_VARIANT_TYPE ("au"));
output: Move output info to MetaOutputInfo struct The output info is established during construction and will stay the same for the lifetime of the MetaOutput object. Moving it out of the main struct enables us to eventually clean up the MetaOutput type inheritence to use proper GObject types. https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1287
2020-02-26 08:45:07 +00:00
for (j = 0; j < output_info->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
{
output: Move output info to MetaOutputInfo struct The output info is established during construction and will stay the same for the lifetime of the MetaOutput object. Moving it out of the main struct enables us to eventually clean up the MetaOutput type inheritence to use proper GObject types. https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1287
2020-02-26 08:45:07 +00:00
MetaCrtc *possible_crtc = output_info->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
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"));
output: Move output info to MetaOutputInfo struct The output info is established during construction and will stay the same for the lifetime of the MetaOutput object. Moving it out of the main struct enables us to eventually clean up the MetaOutput type inheritence to use proper GObject types. https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1287
2020-02-26 08:45:07 +00:00
for (j = 0; j < output_info->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;
output: Move output info to MetaOutputInfo struct The output info is established during construction and will stay the same for the lifetime of the MetaOutput object. Moving it out of the main struct enables us to eventually clean up the MetaOutput type inheritence to use proper GObject types. https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1287
2020-02-26 08:45:07 +00:00
mode_index = g_list_index (combined_modes, output_info->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"));
output: Move output info to MetaOutputInfo struct The output info is established during construction and will stay the same for the lifetime of the MetaOutput object. Moving it out of the main struct enables us to eventually clean up the MetaOutput type inheritence to use proper GObject types. https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1287
2020-02-26 08:45:07 +00:00
for (j = 0; j < output_info->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,
output: Move output info to MetaOutputInfo struct The output info is established during construction and will stay the same for the lifetime of the MetaOutput object. Moving it out of the main struct enables us to eventually clean up the MetaOutput type inheritence to use proper GObject types. https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1287
2020-02-26 08:45:07 +00:00
output_info->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
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
output: Move output info to MetaOutputInfo struct The output info is established during construction and will stay the same for the lifetime of the MetaOutput object. Moving it out of the main struct enables us to eventually clean up the MetaOutput type inheritence to use proper GObject types. https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1287
2020-02-26 08:45:07 +00:00
backlight = meta_output_get_backlight (output);
min_backlight_step =
output_info->backlight_max - output_info->backlight_min
? 100 / (output_info->backlight_max - output_info->backlight_min)
: -1;
is_primary = meta_output_is_primary (output);
is_presentation = meta_output_is_presentation (output);
is_underscanning = meta_output_is_underscanning (output);
connector_type_name = get_connector_type_name (output_info->connector_type);
supports_underscanning = output_info->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
g_variant_builder_init (&properties, G_VARIANT_TYPE ("a{sv}"));
g_variant_builder_add (&properties, "{sv}", "vendor",
output: Move output info to MetaOutputInfo struct The output info is established during construction and will stay the same for the lifetime of the MetaOutput object. Moving it out of the main struct enables us to eventually clean up the MetaOutput type inheritence to use proper GObject types. https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1287
2020-02-26 08:45:07 +00:00
g_variant_new_string (output_info->vendor));
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}", "product",
output: Move output info to MetaOutputInfo struct The output info is established during construction and will stay the same for the lifetime of the MetaOutput object. Moving it out of the main struct enables us to eventually clean up the MetaOutput type inheritence to use proper GObject types. https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1287
2020-02-26 08:45:07 +00:00
g_variant_new_string (output_info->product));
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}", "serial",
output: Move output info to MetaOutputInfo struct The output info is established during construction and will stay the same for the lifetime of the MetaOutput object. Moving it out of the main struct enables us to eventually clean up the MetaOutput type inheritence to use proper GObject types. https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1287
2020-02-26 08:45:07 +00:00
g_variant_new_string (output_info->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",
output: Move output info to MetaOutputInfo struct The output info is established during construction and will stay the same for the lifetime of the MetaOutput object. Moving it out of the main struct enables us to eventually clean up the MetaOutput type inheritence to use proper GObject types. https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1287
2020-02-26 08:45:07 +00:00
g_variant_new_int32 (output_info->width_mm));
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}", "height-mm",
output: Move output info to MetaOutputInfo struct The output info is established during construction and will stay the same for the lifetime of the MetaOutput object. Moving it out of the main struct enables us to eventually clean up the MetaOutput type inheritence to use proper GObject types. https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1287
2020-02-26 08:45:07 +00:00
g_variant_new_int32 (output_info->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",
output: Move output info to MetaOutputInfo struct The output info is established during construction and will stay the same for the lifetime of the MetaOutput object. Moving it out of the main struct enables us to eventually clean up the MetaOutput type inheritence to use proper GObject types. https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1287
2020-02-26 08:45:07 +00:00
g_variant_new_string (output_info->name));
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",
output: Move output info to MetaOutputInfo struct The output info is established during construction and will stay the same for the lifetime of the MetaOutput object. Moving it out of the main struct enables us to eventually clean up the MetaOutput type inheritence to use proper GObject types. https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1287
2020-02-26 08:45:07 +00:00
g_variant_new_int32 (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",
output: Move output info to MetaOutputInfo struct The output info is established during construction and will stay the same for the lifetime of the MetaOutput object. Moving it out of the main struct enables us to eventually clean up the MetaOutput type inheritence to use proper GObject types. https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1287
2020-02-26 08:45:07 +00:00
g_variant_new_int32 (min_backlight_step));
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",
output: Move output info to MetaOutputInfo struct The output info is established during construction and will stay the same for the lifetime of the MetaOutput object. Moving it out of the main struct enables us to eventually clean up the MetaOutput type inheritence to use proper GObject types. https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1287
2020-02-26 08:45:07 +00:00
g_variant_new_boolean (is_primary));
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}", "presentation",
output: Move output info to MetaOutputInfo struct The output info is established during construction and will stay the same for the lifetime of the MetaOutput object. Moving it out of the main struct enables us to eventually clean up the MetaOutput type inheritence to use proper GObject types. https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1287
2020-02-26 08:45:07 +00:00
g_variant_new_boolean (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",
output: Move output info to MetaOutputInfo struct The output info is established during construction and will stay the same for the lifetime of the MetaOutput object. Moving it out of the main struct enables us to eventually clean up the MetaOutput type inheritence to use proper GObject types. https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1287
2020-02-26 08:45:07 +00:00
g_variant_new_string (connector_type_name));
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",
output: Move output info to MetaOutputInfo struct The output info is established during construction and will stay the same for the lifetime of the MetaOutput object. Moving it out of the main struct enables us to eventually clean up the MetaOutput type inheritence to use proper GObject types. https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1287
2020-02-26 08:45:07 +00:00
g_variant_new_boolean (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",
output: Move output info to MetaOutputInfo struct The output info is established during construction and will stay the same for the lifetime of the MetaOutput object. Moving it out of the main struct enables us to eventually clean up the MetaOutput type inheritence to use proper GObject types. https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1287
2020-02-26 08:45:07 +00:00
g_variant_new_boolean (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
monitor-manager: remove get_edid_file() vfunc It wasn't implemented by any subclass, it's not provided by DRM either. And even if a subclass were to have only a file available, it could read it into a GBytes as well and just use `read_edid()`. Found this while working on !269.
2018-11-26 13:19:55 +00:00
edid = manager_class->read_edid (manager, output);
if (edid)
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
{
monitor-manager: remove get_edid_file() vfunc It wasn't implemented by any subclass, it's not provided by DRM either. And even if a subclass were to have only a file available, it could read it into a GBytes as well and just use `read_edid()`. Found this while working on !269.
2018-11-26 13:19:55 +00:00
g_variant_builder_add (&properties, "{sv}", "edid",
g_variant_new_from_bytes (G_VARIANT_TYPE ("ay"),
edid, TRUE));
g_bytes_unref (edid);
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
}
output: Move output info to MetaOutputInfo struct The output info is established during construction and will stay the same for the lifetime of the MetaOutput object. Moving it out of the main struct enables us to eventually clean up the MetaOutput type inheritence to use proper GObject types. https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1287
2020-02-26 08:45:07 +00:00
if (output_info->tile_info.group_id)
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
{
output: Move output info to MetaOutputInfo struct The output info is established during construction and will stay the same for the lifetime of the MetaOutput object. Moving it out of the main struct enables us to eventually clean up the MetaOutput type inheritence to use proper GObject types. https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1287
2020-02-26 08:45:07 +00:00
GVariant *tile_variant;
tile_variant = g_variant_new ("(uuuuuuuu)",
output_info->tile_info.group_id,
output_info->tile_info.flags,
output_info->tile_info.max_h_tiles,
output_info->tile_info.max_v_tiles,
output_info->tile_info.loc_h_tile,
output_info->tile_info.loc_v_tile,
output_info->tile_info.tile_w,
output_info->tile_info.tile_h);
g_variant_builder_add (&properties, "{sv}", "tile", tile_variant);
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
}
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 */
output: Move winsys_id into instance private and rename to id https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1287
2020-02-25 15:13:52 +00:00
meta_output_get_id (output),
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: Move output info to MetaOutputInfo struct The output info is established during construction and will stay the same for the lifetime of the MetaOutput object. Moving it out of the main struct enables us to eventually clean up the MetaOutput type inheritence to use proper GObject types. https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1287
2020-02-26 08:45:07 +00:00
meta_output_get_name (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
&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;
crtc-mode: Move away fields from public MetaCrtcMode struct The ID and name are just moved into the instance private, while the rest is moved to a `MetaCrtcModeInfo` struct which is used during construction and retrieved via a getter. Opens up the possibility to add actual sub types. https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1287
2020-02-26 23:08:58 +00:00
const MetaCrtcModeInfo *crtc_mode_info =
cleanup: Remove duplicate semicolons in C code No functional change, it just hurts my eyes when reading the code. https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1385
2020-07-28 08:11:07 +00:00
meta_crtc_mode_get_info (mode);
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 */
crtc-mode: Move away fields from public MetaCrtcMode struct The ID and name are just moved into the instance private, while the rest is moved to a `MetaCrtcModeInfo` struct which is used during construction and retrieved via a getter. Opens up the possibility to add actual sub types. https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1287
2020-02-26 23:08:58 +00:00
(int64_t) meta_crtc_mode_get_id (mode),
(uint32_t) crtc_mode_info->width,
(uint32_t) crtc_mode_info->height,
(double) crtc_mode_info->refresh_rate,
(uint32_t) crtc_mode_info->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)
{
cleanup: Use g_clear_handle_id() for g_source_remove() It makes sure we do not forget to zero the id and lets us avoid zero checks before. We use it for all new code, lets clean up the existing code base. https://gitlab.gnome.org/GNOME/mutter/merge_requests/947
2019-11-21 23:25:30 +00:00
g_clear_handle_id (&manager->persistent_timeout_id, 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
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,
MonitorManager: Use composition instead of inheriting from dbus skeleton MonitorManager was inheriting from MetaDBusDisplayConfigSkeleton, this was causing introspection to see this like a GDBus skeleton object exposing to clients methods that were not required. Also, this required us to export meta_dbus_* symbols to the library, while these should be actually private. So, make MetaMonitorManager to be just a simple GObject holding a skeleton instance, and connect to its signals reusing most of the code with just few minor changes. https://gitlab.gnome.org/GNOME/mutter/merge_requests/395
2019-01-23 01:49:26 +00:00
GDBusMethodInvocation *invocation,
MetaMonitorManager *manager)
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 '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;
monitor-manager: Use `meta_monitor_get_display_name()` API Use the new monitor's `meta_monitor_get_display_name()` instead of rebuilding the display name for each DBUS request. https://gitlab.gnome.org/GNOME/mutter/issues/645
2019-06-26 09:40:00 +00:00
const 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));
monitor-manager: Use `meta_monitor_get_display_name()` API Use the new monitor's `meta_monitor_get_display_name()` instead of rebuilding the display name for each DBUS request. https://gitlab.gnome.org/GNOME/mutter/issues/645
2019-06-26 09:40:00 +00:00
display_name = meta_monitor_get_display_name (monitor);
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
g_variant_builder_add (&monitor_properties_builder, "{sv}",
"display-name",
monitor-manager: Use `meta_monitor_get_display_name()` API Use the new monitor's `meta_monitor_get_display_name()` instead of rebuilding the display name for each DBUS request. https://gitlab.gnome.org/GNOME/mutter/issues/645
2019-06-26 09:40:00 +00:00
g_variant_new_string (display_name));
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
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);
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;
monitor-manager: check for underscan setting validity upfront Instead of doing a roundtrip to the X server before setting it, rely on the previous value fetched before the configuration was sent over DBus. This matches the argument check we already do elsewhere, and will allow us to more easily add an additional condition to determine if underscan is supported. https://gitlab.gnome.org/GNOME/mutter/merge_requests/673
2019-07-04 19:52:30 +00:00
gboolean set_underscanning = 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
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;
}
monitor-manager: check for underscan setting validity upfront Instead of doing a roundtrip to the X server before setting it, rely on the previous value fetched before the configuration was sent over DBus. This matches the argument check we already do elsewhere, and will allow us to more easily add an additional condition to determine if underscan is supported. https://gitlab.gnome.org/GNOME/mutter/merge_requests/673
2019-07-04 19:52:30 +00:00
set_underscanning =
g_variant_lookup (properties_variant, "underscanning", "b",
&enable_underscanning);
if (set_underscanning)
{
if (enable_underscanning && !meta_monitor_supports_underscanning (monitor))
{
g_set_error (error, G_IO_ERROR, G_IO_ERROR_FAILED,
"Underscanning requested but unsupported");
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
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,
MonitorManager: Use composition instead of inheriting from dbus skeleton MonitorManager was inheriting from MetaDBusDisplayConfigSkeleton, this was causing introspection to see this like a GDBus skeleton object exposing to clients methods that were not required. Also, this required us to export meta_dbus_* symbols to the library, while these should be actually private. So, make MetaMonitorManager to be just a simple GObject holding a skeleton instance, and connect to its signals reusing most of the code with just few minor changes. https://gitlab.gnome.org/GNOME/mutter/merge_requests/395
2019-01-23 01:49:26 +00:00
GVariant *properties_variant,
MetaMonitorManager *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
{
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: Use composition instead of inheriting from dbus skeleton MonitorManager was inheriting from MetaDBusDisplayConfigSkeleton, this was causing introspection to see this like a GDBus skeleton object exposing to clients methods that were not required. Also, this required us to export meta_dbus_* symbols to the library, while these should be actually private. So, make MetaMonitorManager to be just a simple GObject holding a skeleton instance, and connect to its signals reusing most of the code with just few minor changes. https://gitlab.gnome.org/GNOME/mutter/merge_requests/395
2019-01-23 01:49:26 +00:00
gint value,
MetaMonitorManager *manager)
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
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;
output: Move output info to MetaOutputInfo struct The output info is established during construction and will stay the same for the lifetime of the MetaOutput object. Moving it out of the main struct enables us to eventually clean up the MetaOutput type inheritence to use proper GObject types. https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1287
2020-02-26 08:45:07 +00:00
const MetaOutputInfo *output_info;
output: Move configureable state to instance private That is is_presentation, is_primary, is_underscanning and backlight. The first three are set during CRTC assignment as they are only valid when active. The other is set separately, as it is untied to monitor configuration. https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1287
2020-02-25 17:37:21 +00:00
int new_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
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;
}
output: Move output info to MetaOutputInfo struct The output info is established during construction and will stay the same for the lifetime of the MetaOutput object. Moving it out of the main struct enables us to eventually clean up the MetaOutput type inheritence to use proper GObject types. https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1287
2020-02-26 08:45:07 +00:00
output_info = meta_output_get_info (output);
output: Move configureable state to instance private That is is_presentation, is_primary, is_underscanning and backlight. The first three are set during CRTC assignment as they are only valid when active. The other is set separately, as it is untied to monitor configuration. https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1287
2020-02-25 17:37:21 +00:00
if (meta_output_get_backlight (output) == -1 ||
output: Move output info to MetaOutputInfo struct The output info is established during construction and will stay the same for the lifetime of the MetaOutput object. Moving it out of the main struct enables us to eventually clean up the MetaOutput type inheritence to use proper GObject types. https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1287
2020-02-26 08:45:07 +00:00
(output_info->backlight_min == 0 &&
output_info->backlight_max == 0))
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,
"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
output: Move configureable state to instance private That is is_presentation, is_primary, is_underscanning and backlight. The first three are set during CRTC assignment as they are only valid when active. The other is set separately, as it is untied to monitor configuration. https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1287
2020-02-25 17:37:21 +00:00
new_backlight = meta_output_get_backlight (output);
meta_dbus_display_config_complete_change_backlight (skeleton,
invocation,
new_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,
MonitorManager: Use composition instead of inheriting from dbus skeleton MonitorManager was inheriting from MetaDBusDisplayConfigSkeleton, this was causing introspection to see this like a GDBus skeleton object exposing to clients methods that were not required. Also, this required us to export meta_dbus_* symbols to the library, while these should be actually private. So, make MetaMonitorManager to be just a simple GObject holding a skeleton instance, and connect to its signals reusing most of the code with just few minor changes. https://gitlab.gnome.org/GNOME/mutter/merge_requests/395
2019-01-23 01:49:26 +00:00
guint crtc_id,
MetaMonitorManager *manager)
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
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,
MonitorManager: Use composition instead of inheriting from dbus skeleton MonitorManager was inheriting from MetaDBusDisplayConfigSkeleton, this was causing introspection to see this like a GDBus skeleton object exposing to clients methods that were not required. Also, this required us to export meta_dbus_* symbols to the library, while these should be actually private. So, make MetaMonitorManager to be just a simple GObject holding a skeleton instance, and connect to its signals reusing most of the code with just few minor changes. https://gitlab.gnome.org/GNOME/mutter/merge_requests/395
2019-01-23 01:49:26 +00:00
GVariant *blue_v,
MetaMonitorManager *manager)
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
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
MonitorManager: Use composition instead of inheriting from dbus skeleton MonitorManager was inheriting from MetaDBusDisplayConfigSkeleton, this was causing introspection to see this like a GDBus skeleton object exposing to clients methods that were not required. Also, this required us to export meta_dbus_* symbols to the library, while these should be actually private. So, make MetaMonitorManager to be just a simple GObject holding a skeleton instance, and connect to its signals reusing most of the code with just few minor changes. https://gitlab.gnome.org/GNOME/mutter/merge_requests/395
2019-01-23 01:49:26 +00:00
monitor_manager_setup_dbus_config_handlers (MetaMonitorManager *manager)
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
{
MonitorManager: Use composition instead of inheriting from dbus skeleton MonitorManager was inheriting from MetaDBusDisplayConfigSkeleton, this was causing introspection to see this like a GDBus skeleton object exposing to clients methods that were not required. Also, this required us to export meta_dbus_* symbols to the library, while these should be actually private. So, make MetaMonitorManager to be just a simple GObject holding a skeleton instance, and connect to its signals reusing most of the code with just few minor changes. https://gitlab.gnome.org/GNOME/mutter/merge_requests/395
2019-01-23 01:49:26 +00:00
g_signal_connect_object (manager->display_config, "handle-get-resources",
G_CALLBACK (meta_monitor_manager_handle_get_resources),
manager, 0);
g_signal_connect_object (manager->display_config, "handle-change-backlight",
G_CALLBACK (meta_monitor_manager_handle_change_backlight),
manager, 0);
g_signal_connect_object (manager->display_config, "handle-get-crtc-gamma",
G_CALLBACK (meta_monitor_manager_handle_get_crtc_gamma),
manager, 0);
g_signal_connect_object (manager->display_config, "handle-set-crtc-gamma",
G_CALLBACK (meta_monitor_manager_handle_set_crtc_gamma),
manager, 0);
g_signal_connect_object (manager->display_config, "handle-get-current-state",
G_CALLBACK (meta_monitor_manager_handle_get_current_state),
manager, 0);
g_signal_connect_object (manager->display_config, "handle-apply-monitors-config",
G_CALLBACK (meta_monitor_manager_handle_apply_monitors_config),
manager, 0);
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: Use composition instead of inheriting from dbus skeleton MonitorManager was inheriting from MetaDBusDisplayConfigSkeleton, this was causing introspection to see this like a GDBus skeleton object exposing to clients methods that were not required. Also, this required us to export meta_dbus_* symbols to the library, while these should be actually private. So, make MetaMonitorManager to be just a simple GObject holding a skeleton instance, and connect to its signals reusing most of the code with just few minor changes. https://gitlab.gnome.org/GNOME/mutter/merge_requests/395
2019-01-23 01:49:26 +00:00
g_dbus_interface_skeleton_export (G_DBUS_INTERFACE_SKELETON (manager->display_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
connection,
"/org/gnome/Mutter/DisplayConfig",
NULL);
}
static void
on_name_acquired (GDBusConnection *connection,
const char *name,
gpointer user_data)
{
Make meta_* logging utilities not require line break Unlike g_* logging utilities, the meta_* counterparts behave like odd printf() functions. Lets change that so they fit better into how logging is done everywhere else. https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1466
2020-10-02 15:47:22 +00:00
meta_topic (META_DEBUG_DBUS, "Acquired name %s", 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
}
static void
on_name_lost (GDBusConnection *connection,
const char *name,
gpointer user_data)
{
Make meta_* logging utilities not require line break Unlike g_* logging utilities, the meta_* counterparts behave like odd printf() functions. Lets change that so they fit better into how logging is done everywhere else. https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1466
2020-10-02 15:47:22 +00:00
meta_topic (META_DEBUG_DBUS, "Lost or failed to acquire name %s", 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
}
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
}
Add some gtk-doc comments.
2018-10-19 07:15:54 +00:00
/**
* meta_monitor_manager_get_num_logical_monitors:
* @manager: A #MetaMonitorManager object
*
* Returns the number of #MetaLogicalMonitor<!-- -->s (can be 0 in case of a
* headless setup).
*
* Returns: the total number of #MetaLogicalMonitor<!-- -->s.
*/
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
}
Add some gtk-doc comments.
2018-10-19 07:15:54 +00:00
/**
* meta_monitor_manager_get_logical_monitors:
* @manager: A #MetaMonitorManager object
*
* Returns the list of #MetaLogicalMonitor<!-- -->s that is handled. See also
* meta_monitor_manager_get_num_logical_monitors() if you only need the size of
* the list.
*
* Returns: (transfer none) (nullable): the list of logical monitors.
*/
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;
}
Add some gtk-doc comments.
2018-10-19 07:15:54 +00:00
/**
* meta_monitor_manager_get_primary_monitor:
* @manager: A #MetaMonitorManager object
*
* Returns the primary monitor. This can be %NULL (e.g. when running headless).
*
* Returns: (transfer none) (nullable): The primary #MetaMonitor, or %NULL if
* none.
*/
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);
}
Add some gtk-doc comments.
2018-10-19 07:15:54 +00:00
/**
* meta_monitor_manager_get_laptop_panel:
* @manager: A #MetaMonitorManager object
*
* Returns the #MetaMonitor that represents the built-in laptop panel (if
* applicable).
*
* Returns: (transfer none) (nullable): The laptop panel, or %NULL if none.
*/
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;
}
Add some gtk-doc comments.
2018-10-19 07:15:54 +00:00
/**
* meta_monitor_manager_get_logical_monitor_at:
* @manager: A #MetaMonitorManager object
* @x: The x-coordinate
* @y: The y-coordinate
*
* Finds the #MetaLogicalMonitor at the given @x and @y coordinates in the
* total layout.
*
* Returns: (transfer none) (nullable): The #MetaLogicalMonitor at the given
* point, or %NULL if none.
*/
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;
meta: Add META namespace to macros To silence warnings during GIR generation. https://gitlab.gnome.org/GNOME/mutter/merge_requests/822
2019-10-02 18:23:41 +00:00
if (META_POINT_IN_RECT (x, y, logical_monitor->rect))
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 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;
}
Add some gtk-doc comments.
2018-10-19 07:15:54 +00:00
/**
* meta_monitor_manager_get_logical_monitor_from_rect:
* @manager: A #MetaMonitorManager object
* @rect: The rectangle
*
* Finds the #MetaLogicalMonitor which has the largest area in common with the
* given @rect in the total layout.
*
* Returns: (transfer none) (nullable): The #MetaLogicalMonitor which
* corresponds the most to the given @rect, or %NULL if none.
*/
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;
}
Add some gtk-doc comments.
2018-10-19 07:15:54 +00:00
/**
* meta_monitor_manager_get_monitors:
* @manager: A #MetaMonitorManager object
*
* Returns the list of #MetaMonitor<!-- -->s. See also
* meta_monitor_manager_get_logical_monitors() for a list of
* #MetaLogicalMonitor<!-- -->s.
*
* Returns: (transfer none) (nullable): the list of #MetaMonitor<!-- -->s.
*/
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;
}
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: Clean up DPMS state tracking DPMS is configured from a bit all over the place: via D-Bus, via X11 and when reading the current KMS state. Each of these places did it slightly differently, directly poking at the field in MetaMonitorManager. To make things a bit more managable, move the field into a new MetaMonitorManagerPrivate, and add helpers to get and set the current value. Prior to this, there were for example situations where the DPMS setting was changed, but without signal listeners being notified about it. https://gitlab.gnome.org/GNOME/mutter/merge_requests/506
2019-01-11 13:45:44 +00:00
MetaPowerSave
meta_monitor_manager_get_power_save_mode (MetaMonitorManager *manager)
{
MetaMonitorManagerPrivate *priv =
meta_monitor_manager_get_instance_private (manager);
return priv->power_save_mode;
}
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)
{
backend: Move GPU ownership from the monitor manager to the backend Lets work towards making MetaMonitorManager about managing monitors, and not about managing GPUs. This changes other units to keep a pointer to the backend instead of a monitor manager, in case their ownership changed, or their main usage of the monitor manager was to look up GPUs. https://gitlab.gnome.org/GNOME/mutter/issues/548 https://gitlab.gnome.org/GNOME/mutter/merge_requests/525
2019-01-11 14:35:42 +00:00
GList *gpus;
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;
}
backend: Move GPU ownership from the monitor manager to the backend Lets work towards making MetaMonitorManager about managing monitors, and not about managing GPUs. This changes other units to keep a pointer to the backend instead of a monitor manager, in case their ownership changed, or their main usage of the monitor manager was to look up GPUs. https://gitlab.gnome.org/GNOME/mutter/issues/548 https://gitlab.gnome.org/GNOME/mutter/merge_requests/525
2019-01-11 14:35:42 +00:00
gpus = meta_backend_get_gpus (manager->backend);
for (l = 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;
output: Move output info to MetaOutputInfo struct The output info is established during construction and will stay the same for the lifetime of the MetaOutput object. Moving it out of the main struct enables us to eventually clean up the MetaOutput type inheritence to use proper GObject types. https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1287
2020-02-26 08:45:07 +00:00
const MetaOutputInfo *output_info = meta_output_get_info (output);
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: Move output info to MetaOutputInfo struct The output info is established during construction and will stay the same for the lifetime of the MetaOutput object. Moving it out of the main struct enables us to eventually clean up the MetaOutput type inheritence to use proper GObject types. https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1287
2020-02-26 08:45:07 +00:00
if (output_info->tile_info.group_id)
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 (is_main_tiled_monitor_output (output))
{
MetaMonitorTiled *monitor_tiled;
backend: Move GPU ownership from the monitor manager to the backend Lets work towards making MetaMonitorManager about managing monitors, and not about managing GPUs. This changes other units to keep a pointer to the backend instead of a monitor manager, in case their ownership changed, or their main usage of the monitor manager was to look up GPUs. https://gitlab.gnome.org/GNOME/mutter/issues/548 https://gitlab.gnome.org/GNOME/mutter/merge_requests/525
2019-01-11 14:35:42 +00:00
monitor_tiled = meta_monitor_tiled_new (gpu, manager, output);
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->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
monitor: Add display name The display name is being used by the monitor manager to expose to name to the DBUS API. It is being rebuilt each time, so instead build the displa yname once for the monitor and keep it around, with an API to retrieve it, so that we can reuse it in preparation of xdg-output v2 support. https://gitlab.gnome.org/GNOME/mutter/issues/645
2019-06-26 09:24:19 +00:00
monitor_normal = meta_monitor_normal_new (gpu, manager, 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: Clean up DPMS state tracking DPMS is configured from a bit all over the place: via D-Bus, via X11 and when reading the current KMS state. Each of these places did it slightly differently, directly poking at the field in MetaMonitorManager. To make things a bit more managable, move the field into a new MetaMonitorManagerPrivate, and add helpers to get and set the current value. Prior to this, there were for example situations where the DPMS setting was changed, but without signal listeners being notified about it. https://gitlab.gnome.org/GNOME/mutter/merge_requests/506
2019-01-11 13:45:44 +00:00
static void
meta_monitor_manager_real_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++;
backend: Move GPU ownership from the monitor manager to the backend Lets work towards making MetaMonitorManager about managing monitors, and not about managing GPUs. This changes other units to keep a pointer to the backend instead of a monitor manager, in case their ownership changed, or their main usage of the monitor manager was to look up GPUs. https://gitlab.gnome.org/GNOME/mutter/issues/548 https://gitlab.gnome.org/GNOME/mutter/merge_requests/525
2019-01-11 14:35:42 +00:00
for (l = meta_backend_get_gpus (manager->backend); l; l = l->next)
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;
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: Clean up DPMS state tracking DPMS is configured from a bit all over the place: via D-Bus, via X11 and when reading the current KMS state. Each of these places did it slightly differently, directly poking at the field in MetaMonitorManager. To make things a bit more managable, move the field into a new MetaMonitorManagerPrivate, and add helpers to get and set the current value. Prior to this, there were for example situations where the DPMS setting was changed, but without signal listeners being notified about it. https://gitlab.gnome.org/GNOME/mutter/merge_requests/506
2019-01-11 13:45:44 +00:00
void
meta_monitor_manager_read_current_state (MetaMonitorManager *manager)
{
MetaMonitorManagerClass *manager_class =
META_MONITOR_MANAGER_GET_CLASS (manager);
manager_class->read_current_state (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_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);
MonitorManager: Use composition instead of inheriting from dbus skeleton MonitorManager was inheriting from MetaDBusDisplayConfigSkeleton, this was causing introspection to see this like a GDBus skeleton object exposing to clients methods that were not required. Also, this required us to export meta_dbus_* symbols to the library, while these should be actually private. So, make MetaMonitorManager to be just a simple GObject holding a skeleton instance, and connect to its signals reusing most of the code with just few minor changes. https://gitlab.gnome.org/GNOME/mutter/merge_requests/395
2019-01-23 01:49:26 +00:00
g_signal_emit (manager, signals[MONITORS_CHANGED], 0);
meta_dbus_display_config_emit_monitors_changed (manager->display_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
}
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
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;
}
Add some gtk-doc comments.
2018-10-19 07:15:54 +00:00
/**
* meta_monitor_manager_get_is_builtin_display_on:
* @manager: A #MetaMonitorManager object
*
* Returns whether the built-in display (i.e. a laptop panel) is turned on.
*/
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;
}
monitor-manager: Add `get_vendor_name` API The monitor manager keeps the list of PnP Ids, add a new API to get the vendor name from a given PnP ID. https://gitlab.gnome.org/GNOME/mutter/issues/645
2019-06-26 10:29:22 +00:00
/**
* meta_monitor_manager_get_vendor_name:
* @manager: A #MetaMonitorManager object
* @vendor: the PNP ID of the monitor
*
* Find the full vendor name from the given monitor PNP ID.
*
* Returns: (transfer full): A string containing the vendor name,
* or NULL when not found.
*/
char *
meta_monitor_manager_get_vendor_name (MetaMonitorManager *manager,
const char *vendor)
{
if (!manager->pnp_ids)
manager->pnp_ids = gnome_pnp_ids_new ();
return gnome_pnp_ids_get_pnp_id (manager->pnp_ids, vendor);
}
backends: Centralize panel autorotation in a DisplayConfig property Instead of having everyone check net.hadess.SensorProxy themselves, have this all controlled by the MetaOrientationManager, and proxied everywhere else via a readonly property in org.gnome.Mutter.DisplayConfig. We want to attach more complex policies here, and it seems better to centralize the handling of the autorotation feature rather than implementing policy changes all over the place. https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1311
2020-06-11 16:15:22 +00:00
gboolean
meta_monitor_manager_get_panel_orientation_managed (MetaMonitorManager *manager)
{
g_return_val_if_fail (META_IS_MONITOR_MANAGER (manager), FALSE);
return manager->panel_orientation_managed;
}
backends: Hook ClutterSeat::touch-mode to PanelOrientationManaged We only want the panel autorotation to happen if the laptop has an accelerometer, and is in tablet mode. Regular laptop mode should lock the orientation, and let it be configured manually. https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1311
2020-06-11 16:18:37 +00:00
void
meta_monitor_manager_post_init (MetaMonitorManager *manager)
{
ClutterBackend *clutter_backend;
ClutterSeat *seat;
clutter_backend = meta_backend_get_clutter_backend (manager->backend);
seat = clutter_backend_get_default_seat (clutter_backend);
g_signal_connect_object (seat, "notify::touch-mode",
G_CALLBACK (update_panel_orientation_managed), manager,
G_CONNECT_SWAPPED);
}
Copy permalink