Date: Sat, 09 Oct 2004 20:02:15 -0700 From: Nate Lawson <nate@root.org> To: Bruce M Simpson <bms@spc.org> Cc: Jordan Sissel <psionic@gmail.com> Subject: Re: Radeon AGP suspend/resume support Message-ID: <4168A637.7060708@root.org> In-Reply-To: <20041008223600.GL718@empiric.icir.org> References: <5ad23a300410071928791fa9c@mail.gmail.com> <20041008030317.GV664@empiric.icir.org> <5ad23a3004100720467646e1ea@mail.gmail.com> <20041008102758.GH718@empiric.icir.org> <20041008223600.GL718@empiric.icir.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Bruce M Simpson wrote: > 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. I've made a patch for this (attached) that uses a set of compat defines. > 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. Since the comments claim NetBSD dispatches these on /dev/apmctl but the bsd_apm.c code only uses /dev/apm, either NetBSD doesn't actually work or it also dispatches the events to /dev/apm. > 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. I forgot to mention before, this isn't actually true. We call the VTY switch code in user mode to switch to a tty before suspending and switch back to X on resume. This has the same effect as a suspend/resume in most cases since the driver needs to restore the video mode. I agree that it's better though to explicitly work with X's suspend/resume support. Can Eric or someone more familiar with X comment on how bsd_apm.c and the like is actually used in practice? I'm not sure which events X actually uses, whether it needs to block, etc. -- Nate
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4168A637.7060708>