Improving the suspend quirks guessworking
mjg59 at srcf.ucam.org
Sat Mar 22 06:39:56 PDT 2008
On Sat, Mar 22, 2008 at 01:38:57PM +0100, Martin Pitt wrote:
> 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
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
More information about the hal