From: Stefan Seyfried on
Hi,

On Tue, 26 Jan 2010 15:58:43 +0100 Pavel Machek <pavel(a)ucw.cz> wrote:
> We need vt switch when display is controlled by userland app directly
> accessing hw. It may or may not be X (svgalib anyone?,
> gtk-on-framebuffer? qtopia?).

anything-on-framebuffer should not be different from plain framebuffer
console, or am I missing something?

> Ideally, userspace should explicitely tell us. KD_KERNEL_GRAPHICS
> console mode?
>
> Plus the switch is needed for any graphics app using fbcon -- I do not
> think we actually save the framebuffer over suspend. (This one should
> probably be fixed).

Framebuffer should be easy to fix - it works pretty well already
because apparently the fbcon code needs to "shadow buffer" all VT
"windows" anyway - so maybe it's just the issue of doing an additional
"redraw()" somewhere appropriate.

The VGA consoles loses their content, because AFAICT they are in the
graphics card memory, which is not saved and restored.

seife
--
Stefan Seyfried

"Any ideas, John?"
"Well, surrounding them's out."
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Pavel Machek on
On Thu 2010-01-28 00:07:51, Stefan Seyfried wrote:
> Hi,
>
> On Tue, 26 Jan 2010 15:58:43 +0100 Pavel Machek <pavel(a)ucw.cz> wrote:
> > We need vt switch when display is controlled by userland app directly
> > accessing hw. It may or may not be X (svgalib anyone?,
> > gtk-on-framebuffer? qtopia?).
>
> anything-on-framebuffer should not be different from plain framebuffer
> console, or am I missing something?

It is. At least svgalib accesses hw directly. It probably can run even
on framebuffer.

> > Ideally, userspace should explicitely tell us. KD_KERNEL_GRAPHICS
> > console mode?
> >
> > Plus the switch is needed for any graphics app using fbcon -- I do not
> > think we actually save the framebuffer over suspend. (This one should
> > probably be fixed).
>
> Framebuffer should be easy to fix - it works pretty well already
> because apparently the fbcon code needs to "shadow buffer" all VT
> "windows" anyway - so maybe it's just the issue of doing an additional
> "redraw()" somewhere appropriate.

Well, for now the "shadow buffer" contains only text, not graphics
images. So you'd need to enlarge it a lot. Doable but more than one liner.

Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Stefan Seyfried on
On Sun, 31 Jan 2010 09:54:19 +0100
Pavel Machek <pavel(a)ucw.cz> wrote:

> On Thu 2010-01-28 00:07:51, Stefan Seyfried wrote:
> > Hi,
> >
> > On Tue, 26 Jan 2010 15:58:43 +0100 Pavel Machek <pavel(a)ucw.cz> wrote:
> > > We need vt switch when display is controlled by userland app directly
> > > accessing hw. It may or may not be X (svgalib anyone?,
> > > gtk-on-framebuffer? qtopia?).
> >
> > anything-on-framebuffer should not be different from plain framebuffer
> > console, or am I missing something?
>
> It is. At least svgalib accesses hw directly. It probably can run even
> on framebuffer.

If it accesses hw directly, it's not really "anything-on-framebuffer"
anymore, is it? The framebuffer device is there to abstract the
hardware.

> Well, for now the "shadow buffer" contains only text, not graphics
> images. So you'd need to enlarge it a lot. Doable but more than one liner.

Yes, noticed this today. I was using bootsplash-patched kernels, which
are obviously different in this aspect, so that shifted my view on
reality ;)
--
Stefan Seyfried

"Any ideas, John?"
"Well, surrounding them's out."
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/