lkml.org 
[lkml]   [2001]   [Mar]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [Linux-fbdev-devel] [RFC] fbdev & power management
Date
>  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.




-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:22    [W:0.042 / U:1.460 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site