Prev: sound/isa/gus: Remove dead CONFIG_SND_DEBUG_ROM
Next: Support MCP89 hdmi audio
From: Mattia Jona-Lasinio on 21 Jul 2010 09:00
Hi,

this is to introduce the LCD-Linux project (http://lcd-linux.sourceforge.net/),
a kernel level implementation of a VT102 terminal emulator, optimized for small
alphanumeric and graphic displays.

The possibility to connect to the computer small alphanumeric as well as graphic
displays, has always attracted some interest. These small devices are connected
to the computer and can be used to display system diagnostics like network
usage, RAM or disk usage or even to replace the usual monitor. Possible
applications can be found in embedded systems or clusters. These displays are
connected to the computer through serial lines, parallel ports and more recently
through USB connections. Appropriate programs in userspace gather the desired
information and output it on the display. However for this to work, the
userspace program has to implement some sort of display management, to determine
what must be displayed where. This has two major disadvantages. First. Every
userspace program willing to drive a display must solve the very same problems
(display scroll and refresh, for instance), resulting in an overall duplication
of code. Second. Display controllers usually require quite strict timings for
proper operation and it is not trivial neither efficient to obtain this in
userspace, whereas it is straightforward in kernel space through the usual delay
functions. A solution is therefore to provide a sort of minimal terminal
emulation in kernel space, that can be accessed through the standard character
device interface. In this way the problem of the display management is reduced
to some calls to the usual read/write/seek/ioctl routines. At the same time one
has the possibility to implement handling of escape sequences, thus opening the
way to standard applications based on the ncurses library.

LCD-Linux aims to be a complete VT102 terminal emulation in kernel space,
optimized for small alphanumeric and graphic displays. It consists of two
distinct pieces of software.

The first piece is the lcd-linux module in itself, implementing a (hopefully)
complete VT102 terminal with the addition of some custom escape sequences
specific to the world of small LCD displays. Care has been taken to avoid any
conflict between standard and custom escape sequences. A major feature of
lcd-linux is the possibility to define a virtual display geometry larger than
the physical one, so that one can use a small display as a normal 80x25 monitor
in an effective way. The layer takes care about display refresh and keeps the
cursor visible in a smart way. A second feature is the possibility to connect
more than one display (up to 256 different displays). Each display is assigned a
different minor number and is addressed individually. The lcd-linux module also
registers the appropriate major number character device and implements all the
relevant read/write/seek/ioctl functions allowed on the character device.
Finally it creates some /proc files for internal inspection, information and
diagnostics.

The second piece of software is the display driver, implementing all functions
that are controller specific. Each driver registers itself with the lcd-linux
layer and behaves like a 'slave' with respect to it. The interface between
lcd-linux and the display driver is kept as simple as possible and no assumption
is made by any of the two parts on the implementation of the other part. Ideally
there will be one module for each controller. At the current stage, the driver
for the Hitachi HD44780 (and compatibles) controller is fully implemented and
optimized. Drivers for other controllers can be written in an easy way thanks to
the standard interface provided by the lcd-linux layer.

The LCD-Linux project has been under development for several years and has now
reached a stable state. It has been succesfully compiled, tested and used on
different machines running Linux version 2.2, 2.4 and 2.6. The software can be
compiled as a module or compiled statically into the kernel. In the latter case,
the user can pass some parameters at boot time, to configure the display as soon
as possible during the boot sequence. The project comes with Documentation and
examples about how to use it.

LCD-Linux is released under the GNU General Public License version 2. The latest
release is available at the Sourceforge website:

http://lcd-linux.sourceforge.net/
http://prdownloads.sourceforge.net/lcd-linux/lcd-linux-0.13.9.tar.gz?download

The CVS version still includes some partial support for Linux 2.0 but this
support is considered obsolete and now abandoned in the official release.

The LCD4Linux (http://ssl.bulix.org/projects/lcd4linux/) project is known to
support LCD-Linux among the possible connection types.

I would appreciate some comments and feedback on the project. In view of the
potential applications, future developments and improvements of LCD-Linux, I
would also like to propose LCD-Linux for inclusion in the Linux kernel mainline.

Thank you for your attention.

With best regards,

Mattia Jona-Lasinio

(LCD-Linux project developer and maintainer)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Ben Pfaff on 21 Jul 2010 12:40
Mattia Jona-Lasinio <mattia.jona(a)gmail.com> writes:

> The possibility to connect to the computer small alphanumeric
> as well as graphic displays, has always attracted some
> interest. These small devices are connected to the computer and
> can be used to display system diagnostics like network usage,
> RAM or disk usage or even to replace the usual
> monitor. Possible applications can be found in embedded systems
> or clusters. These displays are connected to the computer
> through serial lines, parallel ports and more recently through
> USB connections. Appropriate programs in userspace gather the
> desired information and output it on the display. However for
> this to work, the userspace program has to implement some sort
> of display management, to determine what must be displayed
> where. This has two major disadvantages. First. Every userspace
> program willing to drive a display must solve the very same
> problems (display scroll and refresh, for instance), resulting
> in an overall duplication of code. Second. Display controllers
> usually require quite strict timings for proper operation and
> it is not trivial neither efficient to obtain this in
> userspace, whereas it is straightforward in kernel space
> through the usual delay functions. A solution is therefore to
> provide a sort of minimal terminal emulation in kernel space,
> that can be accessed through the standard character device
> interface. In this way the problem of the display management is
> reduced to some calls to the usual read/write/seek/ioctl
> routines. At the same time one has the possibility to implement
> handling of escape sequences, thus opening the way to standard
> applications based on the ncurses library.

When I wanted to solve the same problem for a small
serial-connected LCD panel (sold under the name EZIO), I wrote a
program called "ezio-term" that has the same functionality but
runs entirely in userspace. It connects to the serial port and
speaks the EZIO protocol on the serial port, and it creates a pty
and acts like an ANSI terminal on that pty. Thus, it translates
back and forth between the two protocols.

ezio-term also comes with a terminfo description that lets
programs take advantage of the special features of the LCD panel.
ezio-term also has the "virtual screen larger than physical
screen" feature that you mention elsewhere, although it currently
only implements an extra-wide screen, not an extra-tall one.

ezio-term solves the first problem you mention. I'm not sure I
understand how the second one would come about across a serial or
parallel or USB connection.

ezio-term is distributed as part of Open vSwitch, in the
directory extras/ezio. You can clone the Open vSwitch Git
repository with:
git clone git://openvswitch.org/openvswitch
--
"Premature optimization is the root of all evil."
--D. E. Knuth, "Structured Programming with go to Statements"

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Mattia Jona-Lasinio on 22 Jul 2010 07:10
Ben Pfaff <blp(a)cs.stanford.edu> writes:

> When I wanted to solve the same problem for a small
> serial-connected LCD panel (sold under the name EZIO), I wrote a
> program called "ezio-term" that has the same functionality but
> runs entirely in userspace. It connects to the serial port and
> speaks the EZIO protocol on the serial port, and it creates a pty
> and acts like an ANSI terminal on that pty. Thus, it translates
> back and forth between the two protocols.
>
> ezio-term also comes with a terminfo description that lets
> programs take advantage of the special features of the LCD panel.
> ezio-term also has the "virtual screen larger than physical
> screen" feature that you mention elsewhere, although it currently
> only implements an extra-wide screen, not an extra-tall one.

This is indeed a possibility. However, in my opinion, it always suffers
the same problems: if you change the display, you have to rewrite everything
from scratch since the protocol for a different display will be different.
The big problem is that there is no standard protocol or connection type for
these small devices; nothing comparable with the VGA standard, for example.
The idea is therefore to write a minimal terminal emulation for a general
abstract display so that the general question about WHAT has to be done
is solved once for all, pushing the question about HOW to do it in a very small
piece of code.

> ezio-term solves the first problem you mention. I'm not sure I
> understand how the second one would come about across a serial or
> parallel or USB connection.

Hmmmm, you are probably right about serial and USB (which is in any case serial)
connections. But for parallel port connections the situation is
different, since you
speak directly with the display controller, so all timing issues are
up to you. For
instance the hd44780 needs timings in the microsecond range. How would you
obtain this in userspace without doing something like real time scheduling?
Of course you can also increase timing but the display refresh will be obviously
worse. In embedded systems these devices can be connected to GPIO lines. The
access is through memory mapped ports. In some sense this is similar to a
parallel port connection but still you are concerned with timing issues.

I downloaded your program and I'm going through it.

Regards,

Mattia
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Alan Cox on 22 Jul 2010 07:20
On Wed, 21 Jul 2010 14:57:54 +0200
Mattia Jona-Lasinio <mattia.jona(a)gmail.com> wrote:

> Hi,
>
> this is to introduce the LCD-Linux project (http://lcd-linux.sourceforge.net/),
> a kernel level implementation of a VT102 terminal emulator, optimized for small
> alphanumeric and graphic displays.

The kernel already has a console and that provides an abstract
implementation that is used for everything from text mode displays to vga
to assorted accelerated hardware platforms.

Why do we need a VT102 as well ?

> functions. A solution is therefore to provide a sort of minimal terminal
> emulation in kernel space, that can be accessed through the standard character
> device interface. In this way the problem of the display management is reduced

If you use the existing kernel console interfaces then you don't need to
worry about vt102 v console or having two terminal emulations running.

The basic idea seems sound enough other than that. Another reason for
using the kernel console/vt driver is that you can then also support mini
bitmap displays because a frame buffer driver backed by a driver for a
suitable LCD panel can work nicely because the vt driver can sit on the
fb layer quite happily and fb then implements low level handling for the
pixels.

Alan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Geert Uytterhoeven on 22 Jul 2010 07:40
On Thu, Jul 22, 2010 at 13:21, Alan Cox <alan(a)lxorguk.ukuu.org.uk> wrote:
> On Wed, 21 Jul 2010 14:57:54 +0200
> Mattia Jona-Lasinio <mattia.jona(a)gmail.com> wrote:
>> this is to introduce the LCD-Linux project (http://lcd-linux.sourceforge.net/),
>> a kernel level implementation of a VT102 terminal emulator, optimized for small
>> alphanumeric and graphic displays.
>
> The kernel already has a console and that provides an abstract
> implementation that is used for everything from text mode displays to vga
> to assorted accelerated hardware platforms.
>
> Why do we need a VT102 as well ?
>
>> functions. A solution is therefore to provide a sort of minimal terminal
>> emulation in kernel space, that can be accessed through the standard character
>> device interface. In this way the problem of the display management is reduced
>
> If you use the existing kernel console interfaces then you don't need to
> worry about vt102 v console or having two terminal emulations running.

Indeed, the kernel already has the console abstraction.

I wrote a LCD console driver (for a HD44780 connected to the parallel
port) using
the standard console abstraction several years ago. As it used the standard
console abstraction, it supported multiple virtual consoles and co-operated with
the VGA text console out-of-the-box. Just use ALT-Fx to switch between different
VCs on the LCD or on VGA.

I never published the code, though. Will do so tonight when I get back
to the machine
that holds the code ;-)

Having a bigger virtual console where the LCD follows the region
surrounding the cursor
is indeed a nice extension to have.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert(a)linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
 |  Next  |  Last
Pages: 1 2 3 4 5
Prev: sound/isa/gus: Remove dead CONFIG_SND_DEBUG_ROM
Next: Support MCP89 hdmi audio