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)
Mattia Jona-Lasinio <[email protected]> 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"
Ben Pfaff <[email protected]> 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
On Wed, 21 Jul 2010 14:57:54 +0200
Mattia Jona-Lasinio <[email protected]> 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
On Thu, Jul 22, 2010 at 13:21, Alan Cox <[email protected]> wrote:
> On Wed, 21 Jul 2010 14:57:54 +0200
> Mattia Jona-Lasinio <[email protected]> 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 -- [email protected]
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
Mattia Jona-Lasinio <[email protected]> writes:
> Ben Pfaff <[email protected]> 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.
>
> 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.
It should not be necessary to rewrite everything, only to write
additional code to interface to the particular device. This code
has to be written in any case, whether it is in userspace or the
kernel.
> I downloaded your program and I'm going through it.
I'm not pushing ezio-term as a general solution, by the way. It
is clearly very specific to EZIO3 devices. I'm just pointing out
that its approach is a reasonable alternative.
--
Ben Pfaff
http://benpfaff.org
On Wed, Jul 21, 2010 at 2:57 PM, Mattia Jona-Lasinio
<[email protected]> 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 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.
Someone told me once ago, when I submitted the cfag12864b/ks0108
drivers, to make them use a framebuffer, so we could get a console on
it using a program like con2fb program in an independent manner. It
worked flawlessly and the console was quite usable!
I see that you want to implement something more complex, but maybe
someone/you can make a use of that idea. Check it out : )
>
> 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)
>
On Thu, Jul 22, 2010 at 9:19 PM, Miguel Ojeda
<[email protected]> wrote:
> Someone told me once ago, when I submitted the cfag12864b/ks0108
> drivers, to make them use a framebuffer, so we could get a console on
> it using a program like con2fb program in an independent manner. It
> worked flawlessly and the console was quite usable!
>
> I see that you want to implement something more complex, but maybe
> someone/you can make a use of that idea. Check it out : )
Hi,
thanks for pointing this out. I'll certainly check it! :)
Regards,
Mattia
On Thu, Jul 22, 2010 at 1:38 PM, Geert Uytterhoeven
<[email protected]> wrote:
> On Thu, Jul 22, 2010 at 13:21, Alan Cox <[email protected]> wrote:
>> Why do we need a VT102 as well ?
>>
>> 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 agree on that and at the beginning I was thinking about writing a
framebuffer driver as well.
But on the way I realized that the standard Linux console was not
exactly what I needed.
I wanted to implement some escape sequences typical of the world of
small displays, like
the generation of custom characters, backward writing or backlighting.
This would have required
a change in the standard console, and I personally wouldn't dare to do
it. I thought it would have been
better to have a separate console emulation dedicated to these small devices.
Moreover I wanted something that COULD be used as a console but not
necessarily, that is
something that could run happily in the presence of a normal monitor
as well. It seems to me, but I may be
wrong, that through the standard console system only the current
visible console is actually updated
while other consoles are just "software" updated. An external LCD
would therefore be updated
only when you "switch" to it, so it would not be possible to use it to
display diagnostics.
> 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 also wrote a very simple (and experimental) LCD console driver
using the standard Linux console and LCD-Linux. More or less it works, though
the "update" problem that I mentioned is still an issue.
> Having a bigger virtual console where the LCD follows the region
> surrounding the cursor
> is indeed a nice extension to have.
That's another point which would have required a modification at the
console level
and, as I said, I didn't want to touch at the standard console. But we
can think about
it! ;)
Regards,
Mattia
Hi,
Mattia Jona-Lasinio <mattia.jona <at> gmail.com> writes:
> Moreover I wanted something that COULD be used as a console but not
> necessarily, that is
> something that could run happily in the presence of a normal monitor
> as well. It seems to me, but I may be
> wrong, that through the standard console system only the current
> visible console is actually updated
> while other consoles are just "software" updated. An external LCD
> would therefore be updated
> only when you "switch" to it, so it would not be possible to use it to
> display diagnostics.
True, that's a general problem one has when multiple framebuffers exist.
Therefore I'd be very happy if someone could come up with a general solution.
The problem I see is as follows:
If multiple framebuffers exist there is no finegrained control which
applications draws to which framebuffer. Common practice seems to be to only
draw from the application running in the active vt. But that's not always what
is wanted so a little extension to the kernel deciding whether an application
may or may not draw would be helpful (of course such a thing would require
changes in userspace as well for applications that directly access the
framebuffer).
Example:
Having two framebuffers (fb0, fb1) and three applications (a0, a1, a2) where a0
wants to draw to fb0, a1 to fb1 and a2 to fb0 & fb1.
At first only a0 is running so only fb0 is used. You than start a1:
current: only fb1 is updated by a1
desired (?): fb0 is updated by a0 and fb1 is updated by a1
After you start a2
current = desired: fb0 & fb1 are updated by fb2
You than switch back to a0:
current: only fb0 is updated by a0
desired (?): fb0 is updated by a0 and fb1 is updated by a2
At least that's how I see the problem. So what must a solution provide:
- keep the old interface consistent to not break old applications
- avoid race-conditions while providing direct graphic access
So for each applications that does not know about this interface it has to
behave as if this application draws to all framebuffers. But if the active
application knows it it can allow the last application updating the "unused"
framebuffers as long as the current application does not request access to it.
But I'm unsure how to implement a clean, race-free and efficient solution.
Any suggestions?
Thanks,
Florian Tobias Schandinat
On Thu, Jul 22, 2010 at 13:38, Geert Uytterhoeven <[email protected]> wrote:
> On Thu, Jul 22, 2010 at 13:21, Alan Cox <[email protected]> wrote:
>> On Wed, 21 Jul 2010 14:57:54 +0200
>> Mattia Jona-Lasinio <[email protected]> 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 ;-)
And so I did, to prevent it from being lost for mankind:
http://users.telenet.be/geertu/Download/hd44780.tar.gz
This is a Linux console driver for a HD44780 LCD connected to a PC-style
parallel port. It supports both 4-bit and 8-bit interface mode.
The code was developed and used with a 20x4 LCD connected to the parallel port
of a standard PC and a CHRP LongTrail PowerPC box, with Linux kernel 2.2
(early development) and 2.4, from 2000 until 2004. There's no guarantee it will
work with more recent kernels.
The console driver has a comment suggesting to use a 20x4 window on an 80x25
virtual screen, but this has never been implemented.
It consists of 4 modules:
- hd44780: Mid-level HD44780 LCD driver, handling the HD44780 commands
[kernel, user]
- parlcd: Low-level HD44780 driver, defining how to talk to a HD44780 LCD
connected to a PC-style parallel port [kernel, user]
- lcdcon: Standard Linux console driver for a HD44780 LCD [kernel]
- play: Interactive test program to talk to the HD44780 or to the raw
parallel port [user]
Modules marked [kernel] are used inside the Linux kernel only.
Modules marked [user] are used with the userspace test program.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]
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
On Sat, Jul 24, 2010 at 16:43, Florian Tobias Schandinat
<[email protected]> wrote:
> Mattia Jona-Lasinio <mattia.jona <at> gmail.com> writes:
>> Moreover I wanted something that COULD be used as a console but not
>> necessarily, that is
>> something that could run happily in the presence of a normal monitor
>> as well. It seems to me, but I may be
>> wrong, that through the standard console system only the current
>> visible console is actually updated
>> while other consoles are just "software" updated. An external LCD
>> would therefore be updated
>> only when you "switch" to it, so it would not be possible to use it to
>> display diagnostics.
>
> True, that's a general problem one has when multiple framebuffers exist.
> Therefore I'd be very happy if someone could come up with a general solution.
Fixing that was (one of the) goal of the linux-console project. James?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]
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
On Mon, Jul 26, 2010 at 10:11 PM, Geert Uytterhoeven
<[email protected]> wrote:
> On Sat, Jul 24, 2010 at 16:43, Florian Tobias Schandinat
> <[email protected]> wrote:
>> Mattia Jona-Lasinio <mattia.jona <at> gmail.com> writes:
>>> Moreover I wanted something that COULD be used as a console but not
>>> necessarily, that is
>>> something that could run happily in the presence of a normal monitor
>>> as well. It seems to me, but I may be
>>> wrong, that through the standard console system only the current
>>> visible console is actually updated
>>> while other consoles are just "software" updated. An external LCD
>>> would therefore be updated
>>> only when you "switch" to it, so it would not be possible to use it to
>>> display diagnostics.
>>
>> True, that's a general problem one has when multiple framebuffers exist.
>> Therefore I'd be very happy if someone could come up with a general solution.
>
> Fixing that was (one of the) goal of the linux-console project. James?
Hmmm, the linux-console project seems to be dead. There are no file
releases after nearly ten
years and the CVS is three years old.
I downloaded your driver and explored the code a bit. Indeed there are
many similarities
with the very early stages of LCD-Linux. At the beginning I also wrote
something very close to what you did.
But then I realized that
the display management part was very much intertwined with the low
level details of the display
(parallel port, 8 bit and 4 bit and so on....),
and this made the module not so obvious to be ported to different displays.
If you abstract the display management, add a framebuffer, you realize
that basically
you get a terminal emulator (nearly) for free, with the possibility to
add custom features
typical of small displays (like custom character generation). And once
a framebuffer is added,
you can play a bit by adding a virtual display larger than the
physical one, also adding
the code to keep the cursor visible in a smart way. Basically this is
the way LCD-Linux
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, and I don't
think it is the case
looking at the age of the Linux console project. So I decided to keep
it separate.
But never say never! In the future the two consoles could merge in a
single one. ;)
Greetings,
Mattia
> 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.
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.
Alan
On Wed, Jul 28, 2010 at 9:39 PM, Alan Cox <[email protected]> wrote:
> Let's start at the beginning. What console layer things need fixing to
> make the LCD Linux project able to use them ?
Good to hear that! :) Just give me a few days to write a detailed todo list.
> On Sat, Jul 24, 2010 at 16:43, Florian Tobias Schandinat
> <[email protected]> wrote:
> > Mattia Jona-Lasinio <mattia.jona <at> gmail.com> writes:
> >> Moreover I wanted something that COULD be used as a console but not
> >> necessarily, that is
> >> something that could run happily in the presence of a normal monitor
> >> as well. It seems to me, but I may be
> >> wrong, that through the standard console system only the current
> >> visible console is actually updated
> >> while other consoles are just "software" updated. An external LCD
> >> would therefore be updated
> >> only when you "switch" to it, so it would not be possible to use it to
> >> display diagnostics.
> >
> > True, that's a general problem one has when multiple framebuffers exist.
> > Therefore I'd be very happy if someone could come up with a general solution.
>
> Fixing that was (one of the) goal of the linux-console project. James?
Yeap. That was one of the goals. Plus a bunch others.
>
> Gr{oetje,eeting}s,
>
> Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]
>
> 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
>
> <[email protected]> wrote:
> > On Sat, Jul 24, 2010 at 16:43, Florian Tobias Schandinat
> > <[email protected]> wrote:
> >> Mattia Jona-Lasinio <mattia.jona <at> gmail.com> writes:
> >>> Moreover I wanted something that COULD be used as a console but not
> >>> necessarily, that is
> >>> something that could run happily in the presence of a normal monitor
> >>> as well. It seems to me, but I may be
> >>> wrong, that through the standard console system only the current
> >>> visible console is actually updated
> >>> while other consoles are just "software" updated. An external LCD
> >>> would therefore be updated
> >>> only when you "switch" to it, so it would not be possible to use it to
> >>> display diagnostics.
> >>
> >> True, that's a general problem one has when multiple framebuffers exist.
> >> Therefore I'd be very happy if someone could come up with a general solution.
> >
> > Fixing that was (one of the) goal of the linux-console project. James?
>
> Hmmm, the linux-console project seems to be dead. There are no file
> releases after nearly ten
> years and the CVS is three years old.
We never did file releases. Mostly people just checked out cvs
and then built and tested out the kernel. At first it was a massive
project which covered several areas. That tree was used as a staging
ground for the input api and the new fbdev api. We even for a time had had
the serial api that you find drivers/serial. All of that has been made
main stream :-) Then we saw graphics cards all becoming agp and mother
boards with multiple apg slots where extremely rare. So interest in the
project died off. Now with usb and pcie plus graphics cards with multiple
crtcs its is becoming possible again.
Recently I have been looking at and working on the DRI mode setting api
since it covers the bulk of the graphics cards out there for the PC market which
are pcie which means the possiblity of multiple graphics cards in
parrallel. You are not the only one looking at this solution.
> 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, and I don't
> think it is the case
> looking at the age of the Linux console project. So I decided to keep
> it separate.
> But never say never! In the future the two consoles could merge in a
> single one. ;)
Hum. Only in the last year have I started to see a interest in this area
again. A few months ago someone else was discussing with me the
limitations of the linux console system. I have a few drm changes I like
to push first for the next merge widow. Perhaps if Andrew Morton is
willing to merge the my linuxconsole git tree into his -mm branch for wide
area testing then I can start the linux console stuff up again. Currently
my console git tree has no commits. Its just a raw tree. BTW yes it is
alot of work to cleanup the console system.
> > 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.
> 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.
No. printk hits console drivers why may or may not be frame buffer
interfaces. Has done for a very long time. Keith Packard has also been
doing stuff with crash time oops displays etc over an X display.
> 4) Seperate out the VT emulation layer. Related to 3.
Separate from what ?
> 5) Multiple independent VT support. Which brings up the question what
> should the mapping of VCs to a VT look like.
I would suggest we borrow the X idea and each VC is
int display; /* Display it is on (for console flipping) */
struct something *vt; /* VT which it is displaying */
int x,y,w,h; /* Window onto vt */
> > 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.
>
> No. printk hits console drivers why may or may not be frame buffer
> interfaces. Has done for a very long time. Keith Packard has also been
> doing stuff with crash time oops displays etc over an X display.
Correct. What I mean is have the ability to just register the console
driver but not the tty driver.
> > 4) Seperate out the VT emulation layer. Related to 3.
>
> Separate from what ?
We can still have a basic tty layer without the control characters, think
do_con_trol in vt.c, junk compiled into the kernel. Make it a options for
userland to do the vt100 emulation.
> > 5) Multiple independent VT support. Which brings up the question what
> > should the mapping of VCs to a VT look like.
>
> I would suggest we borrow the X idea and each VC is
>
> int display; /* Display it is on (for console flipping) */
> struct something *vt; /* VT which it is displaying */
> int x,y,w,h; /* Window onto vt */
/dev/tty[0-16] -> VT display 0
/dev/tty[17-31] -> VT display 1
etc.
At least that is how I handled it several years ago.
I explored the kernel sources dealing with the console emulation,
framebuffer support and console drivers. I do realize that if we want to fix
all layers in a clean way there is a lot of work to do.
But before going any further I'd like to know some preliminary things.
We are talking about a massive rewrite of code, also including a redesign
of the console layer and (at least) the VGA driver (vgacon) and framebuffer
driver (fbcon), not just a couple of patches to throw in. Do we have the will
to do this job? I mean, I personally do but I don't want to spend time and
effort in something that will be eventually rejected.
Linux has a console system, so we are not in a hurry and we can
think about it. So the main question: how do we proceed?
In case we want to fix this, we should discuss about the design and
implementation
to follow. Presently the struct vc_data contains a lot of information
common to the driver and the
console layers. We should split this struct in order to have a more
transparent interface
between the two parts. Ideally the driver should not know anything
about the console
implementation and the members of the vc_data and it should only take care about
displaying the right thing at the right place.
The vt_struct should represent a physical device, like a monitor or a
LCD display.
Every vt_struct can have one or more vc_data associated to it. All
available vt_struct
are physically refreshed but for every vt_struct, only the currently
visible vc_data on that struct is
actually updated. The others are just "software updated". I don't know
if all this is
the same idea that James was suggesting.
We should avoid fixed size vectors of pointers to these structs by
making them elements
of linked lists.
I agree on the mapping between vc and vt but I'd like to make the
number of vc per vt
an option to be passed at boot time or when init is launched (for
instance), not a
compile time option.
I totally agree that all this must be somewhat separated from the tty
layer, to have
a console without a tty driver, or at least a very light one.
What do you think?
Coming back to LCD-Linux, I will write a module to make it use the
present framework,
basically deactivating the terminal emulation and a bunch of other things, but
keeping the virtual display. Let's see the result ;)
BTW, I currently use lcd-linux with a 4x40 LCD display
which has two controllers onboard. The possibility to drive displays
with more than one
(up to 7) controller onboard is a feature of the present hd44780 driver.
Greetings
Mattia
On Thu, Jul 29, 2010 at 8:39 PM, James Simmons <[email protected]> wrote:
>
>> > 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.
>>
>> No. printk hits console drivers why may or may not be frame buffer
>> interfaces. Has done for a very long time. Keith Packard has also been
>> doing stuff with crash time oops displays etc over an X display.
>
> Correct. What I mean is have the ability to just register the console
> driver but not the tty driver.
>
>> > 4) Seperate out the VT emulation layer. Related to 3.
>>
>> Separate from what ?
>
> We can still have a basic tty layer without the control characters, think
> do_con_trol in vt.c, junk compiled into the kernel. Make it a options for
> userland to do the vt100 emulation.
>
>> > 5) Multiple independent VT support. Which brings up the question what
>> > ? ?should the mapping of VCs to a VT look like.
> I explored the kernel sources dealing with the console emulation,
> framebuffer support and console drivers. I do realize that if we want to fix
> all layers in a clean way there is a lot of work to do.
Yes, but the good news is I have been here before. The good news is that
the console code has been abstracted out of most low level drivers so it
makes life much easier this time around. Also today we are starting to
have a greater amount of hardware that can do multi-seat. Another project
dealing with these same issues is
http://plugable.com/2009/11/16/setting-up-usb-multiseat-with-displaylink-on-linux-gdm-up-to-2-20/
> But before going any further I'd like to know some preliminary things.
> We are talking about a massive rewrite of code, also including a redesign
> of the console layer and (at least) the VGA driver (vgacon) and framebuffer
> driver (fbcon), not just a couple of patches to throw in. Do we have the will
> to do this job? I mean, I personally do but I don't want to spend time and
> effort in something that will be eventually rejected.
> Linux has a console system, so we are not in a hurry and we can
> think about it. So the main question: how do we proceed?
Like before. Bit by bit to avoid massive code drops that could break lots
of things. Do certain select changes and push them to Andrew Mortons -mm
tree for wide testing. If we have a successful run then push it main stream.
While in the -mm tree we start the next round of changes. Once the
previous batch from the -mm tree is pushed main stream then push the next
batch of changes.
> In case we want to fix this, we should discuss about the design and
> implementation
> to follow. Presently the struct vc_data contains a lot of information
> common to the driver and the
> console layers. We should split this struct in order to have a more
> transparent interface
> between the two parts. Ideally the driver should not know anything
> about the console
> implementation and the members of the vc_data and it should only take care about
> displaying the right thing at the right place.
> The vt_struct should represent a physical device, like a monitor or a
> LCD display.
> Every vt_struct can have one or more vc_data associated to it. All
> available vt_struct
> are physically refreshed but for every vt_struct, only the currently
> visible vc_data on that struct is
> actually updated. The others are just "software updated". I don't know
> if all this is
> the same idea that James was suggesting.
Yes. That is exactly what I had before.
> We should avoid fixed size vectors of pointers to these structs by
> making them elements
> of linked lists.
I think for our case idrs whould be better.
> I agree on the mapping between vc and vt but I'd like to make the
> number of vc per vt
> an option to be passed at boot time or when init is launched (for
> instance), not a
> compile time option.
I had it as a module option. Now ioctl VT_GETSTATE has a problem with more
tha 16 VCs. So original I made 16 the limitation of VCs per VT.
> I totally agree that all this must be somewhat separated from the tty
> layer, to have
> a console without a tty driver, or at least a very light one.
>
> What do you think?
We pretty much have the same goals.
> Coming back to LCD-Linux, I will write a module to make it use the
> present framework,
> basically deactivating the terminal emulation and a bunch of other things, but
> keeping the virtual display. Let's see the result ;)
Excellent. Let me see the work once your done.
> BTW, I currently use lcd-linux with a 4x40 LCD display
> which has two controllers onboard. The possibility to drive displays
> with more than one
> (up to 7) controller onboard is a feature of the present hd44780 driver.
I can discuss with you off line about getting a hold of one of these
boards.
Okay. I have sync my console git tree up to linus latest tree. I started
last night on the first pass of the console changes. Mostly code cleanup
to make the second round of changes easier to deal with. I will commit
them in the next few days after some testing of course. I will send out a
email once I haev done the commit.
http://git.infradead.org/users/jsimmons/linuxconsole-2.6.git