[Lcdproc] Overloading the 'output' token

Ethan Dicks ethan.dicks at gmail.com
Wed Feb 11 21:26:48 UTC 2009

Hi, Daryl,

Thanks for responding.

On Wed, Feb 11, 2009 at 3:45 PM, Daryl F <wyatt at prairieturtle.ca> wrote:
>On Wed, 11 Feb 2009, Ethan Dicks wrote:
>> For now, though, the question I'm putting on the table is if it's
>> better or worse to make the user set some LCDd.conf parameter like
>> "HasMulticolorBacklight yes/no" to enable these new commands.
>> Implementation is easy either way.  It's about what is a greater or
>> lesser burden to the end-user.
>> Comments?  Complaints?  Acknowledgments?
>> -ethan
> For two reasons I'd say use "HasMulticolorBacklight yes/no" and set the
> default default to "no".
> First, since it is unknown how older devices will respond. It would be
> better if they worked more often. This way, even though the newer device
> won't have colored backlight at least all devices will display correctly,
> without garbled characters or lockups.

It certainly is the safer alternative, but having seen some traffic
on the list about how LCDd.conf is "too complicated", I wanted to
throw the issue out for some examination.

I'm personally not opposed to it, but perhaps someone out there is
thinking, "Ghod!  Not more stuff in LCDd.conf you have to set".

> Second, because of where I think the role of lcdproc developers are in the
> bigger scheme of "new to Linux users". It is up to integrators, like Gentoo
> or Redhat, to write the hand-holding configurators that will ease the path,
> not driver developers.

Hmm... while it would be nice to push the issue out to the distros, are they
really going to do anything with LCDproc that doesn't come out of the box?
I can see a distro maintainer being willing to whip together some simple
init script to start LCDd automatically (whether it releases or not is another
problem that's been all over the list this month), but I'm thinking that if
LCDproc doesn't come pretty much ready to integrate into most popular
distros, it's going to be left out as too much hassle to include.

> Some distributions are targeted to Windows users,
> like Ubuntu, others like Gentoo appeal to those who don't mind learning by
> doing (tweaking). Ubuntu might give them an nice multiple choice quiz
> interspersed with probing the device where Gentoo might give them a written
> "Howto Configure lcdproc" document.

OK... while that makes sense in principle, who writes that?  Who maintains that?
The driver writers know more than anyone about what needs to go into LCDd.conf,
certainly on a driver-by-driver basis.  Is it reasonable to push a
requirement to
understand how even the 20 most popular drivers work onto someone who is
mostly interested in just gathering interesting and cool packages into a distro?
If the answer is 'yes', then OK, but it seems to me that LCDproc could enjoy a
pretty wide distro-based availability if we (the LCDproc developers) meet the
distro guys more than halfway.  Where that point is, I'm not certain,
but I think
we should be willing to go much more than halfsies.

LCDproc supports a *lot* of types of hardware; so many that it's both advantage
and a disadvantage at the same time.  Obviously, since I've worked on multiple
drivers stretching over 10 years, I don't have a problem with digging deep into
the code to fix something, but I've been a professional software
developer a long
time, and I've come to learn (sometimes the hard way ;-) that what's easy and
obvious to me is rarely easy and obvious to "users".

> Just my .02 of a dollar on the question. And kudos for your work on the
> drivers.

Thank you.  I appreciate your input, so please don't take what I've written as
criticism or refutation.  I'm just not sure we have the same expectation of
what to count on from distro maintainers.

Unless someone weighs in with a persuasive argument against adding a
line to LCDd.conf to "EnableMulticolorBacklight" (no nitpicks about Color vs
Colour, please ;-), I'm likely to have something coded up and submitted as
a patch to MtxOrb.c pretty soon.  Right now, I'm fiddling the colors with a
standalone script to bypass LCDd and go right down the pipe, and want to
get some "real support" for this.

I'm having problems finding any concrete references, but isn't there at least
one more module out there that has user-controllable backlight color?  I know
it's not available on every street corner, but I thought there were a
couple that
at least could do simple bi- or tri-color.  If I know what hardware is
out there,
it makes it easier to pick a mechanism that I don't regret later.

Thanks, and keep those cards and letters coming,


More information about the LCDproc mailing list