[Lcdproc] Overloading the 'output' token

Stefan Herdler herdler at gmx.de
Fri Feb 13 01:19:24 UTC 2009

Ethan Dicks wrote:
> On Wed, Feb 11, 2009 at 7:22 PM, Stefan Herdler <herdler at gmx.de> wrote:
>> Hi,
>> Ethan Dicks wrote:
>>> It probably won't take me more than a couple of hours to code up and
>>> test this change to MtxOrb.c... It seems unlikely (I know... famous last
>>> words) that anyone will produce an LCD with more than 16 GPOs (let
>>> alone 24), but I would never dare to say that it will never happen.
>> a few weeks ago (late December) there had been a thread about controlling
>> special icons on display.
> Yes. I recall.  It was specific to a particular display, not a Matrix
> Orbital display
> (relevant because 'output' is driver-specific).
Yes, it was just meant as hint that others are having similar problems 
sending display-specific commands to the display.
>> My suggestion was to create a kind of all-purpose interface to enable the
>> clients sending display specific commands to the driver.
>> The first approaches looked promising to me, but sadly the development
>> stalled, due to lack of response.
> Given the existing client-server protocol we have to work with, I can't envison
> a solution to the icon/GPO problem that handles all existing displays, let alone
> any that might come to market in the near future.
My plan was to add a function the client can use to send numeric values 
directly to the driver.
The names and possible ranges of the variables would be defined in the 
The client should also be able to query the possible variable names and 

Any function of a display i could imagine so far would be controllable e.g.:
Icon, functions: on off blinking -> 1, 0, -1
Bargraph, percent, percent blinking -> 0 ... 100 , -1 ... -100
Brightness , percent -> 0 ... 100
GPIOx , boolean -> 0 ,1

This is a practically future proof concept I think.
> The present protocol is quite old and is unextensible.  It's also not
> going to be
> changed for any 0.5.x version of LCDproc, so I didn't propose any changes to
> the protocol itself.
> I have made a simple proposal to handle a specific case (how to pass 8-bit
> color values from the client to the server) for a particular driver (MtxOrb.c).
> The general case of how to handle more displayable icons on a non-generic
> display than fit in a 32-bit (or is it effectively 31-bit, due to
> sign?) int is, to me,
> a much harder problem to solve.  There are no 24 or 28 _GPO_ displays from
> Matrix Orbital, nor are there likely to be (but anything is possible), so my
> proposal is somewhat easy to implement in a way that will probably not
> break anything.  I'm not inventing a new transport mechanism, just a way to
> interpret the values that are already being transported.   I'm fully prepared to
> code up whatever I create, but since I myself do not approve patches, I
> wanted some discussions so that when I get to the coding stage, I won't
> find that my patches are unwelcome and the effort for naught.
At the other hand you (and everyone with the intension to send commands 
to a driver) are wasting much time trying to squeeze the data somehow 
through the 'output' function.
>> I personally don't own a display that would support that features, but from
>> the side of the client author I appreciate a official and "clean" way to
>> handle this "extended" features.
> Once the discussion opens for a new way for clients and servers to
> communicate, there will be plenty of opportunity to discuss things as
> specific as DVD/VCR-like media displays that are, in effect, mostly
> "icons" (as LCDproc sees them) rather than blocks of plain text, which
> is where LCDproc came from 10+ years ago.
> I've been using LCDproc a long time (since 0.3.something) - it is *much*
> easier to add new drivers and features now than in the bad-old-days.   The
> issue for me now is that the hardware guys are coming up with fantastic
> stuff that we never could have imagined was available, and it is straining
> the boundaries of what LCDproc was set up to do.  Once we get a chance
> to start discussing the next incarnation of the product, there are lots of
> real-world displays that have unsupported features that will be great fun
> to unlock with LCDproc.
> I do like the fact that I can write clients that are mostly display-agnostic
> (by querying the geometry and perhaps altering what widgets are created
> as a result).  I would love to see future versions of LCDproc enhance the
> communications between server and client about what "features" the server
> is prepared to support (a bazillion icons, GPOs, multi-color this and that,
> Dallas 1-wire, less textual interpretation of graphic displays, etc., etc.)  For
> now, though, only small steps are possible.
I agree, it takes time to add support for new display-features to the 

But we are talking about very special features supported by only a few 
displays. I don't think it is possible to control all this features 
(e.g. different Icons) of the different displays by the servercore. In 
such a case it would it would be useful to have the possibility to 
control this features directly by a client.

Well, with the 'output' function it is already possible but it is 
defiantly not user friendly.

...just my 2 cents, regards

> -ethan
> P.S. - while writing this, I did just come up with what might be a less
> intrusive way to assign a new color value - since we have a 32-bit int,
> use the highest bit possible as the selector between "GPO  X"
> and "use the low 24-bits for RGB values" (it might look like 'output
> 0x40RRGGBB' to keep it a positive number).  It reduces the number of
> output commands required to set a color; it reduces the risk that the
> user will see red change, pause, green change, pause, blue change;
> and it leaves the maximum amount of space possible for GPO control.
> This would be, of course, specific to the MtxOrb.c driver, leaving 'output'
> behavior unaltered for all other drivers.
> _______________________________________________
> LCDproc mailing list
> LCDproc at lists.omnipotent.net
> http://lists.omnipotent.net/mailman/listinfo/lcdproc

More information about the LCDproc mailing list