Matthew Garrett wrote: > On Fri, Mar 09, 2007 at 10:08:05AM +0100, Pavel Machek wrote: > > > So... if current console is graphical, we leave X accessing the > > console... That's bad, because video state is not going to be > > restored...? > > A graphical console is not necessarily X. Is there any requirement for > there to be a single VT that isn't in text mode? The vt switching is > a hack, we shouldn't make life difficult for people who have their own > userspace code that's entirely capable of restoring video state on its > own.
The problem actually comes about when using Qtopia Phone Edition (QPE) on a PXA270. QPE puts the console into VT_AUTO+KD_GRAPHICS mode and writes directly to the framebuffer from then on. In this mode the kernel correctly disallows a console change, as QPE is not getting notification of a console change and thus does not know when to repaint the screen. AFAIK, X uses VT_PROCESS+KD_GRAPHICS mode, so it gets notification of a change to and from the X console, thus it knows when to repaint the screen. I think you can test this by changing the mode of a text console to KD_GRAPHICS using the KDSETMODE ioctl, then attempting to change to another text console using chvt. -- Andrew - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
