Re: Applications & ACPI events

Pavel Machek
2003-10-13T17:17:04Z

Hi!

> > > That exactly my point. And I think it should not do full save/restore
> > > on only VT switch, but we may try to have a better fine grained stuff for,
> > > something like 'hey, X we have to go S3, please consider'.
> >
> > I second that. Sure, VT switch is necessary, but it takes quite a few
> > seconds, which is unacceptable for S1 for example (Radeon M7 needs the
> > restore after S1 too).
>
> It's also unncessary for X to do a full save/restore of the video card on
> every VT switch. I personally find it annoying to wait a second or two
> when switching from X to the console.

??

What if game or another X server is running on different console.

> The proper semantics can be obtained with this patch, which I sent to Alan
> last week after asking for a solution. It calls /sbin/hotplug on suspend
> and resume, passing the state that we're entering in the environment
> variables.

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

Hmm, apm.. they already have some mechanism to do just this. These two
should be coordinated. [And this one certainly looks nicer than apm
way.]

> The kernel will wait for userspace to finish, so it is free to do whatever
> it needs (shutdown 3d engines, etc). For now, the kernel will not
> recognize the return value, though there should be a patch floating around
> in the -mm tree that fixes that..

Kernel waiting for userspace to finish with pm_sem held... If that
code tries to do "echo platform > disk" in the meantime, you get ugly
deadlock.

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