gnome-settings-daemon always prevents suspend when proprietary nvidia drivers are used.

Some investigations:

The problem seems to be related to non_laptop_outputs_are_all_off in plugins/power/gsd-power-manager.c

Also possible culprits could be is_laptop and gnome_rr_output_is_laptop.

My Display name is Apple DFP, so it doesn't seem to be caught by gnome_rr_output_is_laptop

However, detecting if it is a laptop monitor by name seems a bit flaky. However, since I don't have any external monitors connected, it seems that a workaround would be to also count how many displays we have in total. If the number is 1, and since this is a laptop (lid event, etc), is there any case where the one display isn't the laptop display ?

I am attaching a patch that fixes (probably incorrectly) the issue for me.

The attachment "count displays, assume only laptop connected if only 1" 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.]

Thank you for taking the time to report this bug and helping to make Ubuntu better. The issue you are reporting is an upstream one and it would be nice if somebody having it could send the bug to the developers of the software by following the instructions at https://wiki.ubuntu.com/Bugs/Upstream/GNOME. If you have done so, please tell us the number of the upstream bug (or the link), so we can add a bugwatch that will inform us about its status. Thanks in advance.

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

Confirmed the patch fixes the regression for me - suspend now works when I close the lid.

This is apparently related to having the binary NVIDIA driver installed. gnome_rr_output_is_laptop() from gnome-desktop tries to guess whether a system is a laptop based on the output name, but the heurisitc doesn't work for the NVIDIA binary driver.

Steve, would you be able to apply the patch in https://bugzilla.gnome.org/show_bug.cgi?id=672030 and check whether this works?

@Martin: The upstream patch doesn't work for me. output->name is 'default' on my system w/ the NVIDIA binary driver, not something with the string 'DFP'. Using the 'test-gnomerr' program from the upstream bug, I get the following output:

steve@steve-laptop:~/src/test-gnomerr$ ./test-gnomerr
[default]
 connected: 1
 laptop: 0
 primary: 1
 id: 352

Thanks Steve, I forwarded this to the upstream bug.

Nvidia driver is not telling us what the connectors are, and is instead using "default" for this. Most systems have "LVDS1" for their attached laptops in panel displays, VGA1, HDMI1 etc for their other ones.

Hi Ursinha, would you please take a look at this? The main problem is that when a driver does not use xrandr, it shows up as [default]. In this case, it's not whitelisted as a "laptop display", and so g-s-d thinks there is an external monitor connected on lid close. I see two possible solutions to this.

1) whitelist [default] as a laptop display
2) Andrei's patch. The logic is that if there is only one display and you have a lid close, you know it must be a laptop display, because desktops don't get lid close events, and laptops don't ship without a display.

We'll have to consult upstream about this.

Another possible solution, taken by using the fix in the upstream bug.

James has a good point that desktops don't get lid closed events. The patch in comment #1 is an interesting way to use that fact. Does the code in question only occur within the context of a lid close event? If so, then it might be a contender to work around the problem.

The patch in comment #11 is simpler; it simply treats all "default" (unknown) monitors as laptops. I'm not sure that's reliably true in all cases (I suspect monitors with corrupt or missing edid might show up as default). The patch would be better if it only tested for "default" if the RANDR level was <1.2 (which is the case for -nvidia; all other common X drivers provide 1.2 or 1.3 support).

Ideally upstream would provide a fix for this, but it is a serious regression so think we need to consider working around it in the distro for the release.

Even if external "default" monitor is misdetected, that just means that in worse case scenario the laptop will suspend even if external monitor is plugged in - which is still noticably less problematic for hardware (and confusing) than staying on even if "suspend on lid close" is selected.

I agree, suspending with "default" only affects non-xrandr drivers, i. e. the proprietary ones, and with them quite a lot of things don't work anyway. The impact of suspending on lid close with external monitors on them is bearable IMHO, and not a regression.

I'd still include upstream's fix for detecting Apple panels as well, though, otherwise I'm ok with adding "default".

Ah, the "eDP"/"DFP" additions are already in 3.4.0, so just adding the "default".

Meant to put this link in yesterday, would someone please test this on nvidia versions to make sure that it makes lid close work? If so I think we can have a conversation with Gnome about it:

https://launchpad.net/~jm-leddy/+archive/lp949296

Patch works fine on Macbook Pro 5,3, Nvidia binary drivers.

This bug was fixed in the package gnome-desktop3 - 3.4.0-0ubuntu2

---------------
gnome-desktop3 (3.4.0-0ubuntu2) precise; urgency=low

  * 02_refuse_to_break_GL_compositors.patch: Add DEP-3 patch header.
  * Add 03_default_display_is_internal.patch: Treat a display named "default"
    as internal. This happens with the proprietary NVidia driver which does
    not do proper XRandR. We cannot detect external vs. internal display
    there, so err on the side of "internal" to make suspend on lid close work.
    Thanks to James M. Leddy for the initial patch! (LP: #949296)
 -- Martin Pitt <email address hidden> Thu, 29 Mar 2012 17:49:37 +0200

Just tested it on my MBP 5,2 and it works again. Yay! ... now, if they only would fix the corrupt graphics in the Unity Launcher when coming out of suspend... :)

I get those too! Is there a bug report or patch?

Thanks, Andrei
On Mar 30, 2012 12:56 AM, "Rainer Rohde" <email address hidden> wrote:

> Just tested it on my MBP 5,2 and it works again. Yay! ... now, if they
> only would fix the corrupt graphics in the Unity Launcher when coming
> out of suspend... :)
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/949296
>
> Title:
> gnome-settings-daemon always prevents suspend when proprietary nvidia
> drivers are used.
>
> Status in GNOME Desktop Common Files:
> Unknown
> Status in OEM Priority Project:
> Confirmed
> Status in OEM Priority Project precise series:
> Confirmed
> Status in “gnome-desktop3” package in Ubuntu:
> Fix Released
>
> Bug description:
> 1. Ubuntu precise (development branch) 12.04
> 2. Installed: 3.3.91-0ubuntu2
> Candidate: 3.3.91-0ubuntu2
> Version table:
> *** 3.3.91-0ubuntu2 0
> 500 http://ro.archive.ubuntu.com/ubuntu/ precise/main amd64
> Packages
> 100 /var/lib/dpkg/status
> 3.
>
> When closing the lid, the machine (MacbookPro 5,3) doesn't suspend.
> Using suspend from the power menu, or using pm-suspend works fine. The
> lid action is detected fine, and upower reports lid close correctly.
>
> Running gnome-settings-daemon --debug gives me the following output:
>
> --
>
> ** DEBUG: Syncdaemon not running, waiting for it to start in
> NameOwnerChanged
> === Applying Configuration Configuration ===
> Clone: false
> Output: Unknown attached to default
> status: on
> width: 1440
> height: 900
> rate: 50
> primary: true
> position: 0 0
> power-plugin-DEBUG: keyboard toggle on
> power-plugin-DEBUG: lid is closed; not suspending nor hibernating since
> some external monitor outputs are still active
> ** DEBUG: Updating client: index=43 name='gnome-settings-daemon'
> ** DEBUG: Updating client: index=43 name='gnome-settings-daemon'
> ** DEBUG: Updating sink: index=0
> name='alsa_output.pci-0000_00_08.0.analog-stereo' description='Built-in
> Audio Analog Stereo' map='front-left,front-right'
>
> --
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/gnome-desktop/+bug/949296/+subscriptions
>

@Andrei - here you go:

https://bugs.launchpad.net/unity/+bug/915265

Works for me on the macbook air 3,1. Thanks a lot!

What package version was this released in?

@Luke: see comment 18. 3.4.0-0ubuntu2