[Lcdproc] How to handle separate icon area on LCD/VFD glass

[Arthur van Dongen]

Hi all,

(I already sent a similar post to this list, but this one is further
developed. Please ignore the previous one.)

I have both a Medion MD8800 VFD and a Shuttle with VFD. Drivers within
LCDproc exist for both displays. I want to control the icons from
mythtv. For a better understanding of what I mean with these icons, here
are two links to pages with photos of the displays in action:
http://jeremy.infogami.com/SetVFD
http://www.martinm-76.dk/md8800/LCD/md8800-lcd.jpg

I searched the net for the best way to implement icons, but the
contributions are either focused on LEDs attached to a small number of
GPIO ports of the display, or drawing custom characters on the LCD dot
matrix. The current drivers for MD8800 and ShuttleVFD already attempt to
support the icons, but implement the other interface.

Currently both implementations do not fulfill the (my) requirements, and
I see the need for an extension to the protocols. Back to the drawing
table....

Requirements
============
* Device-independent interface from client to server. If a client wants
to light the "Play" light on the display, it does not need to know if it
is implemented by a GPIO output attached to a LED or by a triangular LCD
segment somewehere on the glass.
* Extensible. If a new LCD or VFD display appears that has a new set of
icons, it should not require much effort to add support.
* Special handling of grouped segments. For example, both VFDs have a
"Volume" region, with different number of bars. The client can be hidden
from this detail by allowing a "volume 50%" command.
* Queryable. A client can request whether an "Envelope" icon is
supported by the device, and decide to display a "New mail" text based
on the result of this request.
* Separate control of the icons. One client can control the "Play" icon,
and another can control the "Envelope" icon.
* Combined control of icons. Switching from "FF" to "Play" icon should
be possible in a single command. There is no sense in controlling these
from different clients.
* Efficiency. The list of all icon names can only grow, and searching
for an icon in the list should not take too long. Grouping?
* Flexibility in defining combined icons. For example an icon set for
the video source can contain "TV" and "Film" on one device and "DVB-T",
"Sat", "MPEG", "DivX", "unknown-codec-of-the-future" icons on another.  

Design outline
==============
Client-Server interface
-----------------------
Example:
 screen_add scrn0
 widget_add scrn0 iconWidget icon
 widget_set scrn0 iconWidget 0 0 PLAYMODE.FF
 widget_set scrn0 iconWidget 0 0 MAIL.OFF
 widget_set scrn0 iconWidget 0 0 VIDSRC.TV
 widget_set scrn0 iconWidget 0 0 VIDSRC.TV_Sat

Server-Device API
-----------------
<device>_icon(Driver *drvthis, const char iconDef[]);

When using icon names of the form GROUP.SELECTION and passing this
unaltered to the driver, the driver can then decide what to do with it.
I do not know how the screen priorities affect this, when multiple
clients set icons on the same location.
The driver should split the GROUP from the SELECTION and parse these. If
they are known the driver can turn on the right segments in the group,
and otherwise revert to a default. Using partial matching, like the TV
and TV_SAT selection, the driver can revert to a more common icon.

So what do you experts think? Am I heading in the right direction?

Thanks for any corrections, ideas, directions, eye openers and other
info ;-)

Arthur
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://lists.omnipotent.net/pipermail/lcdproc/attachments/20081218/9efa3ea1/attachment.pgp>