Prev: sound/isa/gus: Remove dead CONFIG_SND_DEBUG_ROM
Next: Support MCP89 hdmi audio
From: Ben Pfaff on 22 Jul 2010 14:30
Mattia Jona-Lasinio <mattia.jona(a)gmail.com> writes:
> 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.
>
> 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
--
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: Miguel Ojeda on 22 Jul 2010 15:20
On Wed, Jul 21, 2010 at 2:57 PM, 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 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)
>
--
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 24 Jul 2010 06:00
On Thu, Jul 22, 2010 at 9:19 PM, Miguel Ojeda
<miguel.ojeda.sandonis(a)gmail.com> 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
--
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 24 Jul 2010 06:40
On Thu, Jul 22, 2010 at 1:38 PM, Geert Uytterhoeven
<geert(a)linux-m68k.org> wrote:
> On Thu, Jul 22, 2010 at 13:21, Alan Cox <alan(a)lxorguk.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(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: Florian Tobias Schandinat on 24 Jul 2010 10:50
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

--
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/
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5
Prev: sound/isa/gus: Remove dead CONFIG_SND_DEBUG_ROM
Next: Support MCP89 hdmi audio