> 1) Have as many VC's as I like - not restricted by video RAM
> size.
RAM size has nothing to do with it. I seen the arguments about hwo many
is actually needed. The best thing would be to let teh user decided like
we do with UNIX98 ptys.
> 2) Have the OPTION of having separate scrollback buffers on each
> VC, each of which can be a different runtime configurable
> size.
Thats alot of memory. I can see seperate scrollback for each head.
> 3) The ability to have each VC have its own TEXT MODE video mode,
> and have THE KERNEL be able to switch from VC to VC easily and
> change the video mode on its own without calling any userland
> stuff.
This is possible now. If people created more text hardware modes for their
vidoe cards. Note many modern card no longer a VGA core. Thats the very
reason why we have fbcon.
> Optional idea:
>
> 4) Allow a VC to be split into 2, or 4 either horiz or vert, and
> have each treated like a separate VC. I guess another layer
> of abstraction would be needed.
See other post about hardware panning. A userland app can handle this
(screen).
> 1) Puts MINIMAL code in the kernel to do what needs to be done.
Hey isn't that everyones goal :)
> 2) Does not bloat the kernel with details of every video card
> known to man or mode tables.
Sorry if you want to take advantage of TEXT hardware modes you need to
know something about the video hardware.
> Someone else suggested "screen". That solution does do anything at all
> that I asked for however, and just multiplexes the existing console as a
> layer above what is there. It also hoses many color apps, and
> its terminal emulation is not 1000% linux-console compatible.
Then screen has problems. Remember KISS for the console system. We want a
bare bone system. Yet it has just enough of a good design that userland
can build on it.
> I'm very interested in continuing this discussion with you, and
> the others who have responded! It is making it look to me like
> there is a light at the end of the tunnel that could bring the
> Linux console into the year 2000. ;o) Actually, my guess is
> that the console is allready better than anything else out there,
> so... ;o)
No problem. I see its time to soon start a linux-console developement
soon.
Codito, ergo sum - "I code, therefore I am"
James Simmons (o_
fbdev/gfx developer (o_ (o_ //\
http://www.linux-fbdev.org (/)_ (/)_ V_/_
http://linuxgfx.sourceforge.net
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Tue Feb 29 2000 - 21:00:16 EST