From owner-freebsd-acpi@FreeBSD.ORG Sun Dec 12 05:59:28 2004 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5651E16A4CE for ; Sun, 12 Dec 2004 05:59:28 +0000 (GMT) Received: from ylpvm43.prodigy.net (ylpvm43-ext.prodigy.net [207.115.57.74]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0797643D77 for ; Sun, 12 Dec 2004 05:59:28 +0000 (GMT) (envelope-from nate@root.org) Received: from [10.0.5.50] (adsl-64-171-186-123.dsl.snfc21.pacbell.net [64.171.186.123])iBC5xWsV020834; Sun, 12 Dec 2004 00:59:33 -0500 Message-ID: <41BBDE39.6020101@root.org> Date: Sat, 11 Dec 2004 21:59:21 -0800 From: Nate Lawson User-Agent: Mozilla Thunderbird 1.0RC1 (X11/20041205) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Igor Partola References: <41BA85A0.3050206@pisem.net> <41BB4DC4.6090901@root.org> <41BBB645.3010500@pisem.net> In-Reply-To: <41BBB645.3010500@pisem.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-acpi@freebsd.org Subject: Re: Dell Inspiron 8600 X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Dec 2004 05:59:28 -0000 Igor Partola wrote: > Nate Lawson wrote: > >> >> Yes, this is a deficiency in the current usermode interface. If you >> look at my web page, I have a description of how to fix this if >> someone wants to do it. It includes implementing the /dev/apm >> suspend/standby compatibility ioctls including a timeout interface. >> See the "Implement X suspend/resume notification" section below. >> >> http://www.root.org/~nate/freebsd/acpi-todo.html >> > That's a deficiency in the X server though isn't it? Without X running > this fix would do no good. I thought the problem was in either the > kernel ACPI implementation or in devd. > > I do not claim to be in any degree an expert in this though since I am > not at all familiar with the inner workings of either. I'm just trying > to set up this laptop to work nicely with FreeBSD. :). If I hook up suspend/resume events to just go out devd, there's no guarantee your usermode code would get run before the system suspends since devd is not blocking. By implementing the ioctl, we could depend on apmd running rc.suspend/resume before allowing the requested action to continue. It has the side effect that another usermode program (X), can also sit blocking the suspend path but multiple control programs (apmd, X) would require device cloning or BPF-style /dev/apm0, 1, 2, ... and the kernel would not be allowed to suspend until everyone voted "yes". As you can see, this requires some thinking and implementation work and I'd be happy if someone wanted to do it. -- Nate