On Sun, Oct 20, 2002 at 02:52:16PM -0700, Mark Vojkovich wrote: > On Fri, 18 Oct 2002, Philip Blacker wrote: > > > >> I'm wondering if it's feasible for the kernel to route ACPI power > > >>management events to the corresponding APM events through /dev/apm > > >>(optionally, of course) for some sort of ACPI to APM backwards > > >>compatibility for some apps that use /dev/apm (like XFree86). > > >>Otherwise somebody will have to add /dev/acpi support to XFree86. > > > > >It might be feasible to do this in user space too with a daemon that > > >listens on /dev/acpi and delivers translated events on /dev/apm. > > >Ultimately we probably want to add ACPI support to XFree86 so that it > > >can take full advantage of what ACPI offers over APM. > > > > >I think the original poster mentioned swsusp, which I thought was > > >independent of APM and ACPI? I don't know what (if any) mechanism it > > >uses to inform interested user-space applications that a suspend has > > >been initiated. Either the X server needs to be informed about the > > >suspend and resume so that it can do what needs to do, or have > > something > > >else does get informed use chvt(1) to make the X server VT switch to > > >a text console on suspend and switch back on resume. I think the chvt > > > > >method is what people used before XFree86 had support for monitoring > > >APM events. > > > > >David > > > > Swsusp is totally independant of ACPI and APM, although it can be > > called by either. I am not sure if it fires an APM or ACPI event if > > these are enabled. > > > > Through the swsusp mailing list it has been esatblished that the prblem > > is with XAA, or more specifically with one XAA function, > > SolidTwoPointLine. If this is disabled everything works correctly. It > > apears that the hardware acceleration gets confused during the suspend/ > > resume cycle. > > The bios does something to the hardware when it goes into suspend > that messes up the graphics engine state. At this time, I don't know > what it is that it does.
swsusp is a legacy interface to implement suspend-to-disk feature to linux. No APM call is then done. ACPI (only in linux 2.5) use this legacy interface to implement S4, and call the necessary (as for example the _PTS ASL Methods before suspension, _WAK after resuming, etc) No such things is done, though in linux 2.4 + swsusp. Please note that the same trouble can occur with FreeBSD current, with a S4BIOS suspend/resume cycle, and yes, a system state snapshoot is done by the BIOS in that case. > > > > > It has also been reported that when using the closed source driver, > > patched so that is does not block power management events, the 3d > > functinality does not work immediately after resume but will start > > working some time later. This would imply that there is a problem with > > the nvidia hardware after a resume that requires some form of reset. > > Same problem. Bios messes things up and we have no way of > knowing about it. In the case of the binary drivers it's not safe > to run with the power management unblocked because when the bios > messes with the hardware it can do things that effect the kernel > module in a fatal way (lost interrupts and the like). > It is possible to inform the binary driver that a suspension can occur via ACPI. The function RmPowerManagement() in the binary portion were supposed to be called by ACPI. This function seems to be in the NVIDIA_kernel-1.0.2314 release, but is now removed. If this function is (re)implemented for linux 2.5, suspend/resume via ACPI can be done for this card. Please note also that there were efforts to have proper suspend/resume under ACPI with the help of drm for other cards. Cheers, -- Ducrot Bruno http://www.poupinou.org Page profaissionelle http://toto.tu-me-saoules.com Haume page _______________________________________________ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
