>>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 [[email protected]] ____/|
fbdev/console/gfx developer \ o.O|
http://www.linux-fbdev.org =(_)=
http://linuxgfx.sourceforge.net U
http://linuxconsole.sourceforge.net
> 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.
Ok, I see. Currently, the sleep process is started from an ioctl sent to
another
driver, which will in turn call various notifier functions to shut down
bits of
hardware and finally put the machine to sleep. It's not a direct ioctl to
the /dev/fb (which may not be opened).
One problem I have is that my fbdev sleep routine will restore the mode
on wakeup,
but that of course doesn't work with X when not using useFBDev as fbdev
have no
knowledge of the current mode or register settings used by X.
I'm wondering if it would be possible to make X think there's a console switch
(without actually switching to an active console, as we don't know if we
even have
one of those available for us), wait for it to reply, and then start the sleep
process.
One other possibility would be to implement APM-like events, I still have
to study
those more in details as our sleep process is currently quite different
from APM
(and definitely not BIOS-based).
For now, I have my hooks in fbcon that suspend/restart the cursor timer,
that's
enough to make sleep stable on 2.4 since we take care of shutting down
the display
very last (after any other driver) to make sure no printk will end up
trying to
display something while the chip is powered down.
I'll digest your various comments look into all this in more depth with
2.5 console
codebase. I beleive some solution must be found for x86 laptops too.
Ben.
On Thu, 15 Mar 2001, Benjamin Herrenschmidt wrote:
> One problem I have is that my fbdev sleep routine will restore the mode
> on wakeup,
> but that of course doesn't work with X when not using useFBDev as fbdev
> have no
> knowledge of the current mode or register settings used by X.
That's a bug in X: one must not change the video mode by banging the hardware
when running on a fbdev system.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds