Refresh ACPI APM and PMU devices on resume

Richard Hughes hughsient at gmail.com
Sun Apr 9 05:38:03 PDT 2006


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.

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.

Richard.



More information about the hal mailing list