[Lcdproc] Patch: Driver for VFD in MonCaso 320
bsdfan at nurfuerspam.de
Thu Oct 13 16:59:08 UTC 2011
On 13.10.2011 01:29, Wolfgang Hauck wrote:
> Here I am in a dilemma. For a clean solution, I would have to write an
> own server managing the display resources, which is used by other
> clients as LIRC or LCDproc. But this is much more work, and more
> important, I have no idea how to deploy such a server into the Linux
> world considering existing solutions. So I decided to pursue an
> acceptable alternative.
> This alternative approach shows two flavours:
> 1. By default, the LCDproc driver assumes the display has already
> been initialised (e.g. by LIRC). Then the LCDproc driver has to
> coordinate in some way with - say - the LIRC driver.
> 1. Simple solution: The LCDproc either ignores the initialising
> driver completely, blocks until the initialisation has
> finished (wait for socket, which is the submitted solution),
> or runs into a timeout when waiting for a socket.
> 2. Complex solution: Setup a thread monitoring the initialising
> driver, and only after initialisation the LCDproc driver
> functions work successfully, otherwise they log an error and
> report a failure.
> 2. By default, the LCDproc driver initialises the display itself. But
> this may interfere e.g. with LIRC. The initialisation produces a
> display response that is misinterpreted by LIRC as remote control
> button press.
> As I expect the parallel usage of LIRC and LCDproc as the most frequent
> use case, I tried the solution 1.1. with blocking wait.
> So, here is what I can offer:
> 1. LCDproc assumes an initialised display by default (keeps
> configuration logic as submitted):
> 1. Exit after a defined timeout if no initialisation has
> occurred, and print error to system log file.
> 2. Establish a monitoring thread. Is pthreads allowed in
> LCDproc development?
> 2. LCDproc initialises itself the display by default (inverts
> configuration logic as submitted), and locks the serial port such
> that a concurrent [LIRC] driver or LCDproc itself fails.
> So, which way do you want me to go? 1.1. (disadvantage: your concerns
> are only mitigated), 1.2. (disadvantage: LCDproc is addressable but
> probably not ready) or 2. (disadvantage: a frequent use case does not
> work out of the box)?
I didn't have such complicated things in mind.
The point is: The default should be not not to wait. The documenation /
LCDd.conf should instruct the user that if he has LIRc running, he
should enable waiting for the socket. Once enabled by the user he will
likely be not surprised if LCDd stalls on startup.
More information about the LCDproc