Refresh ACPI APM and PMU devices on resume

[Holger Macht]

On Sun 09. Apr - 13:38:03, Richard Hughes wrote:
> On Sun, 2006-04-09 at 11:37 +0200, Holger Macht wrote:
> > On Fri 31. Mar - 00:24:16, Holger Macht wrote:
> > > On Do 30. Mär - 20:23:11, Richard Hughes wrote:
> > > [...]
> > > > 2006-03-30  Richard Hughes <richard at hughsie.com>
> > > >  * tools/hal-system-power-hibernate, tools/hal-system-power-suspend:
> > > > Refresh device types button, battery and ac_adapter on resume, as a
> > > > suspend or hibernate can do funny things to ACPI. This fixes a common
> > > > problem where HAL forgets the value of the lid button when it is
> > > > resuming and may fix other related problems also.
> > > 
> > > Well, you can't be sure that this is done after resume! Hal suspend
> > > scripts support different ways of actually doing the suspend. You do not
> > > know if the system already finished resume just a few lines later in the
> > > script. What about other calls to do the suspend other then the pm-scripts
> > > on fedora core which do not block? On a non-blocking suspend execution,
> > > it's likely that the device rescan is triggered _before_ the real call to
> > > /sys/power/state or whatever and hence could cause unexpected
> > > behaviour. Imagine some related modules are already unloaded when the
> > > rescan is done...
> > > 
> > > The best solution IMO would be to let the responsible application/script
> > > which does the suspend, trigger the rescan if it thinks that this is
> > > needed. BTW, I never experienced such problems after resume you mentioned.
> > 
> > Any comment on that?
> 
> Sorry for the delay.
> 
> I think HAL should be responsible for the rescan, else every application
> is going to have to learn what and when to refresh.

Well, but this application exactly knows when to refresh because it knows
when the system is back from suspend. Hal does not know that, respectively
there is simply not the architecture in Hal to know that. I do not want to
play the old 'hal agains independent power management daemon game' again,
just consider that there are other implementations for calling the
suspend. From your point of view, Hal should be the central application
for calling a system suspend, thus it has to support all existing
possibilities for doing that.

> Why would a suspend call be non-blocking? Seems crazy to me, as we might
> want to do all manner of stuff on the resume action.

How can you raise the claim that a non-blocking suspend trigger is crazy?
It would be also also crazy to say that a blocking one is crazy then.

The powersave client command line application sends the suspend request
via dbus to the powersave daemon. What's the difference with g-p-m sending
the request _non-blocking_ to the Hal daemon? It's pretty much the same,
thus g-p-m implementation is crazy?


     - Holger