On Fri, Oct 18, 2002 at 08:38:22AM +0100, 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.
Does it make a difference if you switch to a text VT before initiating a suspend? That's how XFree86 handles APM suspend/resume. With a correctly implemented VTEnter(), the driver should then reinitalise the hardware correctly when switching back to the X server after resuming. Some drivers don't to enough hw state initialisation in their VTEnter() function to handle returning from suspend. All of this assumes that the BIOS (and OS?) put the video hardware back into a sane text console state -- ideally the same state as after a normal system boot. If that doesn't happen, then there are likely to be problems. >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. > >Another way to solve the problem is to start another Xserver on another >display then kill it. This probably does the reset that should come >though APM. > >Is there a way for a user space program to signal to the X server that >a suspend is about to happen or that a resume has happend to enable >this reset to be done more cleanly. Currently the X server only monitors the APM device for power management events. If swsusp can use some equivalent of apmd (or acpid), it should be possible to have that daemon force a VT switch on suspend, and switch back on resume (using chvt(1) as I suggested above). >I think adding ACPI support to XFree86 is the way to go rather than a >user space deamon. Kernel 2.4.20 is going to have a (almost) fully >working ACPI implementation, the swsusp patch will still be needed for >S4(suspend to disk), S1 (suspend to RAM) will work on some machines. What's the current state of acpid? David _______________________________________________ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
