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

[Victor Lowther]

On Sun, 2008-09-28 at 11:17 +0100, Matthew Garrett wrote:
> On Sat, Sep 27, 2008 at 08:47:26PM -0500, Victor Lowther wrote:
> > On Sun, 2008-09-28 at 00:10 +0100, Matthew Garrett wrote:
> > > No, there's no deterministic way to determine whether the BIOS code will 
> > > correctly deal with the state that the DRM code programs. It's entirely 
> > > possible for a previously required quirk to start breaking machines. 
> > > That's why we removed the quirks on these kernels in the first place.
> > 
> > No, we removed them becuase you assured me that they were no longer
> > required.  You were mistaken.
> 
> Bugs happen. I didn't ask for the code to be removed because it wasn't 
> necessary, I asked for the code to be removed because it now actively 
> breaks some machines. I'm fully aware that this is a less than ideal 
> situation.

Well, we are in agreement there.  

> > In either case, I think the code required for Intel kernel modesetting
> > is already getting too complicated to live in pm-utils -- if knowledge
> > of the system, bios revision, video card, video driver, and kernel
> > revision will be required to determine the appropriate set of quirks
> > (and an answer of none will be required is not the right blanket
> > answer), this stuff needs to go in the quirks list in HAL.  If the quirk
> > detection in HAL is not smart enough, it needs to be made smart enough
> > to handle all those variables.  If it cannot be made smart enough in
> > HAL, we need a new mechanism for handling quirks.
> 
> No, the quirks handling just needs to die. Utterly. Entirely. It can't 
> be fixed. It's unscalable. Trying to improve it at this point is a waste 
> of time that would be better spent on fixing up the kernel.

In a perfect world, I would agree with you, and having video drivers
that are written with assistance from (or by) chipset and system vendors
will help out a great deal. That still means that quirk handling needs
to be improved to the point where we can have a .fdi file that can take
kernel revisions, drivers, and driver revisions into account, even if it
is just to say "if we are running kernel revision $foo or greater, using
driver $bar revision $baz or leter, then we no longer need quirks".
Blanket whitelisting and blacklisting only seems to work for
closed-source binary blob based video drivers right now, it seems.



-- 
Victor Lowther
Ubuntu Certified Professional