[Lcdproc] Patches for iMON LCD (for example in Antec Fusion Black)

[Peter Marschall]

Hi Dean,

On Saturday, 8. September 2007 04:05, Dean Harding wrote:
> > please make it as easy as possible for the maintainer:
> > base your diffs against current CVS so that they apply cleanly,
> > add proper documentation, send them to mailing list, ...
>
> Thanks for the tips Robert & Peter. I don't know if I mentioned this in my
> email, but I'm fairly new at this :) so I'll keep that in mind.
>
> I've actually already got a few more features implemented (like some
> bitmap-based "big numbers" for the clock and so on) so I'll hold off on
> another patch until I get everything that I wanted finished.
>
> But the point of my original email was mainly to get some feedback. The
> main question I had was about the icons around the outside of the screen
> (see the screenshot on this page for an idea:
> http://www.soundgraph.com/Eng_/Products/oem3.aspx?topMenu=2&subMenu=1&leftM
>e nu=43). Is there anything already in LCDproc that would allow a client to
> control those? Should I add a new command to the protocol? If a new command
> is required, does that mean the protocol version has to increase? I
> wouldn't think so... assuming there was some other way to indicate the
> presence of a *new* command (as opposed to a *changed* command or
> something?)

LCDproc has the 'output' command.
This command can be used to control special output controls
like LEDs, or - in case of your display - special icons.
I suggest using a bitmask for the argument of the output command
where each bit represents an icon: if the bit is set, the icon is
highlighted, if it is unset it is dark.
(Please don't forget to document this feature ;-)

BTW: adding a new command to LCDproc means increasing the protocol
version. Otherwise clients depending on the protocol version to check
for features cannot distinguish between the protocol without and the
protocol with the new command.
I also admit I am not very keen on adding a feature for the language
that is useful only for a very limited subset of devices.
If possible I do not want to clutter the language with device
specific features. This makes it harder to write clients that can run
on different devices.

Regards
Peter

-- 
Peter Marschall
peter@adpm.de