Improving the suspend quirks guessworking

[Martin Pitt]

Hi,

Danny Kukawka [2008-03-21 14:52 +0100]:
> 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.

I'm more or less just the messenger. According to Matthew (CC'ed
again, please keep him in CC) those are necessary to work around
kernel bugs which affect drivers other than fglrx, nvidia, and never
intel.

(Disclaimer: I know pretty much nothing about the nature of the kernel
problems these quirks work around; please ask Matthew for details.)

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

Sorry for being unclear, that was supposed to be "older releases of
Ubuntu" (perhaps Debian as well) in our acpi-support package.

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

Me too, but I understand it as being a much better default than "no
quirks at all" if there is no FDI data for a particular model.

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

I understand that, but I can only parrot Matthew here: "no quirks" is
allegedly guaranteed to fail on those machines, whereas the above set
of quirks at least gives a good chance of succeeding.

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

Full ack, and I just corrected the original patch to behave like that.

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

As I already pointed out, this is *not* a general and clean-design
patch. It works on Ubuntu because you cannot modprobe fglrx or nvidia
unless you actually use the driver in xorg.conf (modprobe.d script).

I just posted the actual patches here for other distros which might
need a quick solution for a pending stable release (such as Ubuntu
Hardy and perhaps Fedora). While my proposed rules (1) to (3) are
generally applicable, the patches are *not*.

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

Oh the joy of proprietary X.org device drivers. But since the best we
can do is to prod AMD/NVidia to fix it, and wait until they do, having
workaround for them is legitimate IMHO.

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

It's just a better heuristics/default, not 100% correct in all cases,
of course. I didn't claim (and neither did Matthew) that these fix
everything once and for all. We still depend on user feedback and
correct model-specific FDIs, of course.

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

Right, but if we have the chance to work around it effectively with a
trivial patch, we still want to do it. :-)

Thank you for the feedback!

Martin

-- 
Martin Pitt                        | http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)