Re: Deprecating the glcdlib driver

On 11.07.2012 21:48, Ethan Dicks wrote:
> On Wed, Jul 11, 2012 at 2:49 PM, Markus Dolze <[email protected]> wrote:
>> I would like to mark the 'glcdlib' driver deprecated and schedule it for
>> removal...
>>
>> The glcdlib driver adds support for the GLCDprocDriver which in turn
>> allows access to the glcdlib-base library. This has failed to built for
>> years now.
> 
> I think the last time I used it was 2006.
> 
>> The only devices that are added by using glcdlib-base are some Noritake
>> GUxxx devices. Most other devices are supported either by LCDproc
>> natively or by using the 'glcd/serdisplib' driver.
> 
> For my own work, I only have bus-interface (parallel) graphic LCDs
> with garden-variety controllers like the sed1330/1335, the sed1520, or
> the t6963.  As long as there's native support for those, I probably
> won't miss glcdlib support, but I'm trying to remember back to why it
> was added in the first place?  Was it to insulate LCDproc from
> variations in graphics LCDs and to abstract the differences to a
> package that just presented a constant API (bringing with it support
> for many types of panels)?

Using some other library to encapsulate the graphical things is a good
idea. The glcd driver was built to shorten the path to serdisplib and to
have more control over its screen refreshing.

With the 'glcd' driver supporting 'serdisplib' directly, one can use a
number of graphical displays right away.

> 
> If it hasn't successfully built in years, I can't imagine who could be
> using it, but perhaps someone is using it with an older version of
> LCDproc and it's keeping them from upgrading?
> 

GraphLCD development ceased until it was moved to the VDR community. I
have to admit that I missed that. I will check the new version again.

Regards,
Markus