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

[James Simmons]

>>I'd go for a fallback to dummycon. It's of no use to waste power on
>>creating graphical images of the text console when asleep. And the
>>fallback to dummycon is needed anyway while a fbdev is opened (in
>>2.5.x).
>
>We do already have the backup image since we need to backup & restore the
>framebuffer content.

  What he is talking about is in 2.5.X when you explictly open /dev/fb it
will call take_over_console with dummy con. This allows for several
things. One is with this approach their is no chance of a conflict between
X/DRI and fbdev. Especially when we will have fbdev drivers using DMA
internally to preform console operations. For some hardware using DMA is
the only way fbdev can work and on some platforms fbcon is the only
choice. So things going into /dev/ttyX will not have a chance to interfere
with X.  The second reason is for security. It is possible to have a
program to open /dev/fb and see what is being typed on the fore ground
console. I sealed up those holes using the dummy con approach and some
test to see if the current process is local.
  Now for fbcon its simpler. Things get writing to the shadow buffer
(vc_screenbuf). When the console gets woken up update_screen is called.
While power down the shadow buffer can be written to which is much faster
than saving a image of the framebuffer. Of course if you still want to do
this such in the case of the X server then copy the image of the
framebuffer to regular ram. Then power down /dev/fb using some ioctl calls
provide.

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