The Linux Console Project

Charter and Objectives:

Our charter is to clean up and properly maintain the Linux console/TTY sub system. There has been scattered work on the console and TTY layer going on for some time. This project will try to pull it all together into a coherent architecture from which we can generate clean patches for Linus and the core kernel team.

Right now the console subsystem and the subsystems that depend on it have a couple of problems as well as some design issues which need to be addressed for today's needs:

Terminal emulation is much too intertwined with the lower levels of the console implementation. Eventually terminal emulations should be loadable modules and/or easily replacable.
The various subsystems are intertwined with the console system. Things like the serial, framebuffer, and input layer should be able to exist independent of the console/TTY layer. Especially on embedded devices this is important.
The console system is too vga-centeric in design. We designed it to be more platform independent.
The built-in ANSI X3.64/ECMA-48 terminal emulation is incomplete and in some respects incorrect.

New Features:

Multi-desktop operation -- console instances running on multiple (possibly dissimilar) video cards and separate keyboards.
With the new console locking mechanism the underlying drivers can be DMA/irq based for maximum speed.
Much simpler framebuffer api. Plus with the new design it is possible to use framebuffer devices without a VT.
The console system input system is based solely on the input api. This allows for things like a universal keymap. No more compiling in new keymaps for every type of different keyboard out there. Plus with this design it is possible to use a keyboard without the console system.
New serial API. The serial layer is more like the parport layer now. Having to use the TTY layer for something like a serial mouse is plain silly. The idea is to create a basic serial API and register device interfaces. For a modem you would want to register a TTY interface whereas for a serial mouse or joystick we would want to register an interface for the input api.
Support for hot plug. We can add or remove graphics cards or even keyboards to create new desktop VTs.
A scrollback buffer implemented in the console itself.
Support for different fonts, and textmodes per VC.
Better Unicode support. You will be able to display Kanji on the command line. Bidirectional support.
Not really a part of the console system, force feedback is a important element to the input layer that this project is also working.

Project Status and News:

Development is moving fast. Since we cover a lot of areas of the linux kernel we have separate links to pages that have developments in each different sub system

Input API

Getting Involved

So you like to try out this new system or even better yet contribute. If you'd like to give it a try click here for instructions. Once you try it out we know you will have questions or just want to tell your experiences we have a public development mailing list. Also our list is archived. If you like to join follow this link. Now if you like to get your hands dirty and get involved I recommend joining our CVS commit mailing list. Here you will see all the changes going on. A must for developers and a great way to learn how the new TTY/console layer works. Plus each page for subscribing has a link to the mailing list archives.

Last but not least is our SourceForge page.

Documentation:

How to write a framebuffer driver using the new api.

People:

James Simmons: Project admin on SourceForge. The release master. Developing the new fbdev API, multihead support, and the core console code.
Vojtech Pavlik: Co-Maintainer of this project. Developing the input API and writing most of the core input drivers.; And many others who have put time in and helped develop various parts of the code. Thank you.

Related Resources:

The Framebuffer Homepage.
Dominik Kubla's emulation patches; these are the basis of our terminal emulation code.
Vojtech Pavlik's input drivers, a previous effort in this direction which we have integrated.
The Linux USB HID document has information about the event device and ioctls.
EvStack, another previous attempt associated with the GGI project. There is a home site; you can also browse some documentation describing their architecture and approach.
Steffen Seeger tells us that his KGI implementation tries to carry forward some of the EvStack ideas while being `less invasive'.
Andries Brouwer maintains the Linux kernel keyboard support and kbd tools.
The terminfo/termcap home page.
The VT Terminal Information site. These people have the VT220 reference manual online.
The vttest program tests an emulations's conformance to a VT100.

James Simmons <jsimmons@www.infradead.org>