isa/mutter
1
0
Fork 0
mirror of https://github.com/brl/mutter.git synced 2024-12-24 20:12:06 +00:00
Code Issues Packages Projects Releases Wiki Activity
2d3deccd8e
mutter/src/backends/meta-monitor-manager.c

1371 lines
45 KiB
C
Raw Normal View History

Rework and consolidate monitor handling in MetaScreen Consolidate all places that deal with output configuration in MetaScreen, which gets it either from XRandR or from a dummy static configuration. We still need to read the Xinerama config, even when running xwayland, because we need the indices for _NET_WM_FULLSCREEN_MONITORS, but now we do it only when needed. https://bugzilla.gnome.org/show_bug.cgi?id=705670
2013-07-18 11:09:16 +00:00
/* -*- mode: C; c-file-style: "gnu"; indent-tabs-mode: nil; -*- */
Remove trailing whitespace
2014-05-02 13:34:02 +00:00
/*
Rework and consolidate monitor handling in MetaScreen Consolidate all places that deal with output configuration in MetaScreen, which gets it either from XRandR or from a dummy static configuration. We still need to read the Xinerama config, even when running xwayland, because we need the indices for _NET_WM_FULLSCREEN_MONITORS, but now we do it only when needed. https://bugzilla.gnome.org/show_bug.cgi?id=705670
2013-07-18 11:09:16 +00:00
* Copyright (C) 2001, 2002 Havoc Pennington
* Copyright (C) 2002, 2003 Red Hat Inc.
* Some ICCCM manager selection code derived from fvwm2,
* Copyright (C) 2001 Dominik Vogt, Matthias Clasen, and fvwm2 team
* Copyright (C) 2003 Rob Adams
* Copyright (C) 2004-2006 Elijah Newren
* Copyright (C) 2013 Red Hat Inc.
Remove trailing whitespace
2014-05-02 13:34:02 +00:00
*
Rework and consolidate monitor handling in MetaScreen Consolidate all places that deal with output configuration in MetaScreen, which gets it either from XRandR or from a dummy static configuration. We still need to read the Xinerama config, even when running xwayland, because we need the indices for _NET_WM_FULLSCREEN_MONITORS, but now we do it only when needed. https://bugzilla.gnome.org/show_bug.cgi?id=705670
2013-07-18 11:09:16 +00:00
* This program is free software; you can redistribute it and/or
* modify it under the terms of the GNU General Public License as
* published by the Free Software Foundation; either version 2 of the
* License, or (at your option) any later version.
*
* This program is distributed in the hope that it will be useful, but
* WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
* General Public License for more details.
Remove trailing whitespace
2014-05-02 13:34:02 +00:00
*
Rework and consolidate monitor handling in MetaScreen Consolidate all places that deal with output configuration in MetaScreen, which gets it either from XRandR or from a dummy static configuration. We still need to read the Xinerama config, even when running xwayland, because we need the indices for _NET_WM_FULLSCREEN_MONITORS, but now we do it only when needed. https://bugzilla.gnome.org/show_bug.cgi?id=705670
2013-07-18 11:09:16 +00:00
* You should have received a copy of the GNU General Public License
Changed obsolete FSF postal address into generic URL. Fix https://bugzilla.gnome.org/show_bug.cgi?id=721517 #2
2014-01-12 01:42:06 +00:00
* along with this program; if not, see <http://www.gnu.org/licenses/>.
Rework and consolidate monitor handling in MetaScreen Consolidate all places that deal with output configuration in MetaScreen, which gets it either from XRandR or from a dummy static configuration. We still need to read the Xinerama config, even when running xwayland, because we need the indices for _NET_WM_FULLSCREEN_MONITORS, but now we do it only when needed. https://bugzilla.gnome.org/show_bug.cgi?id=705670
2013-07-18 11:09:16 +00:00
*/
#include "config.h"
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
#include "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
#include <clutter/clutter.h>
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 <meta/main.h>
Fix regression in mutter-wayland translations Switching meta/util.h to gi18n.h was wrong, mutter is a library and needs gi18n-lib.h, but that cannot be included from a public header (since it depends on config.h or command line options), so split util.h into a public and a private part. https://bugzilla.gnome.org/show_bug.cgi?id=707897
2013-09-11 08:18:53 +00:00
#include "util-private.h"
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
#include <meta/errors.h>
backends: Make KMS EDID information equal to X11's EDID parsing has been refactored to a common meta_output_parse_edid() function, which ensures the extracted information is the same on both KMS and X11 backend, so it can be used consistently on eg. settings values. https://bugzilla.gnome.org/show_bug.cgi?id=742882
2015-01-04 20:24:05 +00:00
#include "edid.h"
Rename monitor-config => meta-monitor-config
2014-04-01 01:59:16 +00:00
#include "meta-monitor-config.h"
Start creating different subdirectories for each backend
2014-04-01 03:25:37 +00:00
#include "backends/x11/meta-monitor-manager-xrandr.h"
backends: Make MetaBackend available to introspection This moves meta-backend.h under meta/ and, for now, just exposes to introspection the methods that we actually need in gnome-shell. https://bugzilla.gnome.org/show_bug.cgi?id=734301
2014-08-05 12:11:59 +00:00
#include "meta-backend-private.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
enum {
MetaPlugin: add a UI hook for confirming display changes We want to show a dialog when a display change happens from the control center. To do so, add a new vfunc to MetaPlugin and call it when a configuration change is requested via DBus. https://bugzilla.gnome.org/show_bug.cgi?id=705670
2013-07-29 08:12:24 +00:00
CONFIRM_DISPLAY_CHANGE,
Rework and consolidate monitor handling in MetaScreen Consolidate all places that deal with output configuration in MetaScreen, which gets it either from XRandR or from a dummy static configuration. We still need to read the Xinerama config, even when running xwayland, because we need the indices for _NET_WM_FULLSCREEN_MONITORS, but now we do it only when needed. https://bugzilla.gnome.org/show_bug.cgi?id=705670
2013-07-18 11:09:16 +00:00
SIGNALS_LAST
};
monitor-manager: Add method to find an output matrix This will be useful to determine input device matrices for touchscreens and tablets. https://bugzilla.gnome.org/show_bug.cgi?id=739397
2014-12-11 17:14:00 +00:00
/* Array index matches MetaMonitorTransform */
static gfloat transform_matrices[][6] = {
{ 1, 0, 0, 0, 1, 0 }, /* normal */
{ 0, -1, 1, 1, 0, 0 }, /* 90° */
{ -1, 0, 1, 0, -1, 1 }, /* 180° */
{ 0, 1, 0, -1, 0, 1 }, /* 270° */
{ -1, 0, 1, 0, 1, 0 }, /* normal flipped */
{ 0, 1, 0, 1, 0, 0 }, /* 90° flipped */
{ 1, 0, 0, 0, -1, 1 }, /* 180° flipped */
{ 0, -1, 1, -1, 0, 1 }, /* 270° flipped */
};
Rework and consolidate monitor handling in MetaScreen Consolidate all places that deal with output configuration in MetaScreen, which gets it either from XRandR or from a dummy static configuration. We still need to read the Xinerama config, even when running xwayland, because we need the indices for _NET_WM_FULLSCREEN_MONITORS, but now we do it only when needed. https://bugzilla.gnome.org/show_bug.cgi?id=705670
2013-07-18 11:09:16 +00:00
static int signals[SIGNALS_LAST];
MonitorManager: inherit directly from DisplayConfig instead of handling signals This way we can handle properties too. https://bugzilla.gnome.org/show_bug.cgi?id=705670
2013-07-23 17:32:17 +00:00
static void meta_monitor_manager_display_config_init (MetaDBusDisplayConfigIface *iface);
Move the dummy monitor manager to his own subclass / file
2014-04-01 01:50:09 +00:00
G_DEFINE_ABSTRACT_TYPE_WITH_CODE (MetaMonitorManager, meta_monitor_manager, META_DBUS_TYPE_DISPLAY_CONFIG_SKELETON,
G_IMPLEMENT_INTERFACE (META_DBUS_TYPE_DISPLAY_CONFIG, meta_monitor_manager_display_config_init));
Rework and consolidate monitor handling in MetaScreen Consolidate all places that deal with output configuration in MetaScreen, which gets it either from XRandR or from a dummy static configuration. We still need to read the Xinerama config, even when running xwayland, because we need the indices for _NET_WM_FULLSCREEN_MONITORS, but now we do it only when needed. https://bugzilla.gnome.org/show_bug.cgi?id=705670
2013-07-18 11:09:16 +00:00
MonitorManager: split the XRandR parts in a subclass Instead of keeping a forest of if backend else ..., use a subclass and virtual functions to discriminate between XRandR and the dummy backend (which lives in the parent class togheter with the common code) https://bugzilla.gnome.org/show_bug.cgi?id=705670
2013-07-29 11:00:15 +00:00
static void initialize_dbus_interface (MetaMonitorManager *manager);
DisplayConfig: make the dummy backend writable Add a number of dummy outputs and modes to the dummy backend, and implement the writing bits. The only visible effect is that you can change the screen size, which resizes the output window. https://bugzilla.gnome.org/show_bug.cgi?id=705670
2013-07-23 08:07:52 +00:00
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)
{
}
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_logical_config:
*
* Turn outputs and CRTCs into logical MetaMonitorInfo,
* that will be used by the core and API layer (MetaScreen
* and friends)
*/
static void
make_logical_config (MetaMonitorManager *manager)
{
GArray *monitor_infos;
unsigned int i, j;
monitor_infos = g_array_sized_new (FALSE, TRUE, sizeof (MetaMonitorInfo),
manager->n_outputs);
/* Walk the list of MetaCRTCs, and build a MetaMonitorInfo
for each of them, unless they reference a rectangle that
is already there.
*/
for (i = 0; i < manager->n_crtcs; i++)
{
MetaCRTC *crtc = &manager->crtcs[i];
/* Ignore CRTCs not in use */
if (crtc->current_mode == NULL)
continue;
for (j = 0; j < monitor_infos->len; j++)
{
monitorManager: Fix logic bug in make_logical_config The code that prevents the creation of multiple MonitorInfos for clones wasn't working due to using the wrong index when getting the already created info so fix that to use the correct one. https://bugzilla.gnome.org/show_bug.cgi?id=710610
2014-02-02 14:09:18 +00:00
MetaMonitorInfo *info = &g_array_index (monitor_infos, MetaMonitorInfo, 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
if (meta_rectangle_equal (&crtc->rect,
&info->rect))
{
crtc->logical_monitor = info;
break;
}
}
if (crtc->logical_monitor == NULL)
{
MetaMonitorInfo info;
info.number = monitor_infos->len;
info.rect = crtc->rect;
info.is_primary = FALSE;
/* This starts true because we want
is_presentation only if all outputs are
marked as such (while for primary it's enough
that any is marked)
*/
info.is_presentation = TRUE;
info.in_fullscreen = -1;
monitor-manager: Rename output_id to winsys_id The output_id is more of an opaque identifier for the monitor, based on its underlying ID from the windowing system. Since we also use the term "output_id" for the output's index, rename our use of the opaque cookie "output_id" to "winsys_id".
2014-07-01 17:23:05 +00:00
info.winsys_id = 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
g_array_append_val (monitor_infos, info);
crtc->logical_monitor = &g_array_index (monitor_infos, MetaMonitorInfo,
info.number);
}
}
/* Now walk the list of outputs applying extended properties (primary
and presentation)
*/
for (i = 0; i < manager->n_outputs; i++)
{
MetaOutput *output;
MetaMonitorInfo *info;
output = &manager->outputs[i];
/* Ignore outputs that are not active */
if (output->crtc == NULL)
continue;
/* We must have a logical monitor on every CRTC at this point */
g_assert (output->crtc->logical_monitor != NULL);
info = output->crtc->logical_monitor;
info->is_primary = info->is_primary || output->is_primary;
info->is_presentation = info->is_presentation && output->is_presentation;
monitor-manager: Rename output_id to winsys_id The output_id is more of an opaque identifier for the monitor, based on its underlying ID from the windowing system. Since we also use the term "output_id" for the output's index, rename our use of the opaque cookie "output_id" to "winsys_id".
2014-07-01 17:23:05 +00:00
if (output->is_primary || info->winsys_id == 0)
info->winsys_id = output->winsys_id;
Introduce a new DBus interface for display configuration This new interface will be used by the control center and possibly the settings daemon to configure the screens. It is designed to resemble a simplified XRandR, while still exposing all the quirks of the hardware, so that the panel can limit the user choices appropriately. To do so, MetaMonitorMode needs to track CRTCs, outputs and modes, so the low level objects have been decoupled from the high-level MetaMonitorInfo, which is used by core and API and offers a simplified view of HW, that hides away the details of what is cloned and how. This is still not efficient as it should be, because on every HW change we drop all data structures and rebuild them from scratch (which is not expensive because there aren't many of them, but at least in the XRandR path it involves a few sync X calls) https://bugzilla.gnome.org/show_bug.cgi?id=705670
2013-07-19 12:39:28 +00:00
if (info->is_primary)
manager->primary_monitor_index = info->number;
}
manager->n_monitor_infos = monitor_infos->len;
manager->monitor_infos = (void*)g_array_free (monitor_infos, FALSE);
}
monitor-manager: Make sure to emit PropertiesChanged for PowerSaveMode We overrode the property for PowerSaveMode, which meant that gdbus's auto-generated PropertiesChanged code wasn't being run. This really confused gnome-rr and gnome-settings-daemon's power plugin about the current DPMS state of the display, since they used their cached PowerSaveMode properties, and never saw a PropertiesChanged being emitted. If a display was on, they set it to off, and then set it back on, the setting back on would never fire, since they thought the display was already off. To fix this, remove our custom property override and just respond to notifications on the object. Namely, this fixes the DPMS management when receiving notifications so that it now properly times out.
2014-09-26 01:39:14 +00:00
static void
power_save_mode_changed (MetaMonitorManager *manager,
GParamSpec *pspec,
gpointer user_data)
{
MetaMonitorManagerClass *klass;
int mode = meta_dbus_display_config_get_power_save_mode (META_DBUS_DISPLAY_CONFIG (manager));
if (mode == META_POWER_SAVE_UNSUPPORTED)
return;
/* If DPMS is unsupported, force the property back. */
if (manager->power_save_mode == META_POWER_SAVE_UNSUPPORTED)
{
meta_dbus_display_config_set_power_save_mode (META_DBUS_DISPLAY_CONFIG (manager), META_POWER_SAVE_UNSUPPORTED);
return;
}
klass = META_MONITOR_MANAGER_GET_CLASS (manager);
if (klass->set_power_save_mode)
klass->set_power_save_mode (manager, mode);
manager->power_save_mode = mode;
}
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: Make sure to emit PropertiesChanged for PowerSaveMode We overrode the property for PowerSaveMode, which meant that gdbus's auto-generated PropertiesChanged code wasn't being run. This really confused gnome-rr and gnome-settings-daemon's power plugin about the current DPMS state of the display, since they used their cached PowerSaveMode properties, and never saw a PropertiesChanged being emitted. If a display was on, they set it to off, and then set it back on, the setting back on would never fire, since they thought the display was already off. To fix this, remove our custom property override and just respond to notifications on the object. Namely, this fixes the DPMS management when receiving notifications so that it now properly times out.
2014-09-26 01:39:14 +00:00
g_signal_connect_object (manager, "notify::power-save-mode",
G_CALLBACK (power_save_mode_changed), manager, 0);
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
manager->in_init = TRUE;
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
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
manager->config = meta_monitor_config_new ();
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
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
meta_monitor_manager_read_current_config (manager);
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
if (!meta_monitor_config_apply_stored (manager->config, manager))
meta_monitor_config_make_default (manager->config, manager);
/* Under XRandR, we don't rebuild our data structures until we see
the RRScreenNotify event, but at least at startup we want to have
the right configuration immediately.
The other backends keep the data structures always updated,
so this is not needed.
*/
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
if (META_IS_MONITOR_MANAGER_XRANDR (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
meta_monitor_manager_read_current_config (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
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_logical_config (manager);
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);
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
manager->in_init = FALSE;
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: 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
static void
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
meta_monitor_manager_free_output_array (MetaOutput *old_outputs,
int n_old_outputs)
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
{
int i;
for (i = 0; i < n_old_outputs; 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
{
g_free (old_outputs[i].name);
g_free (old_outputs[i].vendor);
g_free (old_outputs[i].product);
g_free (old_outputs[i].serial);
g_free (old_outputs[i].modes);
g_free (old_outputs[i].possible_crtcs);
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_free (old_outputs[i].possible_clones);
MonitorManager: add a KMS backend Using the new Cogl API to actually modeset (because we can't use the DRM API directly without controlling buffer swap), we can finally have a KMS monitor backend, which means full display configuration when running on bare metal. https://bugzilla.gnome.org/show_bug.cgi?id=706308
2013-07-30 09:36:18 +00:00
if (old_outputs[i].driver_notify)
old_outputs[i].driver_notify (&old_outputs[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
}
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_free (old_outputs);
}
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
static void
MonitorManager: add a KMS backend Using the new Cogl API to actually modeset (because we can't use the DRM API directly without controlling buffer swap), we can finally have a KMS monitor backend, which means full display configuration when running on bare metal. https://bugzilla.gnome.org/show_bug.cgi?id=706308
2013-07-30 09:36:18 +00:00
meta_monitor_manager_free_mode_array (MetaMonitorMode *old_modes,
int n_old_modes)
{
int i;
for (i = 0; i < n_old_modes; i++)
{
g_free (old_modes[i].name);
if (old_modes[i].driver_notify)
old_modes[i].driver_notify (&old_modes[i]);
}
g_free (old_modes);
}
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);
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
meta_monitor_manager_free_output_array (manager->outputs, manager->n_outputs);
MonitorManager: add a KMS backend Using the new Cogl API to actually modeset (because we can't use the DRM API directly without controlling buffer swap), we can finally have a KMS monitor backend, which means full display configuration when running on bare metal. https://bugzilla.gnome.org/show_bug.cgi?id=706308
2013-07-30 09:36:18 +00:00
meta_monitor_manager_free_mode_array (manager->modes, manager->n_modes);
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_free (manager->monitor_infos);
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_free (manager->crtcs);
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;
}
G_OBJECT_CLASS (meta_monitor_manager_parent_class)->dispose (object);
}
monitor-manager: Move default get_edid_file / read_edid to base class These are also used by the native manager.
2014-04-01 14:24:10 +00:00
static GBytes *
meta_monitor_manager_real_read_edid (MetaMonitorManager *manager,
MetaOutput *output)
{
return NULL;
}
static char *
meta_monitor_manager_real_get_edid_file (MetaMonitorManager *manager,
MetaOutput *output)
{
return NULL;
}
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: Move default get_edid_file / read_edid to base class These are also used by the native manager.
2014-04-01 14:24:10 +00:00
klass->get_edid_file = meta_monitor_manager_real_get_edid_file;
klass->read_edid = meta_monitor_manager_real_read_edid;
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);
Rework and consolidate monitor handling in MetaScreen Consolidate all places that deal with output configuration in MetaScreen, which gets it either from XRandR or from a dummy static configuration. We still need to read the Xinerama config, even when running xwayland, because we need the indices for _NET_WM_FULLSCREEN_MONITORS, but now we do it only when needed. https://bugzilla.gnome.org/show_bug.cgi?id=705670
2013-07-18 11:09:16 +00:00
}
Introduce a new DBus interface for display configuration This new interface will be used by the control center and possibly the settings daemon to configure the screens. It is designed to resemble a simplified XRandR, while still exposing all the quirks of the hardware, so that the panel can limit the user choices appropriately. To do so, MetaMonitorMode needs to track CRTCs, outputs and modes, so the low level objects have been decoupled from the high-level MetaMonitorInfo, which is used by core and API and offers a simplified view of HW, that hides away the details of what is cloned and how. This is still not efficient as it should be, because on every HW change we drop all data structures and rebuild them from scratch (which is not expensive because there aren't many of them, but at least in the XRandR path it involves a few sync X calls) https://bugzilla.gnome.org/show_bug.cgi?id=705670
2013-07-19 12:39:28 +00:00
static const double known_diagonals[] = {
12.1,
13.3,
15.6
};
static char *
diagonal_to_str (double d)
{
unsigned int i;
for (i = 0; i < G_N_ELEMENTS (known_diagonals); i++)
{
double delta;
delta = fabs(known_diagonals[i] - d);
if (delta < 0.1)
return g_strdup_printf ("%0.1lf\"", known_diagonals[i]);
}
return g_strdup_printf ("%d\"", (int) (d + 0.5));
}
static char *
Monitor: restore correct display name handling Now that we have the right values from the EDID, we can load the PNP database and find the proper vendor name, to show in the control center UI. https://bugzilla.gnome.org/show_bug.cgi?id=705670
2013-08-16 15:32:50 +00:00
make_display_name (MetaMonitorManager *manager,
MetaOutput *output)
Introduce a new DBus interface for display configuration This new interface will be used by the control center and possibly the settings daemon to configure the screens. It is designed to resemble a simplified XRandR, while still exposing all the quirks of the hardware, so that the panel can limit the user choices appropriately. To do so, MetaMonitorMode needs to track CRTCs, outputs and modes, so the low level objects have been decoupled from the high-level MetaMonitorInfo, which is used by core and API and offers a simplified view of HW, that hides away the details of what is cloned and how. This is still not efficient as it should be, because on every HW change we drop all data structures and rebuild them from scratch (which is not expensive because there aren't many of them, but at least in the XRandR path it involves a few sync X calls) https://bugzilla.gnome.org/show_bug.cgi?id=705670
2013-07-19 12:39:28 +00:00
{
monitor: improve heuristic to determine display output name Under some circumstances, for example when the display controller driver doesn't report back the correct EDID, or under VirtualBox, Mutter returns suboptimal strings for an output display name, leading to funny labels like 'Unknown 0"', or '(null) 0"' in the Settings panel. This commit improves our heuristic in three ways: - we now avoid putting inches in the display name if either dimension is zero - we use the vendor name in case we're not able to lookup its PnP id from the database. Previously we would have passed over '(null)' - as a special edge-case, when neither inches nor vendor are known, we use the string 'Unknown Display' Finally, we make the combined vendor + inches string translatable, as different languages might want to move the size part of the string to a position different than the end. https://bugzilla.gnome.org/show_bug.cgi?id=721674
2014-01-07 02:26:03 +00:00
char *inches = NULL;
char *vendor_name = NULL;
char *ret;
monitor-manager: Use connector_type instead of name sniffing
2014-12-30 01:13:25 +00:00
switch (output->connector_type)
monitor: improve heuristic to determine display output name Under some circumstances, for example when the display controller driver doesn't report back the correct EDID, or under VirtualBox, Mutter returns suboptimal strings for an output display name, leading to funny labels like 'Unknown 0"', or '(null) 0"' in the Settings panel. This commit improves our heuristic in three ways: - we now avoid putting inches in the display name if either dimension is zero - we use the vendor name in case we're not able to lookup its PnP id from the database. Previously we would have passed over '(null)' - as a special edge-case, when neither inches nor vendor are known, we use the string 'Unknown Display' Finally, we make the combined vendor + inches string translatable, as different languages might want to move the size part of the string to a position different than the end. https://bugzilla.gnome.org/show_bug.cgi?id=721674
2014-01-07 02:26:03 +00:00
{
monitor-manager: Use connector_type instead of name sniffing
2014-12-30 01:13:25 +00:00
case META_CONNECTOR_TYPE_LVDS:
case META_CONNECTOR_TYPE_eDP:
monitor: improve heuristic to determine display output name Under some circumstances, for example when the display controller driver doesn't report back the correct EDID, or under VirtualBox, Mutter returns suboptimal strings for an output display name, leading to funny labels like 'Unknown 0"', or '(null) 0"' in the Settings panel. This commit improves our heuristic in three ways: - we now avoid putting inches in the display name if either dimension is zero - we use the vendor name in case we're not able to lookup its PnP id from the database. Previously we would have passed over '(null)' - as a special edge-case, when neither inches nor vendor are known, we use the string 'Unknown Display' Finally, we make the combined vendor + inches string translatable, as different languages might want to move the size part of the string to a position different than the end. https://bugzilla.gnome.org/show_bug.cgi?id=721674
2014-01-07 02:26:03 +00:00
ret = g_strdup (_("Built-in display"));
goto out;
monitor-manager: Use connector_type instead of name sniffing
2014-12-30 01:13:25 +00:00
default:
break;
monitor: improve heuristic to determine display output name Under some circumstances, for example when the display controller driver doesn't report back the correct EDID, or under VirtualBox, Mutter returns suboptimal strings for an output display name, leading to funny labels like 'Unknown 0"', or '(null) 0"' in the Settings panel. This commit improves our heuristic in three ways: - we now avoid putting inches in the display name if either dimension is zero - we use the vendor name in case we're not able to lookup its PnP id from the database. Previously we would have passed over '(null)' - as a special edge-case, when neither inches nor vendor are known, we use the string 'Unknown Display' Finally, we make the combined vendor + inches string translatable, as different languages might want to move the size part of the string to a position different than the end. https://bugzilla.gnome.org/show_bug.cgi?id=721674
2014-01-07 02:26:03 +00:00
}
Monitor: restore correct display name handling Now that we have the right values from the EDID, we can load the PNP database and find the proper vendor name, to show in the control center UI. https://bugzilla.gnome.org/show_bug.cgi?id=705670
2013-08-16 15:32:50 +00:00
monitor: improve heuristic to determine display output name Under some circumstances, for example when the display controller driver doesn't report back the correct EDID, or under VirtualBox, Mutter returns suboptimal strings for an output display name, leading to funny labels like 'Unknown 0"', or '(null) 0"' in the Settings panel. This commit improves our heuristic in three ways: - we now avoid putting inches in the display name if either dimension is zero - we use the vendor name in case we're not able to lookup its PnP id from the database. Previously we would have passed over '(null)' - as a special edge-case, when neither inches nor vendor are known, we use the string 'Unknown Display' Finally, we make the combined vendor + inches string translatable, as different languages might want to move the size part of the string to a position different than the end. https://bugzilla.gnome.org/show_bug.cgi?id=721674
2014-01-07 02:26:03 +00:00
if (output->width_mm > 0 && output->height_mm > 0)
Introduce a new DBus interface for display configuration This new interface will be used by the control center and possibly the settings daemon to configure the screens. It is designed to resemble a simplified XRandR, while still exposing all the quirks of the hardware, so that the panel can limit the user choices appropriately. To do so, MetaMonitorMode needs to track CRTCs, outputs and modes, so the low level objects have been decoupled from the high-level MetaMonitorInfo, which is used by core and API and offers a simplified view of HW, that hides away the details of what is cloned and how. This is still not efficient as it should be, because on every HW change we drop all data structures and rebuild them from scratch (which is not expensive because there aren't many of them, but at least in the XRandR path it involves a few sync X calls) https://bugzilla.gnome.org/show_bug.cgi?id=705670
2013-07-19 12:39:28 +00:00
{
double d = sqrt (output->width_mm * output->width_mm +
output->height_mm * output->height_mm);
monitor: improve heuristic to determine display output name Under some circumstances, for example when the display controller driver doesn't report back the correct EDID, or under VirtualBox, Mutter returns suboptimal strings for an output display name, leading to funny labels like 'Unknown 0"', or '(null) 0"' in the Settings panel. This commit improves our heuristic in three ways: - we now avoid putting inches in the display name if either dimension is zero - we use the vendor name in case we're not able to lookup its PnP id from the database. Previously we would have passed over '(null)' - as a special edge-case, when neither inches nor vendor are known, we use the string 'Unknown Display' Finally, we make the combined vendor + inches string translatable, as different languages might want to move the size part of the string to a position different than the end. https://bugzilla.gnome.org/show_bug.cgi?id=721674
2014-01-07 02:26:03 +00:00
inches = diagonal_to_str (d / 25.4);
}
Monitor: restore correct display name handling Now that we have the right values from the EDID, we can load the PNP database and find the proper vendor name, to show in the control center UI. https://bugzilla.gnome.org/show_bug.cgi?id=705670
2013-08-16 15:32:50 +00:00
monitor: improve heuristic to determine display output name Under some circumstances, for example when the display controller driver doesn't report back the correct EDID, or under VirtualBox, Mutter returns suboptimal strings for an output display name, leading to funny labels like 'Unknown 0"', or '(null) 0"' in the Settings panel. This commit improves our heuristic in three ways: - we now avoid putting inches in the display name if either dimension is zero - we use the vendor name in case we're not able to lookup its PnP id from the database. Previously we would have passed over '(null)' - as a special edge-case, when neither inches nor vendor are known, we use the string 'Unknown Display' Finally, we make the combined vendor + inches string translatable, as different languages might want to move the size part of the string to a position different than the end. https://bugzilla.gnome.org/show_bug.cgi?id=721674
2014-01-07 02:26:03 +00:00
if (g_strcmp0 (output->vendor, "unknown") != 0)
{
if (!manager->pnp_ids)
manager->pnp_ids = gnome_pnp_ids_new ();
Monitor: restore correct display name handling Now that we have the right values from the EDID, we can load the PNP database and find the proper vendor name, to show in the control center UI. https://bugzilla.gnome.org/show_bug.cgi?id=705670
2013-08-16 15:32:50 +00:00
monitor: improve heuristic to determine display output name Under some circumstances, for example when the display controller driver doesn't report back the correct EDID, or under VirtualBox, Mutter returns suboptimal strings for an output display name, leading to funny labels like 'Unknown 0"', or '(null) 0"' in the Settings panel. This commit improves our heuristic in three ways: - we now avoid putting inches in the display name if either dimension is zero - we use the vendor name in case we're not able to lookup its PnP id from the database. Previously we would have passed over '(null)' - as a special edge-case, when neither inches nor vendor are known, we use the string 'Unknown Display' Finally, we make the combined vendor + inches string translatable, as different languages might want to move the size part of the string to a position different than the end. https://bugzilla.gnome.org/show_bug.cgi?id=721674
2014-01-07 02:26:03 +00:00
vendor_name = gnome_pnp_ids_get_pnp_id (manager->pnp_ids,
output->vendor);
Monitor: restore correct display name handling Now that we have the right values from the EDID, we can load the PNP database and find the proper vendor name, to show in the control center UI. https://bugzilla.gnome.org/show_bug.cgi?id=705670
2013-08-16 15:32:50 +00:00
monitor: improve heuristic to determine display output name Under some circumstances, for example when the display controller driver doesn't report back the correct EDID, or under VirtualBox, Mutter returns suboptimal strings for an output display name, leading to funny labels like 'Unknown 0"', or '(null) 0"' in the Settings panel. This commit improves our heuristic in three ways: - we now avoid putting inches in the display name if either dimension is zero - we use the vendor name in case we're not able to lookup its PnP id from the database. Previously we would have passed over '(null)' - as a special edge-case, when neither inches nor vendor are known, we use the string 'Unknown Display' Finally, we make the combined vendor + inches string translatable, as different languages might want to move the size part of the string to a position different than the end. https://bugzilla.gnome.org/show_bug.cgi?id=721674
2014-01-07 02:26:03 +00:00
if (!vendor_name)
vendor_name = g_strdup (output->vendor);
}
else
{
if (inches != NULL)
vendor_name = g_strdup (_("Unknown"));
Monitor: restore correct display name handling Now that we have the right values from the EDID, we can load the PNP database and find the proper vendor name, to show in the control center UI. https://bugzilla.gnome.org/show_bug.cgi?id=705670
2013-08-16 15:32:50 +00:00
else
monitor: improve heuristic to determine display output name Under some circumstances, for example when the display controller driver doesn't report back the correct EDID, or under VirtualBox, Mutter returns suboptimal strings for an output display name, leading to funny labels like 'Unknown 0"', or '(null) 0"' in the Settings panel. This commit improves our heuristic in three ways: - we now avoid putting inches in the display name if either dimension is zero - we use the vendor name in case we're not able to lookup its PnP id from the database. Previously we would have passed over '(null)' - as a special edge-case, when neither inches nor vendor are known, we use the string 'Unknown Display' Finally, we make the combined vendor + inches string translatable, as different languages might want to move the size part of the string to a position different than the end. https://bugzilla.gnome.org/show_bug.cgi?id=721674
2014-01-07 02:26:03 +00:00
vendor_name = g_strdup (_("Unknown Display"));
}
Introduce a new DBus interface for display configuration This new interface will be used by the control center and possibly the settings daemon to configure the screens. It is designed to resemble a simplified XRandR, while still exposing all the quirks of the hardware, so that the panel can limit the user choices appropriately. To do so, MetaMonitorMode needs to track CRTCs, outputs and modes, so the low level objects have been decoupled from the high-level MetaMonitorInfo, which is used by core and API and offers a simplified view of HW, that hides away the details of what is cloned and how. This is still not efficient as it should be, because on every HW change we drop all data structures and rebuild them from scratch (which is not expensive because there aren't many of them, but at least in the XRandR path it involves a few sync X calls) https://bugzilla.gnome.org/show_bug.cgi?id=705670
2013-07-19 12:39:28 +00:00
monitor: improve heuristic to determine display output name Under some circumstances, for example when the display controller driver doesn't report back the correct EDID, or under VirtualBox, Mutter returns suboptimal strings for an output display name, leading to funny labels like 'Unknown 0"', or '(null) 0"' in the Settings panel. This commit improves our heuristic in three ways: - we now avoid putting inches in the display name if either dimension is zero - we use the vendor name in case we're not able to lookup its PnP id from the database. Previously we would have passed over '(null)' - as a special edge-case, when neither inches nor vendor are known, we use the string 'Unknown Display' Finally, we make the combined vendor + inches string translatable, as different languages might want to move the size part of the string to a position different than the end. https://bugzilla.gnome.org/show_bug.cgi?id=721674
2014-01-07 02:26:03 +00:00
if (inches != NULL)
{
/* TRANSLATORS: this is a monitor vendor name, followed by a
* size in inches, like 'Dell 15"'
*/
ret = g_strdup_printf (_("%s %s"), vendor_name, inches);
Introduce a new DBus interface for display configuration This new interface will be used by the control center and possibly the settings daemon to configure the screens. It is designed to resemble a simplified XRandR, while still exposing all the quirks of the hardware, so that the panel can limit the user choices appropriately. To do so, MetaMonitorMode needs to track CRTCs, outputs and modes, so the low level objects have been decoupled from the high-level MetaMonitorInfo, which is used by core and API and offers a simplified view of HW, that hides away the details of what is cloned and how. This is still not efficient as it should be, because on every HW change we drop all data structures and rebuild them from scratch (which is not expensive because there aren't many of them, but at least in the XRandR path it involves a few sync X calls) https://bugzilla.gnome.org/show_bug.cgi?id=705670
2013-07-19 12:39:28 +00:00
}
else
{
monitor: improve heuristic to determine display output name Under some circumstances, for example when the display controller driver doesn't report back the correct EDID, or under VirtualBox, Mutter returns suboptimal strings for an output display name, leading to funny labels like 'Unknown 0"', or '(null) 0"' in the Settings panel. This commit improves our heuristic in three ways: - we now avoid putting inches in the display name if either dimension is zero - we use the vendor name in case we're not able to lookup its PnP id from the database. Previously we would have passed over '(null)' - as a special edge-case, when neither inches nor vendor are known, we use the string 'Unknown Display' Finally, we make the combined vendor + inches string translatable, as different languages might want to move the size part of the string to a position different than the end. https://bugzilla.gnome.org/show_bug.cgi?id=721674
2014-01-07 02:26:03 +00:00
ret = g_strdup (vendor_name);
Introduce a new DBus interface for display configuration This new interface will be used by the control center and possibly the settings daemon to configure the screens. It is designed to resemble a simplified XRandR, while still exposing all the quirks of the hardware, so that the panel can limit the user choices appropriately. To do so, MetaMonitorMode needs to track CRTCs, outputs and modes, so the low level objects have been decoupled from the high-level MetaMonitorInfo, which is used by core and API and offers a simplified view of HW, that hides away the details of what is cloned and how. This is still not efficient as it should be, because on every HW change we drop all data structures and rebuild them from scratch (which is not expensive because there aren't many of them, but at least in the XRandR path it involves a few sync X calls) https://bugzilla.gnome.org/show_bug.cgi?id=705670
2013-07-19 12:39:28 +00:00
}
monitor: improve heuristic to determine display output name Under some circumstances, for example when the display controller driver doesn't report back the correct EDID, or under VirtualBox, Mutter returns suboptimal strings for an output display name, leading to funny labels like 'Unknown 0"', or '(null) 0"' in the Settings panel. This commit improves our heuristic in three ways: - we now avoid putting inches in the display name if either dimension is zero - we use the vendor name in case we're not able to lookup its PnP id from the database. Previously we would have passed over '(null)' - as a special edge-case, when neither inches nor vendor are known, we use the string 'Unknown Display' Finally, we make the combined vendor + inches string translatable, as different languages might want to move the size part of the string to a position different than the end. https://bugzilla.gnome.org/show_bug.cgi?id=721674
2014-01-07 02:26:03 +00:00
out:
g_free (inches);
g_free (vendor_name);
return ret;
Introduce a new DBus interface for display configuration This new interface will be used by the control center and possibly the settings daemon to configure the screens. It is designed to resemble a simplified XRandR, while still exposing all the quirks of the hardware, so that the panel can limit the user choices appropriately. To do so, MetaMonitorMode needs to track CRTCs, outputs and modes, so the low level objects have been decoupled from the high-level MetaMonitorInfo, which is used by core and API and offers a simplified view of HW, that hides away the details of what is cloned and how. This is still not efficient as it should be, because on every HW change we drop all data structures and rebuild them from scratch (which is not expensive because there aren't many of them, but at least in the XRandR path it involves a few sync X calls) https://bugzilla.gnome.org/show_bug.cgi?id=705670
2013-07-19 12:39:28 +00:00
}
monitor-manager: Add a connector-type property This is so gnome-settings-daemon
2014-12-30 00:18:24 +00:00
static const char *
get_connector_type_name (MetaConnectorType connector_type)
{
switch (connector_type)
{
case META_CONNECTOR_TYPE_Unknown: return "Unknown";
case META_CONNECTOR_TYPE_VGA: return "VGA";
case META_CONNECTOR_TYPE_DVII: return "DVII";
case META_CONNECTOR_TYPE_DVID: return "DVID";
case META_CONNECTOR_TYPE_DVIA: return "DVIA";
case META_CONNECTOR_TYPE_Composite: return "Composite";
case META_CONNECTOR_TYPE_SVIDEO: return "SVIDEO";
case META_CONNECTOR_TYPE_LVDS: return "LVDS";
case META_CONNECTOR_TYPE_Component: return "Component";
case META_CONNECTOR_TYPE_9PinDIN: return "9PinDIN";
case META_CONNECTOR_TYPE_DisplayPort: return "DisplayPort";
case META_CONNECTOR_TYPE_HDMIA: return "HDMIA";
case META_CONNECTOR_TYPE_HDMIB: return "HDMIB";
case META_CONNECTOR_TYPE_TV: return "TV";
case META_CONNECTOR_TYPE_eDP: return "eDP";
case META_CONNECTOR_TYPE_VIRTUAL: return "VIRTUAL";
case META_CONNECTOR_TYPE_DSI: return "DSI";
default: g_assert_not_reached ();
}
}
Introduce a new DBus interface for display configuration This new interface will be used by the control center and possibly the settings daemon to configure the screens. It is designed to resemble a simplified XRandR, while still exposing all the quirks of the hardware, so that the panel can limit the user choices appropriately. To do so, MetaMonitorMode needs to track CRTCs, outputs and modes, so the low level objects have been decoupled from the high-level MetaMonitorInfo, which is used by core and API and offers a simplified view of HW, that hides away the details of what is cloned and how. This is still not efficient as it should be, because on every HW change we drop all data structures and rebuild them from scratch (which is not expensive because there aren't many of them, but at least in the XRandR path it involves a few sync X calls) https://bugzilla.gnome.org/show_bug.cgi?id=705670
2013-07-19 12:39:28 +00:00
static gboolean
MonitorManager: inherit directly from DisplayConfig instead of handling signals This way we can handle properties too. https://bugzilla.gnome.org/show_bug.cgi?id=705670
2013-07-23 17:32:17 +00:00
meta_monitor_manager_handle_get_resources (MetaDBusDisplayConfig *skeleton,
GDBusMethodInvocation *invocation)
Introduce a new DBus interface for display configuration This new interface will be used by the control center and possibly the settings daemon to configure the screens. It is designed to resemble a simplified XRandR, while still exposing all the quirks of the hardware, so that the panel can limit the user choices appropriately. To do so, MetaMonitorMode needs to track CRTCs, outputs and modes, so the low level objects have been decoupled from the high-level MetaMonitorInfo, which is used by core and API and offers a simplified view of HW, that hides away the details of what is cloned and how. This is still not efficient as it should be, because on every HW change we drop all data structures and rebuild them from scratch (which is not expensive because there aren't many of them, but at least in the XRandR path it involves a few sync X calls) https://bugzilla.gnome.org/show_bug.cgi?id=705670
2013-07-19 12:39:28 +00:00
{
MonitorManager: inherit directly from DisplayConfig instead of handling signals This way we can handle properties too. https://bugzilla.gnome.org/show_bug.cgi?id=705670
2013-07-23 17:32:17 +00:00
MetaMonitorManager *manager = META_MONITOR_MANAGER (skeleton);
MonitorManager: add EDID properties to the output DBus description Add "edid-file", if we have one (in the KMS case, where we can point people to the right sysfs file), or "edid" with inline data. These are needed by colord to build the default ICC profile for uncalibrated displays. https://bugzilla.gnome.org/show_bug.cgi?id=705670
2013-08-08 11:32:05 +00:00
MetaMonitorManagerClass *manager_class = META_MONITOR_MANAGER_GET_CLASS (skeleton);
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;
unsigned int i, j;
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})"));
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 (&mode_builder, G_VARIANT_TYPE ("a(uxuud)"));
for (i = 0; i < manager->n_crtcs; i++)
{
MetaCRTC *crtc = &manager->crtcs[i];
GVariantBuilder transforms;
g_variant_builder_init (&transforms, G_VARIANT_TYPE ("au"));
monitor: Don't use wl_output_transform in our APIs Invent our own API so we can build without Wayland headers.
2014-07-10 21:39:47 +00:00
for (j = 0; j <= META_MONITOR_TRANSFORM_FLIPPED_270; j++)
MonitorManager: fix handling of output transform Read the current transform from XRandR, and expose the transforms that are really supported on the bus. The dummy backend now advertises all transforms, since it doesn't actually apply them. https://bugzilla.gnome.org/show_bug.cgi?id=705670
2013-07-24 08:01:57 +00:00
if (crtc->all_transforms & (1 << j))
g_variant_builder_add (&transforms, "u", j);
Introduce a new DBus interface for display configuration This new interface will be used by the control center and possibly the settings daemon to configure the screens. It is designed to resemble a simplified XRandR, while still exposing all the quirks of the hardware, so that the panel can limit the user choices appropriately. To do so, MetaMonitorMode needs to track CRTCs, outputs and modes, so the low level objects have been decoupled from the high-level MetaMonitorInfo, which is used by core and API and offers a simplified view of HW, that hides away the details of what is cloned and how. This is still not efficient as it should be, because on every HW change we drop all data structures and rebuild them from scratch (which is not expensive because there aren't many of them, but at least in the XRandR path it involves a few sync X calls) https://bugzilla.gnome.org/show_bug.cgi?id=705670
2013-07-19 12:39:28 +00:00
g_variant_builder_add (&crtc_builder, "(uxiiiiiuaua{sv})",
i, /* ID */
MonitorManager: make sure to pass the right sizes to vararg functions A gulong is not enough to get 64 bits in all arches, so we must cast it, or we can corrupt the stack. This was downstream bug bugzilla.redhat.com/show_bug.cgi?id=1002055 https://bugzilla.gnome.org/show_bug.cgi?id=707267
2013-09-02 07:29:26 +00:00
(gint64)crtc->crtc_id,
Introduce a new DBus interface for display configuration This new interface will be used by the control center and possibly the settings daemon to configure the screens. It is designed to resemble a simplified XRandR, while still exposing all the quirks of the hardware, so that the panel can limit the user choices appropriately. To do so, MetaMonitorMode needs to track CRTCs, outputs and modes, so the low level objects have been decoupled from the high-level MetaMonitorInfo, which is used by core and API and offers a simplified view of HW, that hides away the details of what is cloned and how. This is still not efficient as it should be, because on every HW change we drop all data structures and rebuild them from scratch (which is not expensive because there aren't many of them, but at least in the XRandR path it involves a few sync X calls) https://bugzilla.gnome.org/show_bug.cgi?id=705670
2013-07-19 12:39:28 +00:00
(int)crtc->rect.x,
(int)crtc->rect.y,
(int)crtc->rect.width,
(int)crtc->rect.height,
(int)(crtc->current_mode ? crtc->current_mode - manager->modes : -1),
MonitorManager: make sure to pass the right sizes to vararg functions A gulong is not enough to get 64 bits in all arches, so we must cast it, or we can corrupt the stack. This was downstream bug bugzilla.redhat.com/show_bug.cgi?id=1002055 https://bugzilla.gnome.org/show_bug.cgi?id=707267
2013-09-02 07:29:26 +00:00
(guint32)crtc->transform,
Introduce a new DBus interface for display configuration This new interface will be used by the control center and possibly the settings daemon to configure the screens. It is designed to resemble a simplified XRandR, while still exposing all the quirks of the hardware, so that the panel can limit the user choices appropriately. To do so, MetaMonitorMode needs to track CRTCs, outputs and modes, so the low level objects have been decoupled from the high-level MetaMonitorInfo, which is used by core and API and offers a simplified view of HW, that hides away the details of what is cloned and how. This is still not efficient as it should be, because on every HW change we drop all data structures and rebuild them from scratch (which is not expensive because there aren't many of them, but at least in the XRandR path it involves a few sync X calls) https://bugzilla.gnome.org/show_bug.cgi?id=705670
2013-07-19 12:39:28 +00:00
&transforms,
NULL /* properties */);
}
for (i = 0; i < manager->n_outputs; i++)
{
MetaOutput *output = &manager->outputs[i];
Extend the DBus XRandR protocol to expose cloning restriction Turns out that even if two outputs say that they can be controlled by a given CRTC, you can't configure them in the same CRTC unless they are marked as "possible clones" one of the other. This can further restrict the configuration options, so we need to expose this limitation in the DBus API. https://bugzilla.gnome.org/show_bug.cgi?id=705670
2013-07-19 16:47:01 +00:00
GVariantBuilder crtcs, modes, clones, properties;
MonitorManager: add EDID properties to the output DBus description Add "edid-file", if we have one (in the KMS case, where we can point people to the right sysfs file), or "edid" with inline data. These are needed by colord to build the default ICC profile for uncalibrated displays. https://bugzilla.gnome.org/show_bug.cgi?id=705670
2013-08-08 11:32:05 +00:00
GBytes *edid;
char *edid_file;
Introduce a new DBus interface for display configuration This new interface will be used by the control center and possibly the settings daemon to configure the screens. It is designed to resemble a simplified XRandR, while still exposing all the quirks of the hardware, so that the panel can limit the user choices appropriately. To do so, MetaMonitorMode needs to track CRTCs, outputs and modes, so the low level objects have been decoupled from the high-level MetaMonitorInfo, which is used by core and API and offers a simplified view of HW, that hides away the details of what is cloned and how. This is still not efficient as it should be, because on every HW change we drop all data structures and rebuild them from scratch (which is not expensive because there aren't many of them, but at least in the XRandR path it involves a few sync X calls) https://bugzilla.gnome.org/show_bug.cgi?id=705670
2013-07-19 12:39:28 +00:00
g_variant_builder_init (&crtcs, G_VARIANT_TYPE ("au"));
for (j = 0; j < output->n_possible_crtcs; j++)
g_variant_builder_add (&crtcs, "u",
(unsigned)(output->possible_crtcs[j] - manager->crtcs));
g_variant_builder_init (&modes, G_VARIANT_TYPE ("au"));
for (j = 0; j < output->n_modes; j++)
g_variant_builder_add (&modes, "u",
(unsigned)(output->modes[j] - manager->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
g_variant_builder_init (&clones, G_VARIANT_TYPE ("au"));
for (j = 0; j < output->n_possible_clones; j++)
g_variant_builder_add (&clones, "u",
(unsigned)(output->possible_clones[j] - manager->outputs));
Introduce a new DBus interface for display configuration This new interface will be used by the control center and possibly the settings daemon to configure the screens. It is designed to resemble a simplified XRandR, while still exposing all the quirks of the hardware, so that the panel can limit the user choices appropriately. To do so, MetaMonitorMode needs to track CRTCs, outputs and modes, so the low level objects have been decoupled from the high-level MetaMonitorInfo, which is used by core and API and offers a simplified view of HW, that hides away the details of what is cloned and how. This is still not efficient as it should be, because on every HW change we drop all data structures and rebuild them from scratch (which is not expensive because there aren't many of them, but at least in the XRandR path it involves a few sync X calls) https://bugzilla.gnome.org/show_bug.cgi?id=705670
2013-07-19 12:39:28 +00:00
g_variant_builder_init (&properties, G_VARIANT_TYPE ("a{sv}"));
g_variant_builder_add (&properties, "{sv}", "vendor",
g_variant_new_string (output->vendor));
g_variant_builder_add (&properties, "{sv}", "product",
g_variant_new_string (output->product));
g_variant_builder_add (&properties, "{sv}", "serial",
g_variant_new_string (output->serial));
MonitorManager: extend the API with physical sizes These will be needed in the new display panel designs to show the diagonal length and physical aspect ratio. https://bugzilla.gnome.org/show_bug.cgi?id=706322
2013-08-19 15:37:24 +00:00
g_variant_builder_add (&properties, "{sv}", "width-mm",
g_variant_new_int32 (output->width_mm));
g_variant_builder_add (&properties, "{sv}", "height-mm",
g_variant_new_int32 (output->height_mm));
Introduce a new DBus interface for display configuration This new interface will be used by the control center and possibly the settings daemon to configure the screens. It is designed to resemble a simplified XRandR, while still exposing all the quirks of the hardware, so that the panel can limit the user choices appropriately. To do so, MetaMonitorMode needs to track CRTCs, outputs and modes, so the low level objects have been decoupled from the high-level MetaMonitorInfo, which is used by core and API and offers a simplified view of HW, that hides away the details of what is cloned and how. This is still not efficient as it should be, because on every HW change we drop all data structures and rebuild them from scratch (which is not expensive because there aren't many of them, but at least in the XRandR path it involves a few sync X calls) https://bugzilla.gnome.org/show_bug.cgi?id=705670
2013-07-19 12:39:28 +00:00
g_variant_builder_add (&properties, "{sv}", "display-name",
Monitor: restore correct display name handling Now that we have the right values from the EDID, we can load the PNP database and find the proper vendor name, to show in the control center UI. https://bugzilla.gnome.org/show_bug.cgi?id=705670
2013-08-16 15:32:50 +00:00
g_variant_new_take_string (make_display_name (manager, output)));
MonitorManager: add support for backlight GnomeRR needs that too. The backlight is exported as a normalized 0-100 value, or -1 if not supported. Clamping to HW limits is handled by the backend. Changing backlight uses a different method call, to avoid recomputing the full display configuration every time the user presses the backlight keys. https://bugzilla.gnome.org/show_bug.cgi?id=705670
2013-07-25 13:06:09 +00:00
g_variant_builder_add (&properties, "{sv}", "backlight",
g_variant_new_int32 (output->backlight));
monitor: expose min-backlight-step Expose min-backlight-step so that gnome-settings-daemon can support backlights with less than 10 steps without mutter normalizing the brightness back to its original value https://bugzilla.gnome.org/show_bug.cgi?id=710380
2013-10-17 15:05:59 +00:00
g_variant_builder_add (&properties, "{sv}", "min-backlight-step",
g_variant_new_int32 ((output->backlight_max - output->backlight_min) ?
100 / (output->backlight_max - output->backlight_min) : -1));
Introduce a new DBus interface for display configuration This new interface will be used by the control center and possibly the settings daemon to configure the screens. It is designed to resemble a simplified XRandR, while still exposing all the quirks of the hardware, so that the panel can limit the user choices appropriately. To do so, MetaMonitorMode needs to track CRTCs, outputs and modes, so the low level objects have been decoupled from the high-level MetaMonitorInfo, which is used by core and API and offers a simplified view of HW, that hides away the details of what is cloned and how. This is still not efficient as it should be, because on every HW change we drop all data structures and rebuild them from scratch (which is not expensive because there aren't many of them, but at least in the XRandR path it involves a few sync X calls) https://bugzilla.gnome.org/show_bug.cgi?id=705670
2013-07-19 12:39:28 +00:00
g_variant_builder_add (&properties, "{sv}", "primary",
g_variant_new_boolean (output->is_primary));
g_variant_builder_add (&properties, "{sv}", "presentation",
g_variant_new_boolean (output->is_presentation));
monitor-manager: Add a connector-type property This is so gnome-settings-daemon
2014-12-30 00:18:24 +00:00
g_variant_builder_add (&properties, "{sv}", "connector-type",
g_variant_new_string (get_connector_type_name (output->connector_type)));
Introduce a new DBus interface for display configuration This new interface will be used by the control center and possibly the settings daemon to configure the screens. It is designed to resemble a simplified XRandR, while still exposing all the quirks of the hardware, so that the panel can limit the user choices appropriately. To do so, MetaMonitorMode needs to track CRTCs, outputs and modes, so the low level objects have been decoupled from the high-level MetaMonitorInfo, which is used by core and API and offers a simplified view of HW, that hides away the details of what is cloned and how. This is still not efficient as it should be, because on every HW change we drop all data structures and rebuild them from scratch (which is not expensive because there aren't many of them, but at least in the XRandR path it involves a few sync X calls) https://bugzilla.gnome.org/show_bug.cgi?id=705670
2013-07-19 12:39:28 +00:00
MonitorManager: add EDID properties to the output DBus description Add "edid-file", if we have one (in the KMS case, where we can point people to the right sysfs file), or "edid" with inline data. These are needed by colord to build the default ICC profile for uncalibrated displays. https://bugzilla.gnome.org/show_bug.cgi?id=705670
2013-08-08 11:32:05 +00:00
edid_file = manager_class->get_edid_file (manager, output);
if (edid_file)
{
g_variant_builder_add (&properties, "{sv}", "edid-file",
g_variant_new_take_string (edid_file));
}
else
{
edid = manager_class->read_edid (manager, output);
if (edid)
{
g_variant_builder_add (&properties, "{sv}", "edid",
g_variant_new_from_bytes (G_VARIANT_TYPE ("ay"),
edid, TRUE));
g_bytes_unref (edid);
}
}
Extend the DBus XRandR protocol to expose cloning restriction Turns out that even if two outputs say that they can be controlled by a given CRTC, you can't configure them in the same CRTC unless they are marked as "possible clones" one of the other. This can further restrict the configuration options, so we need to expose this limitation in the DBus API. https://bugzilla.gnome.org/show_bug.cgi?id=705670
2013-07-19 16:47:01 +00:00
g_variant_builder_add (&output_builder, "(uxiausauaua{sv})",
Introduce a new DBus interface for display configuration This new interface will be used by the control center and possibly the settings daemon to configure the screens. It is designed to resemble a simplified XRandR, while still exposing all the quirks of the hardware, so that the panel can limit the user choices appropriately. To do so, MetaMonitorMode needs to track CRTCs, outputs and modes, so the low level objects have been decoupled from the high-level MetaMonitorInfo, which is used by core and API and offers a simplified view of HW, that hides away the details of what is cloned and how. This is still not efficient as it should be, because on every HW change we drop all data structures and rebuild them from scratch (which is not expensive because there aren't many of them, but at least in the XRandR path it involves a few sync X calls) https://bugzilla.gnome.org/show_bug.cgi?id=705670
2013-07-19 12:39:28 +00:00
i, /* ID */
monitor-manager: Rename output_id to winsys_id The output_id is more of an opaque identifier for the monitor, based on its underlying ID from the windowing system. Since we also use the term "output_id" for the output's index, rename our use of the opaque cookie "output_id" to "winsys_id".
2014-07-01 17:23:05 +00:00
(gint64)output->winsys_id,
Introduce a new DBus interface for display configuration This new interface will be used by the control center and possibly the settings daemon to configure the screens. It is designed to resemble a simplified XRandR, while still exposing all the quirks of the hardware, so that the panel can limit the user choices appropriately. To do so, MetaMonitorMode needs to track CRTCs, outputs and modes, so the low level objects have been decoupled from the high-level MetaMonitorInfo, which is used by core and API and offers a simplified view of HW, that hides away the details of what is cloned and how. This is still not efficient as it should be, because on every HW change we drop all data structures and rebuild them from scratch (which is not expensive because there aren't many of them, but at least in the XRandR path it involves a few sync X calls) https://bugzilla.gnome.org/show_bug.cgi?id=705670
2013-07-19 12:39:28 +00:00
(int)(output->crtc ? output->crtc - manager->crtcs : -1),
&crtcs,
output->name,
&modes,
Extend the DBus XRandR protocol to expose cloning restriction Turns out that even if two outputs say that they can be controlled by a given CRTC, you can't configure them in the same CRTC unless they are marked as "possible clones" one of the other. This can further restrict the configuration options, so we need to expose this limitation in the DBus API. https://bugzilla.gnome.org/show_bug.cgi?id=705670
2013-07-19 16:47:01 +00:00
&clones,
Introduce a new DBus interface for display configuration This new interface will be used by the control center and possibly the settings daemon to configure the screens. It is designed to resemble a simplified XRandR, while still exposing all the quirks of the hardware, so that the panel can limit the user choices appropriately. To do so, MetaMonitorMode needs to track CRTCs, outputs and modes, so the low level objects have been decoupled from the high-level MetaMonitorInfo, which is used by core and API and offers a simplified view of HW, that hides away the details of what is cloned and how. This is still not efficient as it should be, because on every HW change we drop all data structures and rebuild them from scratch (which is not expensive because there aren't many of them, but at least in the XRandR path it involves a few sync X calls) https://bugzilla.gnome.org/show_bug.cgi?id=705670
2013-07-19 12:39:28 +00:00
&properties);
}
for (i = 0; i < manager->n_modes; i++)
{
MetaMonitorMode *mode = &manager->modes[i];
g_variant_builder_add (&mode_builder, "(uxuud)",
i, /* ID */
MonitorManager: make sure to pass the right sizes to vararg functions A gulong is not enough to get 64 bits in all arches, so we must cast it, or we can corrupt the stack. This was downstream bug bugzilla.redhat.com/show_bug.cgi?id=1002055 https://bugzilla.gnome.org/show_bug.cgi?id=707267
2013-09-02 07:29:26 +00:00
(gint64)mode->mode_id,
(guint32)mode->width,
(guint32)mode->height,
Introduce a new DBus interface for display configuration This new interface will be used by the control center and possibly the settings daemon to configure the screens. It is designed to resemble a simplified XRandR, while still exposing all the quirks of the hardware, so that the panel can limit the user choices appropriately. To do so, MetaMonitorMode needs to track CRTCs, outputs and modes, so the low level objects have been decoupled from the high-level MetaMonitorInfo, which is used by core and API and offers a simplified view of HW, that hides away the details of what is cloned and how. This is still not efficient as it should be, because on every HW change we drop all data structures and rebuild them from scratch (which is not expensive because there aren't many of them, but at least in the XRandR path it involves a few sync X calls) https://bugzilla.gnome.org/show_bug.cgi?id=705670
2013-07-19 12:39:28 +00:00
(double)mode->refresh_rate);
}
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),
manager->max_screen_width,
manager->max_screen_height);
return TRUE;
}
static gboolean
output_can_config (MetaOutput *output,
MetaCRTC *crtc,
MetaMonitorMode *mode)
{
unsigned int i;
gboolean ok = FALSE;
for (i = 0; i < output->n_possible_crtcs && !ok; i++)
ok = output->possible_crtcs[i] == crtc;
if (!ok)
return FALSE;
if (mode == NULL)
return TRUE;
ok = FALSE;
for (i = 0; i < output->n_modes && !ok; i++)
ok = output->modes[i] == mode;
return ok;
}
static gboolean
output_can_clone (MetaOutput *output,
MetaOutput *clone)
{
unsigned int i;
gboolean ok = FALSE;
for (i = 0; i < output->n_possible_clones && !ok; i++)
ok = output->possible_clones[i] == clone;
return ok;
}
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
void
meta_monitor_manager_apply_configuration (MetaMonitorManager *manager,
MonitorConfig: add CRTC assignment Ripped off libgnome-desktop, trimming the parts that checked that the configuration was plausible, as that should be done in gnome-control-center before asking mutter for a change. https://bugzilla.gnome.org/show_bug.cgi?id=705670
2013-07-24 16:01:31 +00:00
MetaCRTCInfo **crtcs,
unsigned int n_crtcs,
MetaOutputInfo **outputs,
unsigned int n_outputs)
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
{
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)->apply_configuration (manager,
crtcs, n_crtcs,
outputs, n_outputs);
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;
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
meta_monitor_config_restore_previous (manager->config, manager);
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
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;
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;
}
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
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_apply_configuration (MetaDBusDisplayConfig *skeleton,
GDBusMethodInvocation *invocation,
guint serial,
gboolean persistent,
GVariant *crtcs,
GVariant *outputs)
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
{
MonitorManager: inherit directly from DisplayConfig instead of handling signals This way we can handle properties too. https://bugzilla.gnome.org/show_bug.cgi?id=705670
2013-07-23 17:32:17 +00:00
MetaMonitorManager *manager = META_MONITOR_MANAGER (skeleton);
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
GVariantIter crtc_iter, output_iter, *nested_outputs;
MonitorConfig: add CRTC assignment Ripped off libgnome-desktop, trimming the parts that checked that the configuration was plausible, as that should be done in gnome-control-center before asking mutter for a change. https://bugzilla.gnome.org/show_bug.cgi?id=705670
2013-07-24 16:01:31 +00:00
GVariant *properties;
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
guint crtc_id;
int new_mode, x, y;
MonitorManager: ignore configuration changes that disable all outputs If we compute a screen size of 0 in either direction, we crash later on, as it is invalid for clutter, cogl and X. https://bugzilla.gnome.org/show_bug.cgi?id=705670
2013-07-26 13:31:17 +00:00
int new_screen_width, new_screen_height;
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
guint transform;
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;
MonitorConfig: add CRTC assignment Ripped off libgnome-desktop, trimming the parts that checked that the configuration was plausible, as that should be done in gnome-control-center before asking mutter for a change. https://bugzilla.gnome.org/show_bug.cgi?id=705670
2013-07-24 16:01:31 +00:00
GPtrArray *crtc_infos, *output_infos;
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
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;
}
MonitorConfig: add CRTC assignment Ripped off libgnome-desktop, trimming the parts that checked that the configuration was plausible, as that should be done in gnome-control-center before asking mutter for a change. https://bugzilla.gnome.org/show_bug.cgi?id=705670
2013-07-24 16:01:31 +00:00
crtc_infos = g_ptr_array_new_full (g_variant_n_children (crtcs),
(GDestroyNotify) meta_crtc_info_free);
output_infos = g_ptr_array_new_full (g_variant_n_children (outputs),
(GDestroyNotify) meta_output_info_free);
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
/* Validate all arguments */
MonitorManager: ignore configuration changes that disable all outputs If we compute a screen size of 0 in either direction, we crash later on, as it is invalid for clutter, cogl and X. https://bugzilla.gnome.org/show_bug.cgi?id=705670
2013-07-26 13:31:17 +00:00
new_screen_width = 0; new_screen_height = 0;
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_iter_init (&crtc_iter, crtcs);
while (g_variant_iter_loop (&crtc_iter, "(uiiiuaua{sv})",
&crtc_id, &new_mode, &x, &y, &transform,
&nested_outputs, NULL))
{
MonitorConfig: add CRTC assignment Ripped off libgnome-desktop, trimming the parts that checked that the configuration was plausible, as that should be done in gnome-control-center before asking mutter for a change. https://bugzilla.gnome.org/show_bug.cgi?id=705670
2013-07-24 16:01:31 +00:00
MetaCRTCInfo *crtc_info;
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
MetaOutput *first_output;
MetaCRTC *crtc;
MetaMonitorMode *mode;
MonitorConfig: add CRTC assignment Ripped off libgnome-desktop, trimming the parts that checked that the configuration was plausible, as that should be done in gnome-control-center before asking mutter for a change. https://bugzilla.gnome.org/show_bug.cgi?id=705670
2013-07-24 16:01:31 +00:00
crtc_info = g_slice_new (MetaCRTCInfo);
crtc_info->outputs = g_ptr_array_new ();
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
if (crtc_id >= manager->n_crtcs)
{
g_dbus_method_invocation_return_error (invocation, G_DBUS_ERROR,
G_DBUS_ERROR_INVALID_ARGS,
"Invalid CRTC id");
return TRUE;
}
crtc = &manager->crtcs[crtc_id];
MonitorConfig: add CRTC assignment Ripped off libgnome-desktop, trimming the parts that checked that the configuration was plausible, as that should be done in gnome-control-center before asking mutter for a change. https://bugzilla.gnome.org/show_bug.cgi?id=705670
2013-07-24 16:01:31 +00:00
crtc_info->crtc = crtc;
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
if (new_mode != -1 && (new_mode < 0 || (unsigned)new_mode >= manager->n_modes))
{
g_dbus_method_invocation_return_error (invocation, G_DBUS_ERROR,
G_DBUS_ERROR_INVALID_ARGS,
"Invalid mode id");
return TRUE;
}
mode = new_mode != -1 ? &manager->modes[new_mode] : NULL;
MonitorConfig: add CRTC assignment Ripped off libgnome-desktop, trimming the parts that checked that the configuration was plausible, as that should be done in gnome-control-center before asking mutter for a change. https://bugzilla.gnome.org/show_bug.cgi?id=705670
2013-07-24 16:01:31 +00:00
crtc_info->mode = mode;
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
MonitorManager: fix handling of output transform Read the current transform from XRandR, and expose the transforms that are really supported on the bus. The dummy backend now advertises all transforms, since it doesn't actually apply them. https://bugzilla.gnome.org/show_bug.cgi?id=705670
2013-07-24 08:01:57 +00:00
if (mode)
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
{
MonitorManager: fix handling of output transform Read the current transform from XRandR, and expose the transforms that are really supported on the bus. The dummy backend now advertises all transforms, since it doesn't actually apply them. https://bugzilla.gnome.org/show_bug.cgi?id=705670
2013-07-24 08:01:57 +00:00
int width, height;
if (meta_monitor_transform_is_rotated (transform))
{
width = mode->height;
height = mode->width;
}
else
{
width = mode->width;
height = mode->height;
}
if (x < 0 ||
x + width > manager->max_screen_width ||
y < 0 ||
y + height > manager->max_screen_height)
{
g_dbus_method_invocation_return_error (invocation, G_DBUS_ERROR,
G_DBUS_ERROR_INVALID_ARGS,
"Invalid CRTC geometry");
return TRUE;
}
MonitorManager: ignore configuration changes that disable all outputs If we compute a screen size of 0 in either direction, we crash later on, as it is invalid for clutter, cogl and X. https://bugzilla.gnome.org/show_bug.cgi?id=705670
2013-07-26 13:31:17 +00:00
new_screen_width = MAX (new_screen_width, x + width);
new_screen_height = MAX (new_screen_height, y + height);
crtc_info->x = x;
crtc_info->y = y;
}
else
{
crtc_info->x = 0;
crtc_info->y = 0;
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
}
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
if (transform < META_MONITOR_TRANSFORM_NORMAL ||
transform > META_MONITOR_TRANSFORM_FLIPPED_270 ||
MonitorManager: fix handling of output transform Read the current transform from XRandR, and expose the transforms that are really supported on the bus. The dummy backend now advertises all transforms, since it doesn't actually apply them. https://bugzilla.gnome.org/show_bug.cgi?id=705670
2013-07-24 08:01:57 +00:00
((crtc->all_transforms & (1 << transform)) == 0))
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_dbus_method_invocation_return_error (invocation, G_DBUS_ERROR,
G_DBUS_ERROR_INVALID_ARGS,
"Invalid transform");
return TRUE;
}
MonitorConfig: add CRTC assignment Ripped off libgnome-desktop, trimming the parts that checked that the configuration was plausible, as that should be done in gnome-control-center before asking mutter for a change. https://bugzilla.gnome.org/show_bug.cgi?id=705670
2013-07-24 16:01:31 +00:00
crtc_info->transform = transform;
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
first_output = NULL;
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
while (g_variant_iter_loop (nested_outputs, "u", &output_index))
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
{
MetaOutput *output;
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
if (output_index >= manager->n_outputs)
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_dbus_method_invocation_return_error (invocation, G_DBUS_ERROR,
G_DBUS_ERROR_INVALID_ARGS,
"Invalid output id");
return TRUE;
}
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
output = &manager->outputs[output_index];
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
if (!output_can_config (output, crtc, mode))
{
g_dbus_method_invocation_return_error (invocation, G_DBUS_ERROR,
G_DBUS_ERROR_INVALID_ARGS,
"Output cannot be assigned to this CRTC or mode");
return TRUE;
}
MonitorConfig: add CRTC assignment Ripped off libgnome-desktop, trimming the parts that checked that the configuration was plausible, as that should be done in gnome-control-center before asking mutter for a change. https://bugzilla.gnome.org/show_bug.cgi?id=705670
2013-07-24 16:01:31 +00:00
g_ptr_array_add (crtc_info->outputs, output);
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
if (first_output)
{
if (!output_can_clone (output, first_output))
{
g_dbus_method_invocation_return_error (invocation, G_DBUS_ERROR,
G_DBUS_ERROR_INVALID_ARGS,
"Outputs cannot be cloned");
return TRUE;
}
}
else
first_output = output;
}
if (!first_output && mode)
{
g_dbus_method_invocation_return_error (invocation, G_DBUS_ERROR,
G_DBUS_ERROR_INVALID_ARGS,
"Mode specified without outputs?");
return TRUE;
}
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
g_ptr_array_add (crtc_infos, crtc_info);
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
}
MonitorManager: ignore configuration changes that disable all outputs If we compute a screen size of 0 in either direction, we crash later on, as it is invalid for clutter, cogl and X. https://bugzilla.gnome.org/show_bug.cgi?id=705670
2013-07-26 13:31:17 +00:00
if (new_screen_width == 0 || new_screen_height == 0)
{
g_dbus_method_invocation_return_error (invocation, G_DBUS_ERROR,
G_DBUS_ERROR_INVALID_ARGS,
"Refusing to disable all outputs");
return TRUE;
}
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_iter_init (&output_iter, outputs);
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
while (g_variant_iter_loop (&output_iter, "(u@a{sv})", &output_index, &properties))
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
{
MonitorConfig: add CRTC assignment Ripped off libgnome-desktop, trimming the parts that checked that the configuration was plausible, as that should be done in gnome-control-center before asking mutter for a change. https://bugzilla.gnome.org/show_bug.cgi?id=705670
2013-07-24 16:01:31 +00:00
MetaOutputInfo *output_info;
gboolean primary, presentation;
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
if (output_index >= manager->n_outputs)
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_dbus_method_invocation_return_error (invocation, G_DBUS_ERROR,
G_DBUS_ERROR_INVALID_ARGS,
"Invalid output id");
return TRUE;
}
MonitorConfig: add CRTC assignment Ripped off libgnome-desktop, trimming the parts that checked that the configuration was plausible, as that should be done in gnome-control-center before asking mutter for a change. https://bugzilla.gnome.org/show_bug.cgi?id=705670
2013-07-24 16:01:31 +00:00
output_info = g_slice_new0 (MetaOutputInfo);
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
output_info->output = &manager->outputs[output_index];
MonitorConfig: add CRTC assignment Ripped off libgnome-desktop, trimming the parts that checked that the configuration was plausible, as that should be done in gnome-control-center before asking mutter for a change. https://bugzilla.gnome.org/show_bug.cgi?id=705670
2013-07-24 16:01:31 +00:00
if (g_variant_lookup (properties, "primary", "b", &primary))
output_info->is_primary = primary;
if (g_variant_lookup (properties, "presentation", "b", &presentation))
output_info->is_presentation = presentation;
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
g_ptr_array_add (output_infos, output_info);
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
}
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
/* If we were in progress of making a persistent change and we see a
new request, it's likely that the old one failed in some way, so
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
don't save it, but also don't queue for restoring it.
Remove trailing whitespace
2014-05-02 13:34:02 +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
if (manager->persistent_timeout_id && persistent)
{
g_source_remove (manager->persistent_timeout_id);
manager->persistent_timeout_id = 0;
}
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
MonitorConfig: add CRTC assignment Ripped off libgnome-desktop, trimming the parts that checked that the configuration was plausible, as that should be done in gnome-control-center before asking mutter for a change. https://bugzilla.gnome.org/show_bug.cgi?id=705670
2013-07-24 16:01:31 +00:00
meta_monitor_manager_apply_configuration (manager,
(MetaCRTCInfo**)crtc_infos->pdata,
crtc_infos->len,
(MetaOutputInfo**)output_infos->pdata,
output_infos->len);
g_ptr_array_unref (crtc_infos);
g_ptr_array_unref (output_infos);
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
/* Update MetaMonitorConfig data structures immediately so that we
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
don't revert the change at the next XRandR event, then ask the plugin
manager (through MetaScreen) to confirm the display change with the
appropriate UI. Then wait 20 seconds and if not confirmed, revert the
configuration.
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
*/
meta_monitor_config_update_current (manager->config, manager);
if (persistent)
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 = g_timeout_add_seconds (20, save_config_timeout, manager);
Name all timeouts and idles Better names can be used once we make more use of them. https://bugzilla.gnome.org/show_bug.cgi?id=727979
2014-04-10 16:58:58 +00:00
g_source_set_name_by_id (manager->persistent_timeout_id, "[mutter] save_config_timeout");
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
g_signal_emit (manager, signals[CONFIRM_DISPLAY_CHANGE], 0);
}
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
meta_dbus_display_config_complete_apply_configuration (skeleton, invocation);
return TRUE;
}
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
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;
}
g_source_remove (manager->persistent_timeout_id);
manager->persistent_timeout_id = 0;
if (ok)
meta_monitor_config_make_persistent (manager->config);
else
meta_monitor_config_restore_previous (manager->config, 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
static gboolean
meta_monitor_manager_handle_change_backlight (MetaDBusDisplayConfig *skeleton,
GDBusMethodInvocation *invocation,
guint serial,
monitor-manager: Rename output_id to output_index The term "output_id" is already used as an opaque ID.
2014-07-01 17:00:36 +00:00
guint output_index,
MonitorManager: add support for backlight GnomeRR needs that too. The backlight is exported as a normalized 0-100 value, or -1 if not supported. Clamping to HW limits is handled by the backend. Changing backlight uses a different method call, to avoid recomputing the full display configuration every time the user presses the backlight keys. https://bugzilla.gnome.org/show_bug.cgi?id=705670
2013-07-25 13:06:09 +00:00
gint value)
{
MetaMonitorManager *manager = META_MONITOR_MANAGER (skeleton);
MetaOutput *output;
if (serial != manager->serial)
{
g_dbus_method_invocation_return_error (invocation, G_DBUS_ERROR,
G_DBUS_ERROR_ACCESS_DENIED,
"The requested configuration is based on stale information");
return TRUE;
}
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
if (output_index >= manager->n_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;
}
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
output = &manager->outputs[output_index];
MonitorManager: add support for backlight GnomeRR needs that too. The backlight is exported as a normalized 0-100 value, or -1 if not supported. Clamping to HW limits is handled by the backend. Changing backlight uses a different method call, to avoid recomputing the full display configuration every time the user presses the backlight keys. https://bugzilla.gnome.org/show_bug.cgi?id=705670
2013-07-25 13:06:09 +00:00
if (value < 0 || value > 100)
{
g_dbus_method_invocation_return_error (invocation, G_DBUS_ERROR,
G_DBUS_ERROR_INVALID_ARGS,
"Invalid backlight value");
return TRUE;
}
if (output->backlight == -1 ||
(output->backlight_min == 0 && output->backlight_max == 0))
{
g_dbus_method_invocation_return_error (invocation, G_DBUS_ERROR,
G_DBUS_ERROR_INVALID_ARGS,
"Output does not support changing backlight");
return TRUE;
}
MonitorManager: split the XRandR parts in a subclass Instead of keeping a forest of if backend else ..., use a subclass and virtual functions to discriminate between XRandR and the dummy backend (which lives in the parent class togheter with the common code) https://bugzilla.gnome.org/show_bug.cgi?id=705670
2013-07-29 11:00:15 +00:00
META_MONITOR_MANAGER_GET_CLASS (manager)->change_backlight (manager, output, value);
MonitorManager: add support for backlight GnomeRR needs that too. The backlight is exported as a normalized 0-100 value, or -1 if not supported. Clamping to HW limits is handled by the backend. Changing backlight uses a different method call, to avoid recomputing the full display configuration every time the user presses the backlight keys. https://bugzilla.gnome.org/show_bug.cgi?id=705670
2013-07-25 13:06:09 +00:00
MonitorManager: return the new backlight after changing Modify the interface of ChangeBacklight to return the new value, to account for rounding to HW limits. https://bugzilla.gnome.org/show_bug.cgi?id=706729
2013-08-26 15:27:33 +00:00
meta_dbus_display_config_complete_change_backlight (skeleton, invocation, output->backlight);
MonitorManager: add support for backlight GnomeRR needs that too. The backlight is exported as a normalized 0-100 value, or -1 if not supported. Clamping to HW limits is handled by the backend. Changing backlight uses a different method call, to avoid recomputing the full display configuration every time the user presses the backlight keys. https://bugzilla.gnome.org/show_bug.cgi?id=705670
2013-07-25 13:06:09 +00:00
return TRUE;
}
MonitorManager: add gamma support Add GetCrtcGamma() and SetCrtcGamma(), that wrap the similarly named XRandR API. These are used by GnomeRR inside the color plugin of the control center (and may go away if the color plugin decides to do something different under wayland) https://bugzilla.gnome.org/show_bug.cgi?id=705670
2013-07-26 13:57:34 +00:00
static gboolean
meta_monitor_manager_handle_get_crtc_gamma (MetaDBusDisplayConfig *skeleton,
GDBusMethodInvocation *invocation,
guint serial,
guint crtc_id)
{
MetaMonitorManager *manager = META_MONITOR_MANAGER (skeleton);
MonitorManager: split the XRandR parts in a subclass Instead of keeping a forest of if backend else ..., use a subclass and virtual functions to discriminate between XRandR and the dummy backend (which lives in the parent class togheter with the common code) https://bugzilla.gnome.org/show_bug.cgi?id=705670
2013-07-29 11:00:15 +00:00
MetaMonitorManagerClass *klass;
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
MetaCRTC *crtc;
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;
}
if (crtc_id >= manager->n_crtcs)
{
g_dbus_method_invocation_return_error (invocation, G_DBUS_ERROR,
G_DBUS_ERROR_INVALID_ARGS,
"Invalid crtc id");
return TRUE;
}
crtc = &manager->crtcs[crtc_id];
MonitorManager: split the XRandR parts in a subclass Instead of keeping a forest of if backend else ..., use a subclass and virtual functions to discriminate between XRandR and the dummy backend (which lives in the parent class togheter with the common code) https://bugzilla.gnome.org/show_bug.cgi?id=705670
2013-07-29 11:00:15 +00:00
klass = META_MONITOR_MANAGER_GET_CLASS (manager);
if (klass->get_crtc_gamma)
klass->get_crtc_gamma (manager, crtc, &size, &red, &green, &blue);
MonitorManager: add gamma support Add GetCrtcGamma() and SetCrtcGamma(), that wrap the similarly named XRandR API. These are used by GnomeRR inside the color plugin of the control center (and may go away if the color plugin decides to do something different under wayland) https://bugzilla.gnome.org/show_bug.cgi?id=705670
2013-07-26 13:57:34 +00:00
else
MonitorManager: split the XRandR parts in a subclass Instead of keeping a forest of if backend else ..., use a subclass and virtual functions to discriminate between XRandR and the dummy backend (which lives in the parent class togheter with the common code) https://bugzilla.gnome.org/show_bug.cgi?id=705670
2013-07-29 11:00:15 +00:00
{
size = 0;
red = green = blue = NULL;
}
MonitorManager: add gamma support Add GetCrtcGamma() and SetCrtcGamma(), that wrap the similarly named XRandR API. These are used by GnomeRR inside the color plugin of the control center (and may go away if the color plugin decides to do something different under wayland) https://bugzilla.gnome.org/show_bug.cgi?id=705670
2013-07-26 13:57:34 +00:00
red_bytes = g_bytes_new_take (red, size * sizeof (unsigned short));
green_bytes = g_bytes_new_take (green, size * sizeof (unsigned short));
blue_bytes = g_bytes_new_take (blue, size * sizeof (unsigned short));
red_v = g_variant_new_from_bytes (G_VARIANT_TYPE ("aq"), red_bytes, TRUE);
green_v = g_variant_new_from_bytes (G_VARIANT_TYPE ("aq"), green_bytes, TRUE);
blue_v = g_variant_new_from_bytes (G_VARIANT_TYPE ("aq"), blue_bytes, TRUE);
meta_dbus_display_config_complete_get_crtc_gamma (skeleton, invocation,
red_v, green_v, blue_v);
g_bytes_unref (red_bytes);
g_bytes_unref (green_bytes);
g_bytes_unref (blue_bytes);
return TRUE;
}
static gboolean
meta_monitor_manager_handle_set_crtc_gamma (MetaDBusDisplayConfig *skeleton,
GDBusMethodInvocation *invocation,
guint serial,
guint crtc_id,
GVariant *red_v,
GVariant *green_v,
GVariant *blue_v)
{
MetaMonitorManager *manager = META_MONITOR_MANAGER (skeleton);
MonitorManager: split the XRandR parts in a subclass Instead of keeping a forest of if backend else ..., use a subclass and virtual functions to discriminate between XRandR and the dummy backend (which lives in the parent class togheter with the common code) https://bugzilla.gnome.org/show_bug.cgi?id=705670
2013-07-29 11:00:15 +00:00
MetaMonitorManagerClass *klass;
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
MetaCRTC *crtc;
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;
}
if (crtc_id >= manager->n_crtcs)
{
g_dbus_method_invocation_return_error (invocation, G_DBUS_ERROR,
G_DBUS_ERROR_INVALID_ARGS,
"Invalid crtc id");
return TRUE;
}
crtc = &manager->crtcs[crtc_id];
red_bytes = g_variant_get_data_as_bytes (red_v);
green_bytes = g_variant_get_data_as_bytes (green_v);
blue_bytes = g_variant_get_data_as_bytes (blue_v);
size = g_bytes_get_size (red_bytes) / sizeof (unsigned short);
red = (unsigned short*) g_bytes_get_data (red_bytes, &dummy);
green = (unsigned short*) g_bytes_get_data (green_bytes, &dummy);
blue = (unsigned short*) g_bytes_get_data (blue_bytes, &dummy);
MonitorManager: split the XRandR parts in a subclass Instead of keeping a forest of if backend else ..., use a subclass and virtual functions to discriminate between XRandR and the dummy backend (which lives in the parent class togheter with the common code) https://bugzilla.gnome.org/show_bug.cgi?id=705670
2013-07-29 11:00:15 +00:00
klass = META_MONITOR_MANAGER_GET_CLASS (manager);
if (klass->set_crtc_gamma)
klass->set_crtc_gamma (manager, crtc, size, red, green, blue);
MonitorManager: add gamma support Add GetCrtcGamma() and SetCrtcGamma(), that wrap the similarly named XRandR API. These are used by GnomeRR inside the color plugin of the control center (and may go away if the color plugin decides to do something different under wayland) https://bugzilla.gnome.org/show_bug.cgi?id=705670
2013-07-26 13:57:34 +00:00
meta_dbus_display_config_complete_set_crtc_gamma (skeleton, invocation);
g_bytes_unref (red_bytes);
g_bytes_unref (green_bytes);
g_bytes_unref (blue_bytes);
return TRUE;
}
MonitorManager: inherit directly from DisplayConfig instead of handling signals This way we can handle properties too. https://bugzilla.gnome.org/show_bug.cgi?id=705670
2013-07-23 17:32:17 +00:00
static void
meta_monitor_manager_display_config_init (MetaDBusDisplayConfigIface *iface)
{
iface->handle_get_resources = meta_monitor_manager_handle_get_resources;
iface->handle_apply_configuration = meta_monitor_manager_handle_apply_configuration;
MonitorManager: add support for backlight GnomeRR needs that too. The backlight is exported as a normalized 0-100 value, or -1 if not supported. Clamping to HW limits is handled by the backend. Changing backlight uses a different method call, to avoid recomputing the full display configuration every time the user presses the backlight keys. https://bugzilla.gnome.org/show_bug.cgi?id=705670
2013-07-25 13:06:09 +00:00
iface->handle_change_backlight = meta_monitor_manager_handle_change_backlight;
MonitorManager: add gamma support Add GetCrtcGamma() and SetCrtcGamma(), that wrap the similarly named XRandR API. These are used by GnomeRR inside the color plugin of the control center (and may go away if the color plugin decides to do something different under wayland) https://bugzilla.gnome.org/show_bug.cgi?id=705670
2013-07-26 13:57:34 +00:00
iface->handle_get_crtc_gamma = meta_monitor_manager_handle_get_crtc_gamma;
iface->handle_set_crtc_gamma = meta_monitor_manager_handle_set_crtc_gamma;
MonitorManager: inherit directly from DisplayConfig instead of handling signals This way we can handle properties too. https://bugzilla.gnome.org/show_bug.cgi?id=705670
2013-07-23 17:32:17 +00:00
}
Introduce a new DBus interface for display configuration This new interface will be used by the control center and possibly the settings daemon to configure the screens. It is designed to resemble a simplified XRandR, while still exposing all the quirks of the hardware, so that the panel can limit the user choices appropriately. To do so, MetaMonitorMode needs to track CRTCs, outputs and modes, so the low level objects have been decoupled from the high-level MetaMonitorInfo, which is used by core and API and offers a simplified view of HW, that hides away the details of what is cloned and how. This is still not efficient as it should be, because on every HW change we drop all data structures and rebuild them from scratch (which is not expensive because there aren't many of them, but at least in the XRandR path it involves a few sync X calls) https://bugzilla.gnome.org/show_bug.cgi?id=705670
2013-07-19 12:39:28 +00:00
static void
on_bus_acquired (GDBusConnection *connection,
const char *name,
gpointer user_data)
{
MetaMonitorManager *manager = user_data;
MonitorManager: inherit directly from DisplayConfig instead of handling signals This way we can handle properties too. https://bugzilla.gnome.org/show_bug.cgi?id=705670
2013-07-23 17:32:17 +00:00
g_dbus_interface_skeleton_export (G_DBUS_INTERFACE_SKELETON (manager),
Introduce a new DBus interface for display configuration This new interface will be used by the control center and possibly the settings daemon to configure the screens. It is designed to resemble a simplified XRandR, while still exposing all the quirks of the hardware, so that the panel can limit the user choices appropriately. To do so, MetaMonitorMode needs to track CRTCs, outputs and modes, so the low level objects have been decoupled from the high-level MetaMonitorInfo, which is used by core and API and offers a simplified view of HW, that hides away the details of what is cloned and how. This is still not efficient as it should be, because on every HW change we drop all data structures and rebuild them from scratch (which is not expensive because there aren't many of them, but at least in the XRandR path it involves a few sync X calls) https://bugzilla.gnome.org/show_bug.cgi?id=705670
2013-07-19 12:39:28 +00:00
connection,
"/org/gnome/Mutter/DisplayConfig",
NULL);
}
static void
on_name_acquired (GDBusConnection *connection,
const char *name,
gpointer user_data)
{
meta_topic (META_DEBUG_DBUS, "Acquired name %s\n", name);
}
static void
on_name_lost (GDBusConnection *connection,
const char *name,
gpointer user_data)
{
meta_topic (META_DEBUG_DBUS, "Lost or failed to acquire name %s\n", name);
}
static void
initialize_dbus_interface (MetaMonitorManager *manager)
{
manager->dbus_name_id = g_bus_own_name (G_BUS_TYPE_SESSION,
"org.gnome.Mutter.DisplayConfig",
G_BUS_NAME_OWNER_FLAGS_ALLOW_REPLACEMENT |
(meta_get_replace_current_wm () ?
G_BUS_NAME_OWNER_FLAGS_REPLACE : 0),
on_bus_acquired,
on_name_acquired,
on_name_lost,
g_object_ref (manager),
g_object_unref);
}
monitor-manager: Expose MetaMonitorManager to introspection This just exposes the type and the singleton getter necessary to make it available to introspection. We'll expose more functionality as it becomes needed. https://bugzilla.gnome.org/show_bug.cgi?id=743745
2015-01-30 13:51:18 +00:00
/**
* meta_monitor_manager_get:
*
* Accessor for the singleton MetaMonitorManager.
*
* Returns: (transfer none): The only #MetaMonitorManager there is.
*/
Rework and consolidate monitor handling in MetaScreen Consolidate all places that deal with output configuration in MetaScreen, which gets it either from XRandR or from a dummy static configuration. We still need to read the Xinerama config, even when running xwayland, because we need the indices for _NET_WM_FULLSCREEN_MONITORS, but now we do it only when needed. https://bugzilla.gnome.org/show_bug.cgi?id=705670
2013-07-18 11:09:16 +00:00
MetaMonitorManager *
meta_monitor_manager_get (void)
{
backends: Move MonitorManager creation to MetaBackend as well
2014-04-21 23:41:11 +00:00
MetaBackend *backend = meta_get_backend ();
Rework and consolidate monitor handling in MetaScreen Consolidate all places that deal with output configuration in MetaScreen, which gets it either from XRandR or from a dummy static configuration. We still need to read the Xinerama config, even when running xwayland, because we need the indices for _NET_WM_FULLSCREEN_MONITORS, but now we do it only when needed. https://bugzilla.gnome.org/show_bug.cgi?id=705670
2013-07-18 11:09:16 +00:00
backends: Move MonitorManager creation to MetaBackend as well
2014-04-21 23:41:11 +00:00
return meta_backend_get_monitor_manager (backend);
Rework and consolidate monitor handling in MetaScreen Consolidate all places that deal with output configuration in MetaScreen, which gets it either from XRandR or from a dummy static configuration. We still need to read the Xinerama config, even when running xwayland, because we need the indices for _NET_WM_FULLSCREEN_MONITORS, but now we do it only when needed. https://bugzilla.gnome.org/show_bug.cgi?id=705670
2013-07-18 11:09:16 +00:00
}
MetaMonitorInfo *
meta_monitor_manager_get_monitor_infos (MetaMonitorManager *manager,
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
unsigned int *n_infos)
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
{
*n_infos = manager->n_monitor_infos;
return manager->monitor_infos;
}
MetaOutput *
meta_monitor_manager_get_outputs (MetaMonitorManager *manager,
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
unsigned int *n_outputs)
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
{
*n_outputs = manager->n_outputs;
return manager->outputs;
}
MonitorConfig: add CRTC assignment Ripped off libgnome-desktop, trimming the parts that checked that the configuration was plausible, as that should be done in gnome-control-center before asking mutter for a change. https://bugzilla.gnome.org/show_bug.cgi?id=705670
2013-07-24 16:01:31 +00:00
void
meta_monitor_manager_get_resources (MetaMonitorManager *manager,
MetaMonitorMode **modes,
unsigned int *n_modes,
MetaCRTC **crtcs,
unsigned int *n_crtcs,
MetaOutput **outputs,
unsigned int *n_outputs)
{
wayland: implement HW cursors Use the DRM API and libgbm to upload cursor buffers to the appropriate HW plane, saving on GL calls and compositing. https://bugzilla.gnome.org/show_bug.cgi?id=707573
2013-09-05 14:45:41 +00:00
if (modes)
{
*modes = manager->modes;
*n_modes = manager->n_modes;
}
if (crtcs)
{
*crtcs = manager->crtcs;
*n_crtcs = manager->n_crtcs;
}
if (outputs)
{
*outputs = manager->outputs;
*n_outputs = manager->n_outputs;
}
MonitorConfig: add CRTC assignment Ripped off libgnome-desktop, trimming the parts that checked that the configuration was plausible, as that should be done in gnome-control-center before asking mutter for a change. https://bugzilla.gnome.org/show_bug.cgi?id=705670
2013-07-24 16:01:31 +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
int
meta_monitor_manager_get_primary_index (MetaMonitorManager *manager)
{
return manager->primary_monitor_index;
}
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;
}
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
void
meta_monitor_manager_get_screen_limits (MetaMonitorManager *manager,
int *width,
int *height)
{
*width = manager->max_screen_width;
*height = manager->max_screen_height;
}
monitor-manager: Simplify reading the current configuration Make a wrapper in MetaMonitorManager that handles freeing the existing configuration for us.
2014-10-12 20:35:55 +00:00
void
meta_monitor_manager_read_current_config (MetaMonitorManager *manager)
{
MetaOutput *old_outputs;
MetaCRTC *old_crtcs;
MetaMonitorMode *old_modes;
unsigned int n_old_outputs, n_old_modes;
/* Some implementations of read_current use the existing information
* we have available, so don't free the old configuration until after
* read_current finishes. */
old_outputs = manager->outputs;
n_old_outputs = manager->n_outputs;
old_modes = manager->modes;
n_old_modes = manager->n_modes;
old_crtcs = manager->crtcs;
manager->serial++;
META_MONITOR_MANAGER_GET_CLASS (manager)->read_current (manager);
meta_monitor_manager_free_output_array (old_outputs, n_old_outputs);
meta_monitor_manager_free_mode_array (old_modes, n_old_modes);
g_free (old_crtcs);
}
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
meta_monitor_manager_rebuild_derived (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
{
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
MetaMonitorInfo *old_monitor_infos;
old_monitor_infos = manager->monitor_infos;
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;
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
make_logical_config (manager);
MonitorManager: emit a DBus signal when we change the display configuration Using out-of-band notifications from the wayland protocol or from X is racy, in that the client could ask for the new resources before we have them. Instead, with a signal, we are sure that when the client asks for it, it will get the right values. https://bugzilla.gnome.org/show_bug.cgi?id=706382
2013-08-20 11:25:42 +00:00
g_signal_emit_by_name (manager, "monitors-changed");
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
g_free (old_monitor_infos);
DisplayConfig: make the dummy backend writable Add a number of dummy outputs and modes to the dummy backend, and implement the writing bits. The only visible effect is that you can change the screen size, which resizes the output window. https://bugzilla.gnome.org/show_bug.cgi?id=705670
2013-07-23 08:07:52 +00:00
}
monitor-manager: Put the common hotplug code in a common path as well So we can reuse it in the KMS backend.
2014-10-12 22:13:15 +00:00
backends: Make KMS EDID information equal to X11's EDID parsing has been refactored to a common meta_output_parse_edid() function, which ensures the extracted information is the same on both KMS and X11 backend, so it can be used consistently on eg. settings values. https://bugzilla.gnome.org/show_bug.cgi?id=742882
2015-01-04 20:24:05 +00:00
void
meta_output_parse_edid (MetaOutput *meta_output,
GBytes *edid)
{
MonitorInfo *parsed_edid;
gsize len;
monitor-manager: Initialize MetaOutput even when we can't get the EDID Otherwise we'll crash later when building a MetaConfiguration. https://bugzilla.gnome.org/show_bug.cgi?id=743412
2015-01-23 16:32:21 +00:00
if (!edid)
goto out;
backends: Make KMS EDID information equal to X11's EDID parsing has been refactored to a common meta_output_parse_edid() function, which ensures the extracted information is the same on both KMS and X11 backend, so it can be used consistently on eg. settings values. https://bugzilla.gnome.org/show_bug.cgi?id=742882
2015-01-04 20:24:05 +00:00
parsed_edid = decode_edid (g_bytes_get_data (edid, &len));
if (parsed_edid)
{
meta_output->vendor = g_strndup (parsed_edid->manufacturer_code, 4);
if (parsed_edid->dsc_product_name[0])
meta_output->product = g_strndup (parsed_edid->dsc_product_name, 14);
else
meta_output->product = g_strdup_printf ("0x%04x", (unsigned) parsed_edid->product_code);
if (parsed_edid->dsc_serial_number[0])
meta_output->serial = g_strndup (parsed_edid->dsc_serial_number, 14);
else
meta_output->serial = g_strdup_printf ("0x%08x", parsed_edid->serial_number);
g_free (parsed_edid);
}
monitor-manager: Initialize MetaOutput even when we can't get the EDID Otherwise we'll crash later when building a MetaConfiguration. https://bugzilla.gnome.org/show_bug.cgi?id=743412
2015-01-23 16:32:21 +00:00
out:
backends: Make KMS EDID information equal to X11's EDID parsing has been refactored to a common meta_output_parse_edid() function, which ensures the extracted information is the same on both KMS and X11 backend, so it can be used consistently on eg. settings values. https://bugzilla.gnome.org/show_bug.cgi?id=742882
2015-01-04 20:24:05 +00:00
if (!meta_output->vendor)
{
meta_output->vendor = g_strdup ("unknown");
meta_output->product = g_strdup ("unknown");
meta_output->serial = g_strdup ("unknown");
}
}
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
void
meta_monitor_manager_on_hotplug (MetaMonitorManager *manager)
{
gboolean applied_config = FALSE;
/* If the monitor has hotplug_mode_update (which is used by VMs), don't bother
* applying our stored configuration, because it's likely the user just resizing
* the window.
*/
if (!meta_monitor_manager_has_hotplug_mode_update (manager))
{
if (meta_monitor_config_apply_stored (manager->config, manager))
applied_config = TRUE;
}
/* If we haven't applied any configuration, apply the default configuration. */
if (!applied_config)
meta_monitor_config_make_default (manager->config, manager);
}
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,
MetaOutput *output,
gfloat viewport[6])
{
gfloat x, y, width, height;
if (!output->crtc)
return FALSE;
x = (float) output->crtc->rect.x / manager->screen_width;
y = (float) output->crtc->rect.y / manager->screen_height;
width = (float) output->crtc->rect.width / manager->screen_width;
height = (float) output->crtc->rect.height / manager->screen_height;
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,
MetaOutput *output,
gfloat matrix[6])
{
gfloat viewport[9];
if (!calculate_viewport_matrix (manager, output, viewport))
return FALSE;
multiply_matrix (viewport, transform_matrices[output->crtc->transform],
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
/**
* meta_monitor_manager_get_output_geometry:
* @manager: A #MetaMonitorManager
* @id: A valid #MetaOutput id
*
* Returns: The monitor index or -1 if @id isn't valid or the output
* isn't associated with a logical monitor.
*/
gint
meta_monitor_manager_get_monitor_for_output (MetaMonitorManager *manager,
guint id)
{
MetaOutput *output;
guint i;
g_return_val_if_fail (META_IS_MONITOR_MANAGER (manager), -1);
g_return_val_if_fail (id < manager->n_outputs, -1);
output = &manager->outputs[id];
if (!output || !output->crtc)
return -1;
for (i = 0; i < manager->n_monitor_infos; i++)
if (meta_rectangle_contains_rect (&manager->monitor_infos[i].rect,
&output->crtc->rect))
return i;
return -1;
}
Reference in New Issue Copy Permalink