Improving the suspend quirks guessworking
danny.kukawka at web.de
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 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.
More information about the hal