public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
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:39 UTC|newest]

Thread overview: 22+ 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 16:38 ` Ben Pfaff [this message]
2010-07-22 11:21 ` Alan Cox
2010-07-22 11:38   ` Geert Uytterhoeven
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-22 19:19 ` Miguel Ojeda
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 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 \
    --cc=linux-kernel@vger.kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox