Applications & ACPI events

Applications & ACPI events

[Alan Hourihane]

When using ACPI to shutdown the machine to disk or memory, obviously an
application can read events from /proc/acpi/events to see what to do.

How does ACPI in the kernel wait for applications to do what they
need to when receiving an ACPI event, as it seems the kernel shuts down
everything pretty quickly ?

Alan.


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: Applications & ACPI events

[Ducrot Bruno]

On Tue, Sep 30, 2003 at 05:59:26PM +0100, Alan Hourihane wrote:
> When using ACPI to shutdown the machine to disk or memory, obviously an
> application can read events from /proc/acpi/events to see what to do.
> 
> How does ACPI in the kernel wait for applications to do what they
> need to when receiving an ACPI event, as it seems the kernel shuts down
> everything pretty quickly ?
> 

AFAIK, there is no support for suspending userspace drivers (like X).
And IHMO it is not the task to ACPI for doing so, but to the system
manager via the 'New Device Driver Model', so you can have more generic
methods for that kind of stuff (APM, ACPI, PMU for apple, etc).

You should ask Patrick Mochel (or Pavel Machek), see linux/CREDITS for
correct email address, in order to get more details.

-- 
Ducrot Bruno

--  Which is worse:  ignorance or apathy?
--  Don't know.  Don't care.


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: Applications & ACPI events

[Pavel Machek]

Hi!

> > When using ACPI to shutdown the machine to disk or memory, obviously an
> > application can read events from /proc/acpi/events to see what to do.
> > 
> > How does ACPI in the kernel wait for applications to do what they
> > need to when receiving an ACPI event, as it seems the kernel shuts down
> > everything pretty quickly ?
> 
> AFAIK, there is no support for suspending userspace drivers (like X).

Actually X get console switch event, so they should
give control of VGA to the kernel...
				Pavel
-- 
				Pavel
Written on sharp zaurus, because my Velo1 broke. If you have Velo you don't need...



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: Applications & ACPI events

[Ducrot Bruno]

On Fri, Oct 03, 2003 at 09:38:15PM +0200, Pavel Machek wrote:
> Hi!
> 
> > > When using ACPI to shutdown the machine to disk or memory, obviously an
> > > application can read events from /proc/acpi/events to see what to do.
> > > 
> > > How does ACPI in the kernel wait for applications to do what they
> > > need to when receiving an ACPI event, as it seems the kernel shuts down
> > > everything pretty quickly ?
> > 
> > AFAIK, there is no support for suspending userspace drivers (like X).
> 
> Actually X get console switch event, so they should
> give control of VGA to the kernel...

Exactly, you have to switch to a console.  That's the problem.

-- 
Ducrot Bruno

--  Which is worse:  ignorance or apathy?
--  Don't know.  Don't care.


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: Applications & ACPI events

[Pavel Machek]

Hi!

> > > > When using ACPI to shutdown the machine to disk or memory, obviously an
> > > > application can read events from /proc/acpi/events to see what to do.
> > > > 
> > > > How does ACPI in the kernel wait for applications to do what they
> > > > need to when receiving an ACPI event, as it seems the kernel shuts down
> > > > everything pretty quickly ?
> > > 
> > > AFAIK, there is no support for suspending userspace drivers (like X).
> > 
> > Actually X get console switch event, so they should
> > give control of VGA to the kernel...
> 
> Exactly, you have to switch to a console.  That's the problem.

???

Kernel tells X to switch to console; there's interface to say that,
and we are using it. It should just work.
								Pavel
-- 
When do you have a heart between your knees?
[Johanka's followup: and *two* hearts?]


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: Applications & ACPI events

[Ducrot Bruno]

On Mon, Oct 06, 2003 at 03:05:34PM +0200, Pavel Machek wrote:
> Hi!
> 
> > > > > When using ACPI to shutdown the machine to disk or memory, obviously an
> > > > > application can read events from /proc/acpi/events to see what to do.
> > > > > 
> > > > > How does ACPI in the kernel wait for applications to do what they
> > > > > need to when receiving an ACPI event, as it seems the kernel shuts down
> > > > > everything pretty quickly ?
> > > > 
> > > > AFAIK, there is no support for suspending userspace drivers (like X).
> > > 
> > > Actually X get console switch event, so they should
> > > give control of VGA to the kernel...
> > 
> > Exactly, you have to switch to a console.  That's the problem.
> 
> ???
> 
> Kernel tells X to switch to console; there's interface to say that,
> and we are using it. It should just work.

X know more exactly what it have to do to save current states of
the video chipset, or even know when to put the video chipset
in suspend mode.  The nv driver (for example) have to reset the
whole xvideo stuff just because it do not work anymore after a
suspend/resume, but this reset is not necessary for just
switching to console.  2D/3D acceleration in general also need
more works after a suspend/resume which is not necessary
for just switching to console.
All of that console switching work only on intel like archs.

-- 
Ducrot Bruno

--  Which is worse:  ignorance or apathy?
--  Don't know.  Don't care.


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: Applications & ACPI events

[Pavel Machek]

Hi!

> > > > > > When using ACPI to shutdown the machine to disk or memory, obviously an
> > > > > > application can read events from /proc/acpi/events to see what to do.
> > > > > > 
> > > > > > How does ACPI in the kernel wait for applications to do what they
> > > > > > need to when receiving an ACPI event, as it seems the kernel shuts down
> > > > > > everything pretty quickly ?
> > > > > 
> > > > > AFAIK, there is no support for suspending userspace drivers (like X).
> > > > 
> > > > Actually X get console switch event, so they should
> > > > give control of VGA to the kernel...
> > > 
> > > Exactly, you have to switch to a console.  That's the problem.
> > 
> > ???
> > 
> > Kernel tells X to switch to console; there's interface to say that,
> > and we are using it. It should just work.
> 
> X know more exactly what it have to do to save current states of
> the video chipset, or even know when to put the video chipset
> in suspend mode.  The nv driver (for example) have to reset the
> whole xvideo stuff just because it do not work anymore after a
> suspend/resume, but this reset is not necessary for just
> switching to console.  2D/3D acceleration in general also need
> more works after a suspend/resume which is not necessary
> for just switching to console.
> All of that console switching work only on intel like archs.

IMO X should do full save and restore, on every console switch. That
way it is safe to killall -9 X when you are on console, and I think I
like it that way. I do not think console switching is i386-only, I
know that sparc64's had consoles, too.

OTOH if X knew how to bring video card up from powerdown... that would
help a lot, and would need a kernel support. ("Hey, X, I just did
resume and graphics card is uninitialized. It is not even in vga text
mode. Do something with it.")
								Pavel

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


-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
SourceForge.net hosts over 70,000 Open Source Projects.
See the people who have HELPED US provide better services:
Click here: http://sourceforge.net/supporters.php

Re: Applications & ACPI events

[Alan Hourihane]

On Wed, Oct 08, 2003 at 09:16:11PM +0200, Pavel Machek wrote:
> Hi!
> 
> > > > > > > When using ACPI to shutdown the machine to disk or memory, obviously an
> > > > > > > application can read events from /proc/acpi/events to see what to do.
> > > > > > > 
> > > > > > > How does ACPI in the kernel wait for applications to do what they
> > > > > > > need to when receiving an ACPI event, as it seems the kernel shuts down
> > > > > > > everything pretty quickly ?
> > > > > > 
> > > > > > AFAIK, there is no support for suspending userspace drivers (like X).
> > > > > 
> > > > > Actually X get console switch event, so they should
> > > > > give control of VGA to the kernel...
> > > > 
> > > > Exactly, you have to switch to a console.  That's the problem.
> > > 
> > > ???
> > > 
> > > Kernel tells X to switch to console; there's interface to say that,
> > > and we are using it. It should just work.
> > 
> > X know more exactly what it have to do to save current states of
> > the video chipset, or even know when to put the video chipset
> > in suspend mode.  The nv driver (for example) have to reset the
> > whole xvideo stuff just because it do not work anymore after a
> > suspend/resume, but this reset is not necessary for just
> > switching to console.  2D/3D acceleration in general also need
> > more works after a suspend/resume which is not necessary
> > for just switching to console.
> > All of that console switching work only on intel like archs.
> 
> IMO X should do full save and restore, on every console switch. That
> way it is safe to killall -9 X when you are on console, and I think I
> like it that way. I do not think console switching is i386-only, I
> know that sparc64's had consoles, too.
 
Doing a kill -9 on any application doesn't allow the application to
catch the signal. Thus X cannot restore itself, and neither can any
application that gets it. If you kill -9 anything then suffer the 
consequences of it not cleaning up.

> OTOH if X knew how to bring video card up from powerdown... that would
> help a lot, and would need a kernel support. ("Hey, X, I just did
> resume and graphics card is uninitialized. It is not even in vga text
> mode. Do something with it.")

Most drivers in X do know how to bring up the video chip from an
uninitialized state. If the kernel is doing a VT switch internally and
back again on resume then it should just work.

Is that what your saying currently happens in 2.6.0-test6 ??

Or is it only in your swsusp package for that functionality ??

Alan.


-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
SourceForge.net hosts over 70,000 Open Source Projects.
See the people who have HELPED US provide better services:
Click here: http://sourceforge.net/supporters.php

Re: Applications & ACPI events

[Pavel Machek]

Hi!

> > IMO X should do full save and restore, on every console switch. That
> > way it is safe to killall -9 X when you are on console, and I think I
> > like it that way. I do not think console switching is i386-only, I
> > know that sparc64's had consoles, too.
>  
> Doing a kill -9 on any application doesn't allow the application to
> catch the signal. Thus X cannot restore itself, and neither can any
> application that gets it. If you kill -9 anything then suffer the 
> consequences of it not cleaning up.

I should be able to kill -9 any task and keep my system running (I'm
not complaining about stale lock files etc). Unfortunately that is not
true with X. It would be nice if at kill -9 would be safe at least
when kernel has control of display.

> > OTOH if X knew how to bring video card up from powerdown... that would
> > help a lot, and would need a kernel support. ("Hey, X, I just did
> > resume and graphics card is uninitialized. It is not even in vga text
> > mode. Do something with it.")
> 
> Most drivers in X do know how to bring up the video chip from an
> uninitialized state. If the kernel is doing a VT switch internally and
> back again on resume then it should just work.

Kernel is doing VT switch in -test6. But I do not really think X can
bring up the video chip... are you really able to program video card
memory timings and similar stuff? On what cards?
								Pavel
-- 
When do you have a heart between your knees?
[Johanka's followup: and *two* hearts?]


-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
SourceForge.net hosts over 70,000 Open Source Projects.
See the people who have HELPED US provide better services:
Click here: http://sourceforge.net/supporters.php

Re: Applications & ACPI events

[Karol Kozimor]

Thus wrote Pavel Machek:
> Kernel is doing VT switch in -test6. But I do not really think X can
> bring up the video chip... are you really able to program video card
> memory timings and similar stuff? On what cards?

That's how it's done with the Radeon driver, i.e. 1.9.0 DRM module and
recent DRI snaphosts -- the engine is initialized / POSTed on VT switch.
Best regards,

-- 
Karol 'sziwan' Kozimor
sziwan-DETuoxkZsSqrDJvtcaxF/A@public.gmane.org


-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
SourceForge.net hosts over 70,000 Open Source Projects.
See the people who have HELPED US provide better services:
Click here: http://sourceforge.net/supporters.php

Re: Applications & ACPI eventse

[Pavel Machek]

Hi!

> > Kernel is doing VT switch in -test6. But I do not really think X can
> > bring up the video chip... are you really able to program video card
> > memory timings and similar stuff? On what cards?
> 
> That's how it's done with the Radeon driver, i.e. 1.9.0 DRM module and
> recent DRI snaphosts -- the engine is initialized / POSTed on VT switch.

Well, then radeon should "just work".

Only remaining problem is when you attempt to s3-suspend from console
(not from X). But I do not see how thats solved.
								Pavel
-- 
When do you have a heart between your knees?
[Johanka's followup: and *two* hearts?]


-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
SourceForge.net hosts over 70,000 Open Source Projects.
See the people who have HELPED US provide better services:
Click here: http://sourceforge.net/supporters.php

Re: Applications & ACPI eventse

[Karol Kozimor]

Thus wrote Pavel Machek:
> > That's how it's done with the Radeon driver, i.e. 1.9.0 DRM module and
> > recent DRI snaphosts -- the engine is initialized / POSTed on VT switch.
> Well, then radeon should "just work".

It actually does, at least for S4 in 2.4 (Nigel's swsusp).

> Only remaining problem is when you attempt to s3-suspend from console
> (not from X). But I do not see how thats solved.

That's not a problem for X, since it initializes the adapter on *every* VT 
switch, and for the console, an appropriate driver (i.e. radeonfb or
something different) should take care of that.
Best regards,

-- 
Karol 'sziwan' Kozimor
sziwan-DETuoxkZsSqrDJvtcaxF/A@public.gmane.org


-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
SourceForge.net hosts over 70,000 Open Source Projects.
See the people who have HELPED US provide better services:
Click here: http://sourceforge.net/supporters.php

Re: Applications & ACPI eventse

[Pavel Machek]

Hi!

> > > That's how it's done with the Radeon driver, i.e. 1.9.0 DRM module and
> > > recent DRI snaphosts -- the engine is initialized / POSTed on VT switch.
> > Well, then radeon should "just work".
> 
> It actually does, at least for S4 in 2.4 (Nigel's swsusp).

S4 is very different case, since card is already initialized by
BIOS. Don't mix these!

> > Only remaining problem is when you attempt to s3-suspend from console
> > (not from X). But I do not see how thats solved.
> 
> That's not a problem for X, since it initializes the adapter on *every* VT 
> switch, and for the console, an appropriate driver (i.e. radeonfb or
> something different) should take care of that.

I'm told manufacturer documentation is usually not enough to
completely initialize card; and we do not want x86 emulator inside
kernel, right?
								Pavel

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


-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
SourceForge.net hosts over 70,000 Open Source Projects.
See the people who have HELPED US provide better services:
Click here: http://sourceforge.net/supporters.php

Re: Applications & ACPI eventse

[Karol Kozimor]

Thus wrote Pavel Machek:
> > > > That's how it's done with the Radeon driver, i.e. 1.9.0 DRM module and
> > > > recent DRI snaphosts -- the engine is initialized / POSTed on VT switch.
> > > Well, then radeon should "just work".
> > It actually does, at least for S4 in 2.4 (Nigel's swsusp).
> S4 is very different case, since card is already initialized by
> BIOS. Don't mix these!

But the DRI engine is not, so switching back to unpatched XFree86-4.3.0
after resume corrupts the display and does other not-so-nice things.

The S4 example was merely to illustrate what the radeon driver does.

Best regards,

-- 
Karol 'sziwan' Kozimor
sziwan-DETuoxkZsSqrDJvtcaxF/A@public.gmane.org


-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
SourceForge.net hosts over 70,000 Open Source Projects.
See the people who have HELPED US provide better services:
Click here: http://sourceforge.net/supporters.php

Re: Applications & ACPI eventse

[Bas Mevissen]

Karol Kozimor wrote:
> 
> But the DRI engine is not, so switching back to unpatched XFree86-4.3.0
> after resume corrupts the display and does other not-so-nice things.
> 
> The S4 example was merely to illustrate what the radeon driver does.
> 

Ah, maybe that is my problem with S4 suspend (swsuspend actually). I 
thought installing the binary release (containing kernel driver (build 
from source) and XFree patches) was enough. But do I need other things too?

What do I need (starting with a clean X install from Red Hat 9) to get a 
proper resuming (from S3 and S4) X with a radeon video card? Is the 
agpgart from kernel 2.4.22 new enough?

Bas.





-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
SourceForge.net hosts over 70,000 Open Source Projects.
See the people who have HELPED US provide better services:
Click here: http://sourceforge.net/supporters.php

Re: Applications & ACPI eventse

[Karol Kozimor]

Thus wrote Bas Mevissen:
> Ah, maybe that is my problem with S4 suspend (swsuspend actually). I 
> thought installing the binary release (containing kernel driver (build 
> from source) and XFree patches) was enough. But do I need other things too?

It is enough. You need to install it and switch VTs before suspend and after
resume to get it working. That's provided you use DRI, without DRI you
don't need patching at all.

> What do I need (starting with a clean X install from Red Hat 9) to get a 
> proper resuming (from S3 and S4) X with a radeon video card? Is the 
> agpgart from kernel 2.4.22 new enough?

Install binary packages from dri.sf.net and switch VTs.
Best regards,

-- 
Karol 'sziwan' Kozimor
sziwan-DETuoxkZsSqrDJvtcaxF/A@public.gmane.org


-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
SourceForge.net hosts over 70,000 Open Source Projects.
See the people who have HELPED US provide better services:
Click here: http://sourceforge.net/supporters.php

Re: Applications & ACPI eventse

[Bas Mevissen]

Karol Kozimor wrote:
> Thus wrote Bas Mevissen:
> 
>>Ah, maybe that is my problem with S4 suspend (swsuspend actually). I 
>>thought installing the binary release (containing kernel driver (build 
>>from source) and XFree patches) was enough. But do I need other things too?
> 
> 
> It is enough. You need to install it and switch VTs before suspend and after
> resume to get it working. That's provided you use DRI, without DRI you
> don't need patching at all.
> 

OK. I'll try without DRI to check if I'm not having a different problem.


>>What do I need (starting with a clean X install from Red Hat 9) to get a 
>>proper resuming (from S3 and S4) X with a radeon video card? Is the 
>>agpgart from kernel 2.4.22 new enough?
> 
> Install binary packages from dri.sf.net and switch VTs.
> Best regards,
> 

That's what I did. But it didn't work. Maybe it is a problem with swsusp.

Bas.




-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
SourceForge.net hosts over 70,000 Open Source Projects.
See the people who have HELPED US provide better services:
Click here: http://sourceforge.net/supporters.php

Re: Applications & ACPI eventse

[Pavel Machek]

Hi!

> > > That's how it's done with the Radeon driver, i.e. 1.9.0 DRM module and
> > > recent DRI snaphosts -- the engine is initialized / POSTed on VT switch.
> > Well, then radeon should "just work".
> 
> It actually does, at least for S4 in 2.4 (Nigel's swsusp).
> 
> > Only remaining problem is when you attempt to s3-suspend from console
> > (not from X). But I do not see how thats solved.
> 
> That's not a problem for X, since it initializes the adapter on *every* VT 
> switch, and for the console, an appropriate driver (i.e. radeonfb or
> something different) should take care of that.
> Best regards,

Maybe this clears stuff?
								Pavel

--- clean/Documentation/kernel-parameters.txt	2003-10-09 00:13:09.000000000 +0200
+++ linux/Documentation/kernel-parameters.txt	2003-10-10 09:36:31.000000000 +0200
@@ -90,6 +90,10 @@
 			off -- disabled ACPI for systems with default on
 			ht -- run only enough ACPI to enable Hyper Threading
 			See also Documentation/pm.txt.
+
+	acpi_sleep=	[HW,ACPI] Sleep options
+			Format: { s3_bios, s3_mode }
+			See Documentation/power/video.txt
  
 	ad1816=		[HW,OSS]
 			Format: <io>,<irq>,<dma>,<dma2>
--- clean/Documentation/power/video.txt	2003-10-10 09:11:51.000000000 +0200
+++ linux/Documentation/power/video.txt	2003-10-10 09:40:44.000000000 +0200
@@ -0,0 +1,36 @@
+
+		Video issues with S3 resume
+		~~~~~~~~~~~~~~~~~~~~~~~~~~~
+		     2003, Pavel Machek
+
+During S3 resume, hardware needs to be reinitialized. For most
+devices, this is easy, and kernel driver knows how to do
+it. Unfortunately there's one exception: video card. Those are usually
+initialized by BIOS, and kernel does not have enough information to
+boot video card. (Kernel usually does not even contain video card
+driver -- vesafb and vgacon are widely used).
+
+This is not problem for swsusp, because during swsusp resume, BIOS is
+run normally so video card is normally initialized.
+
+There are three types of systems where video works after S3 resume:
+
+* systems where video state is preserved over S3. (HP Omnibook xe3)
+
+* systems that initialize video card into vga text mode and where BIOS
+  works well enough to be able to set video mode. Use
+  acpi_sleep=s3_mode on these. (Toshiba 4030cdt)
+
+* systems where it is possible to call video bios during S3
+  resume. Unfortunately, it is not correct to call video BIOS at that
+  point, but it happens to work on some machines. Use
+  acpi_sleep=s3_bios (Athlon64 desktop system)
+
+Now, if you pass acpi_sleep=something, and it does not work with your
+bios, you'll get hard crash during resume. Be carefull.
+
+You may have system where none of above works. At that point you
+either invent another ugly hack that works, or write proper driver for
+your video card (good luck getting docs :-(). Maybe suspending from X
+(proper X, knowing your hardware, not XF68_FBcon) might have better
+chance of working.


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


-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
SourceForge.net hosts over 70,000 Open Source Projects.
See the people who have HELPED US provide better services:
Click here: http://sourceforge.net/supporters.php

Re: Applications & ACPI events

[Alan Hourihane]

On Wed, Oct 08, 2003 at 11:58:50PM +0200, Pavel Machek wrote:
> Hi!
> 
> > > IMO X should do full save and restore, on every console switch. That
> > > way it is safe to killall -9 X when you are on console, and I think I
> > > like it that way. I do not think console switching is i386-only, I
> > > know that sparc64's had consoles, too.
> >  
> > Doing a kill -9 on any application doesn't allow the application to
> > catch the signal. Thus X cannot restore itself, and neither can any
> > application that gets it. If you kill -9 anything then suffer the 
> > consequences of it not cleaning up.
> 
> I should be able to kill -9 any task and keep my system running (I'm
> not complaining about stale lock files etc). Unfortunately that is not
> true with X. It would be nice if at kill -9 would be safe at least
> when kernel has control of display.
 
You said 'X should do full save and restore, on every console switch'.
The fact is that X can only do a full save/restore (and it does!) on
the VT that it owns. If you really want to do a kill -9, then the
kernel has no choice but to clean up and restore itself which is impossible
as it knows nothing about some of the intricasies of the some of the graphics
engines out there.

> > > OTOH if X knew how to bring video card up from powerdown... that would
> > > help a lot, and would need a kernel support. ("Hey, X, I just did
> > > resume and graphics card is uninitialized. It is not even in vga text
> > > mode. Do something with it.")
> > 
> > Most drivers in X do know how to bring up the video chip from an
> > uninitialized state. If the kernel is doing a VT switch internally and
> > back again on resume then it should just work.
> 
> Kernel is doing VT switch in -test6. But I do not really think X can
> bring up the video chip... are you really able to program video card
> memory timings and similar stuff? On what cards?

X can bring it up. X uses the int10 library to softboot a video board.
XFree86 even has an x86 emulator so it can do this on non-X86 platforms.

I guess I'll just have to try -test6 to see if it does VT switch when
hitting the power button to suspend.... 

Alan.


-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
SourceForge.net hosts over 70,000 Open Source Projects.
See the people who have HELPED US provide better services:
Click here: http://sourceforge.net/supporters.php

Re: Applications & ACPI events

[Pavel Machek]

Hi!

> > > > IMO X should do full save and restore, on every console switch. That
> > > > way it is safe to killall -9 X when you are on console, and I think I
> > > > like it that way. I do not think console switching is i386-only, I
> > > > know that sparc64's had consoles, too.
> > >  
> > > Doing a kill -9 on any application doesn't allow the application to
> > > catch the signal. Thus X cannot restore itself, and neither can any
> > > application that gets it. If you kill -9 anything then suffer the 
> > > consequences of it not cleaning up.
> > 
> > I should be able to kill -9 any task and keep my system running (I'm
> > not complaining about stale lock files etc). Unfortunately that is not
> > true with X. It would be nice if at kill -9 would be safe at least
> > when kernel has control of display.
>  
> You said 'X should do full save and restore, on every console switch'.
> The fact is that X can only do a full save/restore (and it does!) on
> the VT that it owns. If you really want to do a kill -9, then the
> kernel has no choice but to clean up and restore itself which is impossible
> as it knows nothing about some of the intricasies of the some of the graphics
> engines out there.

Thats okay, I do not want to kill -9 X when it owns console.

X does _not_ do full save/restore, at least not for all
drivers. vesafb does no saving, and generic vga driver is also
incapable of full save/restore. Not sure about others.

> > > > OTOH if X knew how to bring video card up from powerdown... that would
> > > > help a lot, and would need a kernel support. ("Hey, X, I just did
> > > > resume and graphics card is uninitialized. It is not even in vga text
> > > > mode. Do something with it.")
> > > 
> > > Most drivers in X do know how to bring up the video chip from an
> > > uninitialized state. If the kernel is doing a VT switch internally and
> > > back again on resume then it should just work.
> > 
> > Kernel is doing VT switch in -test6. But I do not really think X can
> > bring up the video chip... are you really able to program video card
> > memory timings and similar stuff? On what cards?
> 
> X can bring it up. X uses the int10 library to softboot a video board.
> XFree86 even has an x86 emulator so it can do this on non-X86 platforms.
> 
> I guess I'll just have to try -test6 to see if it does VT switch when
> hitting the power button to suspend.... 

Be sure to report results..
									Pavel
-- 
When do you have a heart between your knees?
[Johanka's followup: and *two* hearts?]


-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
SourceForge.net hosts over 70,000 Open Source Projects.
See the people who have HELPED US provide better services:
Click here: http://sourceforge.net/supporters.php

Re: Applications & ACPI events

[Ducrot Bruno]

On Thu, Oct 09, 2003 at 11:35:05PM +0200, Pavel Machek wrote:
> Hi!
> 
> > > > > IMO X should do full save and restore, on every console switch. That
> > > > > way it is safe to killall -9 X when you are on console, and I think I
> > > > > like it that way. I do not think console switching is i386-only, I
> > > > > know that sparc64's had consoles, too.
> > > >  
> > > > Doing a kill -9 on any application doesn't allow the application to
> > > > catch the signal. Thus X cannot restore itself, and neither can any
> > > > application that gets it. If you kill -9 anything then suffer the 
> > > > consequences of it not cleaning up.
> > > 
> > > I should be able to kill -9 any task and keep my system running (I'm
> > > not complaining about stale lock files etc). Unfortunately that is not
> > > true with X. It would be nice if at kill -9 would be safe at least
> > > when kernel has control of display.
> >  
> > You said 'X should do full save and restore, on every console switch'.
> > The fact is that X can only do a full save/restore (and it does!) on
> > the VT that it owns. If you really want to do a kill -9, then the
> > kernel has no choice but to clean up and restore itself which is impossible
> > as it knows nothing about some of the intricasies of the some of the graphics
> > engines out there.
> 
> Thats okay, I do not want to kill -9 X when it owns console.
> 
> X does _not_ do full save/restore, at least not for all
> drivers. vesafb does no saving, and generic vga driver is also
> incapable of full save/restore. Not sure about others.

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

Again, the nv driver do not properly work after a resume (in fact, S4bios),
some of his accelerated 2D funcitons do not work any more (but rework after
something like 30 to 40 seconds), but work like a charm if VT switch only.
(of course, there is a VT switch in-between).

PS: I have not tryed the newer nv driver though.

-- 
Ducrot Bruno

--  Which is worse:  ignorance or apathy?
--  Don't know.  Don't care.


-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
SourceForge.net hosts over 70,000 Open Source Projects.
See the people who have HELPED US provide better services:
Click here: http://sourceforge.net/supporters.php

Re: Applications & ACPI events

[Karol Kozimor]

Thus wrote Ducrot Bruno:
> 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).
Best regards,

-- 
Karol 'sziwan' Kozimor
sziwan-DETuoxkZsSqrDJvtcaxF/A@public.gmane.org


-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
SourceForge.net hosts over 70,000 Open Source Projects.
See the people who have HELPED US provide better services:
Click here: http://sourceforge.net/supporters.php

Re: Applications & ACPI events

[Pavel Machek]

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

Console switch

a) should not take seconds.

b) should not be needed for S1. It is hw bug if it is.

If radeon m7 is broken, well, ...
									Pavel
-- 
When do you have a heart between your knees?
[Johanka's followup: and *two* hearts?]


-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
SourceForge.net hosts over 70,000 Open Source Projects.
See the people who have HELPED US provide better services:
Click here: http://sourceforge.net/supporters.php

Re: Applications & ACPI events

[Karol Kozimor]

Thus wrote Pavel Machek:
> > 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).
> 
> Console switch
> 
> a) should not take seconds.

You mean switching between a text console and another, or between a text
console and X? If it's the first case, than it doesn't. If th second, than
yes, it takes some 3-4 seconds to switch. Part of that I attribute to the
driver reinitializing the DRI engine.

> b) should not be needed for S1. It is hw bug if it is.

Well, entering S1 while X is running with DRI and no console switch is done
causes similar symptoms to S4 resume in the same situation. I'm not sure
that's the same thing. but it looks so.

> If radeon m7 is broken, well, ...

I don't really know. I'm afraid X's PM support plays the key role here.
Best regards,

-- 
Karol 'sziwan' Kozimor
sziwan-DETuoxkZsSqrDJvtcaxF/A@public.gmane.org


-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
SourceForge.net hosts over 70,000 Open Source Projects.
See the people who have HELPED US provide better services:
Click here: http://sourceforge.net/supporters.php

Re: Applications & ACPI events

[Pavel Machek]

Hi!

> > > 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).
> > 
> > Console switch
> > 
> > a) should not take seconds.
> 
> You mean switching between a text console and another, or between a text
> console and X? If it's the first case, than it doesn't. If th second, than
> yes, it takes some 3-4 seconds to switch. Part of that I attribute to the
> driver reinitializing the DRI engine.

Are you should it is not monitor playing catch up? When you change
resolution/dot clock, monitors take a while to synchronize... DRI
engine should not take seconds to initialize...

> > b) should not be needed for S1. It is hw bug if it is.
> 
> Well, entering S1 while X is running with DRI and no console switch is done
> causes similar symptoms to S4 resume in the same situation. I'm not sure
> that's the same thing. but it looks so.

IIRC, S1 should be transparent to software.
									Pavel
-- 
When do you have a heart between your knees?
[Johanka's followup: and *two* hearts?]


-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
SourceForge.net hosts over 70,000 Open Source Projects.
See the people who have HELPED US provide better services:
Click here: http://sourceforge.net/supporters.php

Re: Applications & ACPI events

[Karol Kozimor]

Thus wrote Pavel Machek:
> > You mean switching between a text console and another, or between a text
> > console and X? If it's the first case, than it doesn't. If th second, than
> > yes, it takes some 3-4 seconds to switch. Part of that I attribute to the
> > driver reinitializing the DRI engine.
> Are you should it is not monitor playing catch up? When you change
> resolution/dot clock, monitors take a while to synchronize... DRI
> engine should not take seconds to initialize...

It's an LCD, and the modes are roughly the same (I'm using radeonfb with
the display's native resolution).

> > > b) should not be needed for S1. It is hw bug if it is.
> > Well, entering S1 while X is running with DRI and no console switch is done
> > causes similar symptoms to S4 resume in the same situation. I'm not sure
> > that's the same thing. but it looks so.
> IIRC, S1 should be transparent to software.

Well, than how is uhci.o locking the system dead if it's loaded on resume
(under 2.4, that is, 2.6 is OK)?
Best regards,

-- 
Karol 'sziwan' Kozimor
sziwan-DETuoxkZsSqrDJvtcaxF/A@public.gmane.org


-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
SourceForge.net hosts over 70,000 Open Source Projects.
See the people who have HELPED US provide better services:
Click here: http://sourceforge.net/supporters.php

Re: Applications & ACPI events

[Pavel Machek]

Hi!

> > > > b) should not be needed for S1. It is hw bug if it is.
> > > Well, entering S1 while X is running with DRI and no console switch is done
> > > causes similar symptoms to S4 resume in the same situation. I'm not sure
> > > that's the same thing. but it looks so.
> > IIRC, S1 should be transparent to software.
> 
> Well, than how is uhci.o locking the system dead if it's loaded on resume
> (under 2.4, that is, 2.6 is OK)?

Okay, I worded it badly.

For S1 kernel should not need to save any hardware
state. Unfortunately that does not stop kernel from doing something
stupid and kill system :-(.
								Pavel

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


-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
SourceForge.net hosts over 70,000 Open Source Projects.
See the people who have HELPED US provide better services:
Click here: http://sourceforge.net/supporters.php

Re: Applications & ACPI events

[Patrick Mochel]

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

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. 

To get this working, you need the latest hotplug package, and you need to
create the directory /etc/hotplug.d/power/. Applications may install
executables, or smlinks to executables, in that directory, which will be
called during both suspend and resume.

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

AFAIK, this should also generate a D-BUS event that desktop applications 
may use to hook into the suspend/resume cycle. TBH, I'm not sure of the 
status of this in the hotplug package. 

The detail that is not worked out is how to signal X to perform a suspend 
resume. Though, extending the X API to trigger a graphics and input 
save/restore should be relatively straight-forward, and might be kinda 
fun. :) 

Barring any serious objections, I'll most likely be sending this to 
Linus/Andrew in the next couple of weeks..


	Pat

===== kernel/power/main.c 1.16 vs edited =====
--- 1.16/kernel/power/main.c	Mon Sep  8 15:13:46 2003
+++ edited/kernel/power/main.c	Tue Sep 30 15:35:47 2003
@@ -16,6 +16,7 @@
 #include <linux/delay.h>
 #include <linux/errno.h>
 #include <linux/init.h>
+#include <linux/kmod.h>
 #include <linux/pm.h>
 
 
@@ -117,6 +118,59 @@
 
 
 
+#ifdef CONFIG_HOTPLUG
+
+
+/**
+ *	user_suspend - notify userspace of suspend.
+ *
+ *	Notify userspace that we're going to sleep, and wait for it to finish
+ *	shutting down whatever it needs before we proceed.
+ *
+ */
+	
+static int tell_userspace(char * state, int suspend)
+{
+	char * argv[3];
+	char * envp[5];
+	char env_action[16];
+	char env_state[16];
+	int error;
+
+	if (!hotplug_path[0])
+		return 0;
+
+	argv[0] = hotplug_path;
+	argv[1] = "power";
+	argv[2] = NULL;
+
+	snprintf(env_state,16,"STATE=%s",state);
+	snprintf(env_action,16,"ACTION=%s",suspend ? "suspend" : "resume");
+
+	envp[0] = "HOME=/";
+	envp[1] = "PATH=/sbin:/bin:/usr/sbin:/usr/bin";
+	envp[2] = env_action;
+	envp[3] = env_state;
+	envp[4] = NULL;
+
+	pr_debug("PM: Calling userspace: %s %s\n",env_action,env_state);
+
+	error = call_usermodehelper(argv[0],argv,envp,1);
+
+	return error;
+}
+
+
+#else /* CONFIG_HOTPLUG */
+
+
+static int tell_userspace(char * state, int suspend)
+{
+	return 0;
+}
+
+#endif 
+
 
 char * pm_states[] = {
 	[PM_SUSPEND_STANDBY]	= "standby",
@@ -150,9 +204,12 @@
 		goto Unlock;
 	}
 
+	if ((error = tell_userspace(pm_states[state],1)))
+		goto Unlock;
+
 	if (state == PM_SUSPEND_DISK) {
 		error = pm_suspend_disk();
-		goto Unlock;
+		goto Resume;
 	}
 
 	pr_debug("PM: Preparing system for suspend\n");
@@ -164,6 +221,8 @@
 
 	pr_debug("PM: Finishing up.\n");
 	suspend_finish(state);
+ Resume:
+	tell_userspace(pm_states[state],0);
  Unlock:
 	up(&pm_sem);
 	return error;



-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
SourceForge.net hosts over 70,000 Open Source Projects.
See the people who have HELPED US provide better services:
Click here: http://sourceforge.net/supporters.php

Re: Applications & ACPI events

[Pavel Machek]

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


-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
SourceForge.net hosts over 70,000 Open Source Projects.
See the people who have HELPED US provide better services:
Click here: http://sourceforge.net/supporters.php

Re: Applications & ACPI events

[Karol Kozimor]

Thus wrote Pavel Machek:
> > 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.

I think Pavel is right in this sense, but aside from that it would be 
extremely convenient to be able to suspend and resume directly from X,
without VT switching. I personally don't care if I have to wait additional
4 seconds of VT switch when resuming from S4, but the same delay is
unacceptable for S1, and even S3 (remember what ACPI spec says about
timings). That's why we really need a way for kernel to tell the userspace
(at least X) that a suspend / resume cycle is going on.

The hard part is on the X side. Given X's development cycle, we can expect
such a mechanism by the time 2.8 is ready :(

Best regards,

-- 
Karol 'sziwan' Kozimor
sziwan-DETuoxkZsSqrDJvtcaxF/A@public.gmane.org


-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
SourceForge.net hosts over 70,000 Open Source Projects.
See the people who have HELPED US provide better services:
Click here: http://sourceforge.net/supporters.php

Re: Applications & ACPI events

[Pavel Machek]

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.
> 
> I think Pavel is right in this sense, but aside from that it would be 
> extremely convenient to be able to suspend and resume directly from X,
> without VT switching. I personally don't care if I have to wait additional
> 4 seconds of VT switch when resuming from S4, but the same delay is
> unacceptable for S1, and even S3 (remember what ACPI spec says about
> timings). That's why we really need a way for kernel to tell the userspace
> (at least X) that a suspend / resume cycle is going on.

Patrick just presented such way, it looks okay.

*But* I think it is not going to speed anything up. Doing console
switch is probably as fast as resume.

OTOH, during S3 suspend, you can get away without "savning"... Okay,
some speedups are possible. Right solution for fast S1 is not to
switch consoles, not to stop processes etc. But that assumes hardware
that works...

Plus your comment about X development cycle looks accurate :-(. 
								Pavel
-- 
When do you have a heart between your knees?
[Johanka's followup: and *two* hearts?]


-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
SourceForge.net hosts over 70,000 Open Source Projects.
See the people who have HELPED US provide better services:
Click here: http://sourceforge.net/supporters.php

Re: Applications & ACPI events

[Patrick Mochel]

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

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

I really don't want to lose the abstraction, since it currently is 
platform-neutral, and doesn't include any x86isms.

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

I agree. If we can agree on an interface, it should be usable for any 
platform's power management notification. 

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


	Pat



-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
SourceForge.net hosts over 70,000 Open Source Projects.
See the people who have HELPED US provide better services:
Click here: http://sourceforge.net/supporters.php

Re: Applications & ACPI events

[Alan Hourihane]

On Tue, Oct 14, 2003 at 04:04:31PM -0700, Patrick Mochel wrote:
> > 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.

Alan.


-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
SourceForge.net hosts over 70,000 Open Source Projects.
See the people who have HELPED US provide better services:
Click here: http://sourceforge.net/supporters.php

Re: Applications & ACPI events

[Pavel Machek]

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


-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
SourceForge.net hosts over 70,000 Open Source Projects.
See the people who have HELPED US provide better services:
Click here: http://sourceforge.net/supporters.php

Re: Applications & ACPI events

[Karol Kozimor]

Thus wrote Pavel Machek:
> Patrick's hotplug patch. (Ouch, it makes X depend on
> /sbin/hotplug... :-( )

I can't see that. Regardless of the actual mechanism used to notify X (be
it polling, a socket or something completely different), X would have to be
specifically tailored to actualy depend on hotplug in the Kconfig-like
sense. In most cases, a safe fallback should be enough.
Best regards,

-- 
Karol 'sziwan' Kozimor
sziwan-DETuoxkZsSqrDJvtcaxF/A@public.gmane.org


-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
SourceForge.net hosts over 70,000 Open Source Projects.
See the people who have HELPED US provide better services:
Click here: http://sourceforge.net/supporters.php

Re: Applications & ACPI events

[Patrick Mochel]

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




-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
SourceForge.net hosts over 70,000 Open Source Projects.
See the people who have HELPED US provide better services:
Click here: http://sourceforge.net/supporters.php

Re: Applications & ACPI events

[Alan Hourihane]

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.


-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
SourceForge.net hosts over 70,000 Open Source Projects.
See the people who have HELPED US provide better services:
Click here: http://sourceforge.net/supporters.php

Hardware state saving & X

[Pavel Machek]

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


-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
SourceForge.net hosts over 70,000 Open Source Projects.
See the people who have HELPED US provide better services:
Click here: http://sourceforge.net/supporters.php

Re: Hardware state saving & X

[Patrick Mochel]

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

Whatever, that's fine. 

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

The fact that different behavior exists is completely obvious (refer to 
the question and documentation). The question was *how* it was different 
from a userpsace perspective. I.e. what exactly is saved, and what isn't. 

Under APM, the BIOS handles the state transition, but it does not know 
each device initimately, so the OS still has to handle some of the device 
state. 

Video devices have an int10 call to save/restore state, which is what the 
APM BIOS uses. Alan, would it suffice to call that from the kernel, in 
either vm86 mode or real mode to handle all the saving/restoring. If we 
were able to call that, what more would you have to do? 


	Pat




-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
SourceForge.net hosts over 70,000 Open Source Projects.
See the people who have HELPED US provide better services:
Click here: http://sourceforge.net/supporters.php

Re: Hardware state saving & X

[Pavel Machek]

Hi!

> > > 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).
> 
> The fact that different behavior exists is completely obvious (refer to 
> the question and documentation). The question was *how* it was different 
> from a userpsace perspective. I.e. what exactly is saved, and what isn't. 
> 
> Under APM, the BIOS handles the state transition, but it does not know 
> each device initimately, so the OS still has to handle some of the device 
> state. 

I guess you answered yourself ;-). X is hardware driver. On some
machines, video is handled by bios during apm -s. That's not the case
during S3. Therefore X wants to know if it should do hardware saving
or not.

[Of course, X might want to save allways (simulated console switch).]

> Video devices have an int10 call to save/restore state, which is what the 
> APM BIOS uses.

Could you elaborate? I'm not aware of int10 call doing that... That
would solve S3 video problems, right? I was told that we can't call
int10 at all from real mode because pci might not yet be intialized
during acpi_wakeup.S; but it works on machines I have here.

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


-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
SourceForge.net hosts over 70,000 Open Source Projects.
See the people who have HELPED US provide better services:
Click here: http://sourceforge.net/supporters.php

Re: Re: Hardware state saving & X

[Alan Hourihane]

On Wed, Oct 15, 2003 at 09:32:18AM -0700, Patrick Mochel wrote:
> The fact that different behavior exists is completely obvious (refer to 
> the question and documentation). The question was *how* it was different 
> from a userpsace perspective. I.e. what exactly is saved, and what isn't. 
> 
> Under APM, the BIOS handles the state transition, but it does not know 
> each device initimately, so the OS still has to handle some of the device 
> state. 
> 
> Video devices have an int10 call to save/restore state, which is what the 
> APM BIOS uses. Alan, would it suffice to call that from the kernel, in 
> either vm86 mode or real mode to handle all the saving/restoring. If we 
> were able to call that, what more would you have to do? 

I'm not sure you can call int10 from kernel space. But think about
other architectures too that don't have int10/x86 available to them.
XFree86 already has an x86 emulator to do the softbooting via int10 in
userspace, but I appreciate if people are not running X, then the kernel
needs to restore some sort of text mode too from the last session.

It's never been an issue of what to save/restore for X - that's the drivers
responsibility in X. And if it doesn't do it properly now, I'd consider it
a bug in the driver and should be fixed.

The main question was how to get events from suspend/resume so that we
can do this saving and restoring.

If the /sbin/hotplug & DBUS is the recommended route, then I really
need to go look at these two pieces of software and craft something up for X.

Alan.


-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
SourceForge.net hosts over 70,000 Open Source Projects.
See the people who have HELPED US provide better services:
Click here: http://sourceforge.net/supporters.php

Re: Re: Hardware state saving & X

[Patrick Mochel]

> It's never been an issue of what to save/restore for X - that's the drivers
> responsibility in X. And if it doesn't do it properly now, I'd consider it
> a bug in the driver and should be fixed.

Fair enough. 

> The main question was how to get events from suspend/resume so that we
> can do this saving and restoring.
> 
> If the /sbin/hotplug & DBUS is the recommended route, then I really
> need to go look at these two pieces of software and craft something up for X.

Please go with that. I'll merge the patch with Linus in the next week. If 
you have any problems with it, please let me know, and I'll be happy to 
fix them. 

Thanks,


	Pat



-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
SourceForge.net hosts over 70,000 Open Source Projects.
See the people who have HELPED US provide better services:
Click here: http://sourceforge.net/supporters.php

Re: Applications & ACPI events

[Pavel Machek]

Hi!

> > X does _not_ do full save/restore, at least not for all
> > drivers. vesafb does no saving, and generic vga driver is also
> > incapable of full save/restore. Not sure about others.
> 
> 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'.

Such interface would be pretty ugly.. There are at least these states
kernel can enter:

S1
S3
swsusp
S4bios
apm -s
apm -S

. And anyway not doing complete hw initialization on console switch is
wrong. How can X know that the game on tty3 is not playing with hw
acceleration?

								Pavel

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


-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
SourceForge.net hosts over 70,000 Open Source Projects.
See the people who have HELPED US provide better services:
Click here: http://sourceforge.net/supporters.php

Re: Applications & ACPI events

[Ducrot Bruno]

On Mon, Oct 13, 2003 at 05:26:37PM +0200, Pavel Machek wrote:
> Hi!
> 
> > > X does _not_ do full save/restore, at least not for all
> > > drivers. vesafb does no saving, and generic vga driver is also
> > > incapable of full save/restore. Not sure about others.
> > 
> > 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'.
> 
> Such interface would be pretty ugly.. There are at least these states
> kernel can enter:
> 
> S1
> S3
> swsusp
> S4bios
> apm -s
> apm -S
> 
> . And anyway not doing complete hw initialization on console switch is
> wrong. How can X know that the game on tty3 is not playing with hw
> acceleration?

Ok, I see your point now.

-- 
Ducrot Bruno

--  Which is worse:  ignorance or apathy?
--  Don't know.  Don't care.


-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
SourceForge.net hosts over 70,000 Open Source Projects.
See the people who have HELPED US provide better services:
Click here: http://sourceforge.net/supporters.php

RE: Applications & ACPI events

[Grover, Andrew]

> [mailto:acpi-devel-admin-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org] On Behalf Of 
> Patrick Mochel
> > 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.

This was what I was aiming for with ospmd/libpower -- a
PM-implementation-neutral method for user apps to get notified of
shutdowns before the kernel does its thing. However, have you read
anything about D-bus? That initiative seems like it might be right for
this kind of thing, too.

http://www.freedesktop.org/Software/dbus

Regards -- Andy


-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
SourceForge.net hosts over 70,000 Open Source Projects.
See the people who have HELPED US provide better services:
Click here: http://sourceforge.net/supporters.php

RE: Applications & ACPI events

[Patrick Mochel]

> This was what I was aiming for with ospmd/libpower -- a
> PM-implementation-neutral method for user apps to get notified of
> shutdowns before the kernel does its thing. However, have you read
> anything about D-bus? That initiative seems like it might be right for
> this kind of thing, too.
> 
> http://www.freedesktop.org/Software/dbus

Funny you should mention that - the hotplug package now generates D-BUS
events for each hotplug event. So, by using the hotplug mechanism, the
desktop folks will also get the event notification, allowing them to
perform user-configured actions, too. 


	Pat



-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
SourceForge.net hosts over 70,000 Open Source Projects.
See the people who have HELPED US provide better services:
Click here: http://sourceforge.net/supporters.php