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

Tue Dec 23 02:46:39 UTC 2008

Hi Arthur,

Arthur van Dongen wrote:
> 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.
>   
Interface?
I just (mis)used the output command to push the display specific 
commands trough the LCDd  ;-) .
> 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....
>
>   
While writing the MD8800 driver I thought about making a better and more 
generic solution for the Icons.
But at that time it was the only display with such icons I've known, so 
I dropped that plan.
> 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.
>   
The icon should indicate a event independent to the screen shown.
Having a icon setup of every client doesn't make much sense to me.
I think one global icon setting is enough too.

Having only one (global) icon setup will make the implementation much 
easier. The LCDd just had to hand over the request to the displaydriver.
The complete icon handling can be done in the driver that is most 
flexible and "future proof" way I think.
> * 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[]);
>   
The client interface I had in mind has 3 functions:

- icon_info
shows the supported icons and their possible values.
Example of the return value:
"icons: DVD:on,off,animate Mail:on,off,animate Volume:percent,off 
State:stop,play,rec,ff,fr,pause ..."

"DVD" and "Mail" are "normal" icons. "animate" means "blinking" or 
highlighting in a other way.
"Volume" is an example of a bargraph and "State" of the playstate-indicator
I think we should define some "standard" icons which should be preferred 
by client and driver, but individual icons could be defined as well.

-icon_set
Sets the value of one or more icons.
Example:
icon_set DVD:on State:play Volume:57

-icon_get
can be used to retrieve the state of a icon.
Example:
icon_get DVD Volume
->
Icon_state: DVD:on Volume:57

All the icon states would be global, so there is no need to define a 
screen or position of the icon I think.
Every client could change the state every icon.
The allocation of the icons will be up to the configuration of clients.
> 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?
>   
Definitely the right direction, I think!

Client programmer will appreciate a common way to control the icons.
And the display owner would be happy if more clients would be able to 
control the Icons.
> Thanks for any corrections, ideas, directions, eye openers and other
> info ;-)
>
> Arthur
>   
> ------------------------------------------------------------------------
>
> _______________________________________________
> LCDproc mailing list
> LCDproc at lists.omnipotent.net
> http://lists.omnipotent.net/mailman/listinfo/lcdproc
>   
regards
Stefan

p.s.
I don't own a display with icons, but if you need help modifying the 
MD8800 driver may contact me.
It's a long time since I've written the driver, but I will see what I 
can do  ;-) .