Re: New glcd driver - your opinion?

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
> [email protected]
> http://lists.omnipotent.net/mailman/listinfo/lcdproc
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 
(http://www.newegg.com/Product/Product.aspx?Item=N82E16811280027). 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.

-Pete