external/internal monitors mirrored on boot when laptop lid is closed

Bug #1065979 reported by Chris J Arges on 2012-10-12
This bug affects 4 people
Affects Status Importance Assigned to Milestone
GNOME Settings Daemon
Fix Released
gnome-settings-daemon (Ubuntu)

Bug Description


 * Booting laptop in docking station with lid closed results in low resolution (1024x768/aka clone mode) on external monitor
 * Low resolution desktop (1024x768) when user logs in, must be manually set to optimal resolution for external montior
 * non-technical users would find the default behaviour not the desired behaviour.

[Test Case]
Steps to Reproduce:
  1. Connect an external monitor to laptop.
  2. Boot system with lid closed with a clean new user
  3. Login screen is shown at 1024x768 ( the highest common resolution supported by both the displays)

 The laptop display ( say 1366x768) should have a lower resolution than the connected external monitor ( say 1920x1080 ) .

[Regression Potential]
 * I dont see any regression potential here, as this does not change any default behaviour.
 * User must manually activate this "new" behaviour .

[Other Info]
 * test packages have been posted to - http://people.canonical.com/~ritesh/work/gsd/
 * Update to this, and update default to "follow-lid"
     $ gsettings set org.gnome.settings-daemon.plugins.xrandr \
       default-monitors-setup "follow-lid"
 * test as usual


If I put my X220 in a dock, and plug in an external monitor. Then I close the lid and turn on the computer, the computer will boot up with both the internal laptop screen and external monitor on and mirror. Because I can't see the laptop screen, I would expect the external monitor to be only on at its maximum resolution. I've actually tried this without the dock by plugging in an external monitor to my laptop and shutting the lid during boot quickly, the same problem persists. This problem is exhibited on Precise/Oneiric as well as Quantal.

In particular this specification mentions this behavior:
In this user story:
"""Alan goes to the office, puts his laptop with the lid closed into a docking station and boots it up. The external display should be run at its native resolution. Later that day he needs to see a customer. He suspends the laptop and takes it out of the docking station. At the customer he wakes up the laptop and the internal screen is used at its native resolution. Finishing his visit the laptop is suspended, brought back to the office. There it is placed in the docking station, woken up and the external display should run again at its native resolution."""

Chris J Arges (arges) wrote :
Changed in xserver-xorg-video-intel (Ubuntu):
importance: Undecided → Medium
Changed in xserver-xorg-video-intel (Ubuntu Oneiric):
importance: Undecided → Medium
Changed in xserver-xorg-video-intel (Ubuntu Precise):
importance: Undecided → Medium
description: updated
Changed in xserver-xorg-video-intel (Ubuntu Oneiric):
status: New → Won't Fix
Changed in xserver-xorg-video-intel (Ubuntu Precise):
status: New → Triaged
importance: Medium → Low
status: Triaged → New
Changed in xserver-xorg-video-intel (Ubuntu Quantal):
importance: Medium → Low
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in xserver-xorg-video-intel (Ubuntu Precise):
status: New → Confirmed
Changed in xserver-xorg-video-intel (Ubuntu):
status: New → Confirmed
Sebastien Bacher (seb128) wrote :

Hey X guys, do you think it's something you could have a look at?

Changed in xserver-xorg-video-intel (Ubuntu Precise):
assignee: nobody → Canonical X.org (canonical-x)
importance: Low → High
Chris J Arges (arges) wrote :

One note, if I select 'automatically log in', then the computer boots up into the proper resolution.
However if I first 'log in' then the resolution changes to low and mirrored.

Chris J Arges (arges) wrote :

Also, when booting up the boot screen has the external monitor at full resolution.
Unity-greeter has the low, mirrored resolution.
And finally when I log in, I will stay at the mirrored resolution if .config/monitors.xml isn't set, otherwise if that file is set I will get the proper resolution.

Eric Williams (eric-canonical) wrote :

I've confirmed this happens on Fedora as well:

- splash screens are proper resolution on both monitor and internal LCD

- GDM starting puts the monitors into clone mode

Attaching an SOSreport of that machine for comparison.


Bryce Harrington (bryce) on 2012-10-17
Changed in xserver-xorg-video-intel (Ubuntu Precise):
assignee: Canonical X.org (canonical-x) → Bryce Harrington (bryce)
Sebastien Bacher (seb128) wrote :

the "set in mirror" could be g-s-d doing in fact, could you try if that happens if you move "/usr/lib/gnome-settings-daemon-3.0/libxrandr.so" somewhere else? (e.g that will disable the xrandr code from g-s-d)

Bryce Harrington (bryce) wrote :

No, it's not g-s-d, but X that is setting it to mirrored in this case. From the Xorg.0.log, after correctly detecting all the resolutions:

[ 16.904] (II) intel(0): Using fuzzy aspect match for initial modes
[ 16.904] (II) intel(0): Output LVDS1 using initial mode 1024x768
[ 16.904] (II) intel(0): Output VGA1 using initial mode 1024x768

This is the standard default behavior that X.org provides, so is not an X bug. Policy is handled at the gnome-settings-daemon layer, so g-s-d *should* be putting your monitors into the extended configuration by default as per the referenced multi-monitor design specification. X.org does not track power or lid open/closed status so probably couldn't make correct decisions anyway.

Unfortunately a large amount of what's in the specification is the correct design yet simply hasn't been implemented, and that includes this use case. Thus I think this is probably best carried as a wishlist bug for gnome-settings-daemon.

Theoretically we could simply hack X.org to do extended by default (this was experimented with briefly back when RANDR was first introduced). The problem arises that in certain circumstances (e.g. projectors), defaulting to extended can lead to confusing and undesired behaviors; in fact there was discussion at some point by the design team to make mirrored the default again, but I don't know the status on that.

Anyway, if/when this does get implemented, it will probably be too invasive of a change to consider backporting, so the precise and quantal tasks will have to be wontfix. For raring, we have a defined focus for development which excludes development work for multimonitor, so I'll target this bug to S.

Changed in xserver-xorg-video-intel (Ubuntu Quantal):
status: Confirmed → Won't Fix
Changed in xserver-xorg-video-intel (Ubuntu Precise):
status: Confirmed → Won't Fix
assignee: Bryce Harrington (bryce) → nobody
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Bryce Harrington (bryce) on 2012-10-25
affects: xserver-xorg-video-intel (Ubuntu) → gnome-settings-daemon (Ubuntu)
Changed in gnome-settings-daemon (Ubuntu):
importance: Low → Wishlist
Changed in gnome-settings-daemon (Ubuntu Quantal):
importance: Low → Wishlist
Changed in gnome-settings-daemon (Ubuntu Precise):
importance: High → Wishlist
Changed in gnome-settings-daemon (Ubuntu Oneiric):
importance: Medium → Wishlist
Ritesh Khadgaray (khadgaray) wrote :


  The default behaviour is to do nothing. And unity-greeter defaults to mirror mode by disabling xrandr plugin.

unity-greeter (0.1.0-0ubuntu1) oneiric; urgency=low
    - Disable xrandr gnome-settings-daemon plugin - always mirror the displays

The proposed patch will allow system admin to add "xinerama" mode as default option. Alternative workaround is to pop up a question asking user to configure the monitor setup ( which could be painful ) .

__self: test patch ( lacking the h/w to currently test this ) .

Sebastien Bacher (seb128) wrote :

Can you upstream the patch as well?

The attachment "proposed patch based of upstream code" of this bug report has been identified as being a patch. The ubuntu-reviewers team has been subscribed to the bug report so that they can review the patch. In the event that this is in fact not a patch you can resolve this situation by removing the tag 'patch' from the bug report and editing the attachment so that it is not flagged as a patch. Additionally, if you are member of the ubuntu-reviewers team please also unsubscribe the team from this bug report.

[This is an automated message performed by a Launchpad user owned by Brian Murray. Please contact him regarding any issues with the action taken in this bug report.]

tags: added: patch
Changed in gnome-settings-daemon:
importance: Unknown → Medium
status: Unknown → Fix Released
Sebastien Bacher (seb128) wrote :

Ritesh: do you have a pointer to the corresponding upstream patch/fix/commit? The one on the bug pointed there, http://git.gnome.org/browse/gnome-settings-daemon/patch/?id=32f7a938fca072e14bad1928b492e29ba0e3090c is quite different

Ritesh Khadgaray (khadgaray) wrote :


 * Booting laptop in docking station with lid closed results in low resolution (1024x768) on external monitor
 * Machine uses Mirror-Mode when booting even when laptop lid is closed
 * Low resolution desktop (1024x768) when user logs in, must be manually set to optimal resolution for external montior
 * Customer is preparing rollout to many non-technical users. Manually setting resolution should not be required.

[Test Case]
Steps to Reproduce:
  1. Boot system in docking station with lid closed
  2. Login screen is shown at 1024x768

After login, user desktop is still 1024x768
Manually setting resolution to optimal is successful

[Regression Potential]

 * I dont see any regression potential here, except for the user to end up auto configured optimal setup as seen in upstream code.
 * This may break display setup on really broken display drivers ( worst case/lid closed detection fails), in which we need to fix the bug with kernel/xorg .

tags: added: precise raring
removed: amd64 apport-bug compiz-0.9 running-unity ubuntu
Sebastien Bacher (seb128) wrote :

@Ritesh: thanks, is that change coming from upstream or being discussed with them? Do you have an bugzilla reference or git commit id for it?

Ritesh Khadgaray (khadgaray) wrote :

Hi @seb128

  This is a modified version of the patch pushed upstream. The upstream seems to have independently written a patch to implement the same idea. The added an option to use the default configuration ( which I have skipped here, as I do not see much use for this ).

  I have posted the gnome bz to the lp, and the git commit -
* http://git.gnome.org/browse/gnome-settings-daemon/commit/plugins/xrandr/gsd-xrandr-manager.c?id=32f7a938fca072e14bad1928b492e29ba0e3090c

The new follow-lid action was added here, which I have skipped over.

-- ritz

Ritesh Khadgaray (khadgaray) wrote :

This tested with on Lenovo x220 w/ intel. The behaviour will be the same with radeon/nv.

* booting with lid closed
* boot with lid closed, open lid and close again
* boot wit lid closed, suspend and resume
* boot with lid close, open lid, suspend and resume
* boot with lid close, open lid, suspend, close lid, resume

I also expect this behaviour to be unchanged for sis/matrox/ and other obscure card. Worst case, we enable a display which is not present ( assuming monitor detection is broken, which not should happen ).

-- ritz

Sebastien Bacher (seb128) wrote :

@Ritesh: looking again to that issue and your patch, they are several problems

* you are changing "do-nothing" to do something, the main reason that this setting was added is that the xrandr calls can be slow on some drivers (e.g taking over a second), your patch will add several seconds delay on boot on some configuration

* you make the default to be xinerama when there is no lid closed, that's wrong in some cases.
E.g we want to default to mirror for projectors configurations) ... there is no good way to detect projectors at the moment though, that's why we default to mirror

* the lid status is not an accurate info, some hardware don't rely that status correctly

Did you consider suggesting to the customer to just change the "default-monitors-setup" gsettings key from 'do-nothing' to 'dock'.
The schemas documentation says: 'dock' will switch off the internal monitor

That seems like what they want, and they should be able to just deplay a custom settings package including a schemas override easily?

Ritesh Khadgaray (khadgaray) wrote :
Download full text (3.9 KiB)

> * you are changing "do-nothing" to do something, the main reason that this
> setting was added is that the xrandr calls can be slow on some drivers
> (e.g taking over a second), your patch will add several seconds delay on boot
> on some configuration

The upstream code has changed this behaviour. The patch reflects the upstream behaviour closely.

from gsd-xrandr-manager.c

1692 static GnomeRRConfig *
1693 make_default_setup (GsdXrandrManager *manager)
1694 {
1695 GsdXrandrManagerPrivate *priv = manager->priv;
1696 GnomeRRConfig *config;
1697 GsdXrandrBootBehaviour boot;
1699 boot = g_settings_get_enum (priv->settings, CONF_KEY_DEFAULT_MONITORS_SETUP);
1700 g_debug ("xrandr default monitors setup: %d\n", boot);
1702 switch (boot) {
1704 config = make_xinerama_setup (manager, priv->rw_screen);
1705 break;
1707 if (laptop_lid_is_closed (manager))
1708 config = make_other_setup (priv->rw_screen);
1709 else
1710 config = make_xinerama_setup (manager, priv->rw_screen);
1711 break;
1713 config = make_clone_setup (manager, priv->rw_screen);
1714 break;
1716 config = make_other_setup (priv->rw_screen);
1717 break;
1718 default:
1719 g_assert_not_reached ();
1720 }
1722 return config;
1723 }

The default being "follow-lid" .

The upstream change is massive ( more to do with power management and systemd ), and as per me not worth it.

This is the code which we use

1810 static void
1811 apply_default_boot_configuration (GsdXrandrManager *mgr, guint32 timestamp)
1812 {
1813 GsdXrandrManagerPrivate *priv = mgr->priv;
1814 GnomeRRScreen *screen = priv->rw_screen;
1815 GnomeRRConfig *config;
1816 GsdXrandrBootBehaviour boot;
1818 boot = g_settings_get_enum (priv->settings, CONF_KEY_DEFAULT_MONITORS_SETUP);
1820 switch (boot) {
1822 return;
1824 config = make_clone_setup (mgr, screen);
1825 break;
1827 config = make_other_setup (screen);
1828 break;
1829 default:
1830 g_assert_not_reached ();
1831 }

The do-nothing does not exists anymore, and we use follow-lid or do-nothing which still call xinerama.

> * you make the default to be xinerama when there is no lid closed, that's
> wrong in some cases.
> E.g we want to default to mirror for projectors configurations) ... there is
> no good way to detect projectors at the moment though, that's why we default
> to mirror

This might be the current behaviour, but not an a...


Sebastien Bacher (seb128) wrote :

> The upstream code has changed this behaviour. The patch reflects the upstream behaviour closely.

Right, the upstream change is also a regression, in the lucid cycle we set up a boot target of 10s on a mini 10v config, xrandr was taking some 1.5 seconds ... that's a 15% slowdown of the whole machine boot time for no good reason, I don't see a reason why we shouldn't consider that as an issue

I'm going to discuss that upstream but until then I suggest that people who have specific scenario that requires xinerama by default change the default key

Note that in the scenario "boot a laptop closed with lid closed" I would argue that the bug is that the kernel/xorg stack, the laptop screen should be declared as active since it's not, the low level should only list on screen on and we wouldn't have any "mirror" issue to start with

Sebastien Bacher (seb128) wrote :

in fact looking to http://git.gnome.org/browse/gnome-settings-daemon/plain/plugins/xrandr/gsd-xrandr-manager.c the upstream code still seems to do nothing in the do-nothing case:

" apply_default_boot_configuration (GsdXrandrManager *mgr, guint32 timestamp)
         config = make_default_setup (mgr);

 so it does return without calling make_default_setup() in that case

Bryce Harrington (bryce) wrote :

[Unsubscribing ubuntu-sponsors since it appears the posted patches need further work.]

Ritesh Khadgaray (khadgaray) wrote :

Allow for "follow-lid" behaviour .

if two monitors are connected, go to "xinerama" mode by default, when the internal display is closed, choose the best resolution on the external display.

description: updated
Iain Lane (laney) wrote :

OK, I'll upload this to precise. I have two comments

  - I'd be slightly more comfortable if you took the whole upstream patch
  - Please include patch headers in your uploads so that people looking know how to find out more information. I did that for you this time.

Iain Lane (laney) on 2013-09-17
Changed in gnome-settings-daemon (Ubuntu Precise):
status: Won't Fix → In Progress
assignee: nobody → Ritesh Khadgaray (khadgaray)

Hello Chris, or anyone else affected,

Accepted gnome-settings-daemon into precise-proposed. The package will build now and be available at http://launchpad.net/ubuntu/+source/gnome-settings-daemon/3.4.2-0ubuntu0.6.3 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, and change the tag from verification-needed to verification-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

Changed in gnome-settings-daemon (Ubuntu Precise):
status: In Progress → Fix Committed
tags: added: verification-needed
Ritesh Khadgaray (khadgaray) wrote :

Hi Iain

This is from https://mail.gnome.org/archives/commits-list/2013-January/msg00253.html . Updated to work precise, with minimal changeset .

commit 32f7a938fca072e14bad1928b492e29ba0e3090c
Author: Paolo Bonzini <email address hidden>
Date: Wed Dec 19 15:37:03 2012 +0100

    xrandr: use default-monitors-setup for autoconfigure

Shih-Yuan Lee (fourdollars) wrote :

gnome-settings-daemon 3.4.2-0ubuntu0.6.3 works fine on precise.

tags: added: verification-done
removed: verification-needed
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package gnome-settings-daemon - 3.4.2-0ubuntu0.6.3

gnome-settings-daemon (3.4.2-0ubuntu0.6.3) precise; urgency=low

  * debain/patches/follow-lid.patch:
    - external/internal monitors mirrored on boot when laptop lid is closed
      (lp: #1065979)
 -- Ritesh Khadgaray <email address hidden> Tue, 13 Aug 2013 11:29:20 +0530

Changed in gnome-settings-daemon (Ubuntu Precise):
status: Fix Committed → Fix Released

The verification of this Stable Release Update has completed successfully and the package has now been released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regresssions.

Bernhard (baumber) wrote :

This patch breaks my multi-monitor configuration!

See Bug Report #1236752
gnome-settings-daemon (3.4.2-0ubuntu0.6.3) breaks nvidia multi-monitor-config

Please help, best regards, Bernhard

Alkis Georgopoulos (alkisg) wrote :


This update broke the default Xorg resolution,
set by e.g. PreferredMode in xorg.conf or by XRANDR_MODE_0 in LTSP,
now gnome-settings-daemon forces the *highest* resolution instead of the default one.

It's very annoying on CRT screens where e.g. 1024x768 is preferred, and 1600x1200 is unreadable.

Could you please revert it until the current bug is properly solved?

Shih-Yuan Lee (fourdollars) wrote :


I think the fix in gnome-settings-daemon 3.4.2-0ubuntu0.6.3 is OK except we should not change the following default value.

+ <key name="default-monitors-setup" enum="org.gnome.settings-daemon.GsdXrandrBootBehaviour">
+- <default>'do-nothing'</default>
++ <default>'follow-lid'</default>

That should be the key to introduce the regression.

Ritesh Khadgaray (khadgaray) wrote :

update the default behaviour to do-nothing.

Shih-Yuan Lee (fourdollars) wrote :

Ritesh Khadgaray,

Your patch has been reverted because of Bug #1236752.
So you need to generate the patch based on gnome-settings-daemon (3.4.2-0ubuntu0.6.4) again.
You can get the Debian source package by `dget -x -u https://launchpad.net/ubuntu/+archive/primary/+files/gnome-settings-daemon_3.4.2-0ubuntu0.6.4.dsc`.

Ritesh Khadgaray (khadgaray) wrote :
Changed in gnome-settings-daemon (Ubuntu):
assignee: nobody → Iain Lane (laney)
Martin Pitt (pitti) wrote :

This last patch shouldn't be uploaded before the issue is fixed in trusty, tested with nvidia (to make sure it doesn't regress again) and forwarded to upstream.

Martin Pitt (pitti) wrote :

Unsubscribing sponsors for now. Please re-subscribe after the above happened. Thank you!

Iain Lane (laney) wrote :

Unassigning myself for that reason.

Changed in gnome-settings-daemon (Ubuntu):
assignee: Iain Lane (laney) → nobody
Changed in gnome-settings-daemon (Ubuntu Precise):
status: Fix Released → Triaged
Changed in gnome-settings-daemon (Ubuntu Saucy):
status: Fix Committed → Triaged
Changed in gnome-settings-daemon (Ubuntu Precise):
assignee: Ritesh Khadgaray (khadgaray) → nobody
Rolf Leggewie (r0lf) wrote :

saucy has seen the end of its life and is no longer receiving any updates. Marking the saucy task for this ticket as "Won't Fix".

Changed in gnome-settings-daemon (Ubuntu Saucy):
status: Triaged → Won't Fix
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.