Re: [Lcd4linux-devel] Driver for "Bit-mapped" displays

[C. M. <cm...@fr...>]

On Mon, Jul 31, 2006 at 10:44:09PM +0200, Ernst Bachmann waxed:
> Hi List,
> 
> I'm currently implementing a LCD4Linux driver for (non dot-matrix) VFDs and 
> similar displays. Think VCR, digital clock and such, or see the attached page 
> from a datasheet.
> 
> Since such displays don't fit the drv_generic_text and drv_generic_graphic 
> models well (There is no concept like rows/cols or pixels), I'll probably 
> have to code the driver from scratch.

My VCR pretty much has one row for ASCII, and the rest of
the blinking lights with pre-printed text cutouts in front
seem like GPOs to me.  No sense re-inventing the wheel.

> This will require some additions to the core functionality, so I'm asking 
> beforehand if there are some objections/ideas for improvement:
> 
> Since I want the code to be somewhat generic and usefull for different 
> devices, I'm splitting it in three parts:
> 
>  - drv_generic_bitmapped: Provides a "framebuffer", where each bit is linked 
> to a segment on the display and helper routines
> 
>  - lowlevel-driver: transfer of the framebuffer to the device (parport, usb, 
> whatever)
> 
>  - layout config file: describing which bits in the framebuffer lights which 
> segment on the display.

Are you proposing a new .conf file in addition to lcd4linux.conf ?

> Which this split it should be possible to attach different Displays without 
> having to touch the driver source, the uC or its firmware...

I would think keeping this functionality in the driver
display source would prevent conf file dependency issues.

> Now I would need an additional set of Widgets, like
> 
>  - "Symbol": a non-character symbol, think "Record" "Play" or "Pause" on a 
> VCR.
> the existing "icon" class does way to much here, the symbol would be a 
> simple "on/off" switch. GPOs wouldn't work here, too, since a display can 
> easily exceed the 32 allowed GPOs.

Where is this limit of 32 GPOs defined ?

>  - "7Segment Text": provides translation ascii->7Segment display, and "knows" 
> (from config) which bits in the framebuffer are part of it.
>  - "14Segment Text": same, for more sophisticated displays

I would think you'd want to keep the vanilla 'Text' widget
so that there would be little changes to configuration
required when changing displays.  Creating a header file
with some arrays for translations from ascii->Nsegment
display bits would allow each driver to implement the
translation in its drv_generic_text_real_write callback.

>  - a specialization of the "Bar" class, for those nifty equalizer bars found 
> on my display 
> 
> Those would be of a new type, "WIDGET_TYPE_BM", since the "_XY" and "_RC" 
> Types won't work here, with additions to layout.c to read them with a special 
> location spec...
> 
> (Btw, off-topic:
> why are the existing widget types defined as 1,2,3,4,5 when widget.c does a 
> bit-wise compare on the type [if ((Class->type & type) == 0) {]?
> Shouldn't they be more like 1,2,4,8,16 ?
> Or does it make sense that e.g. a KEYPAD widget can be positioned wherever a 
> TIMER or RC widget can?
> )

That looks like a bug.  The widget_find proc right below
there uses an integer comparison.  Although I think I wrote
that one in widget_find, so I shouldn't comment.

> So, any ideas/comments/flames?
> 
> /Ernst

I think it sounds like a cool hack.  I'm pretty curious to
how you hook the wires up to such a display.


-- 
Chris Maj
Pronunciation Guide: Maj == May