LCDproc development and user support list

Text archives Help


[Lcdproc] Starter program


Chronological Thread 
  • From: ethan.dicks at gmail.com (Ethan Dicks)
  • Subject: [Lcdproc] Starter program
  • Date: Mon, 5 Jan 2009 14:26:55 -0500

On Mon, Jan 5, 2009 at 1:06 PM, Peter Schmidt <zicronsoft at yahoo.com> wrote:
> Now I understand how many people may find using the LCDd.conf is easy to
> use, but if you plan to port this program to Windows (and the fact that it
> does work on Mac) there should be some sort of setup. I'm NOT saying make
> the entire program a GUI, I'm saying I would like it if there was some sort
> of starter app that helps set you up.
>
> For example, this program would be able to search for all possible LCDs/VFDs
> in /dev/ and would test the bit rates and drivers. There aren't that many
> bit rates or drivers, so I would assume it could take maybe a full minute to
> test all of them (probably less if it finds the correct driver at the
> beginning of its process) and would be fairly minimal to code.

>From you saing "there aren't that many", perhaps you haven't dug into
how many drivers and modules are supported by LCDd. For Matrix
Orbital products alone, there are dozens of compatible LCD and VFD
modules.

In the case of USB-attached devices, it is at least easy to determine
what "odd" vendor/product codes are on the bus and attack that angle
with a list of known products. There's no "speed" to worry about,
etc. It would probably not be _too_ bad to come up with a probe
routine to determine what's on the bus, but at least in case of USB
MtxOrb modules, it might not be possible to reliably determine
geometry since they have been known to reuse ident codes in the past.

For parallel-attached modules, there are several attachment techniques
- 4-bit, 8-bit, with shift register, without... it's not
insurmountable, but neither is it simple.

Serial is the big unknown - baud rates, vendor codes, what state will
modules be in after receiving much garbage data. I would think that
testing wouldn't be reasonably complete without having a stack of
serially attached modules on hand (I have 3-4 myself).

Since there is often zero feedback from modules as to their specific
geometry (some "backpack" interfaces can be told what they have, most
USB modules know one way or another, but many parallel modules just
don't have the first idea), I doubt it is possible to cover more than
a small fraction of the devices that LCDproc supports without feedback
from the human looking at the module. One could imagine a scenario
where LCDd tries the easiest ones first and asks for confirmation that
there is *some* legible message on the display, but after the trivial
ones are exhausted, I foresee a cycle of "how about now?" *click* "how
about now?" for literally dozens of choices.

A tool to build a LCDd.conf and to leave a launch script lying around
is a fine idea, but having worked with a dozen different types of
modules myself, with most interface types represented, I am skeptical
as to how to get a program to guess what you have hanging on your
system beyond a small fraction of cases.

Have you looked at other LCD projects to see how they have done
things? I haven't in enough depth to give a reasonable answer. One
"easy" way to do it is to list in some HCL list the ones that can be
autodetected, then provide for an "advanced" screen if you don't
happen to have one of the 20-or-so modules that are on the autodetect
list.

Right now, I couldn't even tell you how many specific modules and
interfaces and geometries are supported, but it wouldn't surprise me
to hear that it's well over 100. Just MtxOrb alone, one I know well,
is several dozen, and there are subtle differences from product to
product just for that one vendor alone.

This is, essentially, as complex an issue as attaching a random
printer to your system. Saying "for those who don't know exactly what
they are doing or what they have" is incredibly complex when you are
dealing with parallel vs serial vs network vs USB, and some
combinations are much more complex than others. Look at how long it's
taken to get printers *mostly* sorted out - and most of that is by
focusing on USB vs other attachment methods. For anything that
doesn't report details, the user *must* know vendor and model to
direct the install process. LCDs and VFDs aren't magical compared to
printers - they in fact have many of the same issues and problems
(except being out of paper ;-) for much the same reason - there isn't
one or two or three ways to do it - there are many, many combinations
of interfaces, widths, feature sets, etc.

Can things be improved? Almost certainly. Can you take a random
newbie and a random module and a random OS and get a zero (or even,
say, three) question install program? Almost certainly not.
Redefining the scope of the effort will go a long way to increasing
the chances of success.

Now comes the hard part... who's going to write it? It's not me - I
have been programming professionally for over 25 years. In all that
time, paying all my bills by working in IT, I have not written a
single Windows GUI program. Not one. I don't care how many Windows
machines or users are out there; it's just not a direction I've had to
go to further my career. LCDproc, like most open source projects, is
volunteer driven. Saying "hey, wouldn't this be nice?" is usually
followed up with "hey, here's my attempt at it". Perhaps there are
members of this list with lots of relevant experience and, more
importantly, lots of time, but I think that pool is much smaller for
GUI anything than system-level command-line projects.

-ethan




Archive powered by MHonArc 2.6.18.

Top of page