[Pm-utils] Problems with 98smart-kernel-video and intel graphics chipsets
dbn.lists at gmail.com
Sun Sep 21 08:04:40 PDT 2008
On Sat, Sep 20, 2008 at 3:56 PM, Michael Biebl <mbiebl at gmail.com> wrote:
> 2008/9/21 Jesse Barnes <jbarnes at virtuousgeek.org>:
>> 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
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
More information about the Pm-utils