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

[Michael R. <re...@eu...>]

Hi there,

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

Well, maybe. But try to keep as close as possible on the "generic text"
side, as lots of widgets depend upon it.

> struct WIDGET_GPO only has "int num", I could abuse that to contain the bit 
> location (like num = (byte_location << 3) | bit_location)
You can define one single symbol as a GPO, but you can group them, too.
Just as you like.

>>>  - drv_generic_bitmapped: Provides a "framebuffer", where each bit is
>>> linked to a segment on the display and helper routines
Please don't do that yet. Write a driver, do it the "ugly" way, wait for
the next display that fits into this area, try to find commonalities,
and then think about a "generic" part.

This stuff is difficult: I've got a fisplay here that shares a part of
graphic area (about 100x8 pixels) with lots of symbols and a 7-digit
area. Where would that one fit into? I've no idea....

>>>  - "Symbol": a non-character symbol, think "Record" "Play" or "Pause" on
>>> a VCR.
I'd suggest GPO's here.

>>> since a display can
>>> easily exceed the 32 allowed GPOs.
> drv_generic_gpio.c:
> #define MAX_GPIS 32
> #define MAX_GPOS 32
Ignore these limits. they can be easily extended to whatever number you
need....

>>   - "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
Hmmm... you can render all alphanumeric into 7-digit, too, by mixing
upper and lowercase.

As I said above, don't try to generalize at this time.


>>>  - a specialization of the "Bar" class, for those nifty equalizer bars
>>> found on my display
That could be a GPO, too. GPO's are 32 bit at the moment, so if your
bars exceed 32 leds....

>>> (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?
You're right, this looks like a bug. Thanks fopr pointing this out!

> Hmm, it might make sense to, say, declare widget text with 
> type=WIDGET_TYPE_RC | WIDGET_TYPE_XY, that way the layout would accept text 
> widgets with an Row/Col location as well as with a X/Y location.
No, the text widget is Row/Col only.

There may be a "TrueType" Widget for graphic displays in the future (any
volunteers? :-)




bye, Michael (looking forward to see your cool display working with
lcd4linux!)

-- 
Michael Reinelt <re...@eu...>
http://home.pages.at/reinelt
GPG-Key 0xDF13BA50
ICQ #288386781