Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758093Ab0G2Qtj (ORCPT ); Thu, 29 Jul 2010 12:49:39 -0400 Received: from casper.infradead.org ([85.118.1.10]:51874 "EHLO casper.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754739Ab0G2Qti (ORCPT ); Thu, 29 Jul 2010 12:49:38 -0400 Date: Thu, 29 Jul 2010 17:49:31 +0100 (BST) From: James Simmons To: Alan Cox cc: Mattia Jona-Lasinio , Geert Uytterhoeven , Florian Tobias Schandinat , linux-kernel@vger.kernel.org, lcd-linux-users@lists.sourceforge.net Subject: Re: Introducing the LCD-Linux project In-Reply-To: <20100728203921.0dd6562d@lxorguk.ukuu.org.uk> Message-ID: References: <20100722122111.4cf4ca2f@lxorguk.ukuu.org.uk> <20100728203921.0dd6562d@lxorguk.ukuu.org.uk> User-Agent: Alpine 2.00 (LFD 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1763 Lines: 45 > > 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/