[PATCH] Fix Macbook Addon to work after resume

[Ryan Lortie]

Since we lack the infra to do this properly right now (unless somebody
comes along and implements your todo item) I suggest just applying the
patch as originally suggested.  It fill fix the problem for "most
people" and allow the switching off of vbe state saving (which is far
more evil than anything discussed here anyway).

Cheers

On Mon, 2007-04-06 at 13:28 -0400, David Zeuthen wrote:
> On Mon, 2007-06-04 at 11:42 -0400, Ryan Lortie wrote:
> > 1) gnome-power-manager running at all.
> > 
> > 2) gnome-power-manager always implementing this feature.  maybe in the
> > next version you decide that you don't want to do it anymore. :)
> 
> I think whatever policy agent running in the desktop session (be it
> gnome-power-manager, kpowersave or whatever) needs to be smart about
> things _anyway_: e.g. set the preferred brightness when the desktop
> session becomes active again. Just think about fast-user-switching; you
> switch between two sessions that have different ideas of what the
> brightness should be. They need to listen to ConsoleKit and DTRT.
> 
> > the correct behaviour is certainly to make hal self-sufficient rather
> > than relying on a side-effect caused by a feature of g-p-m that wasn't
> > planned to fix this problem in the first place :)
> 
> Yeah, driver code should reinitialize the hardware on resume so it's
> back at the same state when you suspend. We don't do this in the hald
> backlight addons and, for the record, several of the in-kernel backlight
> drivers don't do this either (try resuming from suspend-to-disk). This
> doesn't mean, however, that it shouldn't be fixed; I've added an item to
> doc/TODO about having a mechanism for addon's to do things in the
> suspend/resume path. But as I've argue policy agents (like g-p-m) needs
> to do the right thing _anyway_ so this becomes less of an issue. Also,
> it's preferable for the backlight code to be a real kernel driver..
> 
>      David
> 
>