On Tue 2010-01-26 13:46:01, H. Peter Anvin wrote: > On 01/26/2010 06:58 AM, Pavel Machek wrote: > >> > >> That would have to be done using suspend notifiers and should depend on > >> what > >> driver actually controls the screen at the moment. And I guess the only > >> case > >> in which we actually _need_ to do the kernel VT switch is when the hardware > >> is controlled by X and without KMS. > > > > We need vt switch when display is controlled by userland app directly > > accessing hw. It may or may not be X (svgalib anyone?, > > gtk-on-framebuffer? qtopia?). > > > > Ideally, userspace should explicitely tell us. KD_KERNEL_GRAPHICS > > console mode? > > It seems that the kernel would already know if it's in control of the > mode switch, no?
No, I do not think so. IIRC KD_GRAPHICS means "console is under userland control"; X will use it even if it does not directly talk to the hardware. IOW kernel knows if userland *may* be in control of graphics hardware. (And yes, not switching consoles when console is in KD_TEXT should be easy and obvious optimalization). Currently we have #define KD_TEXT 0x00 #define KD_GRAPHICS 0x01 #define KD_TEXT0 0x02 /* obsolete */ #define KD_TEXT1 0x03 /* obsolete */ I guess KD_KERNEL_GRAPHICS (or KD_INDIRECT_GRAPHICS or KD_GRAPHICS_BUT_KERNEL_CAN_DO_CONSOLE_SWITCHING or something like that) would be needed so that userland can indicate that no, cursor is no longer welcome on the screen but no, it is not accessing hw directly. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ------------------------------------------------------------------------------ The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com -- _______________________________________________ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel