Created attachment 31817 [details] [review] Do not set quirk-no-chvt for nvidia cards After finally tracking down that KDE4 uses pm-utils instead of allowing the end user to select a suspend/resume method I began to investigate why suspend/resume failed to resume with a working X session. It turned out that commenting out a single line in the nvidia section of pm/sleep.d/98smart-kernel-video solved my issues. Dropping the chvt causes my X session to resume with garbled garbage. 01:00.0 VGA compatible controller: nVidia Corporation G73 [GeForce 7600 GT] (rev a1) 01:00.0 0300: 10de:0391 (rev a1) (prog-if 00 [VGA controller]) Subsystem: 1682:2220 Nvidia driver 190.42 Xorg server 1.7.2-2 pm-utils 1.2.6.1-1
504faf0a0c31cbdbc03a608cf633d58f12e49eb7 is the first bad commit commit 504faf0a0c31cbdbc03a608cf633d58f12e49eb7 Author: Victor Lowther <victor.lowther@gmail.com> Date: Sat Nov 7 23:21:45 2009 -0600 Make kernel modesetting detection a little smarter. It turns out that the method we were using to detect kernel modesetting support was not very accurate. It turns out there is no bulletproof way for us to tell if KMS is being used, but Michael Biebl found a way that sucks less than out current method. Hopefully the framebuffer drivers will grow a flag in sysfs somewhere that tells us that KMS is in use. :040000 040000 0489d094c01a7d2fa9cc8c45abaea22211062667 9a4a74d5e9b6eafae8305259ddfdc138f6a1fa0e M pm bisect run success
Interesting -- has this always happened, or did it start happening fairly recently? I have been skipping the chvt for nvidia drivers on my test system for somewhere around 6 months -- IIRC nvidia driver 180 and below have always worked for me.
I always used chvt. Only recently when I did a system upgrade things broke. Most likely when the early November commit changed the default behavior and made it downstream is when things really broke. I do use a suspend/resume progress indicator, which could be the reason I -require- chvt, but the point still stands; this is a change in default behavior that broke my system. Really, there should be a separate control for chvt or not which is easier to configure than an absolute deep in some distribution file.
(In reply to comment #3) > I always used chvt. Only recently when I did a system upgrade things broke. > Most likely when the early November commit changed the default behavior and > made it downstream is when things really broke. > > I do use a suspend/resume progress indicator, which could be the reason I > -require- chvt, but the point still stands; this is a change in default > behavior that broke my system. Which progress indicator do you use? > Really, there should be a separate control for chvt or not which is easier to > configure than an absolute deep in some distribution file.
http://www.tuxonice.net/userui as packaged by Arch Linux's http://aur.archlinux.org/packages.php?ID=24613 .
I can confirm that this change fixes my Macbook (5,1) resuming on Ubuntu Lucid. The graphics card is a GeForce 9400M.
Created attachment 33224 [details] [review] Patch against current git sources I've attached a new patch that can be applied directly to the latest git sources for pm-utils.
In the downstream bug (https://launchpad.net/bugs/488720) we got several more confirmations that this fixes suspend/resume with nvidia.
This was applied in http://cgit.freedesktop.org/pm-utils/commit/?id=509f6badd8ffcc40bd3393d8c222ee8adacfa6b6
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.