[Pm-utils] Problems with 98smart-kernel-video and intel graphics chipsets

[Jesse Barnes]

On Saturday, September 20, 2008 3:04 pm Michael Biebl wrote:
> 2008/9/20 Jesse Barnes <jbarnes at virtuousgeek.org>:
> > On Saturday, September 20, 2008 12:03 pm Dan Nicholson wrote:
> >> On Sat, Sep 20, 2008 at 10:30 AM, Victor Lowther
> >>
> >> <victor.lowther at gmail.com> wrote:
> >> > On Sat, 2008-09-20 at 08:28 -0700, Dan Nicholson wrote:
> >> >> On Sat, Sep 20, 2008 at 6:50 AM, Victor Lowther
> >> >>
> >> >> <victor.lowther at gmail.com> wrote:
> >> >> > On Fri, 2008-09-19 at 21:03 +0200, Michael Biebl wrote:
> >> >> >> Can someone with more knowledge about intel hardware and its
> >> >> >> kernel modesetting driver please comment on the current status of
> >> >> >> this driver with regard to quirk handling and which one should be
> >> >> >> applied or filtered out.
> >> >> >
> >> >> > We will probably have to annoy the driver developers directly.
> >> >> >
> >> >> > I suspect that the Intel driver will ultimatly still require the s3
> >> >> > and the vbe post, state, and mode quirks.
> >> >>
> >> >> That will definitely not be necessary when all is said and done. A
> >> >> major driving factor of getting the modesetting done in the kernel
> >> >> was so it would stand a better chance to handle suspend and resume. A
> >> >> definite goal in all that is that banging the BIOS will not be
> >> >> necessary and the card can be reprogrammed directly.
> >> >>
> >> >> http://www.ussg.iu.edu/hypermail/linux/kernel/0705.2/0893.html
> >> >>
> >> >> I read that the Intel kernel modesetting driver is lacking
> >> >> suspend/resume support right now.
> >> >>
> >> >> That being said, nobody except Fedora users even have the kernel
> >> >> modesetting drivers yet. The disabling of quirks in smart-video was
> >> >> supposed to be taking advantage of fixes in the DRM i915 driver that
> >> >> went in to 2.6.26.
> >> >
> >> > Hmmm... do you have an idea of what, exactly, those fixes were?
> >>
> >> Not exactly. I mean, there were lots of commits about saving and
> >> restoring specific state like this:
> >>
> >> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commi
> >>tdi ff;h=e948e994
> >>
> >> I don't really know graphics card programming to the point where I
> >> could point out a magic bullet to you. I cc'd Jesse Barnes since he's
> >> done a lot of work on the Intel video drivers.
> >>
> >> Jesse, in pm-utils, we have a hook that will call vbetool with quirks
> >> stored in HAL so that video is restored correctly. However, for kernel
> >> 2.6.26 and newer, we assume that the i915 driver will be able to
> >> handle suspend resume and don't call vbetool.
> >>
> >> So, should we expect that on recent releases that the i915 driver
> >> should be able to bring the display back on its own?
> >
> > For the most part.  In current kernels there are a couple of older, 8xx
> > based platforms that we don't fully restore (ThinkPad X40 is one that I'm
> > aware of).  We're working on fixing that but I don't have an ETA.
>
> Hm, but the original bug reporter was reporting this issue on a 915
> chipset. (and kernel 2.6.26).
>
> Is 2.6.26 too old, does the kernel need special patches for that
> actually to work?
>
> 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?

Thanks,
-- 
Jesse Barnes, Intel Open Source Technology Center