On Tue, Oct 22, 2002 at 10:37:07PM -0400, David Dawes wrote: > On Tue, Oct 22, 2002 at 09:52:26AM +0200, Ducrot Bruno wrote: > >On Mon, Oct 21, 2002 at 05:14:28PM -0400, David Dawes wrote: > >> 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 > > > > > >[...] > > > >> 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. > > > >No difference. It is already a common trick for swsusp people. > >I don't see anything in the code that could explain why a perticular > >xaa extension is no more functionnal for this card. > >For me, VTEnter() from the nv driver seems to be correct. > > > >[...] > > > >> >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. > > If VTEnter() is doing everything needed, I'm wondering why starting another > X server then killing it solves the problem.
Me too. And the bad news is that I really do not understand what happens here. > >> 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? > > > >Nothing is done from swsusp to send power management notifications to > >user space before suspension. The same apply for ACPI. > > What's the use of acpid if it doesn't get any notifications before > suspension? Is everything that needs to be done expected to be handled > in the kernel? Yes. All processes are 'frozen', then a suspend event to all devices is send. If swsusp want to notify the suspension to user processes, it will require a major redisign at this stage. Same apply also for ACPI (under Linux, I do not speak for *BSD) because it call swsusp (for 2.5 kernels only) to implement S4. -- 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
