[Lcdproc] Patch: Driver for VFD in MonCaso 320

[Wolfgang Hauck]

Am 13.10.2011 18:59, schrieb Markus Dolze:
> 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)?
>>
> Hi,
>
> 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.
>
> Regards,
> Markus
Hello,

as things started to become difficult I took this as occasion to check a 
few display commands. I did some experiments, and the situation is 
easier than the reverse engineering from Windows suggested at a first 
glance.

In summary, the driver works without the initialisation command that 
caused the trouble. In consequence, there is only one configuration 
parameter and the whole complicated stuff from above concerning 
synchronisation with other drivers as LIRC is obsolete. The driver gets 
rather simple (again).

Changes provided by the attached patch:

    * Only one configuration parameter (serial port device path).
    * Driver works stand-alone or cooperates with LIRC, both without
      further configuration.
    * Corrected and extended character set mapping from ISO 8859-1 to
      display character set.
    * Revised documentation.

Regards,
Wolfgang

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omnipotent.net/pipermail/lcdproc/attachments/20111017/01834986/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: vlsys_m428.patch.gz
Type: application/gzip
Size: 6091 bytes
Desc: not available
URL: <http://lists.omnipotent.net/pipermail/lcdproc/attachments/20111017/01834986/attachment.bin>