LCDproc development and user support list

Text archives Help

[Lcdproc] New glcd driver - your opinion?

Chronological Thread 
  • From: bsdfan at (Markus Dolze)
  • Subject: [Lcdproc] New glcd driver - your opinion?
  • Date: Sat, 10 Sep 2011 11:00:06 +0200

Hello everyone,

yesterday I committed a new driver: glcd. It is supposed to be a 'unified
graphic display driver' which makes it more easy to interface LCDd with
graphical displays and libraries.

It is based on the concept of 'connection types' which I took from the
hd44780 driver. There are differences however: The hd44780 driver knows about
the HD44780 controller and its instruction set. It provides initialization,
movement, double buffering and partial screen updates. The connection type
drivers (CT-drivers) just write one command or one data byte to the display.

The glcd driver on the other hand does nothing of that. It just renders
characters into a framebuffer and instructs the CT-driver to write that image
to the display. The CT-driver is responsible to initialize the display and
implement double buffering or partial updates as needed.

Right now the glcd driver renders only our fixed 5x8 font. My plan is to make
it use Freetype (likely using Bernhard Walle's code).

It also supports only a T6963 display connected to the parallel port (because
this it what I have at hand right now). The next CT-drivers will be
serdisplib and glcd2usb.

Many other things are still missing as well (keypad, brightness, contrast).

Today I am not very confident about this driver anymore. Looking at the
required effort to build a CT-driver it is very close to writing a complete
self-contained driver. Maybe too close.

And at some points it is even more complicated, e.g.:
- If the display's memory layout is not a 'linear framebuffer' as glcd uses
the CT-driver has to do conversions.
- The encapsulation of connection type specific data requires a little more
- In LCDd.conf only one driver will appear with a myriad of options.

So what do you think? Shall I keep it or back it out again?

Another option would be to write a small static library (on include it in
lcd_lib) that does the font rendering and can be used by other drivers).


Archive powered by MHonArc 2.6.18.

Top of page