[Lcdproc] Patch: Driver for VFD in MonCaso 320
wolfgang.hauck at gmx.de
Wed Oct 12 23:29:38 UTC 2011
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
>>>> 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,
>>> Hello Wolfgang,
>>> thank you for your submission. I will take a look at it although this
>>> may take some time (probably some weeks).
>> Hi all!
>> Markus, thank you for your reply.
>> Meanwhile got some feedback, which I added to the patch.
>> * 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.
> 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
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
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
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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the LCDproc