Hardware state saving & X

Pavel Machek
2003-10-14T23:52:41Z

Hi!

> > > 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.
>
> Is it really the current X server's responsibility to provide for what
> ever may be running on what ever console the user switches to? That seems
> backwards - the application that is being switched to should save the
> state of that which it's switching from. This is an X question, though,
> and not fodder for this list..

Well, each application should do

* save state
* reinitialize everything

when it is switched to, and

* shutdown everything
* restore state

when it is being switched from. That includes random game, and that
includes X.

Well, its not quite X question... Its more fbcon question or
something. We are dictating interface X uses.

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

Different scripts should run on apm -s (BIOS saves most of hw state)
and S3 (we have to save most of hw state).

> > 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.
>
> Then, that would be a bug, and would be fixed in early stages of testing.
> :)

Userspace will be able to cause D-stated processes, which is ugly, but
perhaps it is reasonable. But at least document it somewhere.

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