Re: [Linux-fbdev-devel] [RFC] fbdev & power management

[James S. <jsi...@li...>]

>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  [jsi...@li...]               ____/|
fbdev/console/gfx developer                             \ o.O|
http://www.linux-fbdev.org                               =(_)=
http://linuxgfx.sourceforge.net                            U
http://linuxconsole.sourceforge.net