Re: [PATCH] DRM / i915: Fix resume regression on MSI Wind U100 w/o KMS

[Jesse Barnes <jbarnes@virtuousgeek.org>]

On Sun, 10 Jan 2010 07:32:30 +1000
Dave Airlie <airlied@gmail.com> wrote:
> I'm in the 2-3 years at a minimum, with at least one kernel with no
> serious regressions in Intel KMS, which we haven't gotten close to
> yet. I'm not even sure the Intel guys are taking stable seriously
> enough yet. So far I don't think there is one kernel release (even
> stable) that works on all Intel chipsets without
> backporting patches. 2.6.32 needs the changes to remove the messed up
> render clock hacks which should really have been reverted a lot
> earlier since we had a lot of regression reports. The number of users
> using powersave=0 to get anything approaching useable is growing etc.

But you could apply that argument to the existing DRM code (not just
Intel) as well; lots of things are broken or unimplemented and never
get fixed.  I'd say the right metric isn't whether regressions are
introduced (usually due to new features) but whether the driver is
better than the old userspace code.  For Intel at least, I think we're
already there.  The quality of the kernel driver is higher and it has
many more features than the userspace implementation ever did.  That's
just my subjective opinion, but I've done a *lot* of work on our bugs
both in userspace and in the kernel, so I think it's an accurate
statement.

> We do have ppl who run latest kernels on RHEL5 userspace and I'd
> rather not have that break badly, I'm guessing more than 3D will
> break if we remove this, since we need the DRM to allocate memory for
> 2D stuff, and will probably find the fallback to AGP is broken. Again
> Intel ppl would have to do a lot of testing on the fallback before
> removing anything, which is time I don't see anyone willing to spend.

It doesn't have to happen anytime soon, I was just thinking that
removing the old, pre-KMS code would make it easier to avoid
introducing regressions since we'd have one less config (a bit one
atthat) to worry about.

-- 
Jesse Barnes, Intel Open Source Technology Center