Re: Separate icon area: interface for drivers?

On 08.10.2011 00:34, Wolfgang Hauck wrote:
> 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
> 

Hi Wolfgang,

sounds like the beginning of a specification.

However, I am less concerned about the driver API than with the client
language.

There will surely be one client command to set a pictogram, which
requires the name of the pictogram and a level (the server must have a
'name' to 'value' mapping as for icons).

For the client to get a list of supported pictograms another command is
required to which LCDd answers with a list of supported pictograms (and
perhaps its type). The type may not be necessary as the client has to
know how to use the pictogram anyway.

To build the list of supported pictograms LCDd may scan all loaded
drivers for the existence of set_pictogram() and for driver that
implements it cycle through all known pictograms and record if the
drivers supports it (returns 0) or not (return -1) on the call to
set_pictogram().

This way, get_pictogram would not be necessary and 'set_pictogram' could
simply be named 'pictogram'.

However, there is one open point: Shall the client command supports
setting multiple values at once? For example on changes from 'play' to
'pause' the first must be turned off while the second must be turned on.

If these changes are sent in separate messages, there may be a delay in
processing. However, client messages sent directly in sequence _should_
be processed in the same order with no other command mixed in between by
design.

Sending these changes in the same message be overflow the command length
if the application sends may changes in the same command.

Regards,
Markus