LCDproc development and user support list

Text archives Help


[Lcdproc] Re: nSEL (EN2) state inverted (proposal for Soft-wiring)


Chronological Thread 
  • From: joris AT robijn.net (Joris Robijn)
  • Subject: [Lcdproc] Re: nSEL (EN2) state inverted (proposal for Soft-wiring)
  • Date: Wed Mar 23 18:32:01 2005

On 23 Mar 2005 at 11:14, Lucian Muresan wrote:

>
> This would be easy after few changes to LCDproc even without recompiling
> (of course, after someone has done these changes :-) ), if a sort of
> soft-wiring would be implemented. This would of cours grow the number of
> keys to be set maybe in each driver section of /etc/LCDd.conf, but would
> allow the user to configure his own wiring (even with inversions on
> specific lines) without having to modify the source code. I did some
> preliminary work for this sort of thing (not a really flexible
> soft-wiring, but supporting just 2 wirings for now) in the noritake800
> driver of the graphlcd-base library.

The idea has been around for quite long, I think longer than in
lcd4linux. However, it has been implemented there much quicker.
Appearently someone over there put some effort in it. Not on lcdproc yet.
Be my guest if you want to.

I don't think this should be done in a "library" way. The risk is that
after some time, when something has changed in the library, some drivers
are not updated anymore and will not compile/work. We've had these
problems a bit too with the 0.4 to 0.5 conversion, with loadable drivers.
Authors are simply lost. So I would think it should initially be
important for the hd44780 driver then.

I think it is important to keep the current way of configuring working.
It's quite easy to turn the current system into something that selects a
standard wiring scheme if you say "connectionType=winamp". I guess all
settings you specify additionally would override this standard scheme
then, like conn.enable=STROBE. Or should this be pin-wise, like
conn.enable=pin1 . Or both ?

It would probably mean that all subdrivers could be removed. One point
may be that some extra features that are only in some subdrivers cannot
be used anymore. Like there is the semaphore in the ext8bit driver (I
think) to enable other programs to access the port in parallel, but maybe
we should stop supporting that anyway.

Joris

--
Joris Robijn
<joris AT robijn.net>
Mobile: +31 6 288 41 964

// To understand recursion, we must first understand recursion





Archive powered by MHonArc 2.6.18.

Top of page