Laptop + external display does not suspend on lid close

[Colin Law]

Since update to Vivid, laptop does not suspend on lid close if an external monitor is connected, even though suspend is selected in the power settings for lid close. The display flashes and apps move to external display. Syslog shows no attempt to suspend. On Utopic it suspended ok with external monitor. In the logs the lid was closed on Jan 29 15:04:00 and opened at 15:04:30. There are messages in syslog at that time but I suspect they may be a different issue:
i915 0000:00:02.0: BAR 6: [??? 0x00000000 flags 0x2] has bogus alignment

WORKAROUND: Suspend via the menu.

WORKAROUND: Disconnect external monitor first.

ProblemType: Bug
DistroRelease: Ubuntu 15.04
Package: xorg 1:7.7+7ubuntu2
ProcVersionSignature: Ubuntu 3.18.0-11.12-generic 3.18.3
Uname: Linux 3.18.0-11-generic i686
.tmp.unity.support.test.0:

ApportVersion: 2.15.1-0ubuntu4
Architecture: i386
CompizPlugins: No value set for `/apps/compiz-1/general/screen0/options/active_plugins'
CompositorRunning: compiz
CompositorUnredirectDriverBlacklist: '(nouveau|Intel).*Mesa 8.0'
CompositorUnredirectFSW: true
CurrentDesktop: Unity
Date: Thu Jan 29 15:04:52 2015
DistUpgraded: Fresh install
DistroCodename: vivid
DistroVariant: ubuntu
ExtraDebuggingInterest: Yes
GraphicsCard:
 Intel Corporation 4th Gen Core Processor Integrated Graphics Controller [8086:0416] (rev 06) (prog-if 00 [VGA controller])
   Subsystem: Fujitsu Limited. Device [10cf:17a9]
InstallationDate: Installed on 2014-12-27 (33 days ago)
InstallationMedia: Ubuntu 15.04 "Vivid Vervet" - Alpha i386 (20141227)
MachineType: FUJITSU LIFEBOOK A544
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-3.18.0-11-generic root=UUID=09bfc4b3-c846-47be-ba86-c3db22bcff54 ro quiet splash vt.handoff=7
SourcePackage: xorg
UpgradeStatus: No upgrade log present (probably fresh install)
dmi.bios.date: 05/09/2014
dmi.bios.vendor: FUJITSU // Phoenix Technologies Ltd.
dmi.bios.version: Version 1.17
dmi.board.name: FJNBB35
dmi.board.vendor: FUJITSU
dmi.chassis.type: 10
dmi.chassis.vendor: FUJITSU
dmi.modalias: dmi:bvnFUJITSU//PhoenixTechnologiesLtd.:bvrVersion1.17:bd05/09/2014:svnFUJITSU:pnLIFEBOOKA544:pvr:rvnFUJITSU:rnFJNBB35:rvr:cvnFUJITSU:ct10:cvr:
dmi.product.name: LIFEBOOK A544
dmi.sys.vendor: FUJITSU
version.compiz: compiz 1:0.9.12.0+15.04.20141219-0ubuntu1
version.libdrm2: libdrm2 2.4.58-2
version.libgl1-mesa-dri: libgl1-mesa-dri 10.4.2-2ubuntu1
version.libgl1-mesa-dri-experimental: libgl1-mesa-dri-experimental N/A
version.libgl1-mesa-glx: libgl1-mesa-glx 10.4.2-2ubuntu1
version.xserver-xorg-core: xserver-xorg-core 2:1.16.2.901-1ubuntu3
version.xserver-xorg-input-evdev: xserver-xorg-input-evdev 1:2.9.0-1ubuntu2
version.xserver-xorg-video-ati: xserver-xorg-video-ati 1:7.4.0-2ubuntu2
version.xserver-xorg-video-intel: xserver-xorg-video-intel 2:2.99.917-1~exp1ubuntu2
version.xserver-xorg-video-nouveau: xserver-xorg-video-nouveau 1:1.0.11-1ubuntu2
xserver.bootTime: Thu Jan 29 15:00:08 2015
xserver.configfile: default
xserver.errors:

xserver.logfile: /var/log/Xorg.0.log
xserver.outputs:
 product id 13890
 vendor SEC
xserver.version: 2:1.16.2.901-1ubuntu3

[Colin Law (colin-law)]

Bug still present with BIOS version 1.19

[Colin Law (colin-law)]

sudo dmidecode -s bios-version && sudo dmidecode -s bios-release-date
..
Version 1.18
12/01/2014

[Colin Law (colin-law)]

Just in case it is relevant, when I upgraded to BIOS 1.18 I ran into bug #887793 (Kworker constantly taking about 100% CPU) worked around as in comment 114 there (echo "disable" > /sys/firmware/acpi/interrupts/gpe13). This suspend bug was still seen before and after the workaround. Before disabling gpe13, top showed kworker hogging one of the cores and there was no sign of Xorg near the top of the cpu usage list. After implementing the workaround Xorg re-appeared as normal with a few % of processor.

[penalvch (penalvch)]

Colin Law, if you boot into a kernel from Utopic are you then able to suspend again with the external display connected?

[Colin Law (colin-law)]

The bug is present with linux-image-3.17.1-031701-generic_3.17.1-031701.201410150735_amd64.deb

[penalvch (penalvch)]

Colin law, could you please test for this with upstream http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.16-utopic/ and advise to the results?

[Colin Law (colin-law)]

It is the same situation with v3.16-utopic. Closing the lid with ext monitor connected causes windows to move to ext monitor but does not suspend.

I have discovered another symptom that may possibly be related. With any of the kernels and with the external monitor not connected, closing the lid does nothing during the first four minutes after booting. After that time it suspends ok (ext monitor not connected). If closed during first four minutes then nothing happens, but if left closed it does suspend after that time has elapsed. Since discovering this I have gone back and checked the other kernels again and waited till it will suspend with no ext monitor and re-confirmed that it does not suspend with the ext monitor connected.

As a matter of interest are others seeing suspend ok with external monitor?

[penalvch (penalvch)]

Colin law, what prior release specifically did this issue not occur in?

[Colin Law (colin-law)]

In terms of the kernel version I don't know exactly as I do not suspend very often, but I never saw the problem before upgrade from Utopic. I have just tried booting into a live Utopic image which was the release candidate on 17th Oct 14 and uname shows 3.16.0-22 and it suspends ok there. Perhaps it is not purely a kernel issue.

[Colin Law (colin-law)]

In fact I see from my bug #1384454 that Utopic with kernel 3.16.0-23 and with 3.18.0-031800rc1 both suspended ok with external screen (though they did suffer from windows moving workspaces as in that bug).

[Martin Pitt (pitti)]

This might actually be on purpose?

$ systemd-inhibit
[...]
     Who: martin (UID 1000/martin, PID 2278/unity-settings-)
    What: handle-lid-switch
     Why: Multiple displays attached
    Mode: block

I for one really welcome this. Finally my laptop stopped suspending when it's sitting in the dock. (However, I didn't write that part of gnome/unity-settings-daemon). Just making sure that this is what you see?

You might try setting HandleLidSwitchDocked=suspend in /etc/systemd/logind.conf, but the above makes it sound like unity-settings-daemon is actually controlling this. (logind.conf would only get active for VTs or simple desktops which don't implement lid switch handling/policy by themselves).

[Colin Law (colin-law)]

I am pretty sure that a couple of years ago the gnome guys decided that the laptop should not suspend if an external monitor is plugged in (which was a change to the previous strategy). I think that by popular request this was reverted back to suspend (possibly only in Ubuntu, I don't know). I am sure there was a bug for this but I can't find it. Now it has apparently changed again.
I can see that for some it makes sense to not suspend, but for those who use the laptop in a dock with both displays active it is annoying to have to use the menus to suspend. I would have thought it more appropriate to have the default stay as it has been for many years. Ideally there could be an additional option in the settings to allow a choice of lid closure actions when there are two displays. Currently the option is to suspend or not. It does not say "suspend, but only if there is no external display connected".

[Colin Law (colin-law)]

For clarity I am not actually using a dock, I just have the external monitor plugged in to the laptop, and it does not suspend when I close the lid.

[Martin Pitt (pitti)]

For the record, systemd actually checks for "docked/undocked" events, so in a VT you should not actually get this behaviour. Only under Unity, because unity-settings-daemon doesn't seem to check for dock events in particular but just checks the connected monitors. Can you confirm this?

[Colin Law (colin-law)]

@Martin, could you clarify what is meant by dock events please? Also exactly what you want me to do in the VT.
Currently if I switch to a VT and close the lid then as far as I can tell absolutely nothing happens apart from the laptop monitor switching off. Under Unity the external display briefly blanks and then comes back with windows that were on the laptop moved to the external display, so it is switching to single monitor mode.

[Martin Pitt (pitti)]

I meant that when you dock or undock a laptop you get a particular evdev event (SW_DOCK), which logind checks for. This tells apart the simple "external monitor" case from "laptop sits closed in dock and only uses external monitor".

That the laptop doesn't suspend under a VT is not expected (unless you changed HandleLidSwitch=). That might warrant another bug report against systemd. But under unity it's definitively unity-settings-daemon's policy which gets applied here.

[Colin Law (colin-law)]

More evidence, of a rather confusing nature.
With default /etc/systemd/logind.conf (which has everything commented out).

With only the laptop display
Unity and VT both suspend ok when lid is closed

With laptop display + external display
Neither Unity nor VT suspend when lid is closed.

With HandleLidSwitchDocked=suspend in /etc/systemd/logind.conf

With only the laptop display
Unity and VT both suspend ok when lid is closed

With laptop display + external display
Unity does not suspend the first time the lid is closed, but does the second, in fact it suspends every second time the lid is closed (though not absolutely sure this is completely consistent). I think once it was not till the third time that it suspended.
VT suspends ok when lid is closed.

This is software so there is some sense there somewhere. It is just a matter of finding it.

[Terry Neu (terrylneu)]

This bug still exists on the final release.

[Colin Law (colin-law)]

@Terry could you add yourself to 'affects me' so that it increases the visibility. Thanks.

[Launchpad Janitor (janitor)]

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

[Fabien LOISON (flozz)]

Hello,

Same here on my Lenovo Thinkpad X1 Carbon gen3 (2015) with Ubuntu 15.04: the "org/gnome/settings-daemon/power/lid-close-suspend-with-external-monitor" option seems to be ignored (it worked on Ubuntu 14.10).

@penalvch: I don't think it is a kernel bug since I already used the 3.19 kernel on Ubuntu 14.10.