>I think registering fbcon as a PM client and doing the above when the
>fbdev suspend/resume hooks are called should work. A memory backup is
>worked on until the resume is run and the backup is restored to the
>display.
>
>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).
Ben.
On Wed, 14 Mar 2001, Benjamin Herrenschmidt wrote:
> >I think registering fbcon as a PM client and doing the above when the
> >fbdev suspend/resume hooks are called should work. A memory backup is
> >worked on until the resume is run and the backup is restored to the
> >display.
> >
> >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).
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).
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
>> 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).
>
>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.
Ben.
On Wed, 14 Mar 2001, Benjamin Herrenschmidt wrote:
> >> 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).
> >
> >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.
Fine. Keep it. But there's no reason to keep on updating it when the screen
contents change. Fbcon can do that when the fbdev goes out of sleep mode.
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
On 14 Mar 2001 14:39:57 +0100, Geert Uytterhoeven wrote:
> On Wed, 14 Mar 2001, Benjamin Herrenschmidt wrote:
> > >I think registering fbcon as a PM client and doing the above when the
> > >fbdev suspend/resume hooks are called should work. A memory backup is
> > >worked on until the resume is run and the backup is restored to the
> > >display.
> > >
> > >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).
>
> 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).
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?
No, there does not need to be graphical images of the text console -- a
simply text buffer would suffice. 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.
Brad Douglas
[email protected]
http://www.linux-fbdev.org