[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <AANLkTimnxkn5eLRHOAs6v_TJE0hM5=dQ3OWaiQP6tPJd@mail.gmail.com>
Date: Sat, 24 Jul 2010 12:31:53 +0200
From: Mattia Jona-Lasinio <mattia.jona@...il.com>
To: Geert Uytterhoeven <geert@...ux-m68k.org>,
Alan Cox <alan@...rguk.ukuu.org.uk>
Cc: linux-kernel@...r.kernel.org,
Miguel Ojeda Sandonis <miguel.ojeda.sandonis@...il.com>,
Willy Tarreau <w@....eu>,
Andrew Morton <akpm@...ux-foundation.org>,
Linus Walleij <triad@...lth.se>,
linux-arm-kernel@...ts.infradead.org,
Russell King <linux@....linux.org.uk>,
Linus Torvalds <torvalds@...ux-foundation.org>,
ivan.kuten@...mwad.com, lcd-linux-users@...ts.sourceforge.net,
Viktar Palstsiuk <viktar.palstsiuk@...mwad.com>
Subject: Re: Introducing the LCD-Linux project
On Thu, Jul 22, 2010 at 1:38 PM, Geert Uytterhoeven
<geert@...ux-m68k.org> wrote:
> On Thu, Jul 22, 2010 at 13:21, Alan Cox <alan@...rguk.ukuu.org.uk> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists