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

[Jesse Barnes <jbarnes@virtuousgeek.org>]

On Tue, 12 Jan 2010 06:12:37 +1000
Dave Airlie <airlied@gmail.com> wrote:

> On Tue, Jan 12, 2010 at 2:38 AM, Jesse Barnes
> <jbarnes@virtuousgeek.org> wrote:
> > 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.
> 
> The problem is at any single point in time I'm not sure a kms kernel
> exists that works across all the Intel hw, which from a distro POV is
> a real pain in the ass, a regression gets fixed on one piece of hw
> just as another on a different piece gets introduced.
> 
> I'd really like if Intel devs could either slow it down and do more
> testing before pushing to Linus, or be a lot quicker with the reverts
> when stuff is identified. The main thing is the render reclocking
> lately, thats been a nightmare and as far as I can see 2.6.32.3 still
> has all the issues,

Yeah, it may have been better to just revert that early on, but some
users really wanted the power saving features too, so it wasn't totally
clear cut (btw stable has a revert patch queued up now that fixes things
for several people).

> > 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.
> 
> Maybe in 3-4 years.

Ouch, it just went from 2-3 to 3-4.  But really the other drm drivers
have to get converted anyway before we can really start killing code.

-- 
Jesse Barnes, Intel Open Source Technology Center