Improving the suspend quirks guessworking

Danny Kukawka danny.kukawka at
Tue Mar 25 13:06:09 PDT 2008

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 driver 1.x versions,
>              DO NOT use with intel 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.


More information about the hal mailing list