Integrating OS power management with the X server

Integrating OS power management with the X server

[Nate Lawson]

[-- Attachment #1: Type: text/plain, Size: 878 bytes --]

Apologies for cross-posting this to two lists.  I am the FreeBSD ACPI 
maintainer and recently someone brought to my attention that the X 
server expects notification/control over the suspend/resume process. 
This event is implemented in this file:

xc/programs/Xserver/hw/xfree86/os-support/bsd/bsd_apm.c

This interface works for apm (except that it only has NetBSD defines 
currently) but is not implemented for ACPI.  I'd like more information 
as to what the X server actually does with this event.  Is there any 
situation where it actually needs to veto a suspend?  Does it 
potentially take seconds to save state?  Does it need to access other 
running subsystems or is it self-contained?

I've started by adding some compat defines for FreeBSD, in the attached 
patch.  Please let me know more about the expected semantics of this 
event and any caveats.

Thanks,
Nate

[-- Attachment #2: bsd_apm.diff --]
[-- Type: text/plain, Size: 1153 bytes --]

--- bsd_apm.c.orig	Sat Oct  9 12:14:26 2004
+++ bsd_apm.c	Sat Oct  9 12:24:32 2004
@@ -8,12 +8,36 @@
 #include "xf86_OSproc.h"
 #include "xf86_OSlib.h"
 
+#ifdef __FreeBSD__
+#include <machine/apm_bios.h>
+#else
 #include <machine/apmvar.h>
+#endif
 
 #define APM_DEVICE "/dev/apm"
 
 static pointer APMihPtr = NULL;
 static void bsdCloseAPM(void);
+
+/* Compat defines for FreeBSD APM. */
+#ifdef __FreeBSD__
+#define APM_STANDBY_REQ		PMEV_STANDBYREQ
+#define APM_SUSPEND_REQ		PMEV_SUSPENDREQ
+#define APM_NORMAL_RESUME	PMEV_NORMALRESUME
+#define APM_CRIT_RESUME		PMEV_CRITRESUME
+#define APM_BATTERY_LOW		PMEV_BATTERYLOW
+#define APM_POWER_CHANGE	PMEV_POWERCHANGE
+#define APM_UPDATE_TIME		PMEV_UPDATETIME
+#define APM_CRIT_SUSPEND_REQ	PMEV_CRITSUSPENDREQ
+#define APM_USER_STANDBY_REQ	PMEV_USERSTANDBYREQ
+#define APM_USER_SUSPEND_REQ	PMEV_USERSUSPENDREQ
+#define APM_SYS_STANDBY_RESUME	PMEV_STANDBYRESUME
+#define APM_CAPABILITY_CHANGE	PMEV_CAPABILITIESCHANGE
+
+#define APM_IOC_NEXTEVENT	APMIO_NEXTEVENT
+#define APM_IOC_STANDBY		APMIO_STANDBY
+#define APM_IOC_SUSPEND		APMIO_SUSPEND
+#endif /* __FreeBSD__ */
 
 static struct {
     u_int apmBsd;

Re: Integrating OS power management with the X server

[Matthew Garrett]

On Mon, 2004-10-25 at 10:26 -0700, Nate Lawson wrote:

> This interface works for apm (except that it only has NetBSD defines 
> currently) but is not implemented for ACPI.  I'd like more information 
> as to what the X server actually does with this event.  Is there any 
> situation where it actually needs to veto a suspend?  Does it 
> potentially take seconds to save state?  Does it need to access other 
> running subsystems or is it self-contained?

At the moment, is it still the case that X will be unhappy if there are
any DRI clients running when going through a suspend/resume cycle? If
so, it sounds like the server ought to reject a suspend (or,
alternatively, use the notification to kill clients).

In the future, I'd expect that some dbus-related system would be
preferable - that way X doesn't get special cased, and any application
with good cause could reject a suspend.

-- 
Matthew Garrett | mjg59-1xO5oi07KQx4cg9Nei1l7Q@public.gmane.org



-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl

Re: Integrating OS power management with the X server

[Nate Lawson]

Matthew Garrett wrote:
> On Mon, 2004-10-25 at 10:26 -0700, Nate Lawson wrote:
>>This interface works for apm (except that it only has NetBSD defines 
>>currently) but is not implemented for ACPI.  I'd like more information 
>>as to what the X server actually does with this event.  Is there any 
>>situation where it actually needs to veto a suspend?  Does it 
>>potentially take seconds to save state?  Does it need to access other 
>>running subsystems or is it self-contained?
> 
> At the moment, is it still the case that X will be unhappy if there are
> any DRI clients running when going through a suspend/resume cycle?

I don't know.

> If
> so, it sounds like the server ought to reject a suspend (or,
> alternatively, use the notification to kill clients).

Or better, properly implement saving state in DRI.

> In the future, I'd expect that some dbus-related system would be
> preferable - that way X doesn't get special cased, and any application
> with good cause could reject a suspend.

The existing bsd_apm.c works for NetBSD and is the same interface as APM 
in FreeBSD.  Basically, you open /dev/apm and get notification of 
suspend requests.  Then you can continue them by sending a suspend ioctl 
or veto by just ignoring them.  The problem is, there are some times in 
ACPI when the userland cannot veto a suspend (i.e., critical battery or 
system temperature).  My plan is to initiate an unconditional suspend in 
those cases from the kernel.  Userland will have a chance to get the 
notification but if it doesn't respond within some timeout (say a few 
seconds), the kernel continues the suspend process.

The reason for my email is it's not clear what semantics X expects and 
how much it even uses this interface.

-- 
Nate


-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl

Re: Integrating OS power management with the X server

[Stefan Dösinger]

> > At the moment, is it still the case that X will be unhappy if there are
> > any DRI clients running when going through a suspend/resume cycle?
>
> I don't know.
I don't get any crashes, but the 3D graphics flickers a lot if I have a dri 
client opened during a suspend/resume cycle.
I use the radeon(Open source) video driver, fglrx(binary) crashes when I try 
to switch back to X.

Cheers,
Stefan


-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl