Bug 76267

Addendum: I am running Arch Linux x86-64. The laptop has been rebooted since upgrading nvidia and systemd.

You are using the nvidia binary driver I assume?

The binary driver does not implement the DRM interfaces in /sys. This means we cannot detect how many displays are connected and then we decide not to handle the lid switch since we cannot be sure about whether the device is in "docking" mode, or not...

A "fix" is to use nouveau...

But other than that we could add a logind.conf option which overrides automatic display detection and makes the system suspend regardless of it...

While I support the nouveau driver, at the time it's not feasible for me to use their driver.

I like that systemd has the logic to not suspend if in docking mode, but in the mean time it feels like a regression given that 210 suspended fine when the lid was closed.

The option sounds very reasonable and would be much appreciated by both amd and nvidia blobcrap users like myself.

(In reply to comment #2)
> You are using the nvidia binary driver I assume?
> 
> The binary driver does not implement the DRM interfaces in /sys. This means
> we cannot detect how many displays are connected and then we decide not to
> handle the lid switch since we cannot be sure about whether the device is in
> "docking" mode, or not...
> 
> A "fix" is to use nouveau...
> 
> But other than that we could add a logind.conf option which overrides
> automatic display detection and makes the system suspend regardless of it...

Side note:
The option would actually be useful to non-binary users as well.

Namely, if I had a second monitor hooked up to my laptop, and my laptop were closed, I would want the system to suspend because that likely means I'm packing up to leave.  I tend to close the lid and unhook everything after.

Thank you for responding so promptly.

I'm experiencing this this without any monitor attached. I'm on a x230 laptop with only an integrated intel gpu.

Pretty much I'm seeing that
- successful suspend when I run 'systemctl suspend'
- successful suspend when I press the suspend key (Fn-F4)
- opening the laptop lid will wake the laptop up (after suspending with the FN key)
- journalctl systemd-logind outputs that logind received lid close/open events

Other people see the same: https://bbs.archlinux.org/viewtopic.php?id=176883

Hopping on board. Re this:

> The binary driver does not implement the DRM interfaces in /sys. This means we
> cannot detect how many displays are connected and then we decide not to handle
> the lid switch since we cannot be sure about whether the device is in "docking"
> mode, or not...

Is this per a recent systemd change, or has this always been the case? If the former, I understand. If the latter, I disagree as only within the last few weeks have I noticed the change. I've never changed /etc/systemd/logind.con, and uncommenting `#HandleLidSwitch=suspend` as is often first suggested in Arch Linux forum posts should be irrelevant since it's the default behavior.

I have no external monitors connected. As mentioned, nouveau works, but I can't use nouveau for anything legitimate (https://bugs.freedesktop.org/show_bug.cgi?id=77371).

(In reply to comment #6)
> Hopping on board. Re this:
> 
> > The binary driver does not implement the DRM interfaces in /sys. This means we
> > cannot detect how many displays are connected and then we decide not to handle
> > the lid switch since we cannot be sure about whether the device is in "docking"
> > mode, or not...
> 
> Is this per a recent systemd change, or has this always been the case? If
> the former, I understand. If the latter, I disagree as only within the last
> few weeks have I noticed the change. I've never changed
> /etc/systemd/logind.con, and uncommenting `#HandleLidSwitch=suspend` as is
> often first suggested in Arch Linux forum posts should be irrelevant since
> it's the default behavior.
> 
> I have no external monitors connected. As mentioned, nouveau works, but I
> can't use nouveau for anything legitimate
> (https://bugs.freedesktop.org/show_bug.cgi?id=77371).

Nothing about nvidia has changed. Systemd has added logic that checks for whether you have multiple monitors (or in docking mode) attached and prevents lidclosing from suspending the machine.

That way, those who dock their laptops can close the lids and still use it via the external monitor.

However, systemd checks for those monitors using the DRM interface mentioned by Lennart.
Because nvidia does not implement that interface, systemd cannot really check for whether there are other monitors (except, perhaps through Xorg, but not everyone uses Xorg).

Thus, they have to make a choice.
1) Inconvenience non-docking users by assuming that suspend shouldn't occur on lid close; this conveniences docking users, because they can actually close their laptops and continue working.

2) Inconvenience docking users by assuming suspend should occur on lid close and that there aren't other monitors; this conveniences non-docking users, because they can actually close their laptops and have them suspend.

The team apparently went with 1).
Docking users would prefer 1, because their docking setups keep working as per normal. If they chose 2, docking users would have to disable lidsuspend.
Non-docking users would prefer 2, because their lid suspend would keep working as per normal. If they chose 1, non-docking users would have to manually suspend.

In my opinion, the assumption should be to suspend on lid close if they can't detect monitors.
Mainly, because there are surely far more people who use their laptops and want it to suspend when the lid is closed; if they don't, they can just disable the feature.
There are surely fewer people who dock their laptops or use an external monitor in lieu of the laptop monitor; if they want to disable lid suspension, they can do so manually.

@Stephen: many thanks for the explanation, and my query is resolved. I'll just continue suspending manually or try and implement an openbox keyboard shortcut for it (though perhaps I'll need gksudo or similar). All makes sense and your rationale is sound!

I use the nvidia (ThinkPad W530, K2000) drivers as well (tried nouveau but had a lot of problems: lags/crashes when docking/undocking) so I have to use the nvidia driver.

But what I don't get is that on systemd210, I can close the lid while docked and will not end up in suspend (booting with closed lid will suspend the laptop at the end of the boot(I think even this worked in older versions, but may I had still acpi installed back these days). Also I can undock the laptop and close the lid and it will also suspend as required.

This issue came just up on the mailing list again, with a patch [1].

As far as I can tell the change that introduced this behavior is at [2]. Note that the commit message at this point said 'logind: ignore lid switch if more than 1 display is connected', but the code checked for 'if the number of displays is not 0'.

The check as hinted at by the commit message would be fine - users with Nvidia blobs would end up with "0" displays (not > 1, suspending fine).

A configuration parameter (logind.conf for example) would certainly be helpful, but it would also help to understand at what point the mismatch between commit message (> 1) and code (!= 1) leaned to the latter?

The current code (as seen in the patch) has the following comment, introduced in a later commit [3]:

/* If we have more than one or no displays connected,
 * don't react to lid closing. The no display case we
 * treat like this under the assumption that there is
 * no modern drm driver available. */

At this point I'm drawing a blank here - I wouldn't understand the requirement for the no display case. I'm just a curious end user and certainly lack the insights necessary. "Lid closing" can only happen on laptops, right? Which drivers are the reasons for the 0-case here, if nouveau for example isn't it? Wouldn't most (all?) free drivers come up with a valid number here? Is the ratio of laptops with no modern drm drivers available expected to be much larger than the nvidia user base?

I might be totally off, but this reads like a case for 'running a very recent systemd based system on a laptop with outdated video drivers'. Obviously (I'm serious, no snark) I'm not clever enough to be sure about that, nor do I know how common that case is.

Given that the whole point of that exception is to avoid suspending
- IF you close the lid
- AND have no 'modern' video drivers 
- AND actually have more than one display connected

isn't that more rare than closing one's laptop and taking it somewhere, period?
Plus, isn't there a working way to solve that issue (systemd-inhibit) if you're in the special case above? It seems the commit fixed a scenario that already had a configurable workaround and introduced a problem for nvidia users without a configurable workaround? [4]

1: http://article.gmane.org/gmane.comp.sysutils.systemd.devel/18764

2: http://cgit.freedesktop.org/systemd/systemd/commit/src/login/logind-action.c?id=6a79c58603ea816a1b4fa1520397b4e138bc1ca0

3: http://cgit.freedesktop.org/systemd/systemd/commit/src/login/logind-action.c?id=f9cd6be10ece07e10488c05e270a0b5860779864

4: Not quite true - people in the Arch Linux tracker suggest using acpid events/hooks to issue systemctl suspend

I'm affected of this bug though I'm using the nouveau drivers. Pressing the suspend key ([Fn]+[F4]) also doesn't work since upgrading to systemd 212. Manually running "systemctl suspend" does work.

I'm running Arch Linux x86-64 on a Thinkpad T520. I had the nvidia drivers installed but uninstalled them some time ago and switched to nouveau. Also I have bumblebee still installed (but reconfigured it to use nouveau instead of nvidia).

I'll gladly supply additional infos as well as logs if needed.

Fixed in git. We now avoid suspend when the number of displays is > 1, not already when it is != 1.

Hello developers!

The problem still exists in hybrid VGA configuration. For example, my laptop has discrete ATI HD 5650 card and integrated Intel card. There are 2 external outputs, VGA and HDMI, but they are not used. Following is the report from kernel:

---
# cat /sys/class/drm/card0/card0-LVDS-1/status 
connected

# cat /sys/class/drm/card0/card0-VGA-1/status 
disconnected

# cat /sys/class/drm/card1/card1-LVDS-2/status 
connected

# cat /sys/class/drm/card1/card1-VGA-2/status 
connected

# cat /sys/class/drm/card1/card1-HDMI-A-1/status 
disconnected
---

card0 - Integrated Intel (i915 module)
card1 - Discrete AMD (radeon module)


As you can see, kernel reports about 3 connected monitors, although only integrated laptop's LCD is used and AMD card is disabled via vgaswitcheroo:

---
cat /sys/kernel/debug/vgaswitcheroo/switch 
0:IGD:+:Pwr:0000:00:02.0
1:DIS: :Off:0000:01:00.0
2:DIS-Audio: :Off:0000:01:00.1
---


By blacklisting radeon kernel module I can workaround the problem because kernel reports only one card, but a drawback is the vgaswitcheroo interface no longer available. Therefore I can't completely switch off discrete card.

Thank you!

Installed software:
 Kernel: 3.15.2
 systemd: 214

Garri, this really looks like a driver problem. It really shouldn't report that displays are connected when in fact they aren't. Please file a bug against the kernel.

@Lennart: Thank you for review!

For the people encountering with the problem described in comment 13, related kernel bug report is https://bugzilla.kernel.org/show_bug.cgi?id=83651.

I have laptop with external monitor attached and when I finish work I used to close the lid to put laptop into suspend, with latest systemd updates this is not an option anymore. Why?

I have tried using "LidSwitchIgnoreInhibited=yes" but this option is also being ignored.

From my point of view current systemd behaviour is an issue and makes my desktop much less usable than I was used to.

A workaround for people suffering from this issue:
I noticed that in reaction to another bug (https://bugs.freedesktop.org/show_bug.cgi?id=82485), a config option was introduced in logind that will allow configuring suspend even when systemd believes that the laptop is docked:
http://cgit.freedesktop.org/systemd/systemd/commit/?id=3c56cab44150ad47323970cfadfb0257c6305a74

However it appears that it is not in a systemd release yet (newest release is v216 at time of writing).

The option 'HandleLidSwitchDocked=suspend' introduced in 217 works perfectly!

Thanks!

(In reply to Garri from comment #18)
> The option 'HandleLidSwitchDocked=suspend' introduced in 217 works perfectly!
Yup, even without the kernel fix, HandleLidSwitchDocked can be used as a workaround.