Integrating OS power management with the X server
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
bsd_apm.c renamed from bsd_apm.c.orig +24 -0
@@ -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;
A message that is not in the archive (sent off-list or not yet received): [email protected]
Quoted 6 lines · Nate Lawson
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.
Signature · 9 lines
Matthew Garrett | [email protected] ------------------------------------------------------- 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
Quoted 5 lines · Matthew Garrett
Quoted 1 line · Nate Lawson
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.
Quoted 3 lines
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.
Quoted 3 lines
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.
Signature · 8 lines
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
A message that is not in the archive (sent off-list or not yet received): [email protected]
Quoted 4 lines
Quoted 2 lines
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