Re: Applications & ACPI events

[Alan Hourihane <alanh-ASBjxr/nLg+TY6FTCsQk+9Bc4/FLrbF6@public.gmane.org>]

On Tue, Oct 14, 2003 at 04:04:31PM -0700, Patrick Mochel wrote:
> > Patch looks reasonable, but:
> > 
> > STATE= should really be more finegrained. ACPI s3 is really differnent
> > from apm -s, and it looks to me like you'll only tell userspace 'mem'.
> 
> Well, it depends on what X (and in general userspace) needs to know on a 
> power-state transition. Alan, how does/will X behave differently for each 
> power state that we can enter? 
 
Not normally, but it can. X has two functions called EnterVT() and LeaveVT()
when switching VT's, but we can also define a function called PMEvent() in
each driver to do specific things based on the PM event type. Now back
in the days of APM we can handle various things, and the only driver that
implements the extended functionality of PMEvent() currently is the Intel
i830 driver. Traditionally though, during an APM event we'd normally just
called the drivers EnterVT()/LeaveVT() function.

So with APM we could open /proc/apm & /dev/apm_bios and X could get
events itself and deal with them in different ways.

Currently I've got X opening /proc/acpi/events and acting upon them, but
obviously this race condition is with the kernel shutting us down before
X has a chance to catch up. This is where the stickling point is on
how to signal X from the kernel.

I'm keen to hear anymore opinions on this.

Alan.


-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
SourceForge.net hosts over 70,000 Open Source Projects.
See the people who have HELPED US provide better services:
Click here: http://sourceforge.net/supporters.php