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

[Ernst B. <e.b...@xe...>]

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.

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.

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

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.

 - "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

 - 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?
)

So, any ideas/comments/flames?

/Ernst