[Lcdproc] Overloading the 'output' token
ethan.dicks at gmail.com
Thu Feb 12 00:56:58 UTC 2009
On Wed, Feb 11, 2009 at 7:22 PM, Stefan Herdler <herdler at gmx.de> wrote:
> 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
(relevant because 'output' is driver-specific).
> 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.
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.
> 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.
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.
More information about the LCDproc