[Lcdproc] Patch: Driver for VFD in MonCaso 320

[Wolfgang Hauck]

Am 12.10.2011 00:05, schrieb Markus Dolze:
> On 20.09.2011 01:35, Wolfgang Hauck wrote:
>> Am 15.09.2011 08:23, schrieb Markus Dolze:
>>> On 13.09.2011 01:59, Wolfgang Hauck wrote:
>>>> Hi all,
>>>>
>>>> hopefully this is the right board to submit a new driver.
>>>>
>>>> The Moncaso 320
>>>> (http://moneualusa.com/?option=com_content&view=article&id=158&Itemid=159)
>>>> contains a small one-line-display. The cases MonCaso 312/320 are
>>>> discussed in the thread
>>>> http://ubuntuforums.org/showthread.php?t=1536934. By reverse
>>>> engineering I have been able to write a very simple display driver,
>>>> which is attached to this e-mail as patch to LCDproc 0.5.4.
>>>> Unfortunately, I have no information about the full functionality of
>>>> the VFD (as e.g. icons).
>>>>
>>>> The driver works quite well with VDR
>>>> (http://en.wikipedia.org/wiki/Video_Disk_Recorder) and some supportive
>>>> scripts I have written.
>>>>
>>>> By the way: Is there anyone with some more information about the VFD
>>>> found in the MonCaso 320? It is hard to get a technical manual.
>>>>
>>>> I tried my very best to adhere to your conventions. Let me know if
>>>> some changes or adaptations are necessary.
>>>>
>>>> Kind regards,
>>>> Wolfgang
>>> Hello Wolfgang,
>>>
>>> thank you for your submission. I will take a look at it although this
>>> may take some time (probably some weeks).
>>>
>>> Regards,
>>> Markus
>>>
>> Hi all!
>>
>> Markus, thank you for your reply.
>>
>> Meanwhile got some feedback, which I added to the patch.
>>
>> Changes:
>>
>>     * The configure script is now part of the patch file. The command
>>       autoconf had to be executed in the version before.
>>     * Settings of serial port were only correct if LIRC was running
>>       before. Now, the driver can be configured to configure the port
>>       on its own.
>>     * Added some parameters controlling the collaberation with other
>>       drivers using the same serial port (particularly LIRC).
>>
>> Further feedback is welcome!
>>
>> And again, I am looking for more information on this device. If 
>> anyone should know the one or other thing, please let me know.
>>
>> Regards,
>> Wolfgang
>
> Hello Wolfgang,
>
> I had a look at both versions of the driver. The driver looks fine 
> (have not yet compiled it) and it quite simple.
>
> Hoewever, setting the driver to wait for the socket by default is not 
> appreciated! To prevent configuration mistakes, the driver should not 
> wait for something other than the display on startup unless the user 
> decided it shall do so.
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)?

> Please do not send in the configure script. For developers the 
> configure script should always be regenerated using 'sh autogen.sh' 
> (if you use a release you may download autogen.sh from 
> http://lcdproc.cvs.sourceforge.net/viewvc/lcdproc/lcdproc/). Users 
> would additionally need the updated Makefile.in files, too.
>
> Hint: You can save yourself some typing by using '-X diff-ignore' to 
> your diff command (get it from CVS web as above). It contains a list 
> if all files to ignore.
Thanks for the hint. I have already been looking for this file.

Regards,
Wolfgang
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omnipotent.net/pipermail/lcdproc/attachments/20111013/42a22ab7/attachment.html>