Improving the suspend quirks guessworking

[Matthew Garrett]

On Sat, Mar 22, 2008 at 01:38:57PM +0100, Martin Pitt wrote:
> 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.

Not bugs - deficiencies. This dates back to when I originally added 
suspend/resume code to Ubuntu back in early 2005. The majority of 
hardware requires some sort of assistance in getting video back after 
suspend, so I decided that we were better off defaulting to enabling a 
bunch of things that would stand a chance of working. The alternative 
was pretty much to guarantee failure.

The nvidia and fglrx modules are now pretty much able to handle video 
resume on their own, as is the latest version of the i915 DRM code. 
There's no need to use any of these quirks on that hardware.

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

There's almost no hardware that will work without any quirks, unless 
you're using very recent (or closed) video drivers. I don't think 
optimising for that case is helpful.

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

Yeah, but that's pathological behaviour. Don't do that.

-- 
Matthew Garrett | mjg59 at srcf.ucam.org