On Sat, Sep 20, 2008 at 3:56 PM, Michael Biebl <[EMAIL PROTECTED]> wrote: > 2008/9/21 Jesse Barnes <[EMAIL PROTECTED]>: >> On Saturday, September 20, 2008 3:04 pm Michael Biebl wrote: >>> >>> Or put in other words: What are the exact prerequisites >>> (hardware/software) for kernel modesetting to actually work. And what >>> kind of quirks are no longer necessary then (all?) ? >> >> Ah I didn't read the whole original message. Kernel mode setting should work >> on 855 and above (and possibly 830 though I haven't tested). Suspend/resume >> code is part of the patch, but is currently broken on all chipsets that I'm >> aware of (we'll get this fixed before merging upstream). >> >> Maybe you can point me at the original bug report so I can take a look? >> > > It's http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=499442 > > The beginning of the discussion is > http://lists.freedesktop.org/archives/pm-utils/2008-September/001637.html
Hang on, Michael. I don't think we're talking about kernel modesetting here. Correct me if I'm wrong, but none of the modesetting patches have landed in upstream linux, much less in 2.6.26. I don't think Debian has backported the modesetting patches, right? What we're concerned with right now is just if the 915 drm driver in recent vanilla kernels (2.6.26 and 2.6.27-rc*) is saving and restoring all the state necessary around a suspend/resume cycle to get the display up. Having all the modesetting done in the drm driver is a new feature around the corner. Right now, you need some coordination between the X video driver and the DRM driver to get the display restored. -- Dan _______________________________________________ Pm-utils mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/pm-utils
