Improving the suspend quirks guessworking

[Danny Kukawka]

On Dienstag, 25. März 2008, Matthew Garrett wrote:
> On Tue, Mar 25, 2008 at 01:44:00AM +0100, Danny Kukawka wrote:
> > On Dienstag, 25. März 2008, Matthew Garrett wrote:
[...]
> > > 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. 

But the defaults you use are like get something from /dev/random. It make no 
sense to set a global default. As I already pointed out several times, there 
are several vendors where the most machines need other quirks. I don't see 
why we should use these quirks.

> 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.

But in this case you break machines which currently correctly suspend because 
they don't need any quirks. 

> 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.

I wouldn't be that sure.

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

IIRC these are e.g. from s2ram where the suspend normaly work from X and 
console, so X isn't causing this.

> Because you know what graphics card is in it? 

We could do graphic card matching, no problem. But since we don't know which 
driver, driver version and maybe X version is involved I would say it make 
atm not that much sense. IMO the X server itself should be responsable to 
export these information to HAL, then we can maybe do more general 
matches/default for cards/driver/driver versions. 

Btw. This has nothing to do with what you proposed. Some strange default make 
IMO no sense, we should prefer reported quirks only for the moment.

> 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)

I didn't add these, so I don't know if they are needed or if they make sense 
in this case, but this don't have anything to do with the thing you proposed.

Danny