[Lcdproc] [Fwd: Re: Overloading the 'output' token]

[Arthur van Dongen]

Hi,
-------- Forwarded Message --------
> From: Ethan Dicks <ethan.dicks at gmail.com>
> To: lcdproc at lists.omnipotent.net
> Subject: Re: [Lcdproc] Overloading the 'output' token
> Date: Wed, 11 Feb 2009 19:56:58 -0500
> 
> 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).
> 
I was the one who started that thread. It touched the 'output'
functionality because the current driver had the 'icons' on the glass
available through 'output' commands. I thought I could implement better
support for these icons in the Christmas period, but did not succeed in
the time I had. 

> > 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 see two problems when hijacking the 'output' commands for controlling
the backlight. The first is that the value set in the 'output' command
is buffered, and only written to the driver periodically. So you cannot
use numeric commands like the 32-bit color command, and the lower bits
to control the output pins at the same time.
The other problem is that the output interface could work well if you
configure the _client_ which pin means what. But backlight/vfd
illumination is a common thing that should have a dedicated command. 
> 
> > 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 that changes to the interface at this point should be avoided.
But I would suggest to make an exception for controlling the
backlight/illumination, because otherwise different drivers would go in
diverging directions. I've seen that happen in the icon business: one
driver uses the 'output' command, another the 'icon' command. For very
similar things...
> 
> -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

BR,
Arthur