linux-kernel - Re: Introducing the LCD-Linux project

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <alpine.LFD.2.00.1007291659400.16616@casper.infradead.org>
Date:	Thu, 29 Jul 2010 17:49:31 +0100 (BST)
From:	James Simmons <jsimmons@...radead.org>
To:	Alan Cox <alan@...rguk.ukuu.org.uk>
cc:	Mattia Jona-Lasinio <mattia.jona@...il.com>,
	Geert Uytterhoeven <geert@...ux-m68k.org>,
	Florian Tobias Schandinat <FlorianSchandinat@....de>,
	linux-kernel@...r.kernel.org, lcd-linux-users@...ts.sourceforge.net
Subject: Re: Introducing the LCD-Linux project

> > 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.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/