Re: Applications & ACPI events

Alan Hourihane
2003-10-15T17:07:35Z

On Wed, Oct 15, 2003 at 09:20:22AM -0700, Patrick Mochel wrote:
>
> > > 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.
>
> Not quite what I was looking for, but thanks.

Then, can you elaborate on what you are looking for ??

> What state would the i830 driver save?

Driver specific stuff. Anything it wants to...

> What more would you expect to save with ACPI?

Nothing. I'm not sure what your asking here. The EnterVT/LeaveVT functions
do all the save and restoring of the driver specific state, so if the
kernel is doing a VT switch for us, then X should work out of the box.

> Do you expect XInput drivers to care?

Possibly, it's not something I've considered yet. I'd like to get the
graphics driver doing the right thing first.

> > 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.
>
> It's actually a lot cleaner, and a lot easier to use the hotplug interface
> that I described before. We can extend the X API to include a PM event
> signalling mechanism. The hotplug scripts can call some simple X app that
> sends the message to the server and causes the graphics driver (and any
> XInput drivers that need the message) to save state.
>
> This would also be portable across Linux platforms that used different
> mechanisms for reading PM events from the kernel (acpid or some APM
> daemon); and across OSes that have similar needs.

I know. I've now got to go off and plug up some solution for the hotplug
scripts to signal X.

Alan.