Re: Introducing the LCD-Linux project

[James Simmons <jsimmons@infradead.org>]

> > was born. Implementing this  in the standard Linux terminal emulation
> > would require
> > a rewrite of most of the code, which I personally would do only if
> > there is some interest from
> > the community in improving the standard Linux console
> 
> There is a great deal of interest. Most of the console (as in
> framebuffer) activity moved to the 3D direct rendering world some time
> ago.

Really. I didn't expect the console to be of much interest.
 
> Let's start at the beginning. What console layer things need fixing to
> make the LCD Linux project able to use them ?
> 
> Multiple displays live at once is an obvious one - the 3D graphics folks
> also want some of that too.

Okay you asked for it. 

1) To do multiple displays will require the console tool updates.

2) Kill the big ugly console lock. One lock for not only multiple 
   VTs but even multiple types of consoles is horrible. I seen on 
   embedded board using the framebuffer device take the console
   lock thus block the serial port.

3) Invert the VT layer. Currently the console/printk driver is on top of
   the tty layer. It would be nice to be able to only use a very light 
   weight vt printk without the VT tty on top for embedded platforms.

4) Seperate out the VT emulation layer. Related to 3.

5) Multiple independent VT support. Which brings up the question what 
   should the mapping of VCs to a VT look like. 

6) A nice scrollback buffer on the VT layer level instead of the hacks we 
   have in fbcon and vgacon.