From owner-freebsd-current@FreeBSD.ORG Sat Oct 9 13:15:40 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0FE6416A4CE for ; Sat, 9 Oct 2004 13:15:40 +0000 (GMT) Received: from smtpout.mac.com (smtpout.mac.com [17.250.248.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id D490D43D2F for ; Sat, 9 Oct 2004 13:15:39 +0000 (GMT) (envelope-from itinerant@mac.com) Received: from mac.com (smtpin02-en2 [10.13.10.147]) by smtpout.mac.com (Xserve/MantshX 2.0) with ESMTP id i99DFdvV013963 for ; Sat, 9 Oct 2004 06:15:39 -0700 (PDT) Received: from [192.168.1.197] (82-32-116-242.cable.ubr03.hawk.blueyonder.co.uk [82.32.116.242]) (authenticated bits=0) by mac.com (Xserve/smtpin02/MantshX 4.0) with ESMTP id i99DFbGI018213 for ; Sat, 9 Oct 2004 06:15:38 -0700 (PDT) Message-ID: <4167E476.4050505@mac.com> Date: Sat, 09 Oct 2004 14:15:34 +0100 From: Pete Carss User-Agent: Mozilla Thunderbird 0.6 (Windows/20040502) X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-current@freebsd.org References: <5ad23a300410071928791fa9c@mail.gmail.com> <416731A3.50807@root.org> In-Reply-To: <416731A3.50807@root.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: Radeon AGP suspend/resume support X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Oct 2004 13:15:40 -0000 Nate Lawson wrote: > Bruce M Simpson wrote: > >> Hello, >> >> I should be most grateful if someone else could confirm my findings here. >> This is based purely on my reading of the code; I haven't tried watching >> debug messages yet to see what happens. > > > This is interesting and I agree work is needed here. > >> On Fri, Oct 08, 2004 at 03:27:58AM -0700, Bruce M Simpson wrote: >> >>> Ok. Well some initial research suggests that many of the userland >>> pieces are >>> already there in xorg 6.7.0, after some rummaging around in the source: >>> http://www.spinics.net/lists/xf-xpert/msg04368.html >> >> >> Actually the problem is worse than that, from what I can see. There is a >> module in the xorg/Xfree86 tree called bsd_apm.c. This is meant to poll >> the /dev/apm device on the BSDs for suspend/resume event notifications >> coming from the APM BIOS. >> >> There are two problems with this: >> 1) This uses a NetBSD specific interface, which, whilst broadly similar >> to FreeBSD's apm support, is not ABI compatible with ours. >> 2) The ACPI apm shim does not dispatch such events. They are only >> dispatched within the system if 'real' BIOS APM support is in the >> kernel. This cannot co-exist with ACPI. Furthermore they are only >> announced on the /dev/apmctl device; there are some comments in the >> code to this effect. >> >> So *no* suspend/resume support ever actually gets called, for any >> userland >> driver in the X tree, on FreeBSD. It seems X needs to be re-educated >> about >> how FreeBSD suspends and resumes. It may well be more appropriate to >> rewrite >> this module entirely from scratch for use with ACPI. >> >> This would seem to boil down to two components being needed: >> a) AGP suspend/resume support. >> b) X.org/XF86 support for suspend/resume with ACPI. > > > I agree. Here's some more detail of what I think is needed in these areas. > > a) PCI/AGP video driver > John has some initial support for a real PCI/AGP video driver. This > would implement the suspend/resume functionality for VGA and also do > DPMS calls to turn off/on the display as appropriate. This needs to > interface with acpi_video in some way since they are both attaching to > the same actual device. > > b) X notification of suspend/resume on FreeBSD > This is easy in one sense but tricky in another. The easy approach is > to just add support for the APM_IOC_NEXTEVENT ioctl and a no-op for > APM_IOC_STANDBY (or the FreeBSD equivalents if this is NetBSD-specific.) > Then X gets the notify and has the chance to suspend. The catch is > that the current model doesn't support userland being in the blocking > path for any ACPI events. So currently if X took a while to suspend, it > might not complete before the actual suspend. > > The tough thing about putting usermode in the driver seat is how to know > if it has crashed. I suspect we can do this with a timeout() and just > give the usermode a max of 10 seconds or so to complete suspending > before the system unconditionally suspends. I'm curious if anyone else > has thoughts on this model. > This make me wonder how Apple do it in their implementation of X - anything that could be ported back to FreeBSD? Pete