Re: Separate icon area: interface for drivers?

Am 07.10.2011 08:24, schrieb Markus Dolze:
> 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?
>>
>> Regards,
>> Wolfgang
>>
>
> Hi Wolfgang,
>
> 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
>       every display.
>     * 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 available.
>     * 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
>       configure it.
>
> 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 display connected.
>
> Regards,
> Markus
>
Hi Markus,

thanks for your detailed answer.

Yes, you are right.

    * You never will catch all upcoming features supported by new displays.
    * The client must not deal with display types.

What about the following interface extension ("pictogram" in order to 
distinguish from "icon"):

    * enum Pictogram {PICTOGRAM_PLAY, PICTOGRAM_PAUSE, PICTOGRAM_STOP,
      PICTOGRAM_RECORD, PICTOGRAM_VOLUME, ..., PICTOGRAM_CD , ...}
          o Enumeration may be extended by new features we are not aware
            up to now.
          o Furthermore, you can already tell from the enumeration value
                + if a pictogram just can be switched on or off (e.g.
                  PICTOGRAM_PLAY),
                + or if some kind of strength can be specified (e.g.
                  PICTOGRAM_VOLUME)
          o If there happens a type to become popular, you extend the
            enumeration. E.g. a fancy play icon whose colour tells the
            point of time in a recording could be called
            PICTOGRAM_PLAY_FANCY, which implies a new type with
            assignable strength parameter.
    * int get_pictogram(enum Pictogram type)
          o Reports strength (e.g. brightness, volume, WLAN strength)
            for pictogram use case.
                + Returns a non-negative value in case of success.
                + Returns an error if pictogram is not supported. Say -1
                  if pictogram is not supported; or -2, if a hardware
                  problem has occured. Or you keep to the >=0 (success)
                  versus -1 (failure & errno set) convention.
          o Clients may scan which pictograms are supported.
    * void set_pictogram(enum Pictogram type, int strength)
          o If the pictogram is not supported the call is simply
            ignored; which has some compatibility advantages.
          o Strength equal to zero switches off, strength equal to - say
            - 255 switches to full strength; other values in between
            denote intermediate values.
          o For on/off pictograms, strength from 0 to 127 could switch
            off, and 128 to 255 could switch on.

OK, this approach fails if multiple parameters can be assigned to 
pictograms (brightness, colour information, rotation speed, blink rate, 
fading rate, 3D depth information [if ever], etc.). But probably it 
covers a lot of applications.

Maybe a candidate for a poll in the IdeaTorrent? What pictograms are 
required, and which parameters are known up to now?

Whatever you are going to do... I would offer some support from my side: 
Documentation, examples, implementation; just what helps you most.

Regards,
Wolfgang

_______________________________________________
LCDproc mailing list
[email protected]
http://lists.omnipotent.net/mailman/listinfo/lcdproc