From: Stefan Seyfried on 27 Jan 2010 18:10 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 31 Jan 2010 04:00 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 3 Feb 2010 09:30 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/
|
Pages: 1 Prev: SCSI bug fixes for 2.6.33-rc5 Next: perf session: Create kernel maps in the constructor |