>>So the fbdev drivers would register PM with fbcon, not PCI, correct?
>
>Either that, or the fbdev would register with PCI (or whatever), _and_
>fbcon would too independently. In that scenario, fbcon would only handle
>things like disabling the cursor timer, while fbdev's would handle HW
>issues. THe only problem is for fbcon to know that a given fbdev is
>asleep, this could be an exported per-fbdev flag, an error code, or
>whatever. In this case, fbcon can either buffer text input, or fallback
>to the cfb working on the backed up fb image (that last thing can be
>handled entirely within the fbdev I guess).
Hi!
I had to give it some thought. I like to see this handles inside the
fbdev driver itself instead of inside fbcon. For 2.5.X it will be possible
to use /dev/fb with vgacon. Even better yet it will be possible to use
just a serial console and not use a VT but still use /dev/fb. So we will
want to to have fbdev doing power management itself. As for handling the
cursors I recently purposed a standardize cursor api so X can use it as
well via userland and a standard fbcon_cursor can be written. With this
api it would be easy to handle suspending and restoring the cursor for
fbcon for /dev/fb.
As for fbcon knowing when it is asleep. Hum. We could have a flags to
tell it to have text data updates to be placed in the shadow buffer
(struct vc_datas->vc_screenbuffer) only;
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
On Wed, 14 Mar 2001, James Simmons wrote:
> >>So the fbdev drivers would register PM with fbcon, not PCI, correct?
> >
> >Either that, or the fbdev would register with PCI (or whatever), _and_
> >fbcon would too independently. In that scenario, fbcon would only handle
> >things like disabling the cursor timer, while fbdev's would handle HW
> >issues. THe only problem is for fbcon to know that a given fbdev is
> >asleep, this could be an exported per-fbdev flag, an error code, or
> >whatever. In this case, fbcon can either buffer text input, or fallback
> >to the cfb working on the backed up fb image (that last thing can be
> >handled entirely within the fbdev I guess).
[...]
> As for fbcon knowing when it is asleep. Hum. We could have a flags to
> tell it to have text data updates to be placed in the shadow buffer
> (struct vc_datas->vc_screenbuffer) only;
Very simple to implement in the fbdev itself: just replace the drawing ops by
dummy drawing ops.
This can already be done now, by providing a dummy struct display_switch, and
in the future by providing dummy accels.
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