[Lcdproc] Separate icon area: interface for drivers?
bsdfan at nurfuerspam.de
Fri Oct 7 06:24:17 UTC 2011
On 21.09.2011 22:59, Wolfgang Hauck wrote:
> Hi all,
> recently I have discovered that the Moncaso 320 display offers icons
> above the text line, e.g. "play", "pause" or "stop". Now I would l
> like to extend the driver to support icons of this kind.
> I have found some discussions on this subject, but they are a little
> outdated. Obviously the interface callback function "icon" is the
> wrong function (implements other use case), and the suggested driver
> function was "output" (one bit per icon switches on/off).
> Are there any news concerning these "out-of-band" icons? E.g. is there
> a plan to introduce a new interface function handling this icon type?
those 'off-screen icons' have been subject to discussion since the first
display using it.
The 'icon' function available in the client language is not suitable for
driving them for several reasons:
1. It assumes the icon is to be printed on the screen. Therefore one
has to provide a x,y-position.
2. In case the icon is not supported by the driver an alternate
characters is printed.
3. Additionally there is no way to turn an icon off as it is assumed
the screen is always cleared upon redraw.
Historically the 'output' function is used for driving those off-screen
icons. This function is intended to driver anything else than the screen
of the display, like power switches or LEDs.
However using 'output' for driving off-screen icons has one major
drawback: The client has to know the type of display and exactly needs
to know how the bits sent to 'output' will affect the icons.
There were already some thoughts about adding a new function / interface
for driving off-screen icons. I don't remember the result, but here are
my thoughts on it:
* Looking at the drivers using 'output' to drive off-screen icons
(imonlcd, MD8800, mdm166a, picolcd, ea65) one can see that -
although 'output' only has 32 different possibilities - there are
much more different meaning of these bits.
* This result in a large list of possibly icons, increasing with
* To make fully use a new client interface without the client having
to know the type of display a new protocol / interface is required
so that a driver can tell LCDd which icons it supports and on the
other side that the server can tell the client which icons are
* A new client interface will only work with displays where users
can connect LEDs to generic I/O ports if there is some way to
There could be some 'basic set' of icons like the usual Play, Pause,
Stop, Recoding but I bet that if a display has things like bar graphs
for volume, different icons for input type (CD, DVD, AUX) or even WLAN
strength indicators people will want to have it supported.
Right now I only see an advantage using a new off-screen icon interface
over using 'output' if the client will not need to know the type of
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the LCDproc