>But wouldn't falling back to dummycon prevent the driver specific
>suspend/resume calls from working? Or at a minimum, make handling those
>calls more complex?
Not if suspend/resume are handled on the fbdev driver level. Dummycon
would only shutdown fbcon on explict open of /dev/fb. Also note it will be
possible to have only a serial console and use /dev/fb by itself. In this
case we don't even need dummycon since their is no VT support present.
>No, there does not need to be graphical images of the text console -- a
>simply text buffer would suffice.
See email to Ben.
>But what about things like GTKFb and
>Embedded QT? They would certainly benefit from having a backup screen
>image, right? I do not believe there is any way to determine if the
>console is in fact in a 'text' or graphical state.
Yes and it would not be hard to do this. I have the basic idea in the
email to Ben. As for console in text or graphical state take a look at
vt_ioctl.c:vt_ioctl() for KDGETMODE. You get back KD_TEXT or KD_GRAPHICS.
MS: (n) 1. A debilitating and surprisingly widespread affliction that
renders the sufferer barely able to perform the simplest task. 2. A disease.
James Simmons [[EMAIL PROTECTED]] ____/|
fbdev/console/gfx developer \ o.O|
http://www.linux-fbdev.org =(_)=
http://linuxgfx.sourceforge.net U
http://linuxconsole.sourceforge.net
-
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/
