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]