All of lore.kernel.org
 help / color / mirror / Atom feed
From: blp@cs.stanford.edu (Ben Pfaff)
To: linux-arm-kernel@lists.infradead.org
Subject: Introducing the LCD-Linux project
Date: Wed, 21 Jul 2010 09:38:54 -0700	[thread overview]
Message-ID: <874ofsdc2p.fsf@benpfaff.org> (raw)
In-Reply-To: AANLkTikitTGpiE5Oe_P5a4f2OCOnlB9j_LVm5CQhQIno@mail.gmail.com

Mattia Jona-Lasinio <mattia.jona@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"

WARNING: multiple messages have this Message-ID (diff)
From: blp@cs.stanford.edu (Ben Pfaff)
To: linux-kernel@vger.kernel.org
Cc: linux-arm-kernel@lists.infradead.org
Subject: Re: Introducing the LCD-Linux project
Date: Wed, 21 Jul 2010 09:38:54 -0700	[thread overview]
Message-ID: <874ofsdc2p.fsf@benpfaff.org> (raw)
In-Reply-To: AANLkTikitTGpiE5Oe_P5a4f2OCOnlB9j_LVm5CQhQIno@mail.gmail.com

Mattia Jona-Lasinio <mattia.jona@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"


  reply	other threads:[~2010-07-21 16:38 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-07-21 12:57 Introducing the LCD-Linux project Mattia Jona-Lasinio
2010-07-21 12:57 ` Mattia Jona-Lasinio
2010-07-21 16:38 ` Ben Pfaff [this message]
2010-07-21 16:38   ` Ben Pfaff
2010-07-22 11:21 ` Alan Cox
2010-07-22 11:21   ` Alan Cox
2010-07-22 11:38   ` Geert Uytterhoeven
2010-07-22 11:38     ` Geert Uytterhoeven
2010-07-24 10:31     ` Mattia Jona-Lasinio
2010-07-24 10:31       ` Mattia Jona-Lasinio
2010-07-24 14:43       ` Florian Tobias Schandinat
2010-07-26 20:11         ` Geert Uytterhoeven
2010-07-28 19:24           ` Mattia Jona-Lasinio
2010-07-28 19:39             ` Alan Cox
2010-07-29  9:09               ` Mattia Jona-Lasinio
2010-07-29 16:49               ` James Simmons
2010-07-29 18:05                 ` Alan Cox
2010-07-29 18:39                   ` James Simmons
2010-08-03 12:22                     ` Mattia Jona-Lasinio
2010-08-04 14:29                       ` James Simmons
2010-07-29 15:58             ` James Simmons
2010-07-29 15:17           ` James Simmons
2010-07-26 20:08     ` Geert Uytterhoeven
2010-07-26 20:08       ` Geert Uytterhoeven
2010-07-22 19:19 ` Miguel Ojeda
2010-07-22 19:19   ` Miguel Ojeda
2010-07-24  9:52   ` Mattia Jona-Lasinio
2010-07-24  9:52     ` Mattia Jona-Lasinio
  -- strict thread matches above, loose matches on Subject: below --
2010-07-22 11:00 Mattia Jona-Lasinio
2010-07-22 11:00 ` Mattia Jona-Lasinio
2010-07-22 18:12 ` Ben Pfaff

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=874ofsdc2p.fsf@benpfaff.org \
    --to=blp@cs.stanford.edu \
    --cc=linux-arm-kernel@lists.infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.