On Tue 2006-09-12 14:18:05, Jordan Crouse wrote: > On 12/09/06 14:14 -0400, Jim Gettys wrote: > > > Alternatively, hack kernel to take control from X without actually > > > switching consoles. That should be possible even with current > > > interface. > > > > This would require saving/restoring all graphics state in the kernel > > (and X already has that state internally). Feasible, but seems like > > duplication of effort. I haven't checked if there are any write-only > > registers in the Geode (though, thankfully, this kind of brain damage is > > rarer than it once was). This then begs interesting kernel/X > > synchronization issues, of course. > > We don't need any kernel output during suspend or resume. Thus, if the VT > doesn't change, then the kernel doesn't need worry about saving or restoring > the graphics state, and thats the way it should be, IMHO. > Whoever owns the current VT should be in charge of saving and restoring > the registers. > > So, we would need some way of indicating the "ownership" of the VT. And > in reality, we really only to know if the framebuffer console owns it or > not, so a boolean would suffice. In the past, I've used KD_TEXT and > KD_GRAPHICS for this purpose. As an example, on the Geode LX, I assume > that if the vc_mode is KD_GRAPHICS, then we don't own it, and we don't > do 2D accelerations. If the mode is KD_TEXT then we are free to use the > 2D engine. All I needed to add ws a notifier chain to let the framebuffer > know when the mode switched, and I was happy. I'm not sure if thats the > smartest way to handle it permanently, but it works in a pinch. KD_TEXT vs. KD_GRAPHICS looks like the way to go. Just tell X you want console back, but then don't actually redraw/switch consoles. We probably want that on normal PCs, too... console switch for suspend-to-RAM looks ugly. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html - To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
