Improving the suspend quirks guessworking

Danny Kukawka danny.kukawka at web.de
Fri Mar 21 06:52:35 PDT 2008


On Donnerstag, 20. März 2008, Martin Pitt wrote:
> Hello all,
>
> a while ago, Matthew Garrett applied a patch to Ubuntu's hal to apply
> some kernel workaround suspend quirks by default, even if they weren't
> specified in the hal-info FDIs (see attached patch for reference).
> This was done because a lot of older hardware usually needs those
> quirks, so while not applying any would be guaranteed to fail,
> applying the subset mentioned in the patch by default would at least
> have a good chance of succeeding. 

I'm not sure about that. You propose these quirks as default?:
   
   --quirk-dpms-on
   --quirk-vbestate-restore
   --quirk-vbemode-restore
   --quirk-vga-mode3
   --quirk-vbe-post
   --quirk-reset-brightness

This combination looks strange to me, but maybe Stefan can comment, he works 
on suspend since ages.

> This was the default behaviour of 
> older releases (the pre-pm-utils era) and it worked reasonably well.

In HAL? When was that? I can't remember that there where any defaults. IIRC  
HAL never used defaults, only whitelisting is/was used, for good reasons. 

> However, this patch causes a lot of problems on more recent hardware
> where using the quirks actively breaks suspend.

I'm not surprised.

> Thus today we discussed this problem in-depth and came to the
> conclusion that the following schema would deliver the best results:
>
> (1) laptop model has no matching FDI rule -> use the default quirks
>     in the attached patch

IMO not a good idea. I would still prefer that the people which have problems 
with suspending go the current workflow: test the needed quirks, report them 
back, we add them to hal-info.

What you propose would cause also many trouble e.g. on machines which are not 
listed and don't need any quirks (only as one example).

> (2) laptop model has matching FDI rule -> use them as they are, and
>     do not add any default quirks

This is IMO the only acceptable solution in general. And I have to say we had 
never big problems with this behavior.

> (3) the proprietary nvidia and fglrx drivers, and intel >= i915 [1]
>     know how to reset the video hardware on resume and must not use
>     any video quirk in /usr/lib/pm-utils/sleep.d/99video.
>     resume_video() should immediately return in those cases.

1) means the module is loaded that X use also the related module? On my 
machine I can use radeon and load fglrx, which don't mean that I use the 
fglrx module.
2) until these modules don't export (device) information (not that may a 
module with this name was loaded) to the sysfs we can't detect that in HAL. 

> So the attached patch (which is currently applied in Ubuntu) provides
> (1), but breaks (2),

It don't break only (2), it can also break (1) very often if you take a look 
at the needed quirks for older machines as the old IBMs or other machines. It 
would make maybe sense to whitelist all older IBMs with s3_bios and s3_mode, 
but IMO not with the quirks you proposed. And this is IMO only one example of 
many.

> (3) is particularly important since FDI rules only match hardware
> models, not device drivers. 

See above. Until there are no device info in the sysfs we can't do anything.

Danny


More information about the hal mailing list