Re: Applications & ACPI events

Pavel Machek
2003-10-14T23:55:51Z

Hi!

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

Kernel really should call LeaveVT() before suspend, and EnterVT()
after suspend [And it does now, with exception of apm.]. That should
get rid of 99% of problems... The rest of them can be handled by
Patrick's hotplug patch. (Ouch, it makes X depend on
/sbin/hotplug... :-( )

Pavel
--
When do you have a heart between your knees?
[Johanka's followup: and *two* hearts?]