LCDproc development and user support list

Text archives Help

[Lcdproc] New glcd driver - your opinion?

Chronological Thread 
  • From: goballstate at (Peter Buelow)
  • Subject: [Lcdproc] New glcd driver - your opinion?
  • Date: Wed, 14 Sep 2011 06:50:50 -0500

On 09/10/2011 04:00 AM, Markus Dolze wrote:
> 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
> coding.
> - 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).
> Regards,
> Markus
> _______________________________________________
> LCDproc mailing list
> LCDproc at
I like the idea, but what if instead of doing graphical operations
directly to a framebuffer, the driver made it possible to connect to
existing framebuffer frameworks (QT or directfb as examples) without
very much effort. I've been thinking about doing a similar driver using
QT to draw to the LCD screen for devices such as the following
( I am
interested in getting this working for a MythTV project I want to do,
and having a way to easily connect the display to LCDProc would be great.

Or quite honestly, you could just write a QT driver to render to a QT
framebuffer. Let QT do the heavy lifting (fonts, display control, etc),
and you can concentrate on layout and messaging. I'm not trying to pass
my project on to you, but it seems you want to do a bunch of work that
others have already done. I say leverage existing frameworks.


Archive powered by MHonArc 2.6.18.

Top of page