From mboxrd@z Thu Jan 1 00:00:00 1970 From: Matthew Garrett Subject: Re: Integrating OS power management with the X server Date: Mon, 25 Oct 2004 19:13:06 +0100 Sender: acpi-devel-admin-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org Message-ID: <1098727986.3996.65.camel@tyrosine> References: <417D372C.3000107@root.org> Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <417D372C.3000107-Y6VGUYTwhu0@public.gmane.org> Errors-To: acpi-devel-admin-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , List-Archive: To: acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org List-Id: linux-acpi@vger.kernel.org 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