[Pm-utils] [PATCH 6/7] This patch adds framebuffer console handling routines.

[Victor Lowther]

On Wed, Feb 13, 2008 at 06:44:43PM +0100, Michael Biebl wrote:
> 2008/2/13, Victor Lowther <victor.lowther at gmail.com>:
> > Mostly because right now I am submitting patches for pm-utils, so I will
> > favor the approach it currently uses instead in relying on yet another
> > external package.
> 
> It wouldn't be *another* dependency but a replacement for radeontools
> *and* vbetools (so actually less dependencies)

Fair enough.  

> > We cannot get rid of the dependence on vbetools
> > because tuxonice relies on it for all three sleep methods.
> 
> This is a valid point. s2ram should have a command line option (like
> --save-only/--restore), so it would be usable together with tuxonice.

And when s2ram actually has that level of support built-in, we can add
support for it and recommend that everyone else use it.  Until then,
though, the current methods will continue to work, and removing them
would not really be appropriate.

> > > Imho using s2ram (with the quirks provided by hal, and optionally
> > > fallback to the builtin whitelist) seems like a good solution.
> >
> > If a given distro wants to do that, fine.  I have made it easier
> > for them to do so.  With the modular sleep method patches, distros do
> > not have to patch the core pm-utils functionality to do just what you
> > propose -- just replace the uswsusp module with the one you want and
> > delete the (20|99)video sleep hooks.
> >
> > I think that adding logic into pm-utils to handle s2ram or s2both
> > as a special case in our video quirk handling complexifies the current
> > video handling needlessly, when all the end-user or distro.
> 
> I don't think that using s2ram would realy make it that more complex,
> actually, as it would replace vbetools/radeontools, it would make it
> simpler.

Not really -- most of the complexity in the current video hooks is due
to parsing the options from HAL and accounting for user overrides, and
making user overrides easy overwhelmingly more important to me than what
method we actually use to run the quirks, and here is why:

My system is a Dell Latitude D820 with the nvidia 7400 go.  They also
shipped with intergrated Intel video.  You cannot tell the difference
looking just at system model and BIOS revision.  In my system, the
default whitelist applies the wrong quirks every time and without
overriding the whitelist supplied settings my system will die on resume
every time when the card gets POSTed.  Submitting a whitelist update
would be guaranteed to break other systems in the field, because the
whitelist does not look at what video card the system is actually using,
which (these days) is the single biggest source of suspend/resume
glitches.

The same holds true for any portable system that can be purchased with
different models of video card.

I would prefer a whitelist that actually looks at the installed video
card(s) and the driver(s) those cards are using before applying quirks.

Without fixing that flaw, arguing the benefits of using s2ram vs.
vbetool to run quirk workarounds is a waste of electrons from my
perspective.

> Cheers,
> Michael
> 
> 
> -- 
> Why is it that all of the instruments seeking intelligent life in the
> universe are pointed away from Earth?

-- 
Victor Lowther
Ubuntu Certified Professional