Improving the suspend quirks guessworking

[Matthew Garrett]

On Tue, Mar 25, 2008 at 01:44:00AM +0100, Danny Kukawka wrote:
> On Dienstag, 25. März 2008, Matthew Garrett wrote:
> > We don't want to force people to report quirks to us. 
> 
> I'm not sure if this is true for all of _us_. SUSE for example do this since 
> ages with e.g. s2ram and it works perfect. 

Well, sure, if your default position is "We want to know the precise set 
of quirks that will cause this hardware to work and unless we have them 
your machine won't work" then you want to force people to report quirks 
to you. But:

> > We want hardware to work.
> 
> That's what we all want, but what you try would break IMO more machine than 
> fix them.

The most likely worst case is that using a set of default fallbacks will 
cause a machine that didn't resume to continue not resuming. The best 
case is that it helps a machine that wouldn't otherwise resume. The case 
you're talking about (hardware resumes graphics in the BIOS, running the 
quirks breaks it) is so vanishingly unlikely that it's not worth 
bothering about. Having the BIOS unconditionally rePOST the graphics 
slows down the resume cycle and causes extra screen flickering under 
Windows, which worsens the user experience. As a result, almost no 
hardware does this. So, the probability of breakage is painfully small.

Ugh. Looking at some of the "none" entries in the current hal-info makes 
me strongly suspect that the only thing restoring video is X or the 
nvidia binary blob. Oh, ugh.

<!-- another ASUS Mainboard, this need no quirk -->

Because you know what graphics card is in it? I suspect not. This is all 
just painfully wrong and horrible and broken and I'm going back to 
working on softbooting nvidia hardware. I mean:

        <!-- ONLY needed with i810 X.org driver 1.x versions,
             DO NOT use with intel X.org driver 2.x version (not needed 
and causes problems)

Come on.
-- 
Matthew Garrett | mjg59 at srcf.ucam.org