Re: Applications & ACPI events

Patrick Mochel
2003-10-15T16:20:22Z

> > 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.

What state would the i830 driver save?

What more would you expect to save with ACPI?

Do you expect XInput drivers to care?

> 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.

Pat