Index:
[thread]
[date]
[subject]
[author]
From: James Simmons <jsimmons@edgeglobal.com>
To : ggi-develop@eskimo.com
Date: Wed, 18 Aug 1999 15:22:43 -0400 (EDT)
Re: VC Switching
On Wed, 18 Aug 1999, Brian S. Julin wrote:
> On Tue, 17 Aug 1999, Michael Gersten wrote:
> > Lets face it: We want Linux, and the graphic console system, to
> > run equally well on 1-4 MB cards on 386/486 systems, or 56 MB cards
> > on P2's and P3's with 32-128 MB of memory, right?
>
> I for one don't buy the "56M card" rational for killing VC switching
> while in graphics mode. Most apps won't use nearly that much of
> the card's RAM. In fact, a 56M card whose driver could protect it's
> memory area would allow us to stow away several VC's worth of fb
> data *in video RAM* simultaneously; perhaps even to allow drawing
> by several apps on their fb data whether or not their VC is
> focused. Maybe even eventually allowing card<->disk DMA transfer
> directly into the swap partition as needed -- who knows.
No. Thats not what I'm saying. VC are no problem to allow switching. For
fbcon a text buffer is tsored and when a VT switch happens the text buffer
is read and then translated to pixel images. So with fbcon you still can
use the 4Kb text buffers of VTs. What I am saying is that once you open
fbdev and are using it for graphical purposes that you can't vt switch.
Now you can if you chose save a image of fbdev and close fbdev then vt
switch. I'm saying is that with /dev/fb open and mmap that a vt switch
then is impractical unless you drop the mmap image each time. Now their
will be some users that want the kernel to save this image. I as it should
be decided in userland instead on what to do with the framebuffer image.
Index:
[thread]
[date]
[subject]
[author]