From ethan.dicks at gmail.com  Sun Mar  1 00:05:35 2009
From: ethan.dicks at gmail.com (Ethan Dicks)
Date: Sat, 28 Feb 2009 19:05:35 -0500
Subject: [Lcdproc] 4x40 (and other odd sizes)
Message-ID: <f4eb766f0902281605g736f9d65md53b320c460644db@mail.gmail.com>

On Sat, Feb 28, 2009 at 1:14 PM, Sascha <sascha.zielinski at gmx.de> wrote:
> lcdproc looks good, but it is not optimized for 4x40 lcd's, I think.

Not as such, no.  LCDproc was originally written for a 4x20 Matrix
Orbital display, and while it has improved greatly over the years, I
think the clients assume that geometry (which is fair, since it _is_
the default).

I have a couple of 4x40 displays, HD44780-based, one with an lcd2usb
attached, one "spare".  I think they are great and lots of fun to
write clients for, but they are not common.  The best use I have for
mine is either displaying multiple timezones (like the wall of clocks
that used to hang in airports or behind the anchor on TV newscasts
decades ago) or displaying songs and artists with a bignum year from
the id3 tag filling the right side of the display on my xmms client.

For many things, 4x20 is a nice size.  Not scrolling 25-character song
titles is rather nice, though, and 2x40 just isn't much room for a
music player front-end.

I've mentioned in the past that I write my clients to be aware of
geometries other than 4x20, and I can suggest that other client
writers do the same.  If nothing else, there's the curses client for
testing of proportions, layout, etc.  BTW, I haven't written a client
in C yet (where string formatting and parsing is rather tedious), but
writing multi-screen geometry support for Perl clients is a breeze.

-ethan

From ethan.dicks at gmail.com  Sun Mar  1 00:16:59 2009
From: ethan.dicks at gmail.com (Ethan Dicks)
Date: Sat, 28 Feb 2009 19:16:59 -0500
Subject: [Lcdproc] imonlcd / icons question
In-Reply-To: <0A02838AFAB4AA41A421A9D09800FE66B2DD4C5F5B@server-tim.tim-online.nl>
References: <0A02838AFAB4AA41A421A9D09800FE66B2DD4C5F5B@server-tim.tim-online.nl>
Message-ID: <f4eb766f0902281616y56b4d112ld9d2b710538ce883@mail.gmail.com>

On Sat, Feb 28, 2009 at 5:48 PM, Leon Bogaert <leon at tim-online.nl> wrote:
> Hi all,
>
> I'm trying to write a simple script to control the icons of my imon lcd screen.
> Browsing throught the code of that driver I saw that every icon has it's own code.

Yes.  Each icon has a 'bit' associated with it so that the sum total
of all the bitfields is what icons are shown.

> For example: the spinning disk => 0x0080FF0000000000
> The music icon => 0x1 << 23

OK.

> So if I telnet output 1, I get the spinning disk.
> I I telnet output 2, I get the music icon.
> I I telnet output3, I get the the spinning disk AND the music icon.

Right.

> But how do I convert the this? So that I get 3, if I do '0x0080FF0000000000 + 0x1 << 23'.
> I tried to convert it to ints. '0x1 << 23' converts to 1.
> But '0x0080FF0000000000' converts to '36309172484046848'.

You can add or 'or' the values together, but, and here's the part that
I don't think you are getting, you don't have to convert the bitfield
to decimal before sending it. Having just peered at the code when
working on the tricolor backlight experiment, the parser uses strtol()
to pull the value off the socket.  It doesn't care if the number is
decimal, octal or hex, as long as it's marked such.  It does matter
how large the number is - you have 31 bits to work with, not 32, since
strtol() thinks your 'long' is a signed long.  You'll get an overflow
error from the call, which LCDd handles, but if you aren't running at
a high enough logging level, you might not see it yourself.  Just
don't try to send 0x8000000000000000 or larger.

So...
your spinning disk is 0x0080FF0000000000, and your music icon is
(pre-shifted) 0x400000 (if I did the math in my head right), so you
could send an 'output 0x0080FF0000400000' to get both on at the same
time.

Doing bitfield math in the shell is a bit rough, but there are ways to
do it.  Just remember that LCDd will handle hex numbers directly as
long as you preface them with '0x'.

-ethan

From sascha.zielinski at gmx.de  Sun Mar  1 02:23:48 2009
From: sascha.zielinski at gmx.de (Sascha)
Date: Sun, 1 Mar 2009 03:23:48 +0100
Subject: [Lcdproc] HD44780 40x4 with Backlight and winamp wiring
In-Reply-To: <49A98DF6.6060507@nurfuerspam.de>
References: <9185341920196262063@unknownmsgid>
	<200902281555.39972.sascha.zielinski@gmx.de>
	<49A98DF6.6060507@nurfuerspam.de>
Message-ID: <200903010323.49120.sascha.zielinski@gmx.de>

Am Samstag 28 Februar 2009 20:18:14 schrieben Sie:
> Sascha wrote:
> > Hi
> > I loaded 4 instances of burnMMX and watched the SMP CPU Screen but I
> > didn't noticed any strange things. While switching between the screens I
> > noticed something strange in the CPU Graph screen. I attached 2 videos
> > with shows my two screens.
>
> Do you mean the large vertical bars passing by or that the overall load
> is not as high as the SMP screen suggests?

The two large bars are always shown (if my cpu Load is low they are smaller) 
and I don't know why.. The overall load should go from top to bottom, because 
all 4 cores have 100% Load.

> > Is there a feature wish list where I can write down some things?
>
> If you want to get feedback about your ideas write to the mailing list.
> While the Sourceforge 'feature requests' tracker exists, it is mostly
> unused.

Do I have to use a special subject?

> > lcdproc looks good, but it is not optimized for 4x40 lcd's, I think.
>
> 40x4 displays are rarely used. For displays built into computers or
> servers 40x4 is just too large.

I own a self made Living room PC. I'll make some new. These are some old 
pictures.
http://uploading.com/files/V9PZ0EUJ/PC 2008-01-01.rar.html

> The lcdproc client screens are designed for 20x4 and 20x2 screens. On
> smaller 16x2 some information may be missing and on 40x4 you only get
> more space on most screens.
>
> While it is possible to put more information on a 40x4 you would have to
> cut it down for the majority of 20x4/20x2/16x2 displays again. This is
> why I would not put more information into the standard screens.

Is it possible to display 2 screens (20x4) at the same time?

> > It would be nice if the CPU MHz for each core is shown in the SMP-CPU
> > Graph.
>
> This on the other hand sounds like an interesting feature.
>
> Regards
> Markus

I noticed, that my lcd doesn't switch the backlight off, if the min. Load is 
reached. How many seconds the Load must stay below the min. value?

I will collect some more of my Ideas.

Thanks for your help.

Regards,
Sascha


From bsdfan at nurfuerspam.de  Sun Mar  1 12:18:28 2009
From: bsdfan at nurfuerspam.de (Markus Dolze)
Date: Sun, 01 Mar 2009 13:18:28 +0100
Subject: [Lcdproc] Increasing the server's receive buffer
In-Reply-To: <0CCDE7FF-6F93-4F7D-A568-505EDF06DF7B@siliconlandmark.com>
References: <49A8F32F.10800@nurfuerspam.de>
	<20090228091028.C44792C407A@tippex.mynet.homeunix.org>
	<0CCDE7FF-6F93-4F7D-A568-505EDF06DF7B@siliconlandmark.com>
Message-ID: <49AA7D14.9070508@nurfuerspam.de>

PS: By 'lcdproc client' I mean the client we ship in clients/lcdproc/.

Andre Guibert de Bruet wrote:
> On Feb 28, 2009, at 4:10 AM, aeriksson2 at fastmail.fm wrote:
> 
>> bsdfan at nurfuerspam.de said:
>>> if LCDd is used with large displays (40x4) it may happen that the  
>>> server's
>>> receive buffer is too small and the client gets disconnected.  The 
>>> disconnect
>>> is triggered if the client sends 7K. This is likely to  occur during 
>>> initial
>>> creation of screens by the client if the client  sets up several 
>>> screens.
>>
>> This sounds like a client error to me. You can't just write to the 
>> socket and
>> expect all bytes to be sucessfully written. Queueing _will_ happen. 
>> Have you
>> tried over a 2400 bps modem link?

I think I can expect this. Because this is what TCP is for. The TCP send 
/ receive buffers are usually larger than LCDd's ones.

> 
> There appears to be a client bug, an aggressively low receive buffer 
> size and an LCDd bug involved here. From the way that I read 
> sock_read_from_client(), Markus' client should be getting the "Too much 
> data received... quiet down!" message. The magical 7KB value comes from 
> sock.c line 414:
> 
> else if (nbytes > (MAXMSG - (MAXMSG / 8))) {    /* Very noisy client... */
>       something > (8192 - (8192 / 8)) /* which becomes: something > 7168 */
> 
> It is important to note that our call to recv() is made with MAXMSG, so 
> the buffer may legitimately be filled with 7169 through 8192 bytes worth 
> of data. In my opinion, the entire else if() check on line 414 is bogus 
> and should be removed, and its "quiet down!" message along with it.

I was already wondering about this. If the client sends 7.5 K of data it 
is disconnected although the server would be able to process this.

Looking at our implementations in LCDd and lcdproc, I found they handle 
input differently: The lcdproc client loops over the input stream as 
long as data is available and handles the input immediately. Whereas the 
server reads up to 8K, enqueues the messages to processes them later and 
goes on.

However, the client does not check the server response for every message 
it sends, but reads server responses asynchronously. If it encounters 
the "Too much data received" message it  may be already to late.

The developer's guide says "the (error) description is not meant to be 
parsed".

I suggest to not disconnect the client, but send the message anyway and 
parse the client's data. Even if the message is not intended to or 
cannot be parsed by the client, the client could warn the user something 
will go wrong.

Because if the limit is hit the last message from the client is likely 
to be truncated and will trigger other errors.

> 
> It then becomes advisable to make "buffer" MAXMSG+1 in size in order to 
> prevent the buffer[nbytes] = '\0' code on line 419 from writing one byte 
> past the end of the buffer and corrupting the stack.

I will fix this.

> 
>>> Our lcdproc client is sometimes struck by this if you use a 40x4 
>>> display  and
>>> the 'L' screen in addition to the default lcdproc.conf. I wrote  
>>> "sometimes"
>>> because it depends on how fast LCDd reads out the buffer. I  was not 
>>> able to
>>> reproduce this with the curses driver (server reads  about 4K), but it
>>> happened everytime I use the hd44780-lcd2usb (server  reads about 8K).
>>
>>> Updates of a single screen are < 1K most times.
>>
>>> I suggest on of these options: 1. Increase the server's receive 
>>> buffer to 16K
> 
> As more data gets communicated between the clients and server, this may 
> become desirable.

Well, if there is a limit, someone will surely hit it. E.g. if we 
introduce icons API.

A client should not update a single screen more than 8 times a second as 
this is the 'screen refresh rate'. The lcdproc client does exactly this.

> 
>>> 2. Slow down the client's initial screen setup.
> 
> This band-aid does nothing to address the root of the problem.

After reading the sources more thoroughly I found this is exactly what 
the '-e' aka 'Delay' option in the lcdproc client is for. It adds a 
delay between each update_screen() which gives the server time to 
process the data. This option has been available since 2003.

However, whereas the config file states "slow down initial announcement 
of modes" is delay is set for all screen updates not just the initial 
ones, slowing down the client a lot if a number of screens is available.

> 
>>> Any objections against 1?
>>
>> Yes. It would waste memory on a potentially memory-short device.
> 
> I really question whether anyone has lcdproc rolled out on a machine 
> where an 8KB of RAM increase is a "make-it-or-break-it" proposition.

I don't know what people use LCDd for. This is why I put the question.


Regards
Markus

From bsdfan at nurfuerspam.de  Sun Mar  1 20:05:44 2009
From: bsdfan at nurfuerspam.de (Markus Dolze)
Date: Sun, 01 Mar 2009 21:05:44 +0100
Subject: [Lcdproc] Increasing the server's receive buffer
In-Reply-To: <49AA7D14.9070508@nurfuerspam.de>
References: <49A8F32F.10800@nurfuerspam.de>	<20090228091028.C44792C407A@tippex.mynet.homeunix.org>	<0CCDE7FF-6F93-4F7D-A568-505EDF06DF7B@siliconlandmark.com>
	<49AA7D14.9070508@nurfuerspam.de>
Message-ID: <49AAEA98.60406@nurfuerspam.de>

Markus Dolze wrote:
> Andre Guibert de Bruet wrote:
>> There appears to be a client bug, an aggressively low receive buffer 
>> size and an LCDd bug involved here. From the way that I read 
>> sock_read_from_client(), Markus' client should be getting the "Too 
>> much data received... quiet down!" message. The magical 7KB value 
>> comes from sock.c line 414:
>>
>> else if (nbytes > (MAXMSG - (MAXMSG / 8))) {    /* Very noisy 
>> client... */
>>       something > (8192 - (8192 / 8)) /* which becomes: something > 
>> 7168 */
>>
>> It is important to note that our call to recv() is made with MAXMSG, 
>> so the buffer may legitimately be filled with 7169 through 8192 bytes 
>> worth of data. In my opinion, the entire else if() check on line 414 
>> is bogus and should be removed, and its "quiet down!" message along 
>> with it.
>
> I was already wondering about this. If the client sends 7.5 K of data 
> it is disconnected although the server would be able to process this.
>
> Looking at our implementations in LCDd and lcdproc, I found they 
> handle input differently: The lcdproc client loops over the input 
> stream as long as data is available and handles the input immediately. 
> Whereas the server reads up to 8K, enqueues the messages to processes 
> them later and goes on.
>
> ...
>
>>
>> As more data gets communicated between the clients and server, this 
>> may become desirable.
>
> Well, if there is a limit, someone will surely hit it. E.g. if we 
> introduce icons API.
>
> A client should not update a single screen more than 8 times a second 
> as this is the 'screen refresh rate'. The lcdproc client does exactly 
> this.
>

Looking harder at the server I found that LCDd indeed loops when reading 
from the client as long as data is available, but *only* if the client 
does not send more than 7K. The loop is part of sock_poll_clients().

To have something to play with, I started rewriting that part.

My first attempt (patch-server-sock.diff) was using sock_recv_string() 
which reads one line from the network and pass this to 
client_add_message(). The advantage is that the string tokenizing in 
client_add_message() can be omitted. The major disadvantage is that it 
uses one read() system call to retrieve one byte.

So I tried a second solution (patch-server-sock-pushback.diff) which 
retrieves up to 8K with one read() call and uses a second buffer. The 
disadvantage here is that data is copied between the two buffers. This 
solution is very much like the original one, but solves the problem that 
client messages are truncated.

Please test, select your favourite, improve it, or come up with your own 
solution.

Regards
Markus
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patch-server-sock.diff
URL: <http://lists.omnipotent.net/pipermail/lcdproc/attachments/20090301/9f1ad983/attachment.txt>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patch-server-sock-pushback.diff
URL: <http://lists.omnipotent.net/pipermail/lcdproc/attachments/20090301/9f1ad983/attachment-0001.txt>

From malte at maltepoeggel.de  Mon Mar  2 10:31:13 2009
From: malte at maltepoeggel.de (=?iso-8859-1?Q?Malte_P=F6ggel?=)
Date: Mon, 2 Mar 2009 11:31:13 +0100
Subject: [Lcdproc] Changes to get EA-DOGM163 + four keys working with
	hd44780-lcd2usb driver
References: <BBC090545EA14A1CB4E61EF56FAA5219@subnote1400><20090221201626.289250@gmx.net><D8B559509C6B4526B97C4F675184332A@Schleppi4000><20090224193947.216800@gmx.net><640A2DDB416645A58B0EC4D12737744D@subnote1400><f4eb766f0902250800x3668a120s15fa2108f6d0a50f@mail.gmail.com><2B7A08BBA8BC484FA8831E5428471578@subnote1400><f4eb766f0902261039p21810db9q209400d28565b40d@mail.gmail.com><49A6E42F.4070805@nurfuerspam.de>
	<f4eb766f0902261113k3e7cb874s4b9a4929d2bff206@mail.gmail.com>
Message-ID: <A8456570236948138C19EFEC595E0481@subnote1400>

Hi,

I have been testing the EA-DOGM for the whole weekend and it runs without 
any problems.

Now, the project page is also available in a english translation:
http://www.maltepoeggel.de/index.php?site=sp-lcd&lang=en

and the LCDproc patch is attached to this email.


TODO: Create a charset table for ISO 8859-1 to ST7036.

Malte

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patch.txt
URL: <http://lists.omnipotent.net/pipermail/lcdproc/attachments/20090302/2f69bc92/attachment.txt>

From aeriksson2 at fastmail.fm  Tue Mar  3 10:17:29 2009
From: aeriksson2 at fastmail.fm (aeriksson2 at fastmail.fm)
Date: Tue, 03 Mar 2009 11:17:29 +0100
Subject: [Lcdproc] Increasing the server's receive buffer
In-Reply-To: <49AAEA98.60406@nurfuerspam.de>
References: <49A8F32F.10800@nurfuerspam.de>
	<20090228091028.C44792C407A@tippex.mynet.homeunix.org>
	<0CCDE7FF-6F93-4F7D-A568-505EDF06DF7B@siliconlandmark.com>
	<49AA7D14.9070508@nurfuerspam.de> <49AAEA98.60406@nurfuerspam.de>
Message-ID: <20090303101729.6F6532C40B7@tippex.mynet.homeunix.org>

bsdfan at nurfuerspam.de said:
> Looking harder at the server I found that LCDd indeed loops when reading
> from the client as long as data is available, but *only* if the client  does
> not send more than 7K. The loop is part of sock_poll_clients(). 

I'm obviously missing something. Can anyone share why the server and/or client 
uses, or is supposed to use, tcp's message interface? Why doesn't it read the 
data straight into the parsing buffer as most other code do these days?

The only answer I can come up with is that you might want "create screen + 
define its content" to be an atomic operation. Is that defined anywhere? If 
that's indeed the case, maybe explicit barriers in the protocol would be more 
stable.

/Anders






From andy at siliconlandmark.com  Tue Mar  3 13:27:52 2009
From: andy at siliconlandmark.com (Andre Guibert de Bruet)
Date: Tue, 3 Mar 2009 08:27:52 -0500
Subject: [Lcdproc] Increasing the server's receive buffer
In-Reply-To: <20090303101729.6F6532C40B7@tippex.mynet.homeunix.org>
References: <49A8F32F.10800@nurfuerspam.de>
	<20090228091028.C44792C407A@tippex.mynet.homeunix.org>
	<0CCDE7FF-6F93-4F7D-A568-505EDF06DF7B@siliconlandmark.com>
	<49AA7D14.9070508@nurfuerspam.de> <49AAEA98.60406@nurfuerspam.de>
	<20090303101729.6F6532C40B7@tippex.mynet.homeunix.org>
Message-ID: <25BDE767-5ECB-4D11-87E9-4D19CB06CF86@siliconlandmark.com>

On Mar 3, 2009, at 5:17 AM, aeriksson2 at fastmail.fm wrote:

> bsdfan at nurfuerspam.de said:
>> Looking harder at the server I found that LCDd indeed loops when  
>> reading
>> from the client as long as data is available, but *only* if the  
>> client  does
>> not send more than 7K. The loop is part of sock_poll_clients().
>
> I'm obviously missing something. Can anyone share why the server and/ 
> or client
> uses, or is supposed to use, tcp's message interface? Why doesn't it  
> read the
> data straight into the parsing buffer as most other code do these  
> days?

Though DMA-like systems are used where performance is critical, these  
types of systems are often inflexible and of limited functionality in  
a networked environment. Think of it this way: Besides host-specific  
zero-copy sockets, what use is DMA on a network? TCP allows the source  
of the data to be in a geographically separate area (It could be in  
outer space, literally), or not, from the system running LCDd.

> The only answer I can come up with is that you might want "create  
> screen +
> define its content" to be an atomic operation.

This is a good idea, but for the operation to be truly atomic, it  
would have to fit in exactly one ethernet frame and not cross any  
routers where it might get fragmented. Otherwise, you stall waiting  
for more data until you get the expected number of bytes, which is the  
design we have, presently.

> Is that defined anywhere? If that's indeed the case, maybe explicit  
> barriers in the protocol would be more stable.

I don't follow.

Cheers,
Andy

/*  Andre Guibert de Bruet  * 436f 6465 2070 6f65 742e 2042 6974 206a */
/*     Managing Partner     * 6f63 6b65 792e 2053 7973 4164 6d69 6e2e */
/*   GSM: +1 734 846 8758   * 2055 4e49 5820 736c 6575 7468 2e00 0000 */
/* WWW: siliconlandmark.com * C/C++, Java, Perl, PHP, SQL, XHTML, XML */


From joehenley at kc.rr.com  Tue Mar  3 20:18:40 2009
From: joehenley at kc.rr.com (Joe Henley)
Date: Tue, 03 Mar 2009 14:18:40 -0600
Subject: [Lcdproc] newbie question
In-Reply-To: <49A6F548.7090902@kc.rr.com>
References: <49A57C26.4060808@kc.rr.com> <49A58FDA.5060307@nurfuerspam.de>
	<49A6F548.7090902@kc.rr.com>
Message-ID: <49AD90A0.4050601@kc.rr.com>

Hi Markus,

I was very encouraged after your initial reply.  Hopefully you'll have 
some time to reply to these follow-up questions.

Also, while the the "off-by-one" issue looks to be fixed (per the notes 
on Sourceforge), have the other items related to the picolcd also been 
fixed?

Thanks again for your help.

Joe Henley

Joe Henley wrote:
> Hi Markus,
> 
> Thanks very much for your reply.
> 
> Markus Dolze wrote:
>> Joe Henley wrote:
>>> Hi,
>>>
>>> I'm a newbie here, so please forgive any un-intended "politically 
>>> incorrect" items.  Also, I'm not a C programmer, so I'm pretty much 
>>> dependent upon what I can find at sites like this.
>>>
>>> Is lcdproc still under development?  The last version is from 2007.  
>>> I see lots and lots of patches; and I see comments about folks not 
>>> getting things to run when patches overlap.  I see alot of notes 
>>> about getting patches incorporated, but it seems none do.  I've 
>>> looked repeatedly at the sourceforge site for updates to the code, 
>>> but patches I see here don't seem to show up there.
>> Yes, there is ongoing development. Unlike other projects we use this 
>> mailing list to submit patches for review. Someone with write access 
>> commits the patches once they have received feedback.
> 
> Ah, OK.  As I confessed earlier, I'm a newbie .... does "commit" mean to 
> incorporate it into the nightly updates?
> 
>> The changelog since 0.5.2 has grown large. Usually you receive the 
>> latest code directly from CVS or by using a 'nightly current build' 
>> from http://lcdproc.sourceforge.net/nightly/.
> 
> Is that OK now?  I saw a message in the archives that the nightlies 
> weren't always current.  Since I don't yet know enough about this to be 
> able to tell when it is, or when it isn't current, I just decided to 
> avoid them.  Probably the wrong thing to do, huh? ....
> 
>> Currently our most important maintainer is away, so changes pile up, 
>> but I commited a few fixes recently.
>>>
>>> I bought a picolcd to use with MythTV and have given up on getting 
>>> support from mini-box.  I hoped to get some here, so I've lurked abit 
>>> to see what's happening.  But I must be missing something, because I 
>>> see alot of folks submitting patches, raising questions and 
>>> suggesting fixes, but nothing seems to be done to the code.
>>>
>>> What am I missing?  Is there some other place to look (other than 
>>> here and the sourceforge site)?
>> As LCDproc is open source anyone can take it and ship modified 
>> versions. Some Linux distributions may contain additional patches.
> 
> Yes, that's part of the problem I'm having with mini-box.  They have a 
> version on their site which they reference as 0.5.2, but which is NOT 
> the same as what you have here.  It's abit confusing, and very 
> frustrating, for someone just getting started (like me).
> 
>>> Thanks for any help/suggestions/guidance/etc.
>>>
>>> Joe Henley
>>>
>>> PS:  Yes, I know I have not indicated my picolcd problems.  But they 
>>> are  all previously listed here by others, and are still open as far 
>>> as I can tell.
>>>
>> If you do need help, as on this list. There are people familiar with 
>> these devices here.
> 
> Thanks for the offer.  I looked back thru the last 4 or 5 months of 
> posts in the archives and picked out the problems/patches others had 
> identified which also looked like ones I'm having.  These include:
> 10/1/08  pavel      "add support"
> 11/2/08  marschall  "picolcd build problems"
> 11/6/08  ekholm     "LCDproc & PicoLCD"
> 1/13/09  dicks      "19 to 20 character"
> 2/2/09   de Bruet   "off by one"
> 2/25/09  de Bruet   various
> 
> Again, it's a newbie picking these out, so I might be wrong on some.
> 
> So if these were fixed (I assume that means "committed") then I should 
> be able to move forward on getting my picolcd 4x20 to work.
> 
>> Regards,
>> Markus
> 
> Oh, while I may be a newbie, I can probably help by doing any testing 
> you'd like.  I'd be happy to do that.  As indicated before, I have a 
> picolcd 4x20 from mini-box.  Right now it's connected to a miniMyth 
> front end running version 0.21.0-53 (kernel is 2.6.25).
> 
> Thanks again for all your help.  It is very much appreciated.
> 
> Joe Henley
> 

From bsdfan at nurfuerspam.de  Tue Mar  3 20:20:44 2009
From: bsdfan at nurfuerspam.de (Markus Dolze)
Date: Tue, 03 Mar 2009 21:20:44 +0100
Subject: [Lcdproc] Changes to get EA-DOGM163 + four keys working with
 hd44780-lcd2usb driver
In-Reply-To: <A8456570236948138C19EFEC595E0481@subnote1400>
References: <BBC090545EA14A1CB4E61EF56FAA5219@subnote1400><20090221201626.289250@gmx.net><D8B559509C6B4526B97C4F675184332A@Schleppi4000><20090224193947.216800@gmx.net><640A2DDB416645A58B0EC4D12737744D@subnote1400><f4eb766f0902250800x3668a120s15fa2108f6d0a50f@mail.gmail.com><2B7A08BBA8BC484FA8831E5428471578@subnote1400><f4eb766f0902261039p21810db9q209400d28565b40d@mail.gmail.com><49A6E42F.4070805@nurfuerspam.de>	<f4eb766f0902261113k3e7cb874s4b9a4929d2bff206@mail.gmail.com>
	<A8456570236948138C19EFEC595E0481@subnote1400>
Message-ID: <49AD911C.4070308@nurfuerspam.de>

Malte P?ggel wrote:
> Hi,
>
> I have been testing the EA-DOGM for the whole weekend and it runs 
> without any problems.
>
> Now, the project page is also available in a english translation:
> http://www.maltepoeggel.de/index.php?site=sp-lcd&lang=en
>
> and the LCDproc patch is attached to this email.
>
>
> TODO: Create a charset table for ISO 8859-1 to ST7036.
>
> Malte
>
Committed with a slightly changed LCDd.conf description and a link to 
your homepage (as well as one to lcdmodkit.com) to the user's guide 
section on lcd2usb.

Markus

From andy at siliconlandmark.com  Tue Mar  3 20:50:43 2009
From: andy at siliconlandmark.com (Andre Guibert de Bruet)
Date: Tue, 3 Mar 2009 15:50:43 -0500
Subject: [Lcdproc] newbie question
In-Reply-To: <49AD90A0.4050601@kc.rr.com>
References: <49A57C26.4060808@kc.rr.com> <49A58FDA.5060307@nurfuerspam.de>
	<49A6F548.7090902@kc.rr.com> <49AD90A0.4050601@kc.rr.com>
Message-ID: <EB304894-1ADA-4A55-8EFA-4FD5B33F8036@siliconlandmark.com>

On Mar 3, 2009, at 3:18 PM, Joe Henley wrote:

> while the the "off-by-one" issue looks to be fixed (per the notes on  
> Sourceforge), have the other items related to the picolcd also been  
> fixed?


Everything I have reported has. Are there any [other] issues that are  
affecting you?

Cheers,
Andy

/*  Andre Guibert de Bruet  * 436f 6465 2070 6f65 742e 2042 6974 206a */
/*     Managing Partner     * 6f63 6b65 792e 2053 7973 4164 6d69 6e2e */
/*   GSM: +1 734 846 8758   * 2055 4e49 5820 736c 6575 7468 2e00 0000 */
/* WWW: siliconlandmark.com * C/C++, Java, Perl, PHP, SQL, XHTML, XML */

From ethan.dicks at gmail.com  Tue Mar  3 20:56:18 2009
From: ethan.dicks at gmail.com (Ethan Dicks)
Date: Tue, 3 Mar 2009 15:56:18 -0500
Subject: [Lcdproc] newbie question
In-Reply-To: <EB304894-1ADA-4A55-8EFA-4FD5B33F8036@siliconlandmark.com>
References: <49A57C26.4060808@kc.rr.com> <49A58FDA.5060307@nurfuerspam.de>
	<49A6F548.7090902@kc.rr.com> <49AD90A0.4050601@kc.rr.com>
	<EB304894-1ADA-4A55-8EFA-4FD5B33F8036@siliconlandmark.com>
Message-ID: <f4eb766f0903031256k4569da33mdd2041bf64fe754f@mail.gmail.com>

On Tue, Mar 3, 2009 at 3:50 PM, Andre Guibert de Bruet
<andy at siliconlandmark.com> wrote:
> On Mar 3, 2009, at 3:18 PM, Joe Henley wrote:
>
>> while the the "off-by-one" issue looks to be fixed (per the notes on
>> Sourceforge), have the other items related to the picolcd also been fixed?
>
> Everything I have reported has. Are there any [other] issues that are
> affecting you?

Has anyone checked the hbar missing pixel issue lately?  I fixed that
a while back, too, but don't think I see it in the most recent code I
fetched.  It's another off-by-one error in the bit of code that loads
up the custom chars for the hbars.

I can resubmit if that would help.

-ethan

From andy at siliconlandmark.com  Tue Mar  3 21:09:42 2009
From: andy at siliconlandmark.com (Andre Guibert de Bruet)
Date: Tue, 3 Mar 2009 16:09:42 -0500
Subject: [Lcdproc] newbie question
In-Reply-To: <f4eb766f0903031256k4569da33mdd2041bf64fe754f@mail.gmail.com>
References: <49A57C26.4060808@kc.rr.com> <49A58FDA.5060307@nurfuerspam.de>
	<49A6F548.7090902@kc.rr.com> <49AD90A0.4050601@kc.rr.com>
	<EB304894-1ADA-4A55-8EFA-4FD5B33F8036@siliconlandmark.com>
	<f4eb766f0903031256k4569da33mdd2041bf64fe754f@mail.gmail.com>
Message-ID: <696FB426-171F-4161-83CF-1D65DF02BD89@siliconlandmark.com>

On Mar 3, 2009, at 3:56 PM, Ethan Dicks wrote:

> On Tue, Mar 3, 2009 at 3:50 PM, Andre Guibert de Bruet
> <andy at siliconlandmark.com> wrote:
>> On Mar 3, 2009, at 3:18 PM, Joe Henley wrote:
>>
>>> while the the "off-by-one" issue looks to be fixed (per the notes on
>>> Sourceforge), have the other items related to the picolcd also  
>>> been fixed?
>>
>> Everything I have reported has. Are there any [other] issues that are
>> affecting you?
>
> Has anyone checked the hbar missing pixel issue lately?  I fixed that
> a while back, too, but don't think I see it in the most recent code I
> fetched.  It's another off-by-one error in the bit of code that loads
> up the custom chars for the hbars.

I see it in my most recent build (From a couple of days ago). I'll  
look into it tonight.

Cheers,
Andy

/*  Andre Guibert de Bruet  * 436f 6465 2070 6f65 742e 2042 6974 206a */
/*     Managing Partner     * 6f63 6b65 792e 2053 7973 4164 6d69 6e2e */
/*   GSM: +1 734 846 8758   * 2055 4e49 5820 736c 6575 7468 2e00 0000 */
/* WWW: siliconlandmark.com * C/C++, Java, Perl, PHP, SQL, XHTML, XML */



From bsdfan at nurfuerspam.de  Tue Mar  3 22:01:31 2009
From: bsdfan at nurfuerspam.de (Markus Dolze)
Date: Tue, 03 Mar 2009 23:01:31 +0100
Subject: [Lcdproc] Hbar missing pixel [was: newbie question]
In-Reply-To: <f4eb766f0903031256k4569da33mdd2041bf64fe754f@mail.gmail.com>
References: <49A57C26.4060808@kc.rr.com>
	<49A58FDA.5060307@nurfuerspam.de>	<49A6F548.7090902@kc.rr.com>
	<49AD90A0.4050601@kc.rr.com>	<EB304894-1ADA-4A55-8EFA-4FD5B33F8036@siliconlandmark.com>
	<f4eb766f0903031256k4569da33mdd2041bf64fe754f@mail.gmail.com>
Message-ID: <49ADA8BB.6020606@nurfuerspam.de>

Ethan Dicks wrote:
> Has anyone checked the hbar missing pixel issue lately?  I fixed that
> a while back, too, but don't think I see it in the most recent code I
> fetched.  It's another off-by-one error in the bit of code that loads
> up the custom chars for the hbars.
>
>
>   

I fixed that a few days ago for MtxOrb, but I see other drivers using 
the same code.

Would anyone using these drivers:
* CFontz
* CFont633
* CFontzPacket
report if this is a problem as well?

I have already recognized this to be a problem with picolcd.

Markus

From bsdfan at nurfuerspam.de  Tue Mar  3 23:28:06 2009
From: bsdfan at nurfuerspam.de (Markus Dolze)
Date: Wed, 04 Mar 2009 00:28:06 +0100
Subject: [Lcdproc] Hbar missing pixel [was: newbie question]
In-Reply-To: <49ADA8BB.6020606@nurfuerspam.de>
References: <49A57C26.4060808@kc.rr.com>	<49A58FDA.5060307@nurfuerspam.de>	<49A6F548.7090902@kc.rr.com>	<49AD90A0.4050601@kc.rr.com>	<EB304894-1ADA-4A55-8EFA-4FD5B33F8036@siliconlandmark.com>	<f4eb766f0903031256k4569da33mdd2041bf64fe754f@mail.gmail.com>
	<49ADA8BB.6020606@nurfuerspam.de>
Message-ID: <49ADBD06.4010109@nurfuerspam.de>

Markus Dolze wrote:
> Ethan Dicks wrote:
>> Has anyone checked the hbar missing pixel issue lately?  I fixed that
>> a while back, too, but don't think I see it in the most recent code I
>> fetched.  It's another off-by-one error in the bit of code that loads
>> up the custom chars for the hbars.
>>
>>
>>   
>
> I fixed that a few days ago for MtxOrb, but I see other drivers using 
> the same code.

Hm, actually I broke it - somehow. Searching the mailing list archive, 
what we know as "missing hbar line" is on purpose.

Read more about this here 
http://lists.omnipotent.net/pipermail/lcdproc/2006-October/011207.html

>
> Would anyone using these drivers:
> * CFontz
> * CFont633
> * CFontzPacket
> report if this is a problem as well?
>
> I have already recognized this to be a problem with picolcd.
>

You should get a different result if you use "./configure 
--enable-seamless-hbars".

Having the hbar 7 dots high to align with [] characters or 8 dots high 
is probably a matter of personal taste.

But currently you can either have 7 dots high hbar or those where the 
full blocks are 8 and the partial ones 7 dots high.

And more interestingly some drivers use the 7 dots while others use 8 dots.

Regards,
Markus

From ethan.dicks at gmail.com  Wed Mar  4 04:11:42 2009
From: ethan.dicks at gmail.com (Ethan Dicks)
Date: Tue, 3 Mar 2009 23:11:42 -0500
Subject: [Lcdproc] Hbar missing pixel [was: newbie question]
In-Reply-To: <49ADBD06.4010109@nurfuerspam.de>
References: <49A57C26.4060808@kc.rr.com> <49A58FDA.5060307@nurfuerspam.de>
	<49A6F548.7090902@kc.rr.com> <49AD90A0.4050601@kc.rr.com>
	<EB304894-1ADA-4A55-8EFA-4FD5B33F8036@siliconlandmark.com>
	<f4eb766f0903031256k4569da33mdd2041bf64fe754f@mail.gmail.com>
	<49ADA8BB.6020606@nurfuerspam.de> <49ADBD06.4010109@nurfuerspam.de>
Message-ID: <f4eb766f0903032011n7926dd5elff7bfc887d5c3ef5@mail.gmail.com>

On Tue, Mar 3, 2009 at 6:28 PM, Markus Dolze <bsdfan at nurfuerspam.de> wrote:
> Markus Dolze wrote:
>>
>> Ethan Dicks wrote:
>>> Has anyone checked the hbar missing pixel issue lately? ?I fixed that
>>> a while back, too, but don't think I see it in the most recent code I
>>> fetched. ?It's another off-by-one error in the bit of code that loads
>>> up the custom chars for the hbars.
>
> Hm, actually I broke it - somehow. Searching the mailing list archive, what
> we know as "missing hbar line" is on purpose.

I'm not describing a missing line.  The problem I fixed was that the
partial blocks (1 col, 2 cols...) were one pixel shorter than the
solid block char in the ROM font of the picoLCD.  The visual
appearance was like this...


#########
#########
#########
#########
#########
#########
#####

... where all the solid block chars were the same height, but the
last, partial char, was one pixel shorter.

The version of picoLCD.c I'm running at the moment (recently fetched
from CVS HEAD) has that bug.

-ethan

From ethan.dicks at gmail.com  Wed Mar  4 04:18:56 2009
From: ethan.dicks at gmail.com (Ethan Dicks)
Date: Tue, 3 Mar 2009 23:18:56 -0500
Subject: [Lcdproc] Hbar missing pixel [was: newbie question]
In-Reply-To: <f4eb766f0903032011n7926dd5elff7bfc887d5c3ef5@mail.gmail.com>
References: <49A57C26.4060808@kc.rr.com> <49A58FDA.5060307@nurfuerspam.de>
	<49A6F548.7090902@kc.rr.com> <49AD90A0.4050601@kc.rr.com>
	<EB304894-1ADA-4A55-8EFA-4FD5B33F8036@siliconlandmark.com>
	<f4eb766f0903031256k4569da33mdd2041bf64fe754f@mail.gmail.com>
	<49ADA8BB.6020606@nurfuerspam.de> <49ADBD06.4010109@nurfuerspam.de>
	<f4eb766f0903032011n7926dd5elff7bfc887d5c3ef5@mail.gmail.com>
Message-ID: <f4eb766f0903032018l1348c564qd69cc502309ac380@mail.gmail.com>

On Tue, Mar 3, 2009 at 11:11 PM, Ethan Dicks <ethan.dicks at gmail.com> wrote:
> I'm not describing a missing line...
>
> ... where all the solid block chars were the same height, but the
> last, partial char, was one pixel shorter.

Sorry; now I think I get what you meant... I went back and re-read the
older thread.

I was considering it a bug since there were two simultaneous heights
in use on the same hbar.

It really should be either 7 or 8, not 8 _then_ 7.  Mixed heights
_should_ be considered a bug.

For the drivers I've written, I use the entire height of the char
cell.  I guess I never thought it looked strange to use an
8-pixel-tall bar since I don't tend to use the "normal" lcdproc client
that brackets hbars in 7-pixel-tall square brackets.

Sounds like an issue to tack onto future discussions of the next
incarnation of the client-server protocol - allow the clients to
optionally ask for "full height" or "align with the baseline of the
font" hbars.

For now, though, I'd think that at the very least, visual consistency
is an important goal.

-ethan

From bsdfan at nurfuerspam.de  Wed Mar  4 06:26:26 2009
From: bsdfan at nurfuerspam.de (Markus Dolze)
Date: Wed, 04 Mar 2009 07:26:26 +0100
Subject: [Lcdproc] Hbar missing pixel [was: newbie question]
In-Reply-To: <f4eb766f0903032018l1348c564qd69cc502309ac380@mail.gmail.com>
References: <49A57C26.4060808@kc.rr.com>
	<49A58FDA.5060307@nurfuerspam.de>	<49A6F548.7090902@kc.rr.com>
	<49AD90A0.4050601@kc.rr.com>	<EB304894-1ADA-4A55-8EFA-4FD5B33F8036@siliconlandmark.com>	<f4eb766f0903031256k4569da33mdd2041bf64fe754f@mail.gmail.com>	<49ADA8BB.6020606@nurfuerspam.de>
	<49ADBD06.4010109@nurfuerspam.de>	<f4eb766f0903032011n7926dd5elff7bfc887d5c3ef5@mail.gmail.com>
	<f4eb766f0903032018l1348c564qd69cc502309ac380@mail.gmail.com>
Message-ID: <49AE1F12.3040407@nurfuerspam.de>

Ethan Dicks wrote:
> ...
> It really should be either 7 or 8, not 8 _then_ 7.  Mixed heights
> _should_ be considered a bug.
>   

I agree with that.

> ...
>
> Sounds like an issue to tack onto future discussions of the next
> incarnation of the client-server protocol - allow the clients to
> optionally ask for "full height" or "align with the baseline of the
> font" hbars.

I don't agree here. The way things are displayed is controlled by the 
server and there it should stay (the controllable backlight is already 
an exception).

Markus


From ethan.dicks at gmail.com  Wed Mar  4 07:03:39 2009
From: ethan.dicks at gmail.com (Ethan Dicks)
Date: Wed, 4 Mar 2009 02:03:39 -0500
Subject: [Lcdproc] Hbar missing pixel [was: newbie question]
In-Reply-To: <49AE1F12.3040407@nurfuerspam.de>
References: <49A57C26.4060808@kc.rr.com> <49A6F548.7090902@kc.rr.com>
	<49AD90A0.4050601@kc.rr.com>
	<EB304894-1ADA-4A55-8EFA-4FD5B33F8036@siliconlandmark.com>
	<f4eb766f0903031256k4569da33mdd2041bf64fe754f@mail.gmail.com>
	<49ADA8BB.6020606@nurfuerspam.de> <49ADBD06.4010109@nurfuerspam.de>
	<f4eb766f0903032011n7926dd5elff7bfc887d5c3ef5@mail.gmail.com>
	<f4eb766f0903032018l1348c564qd69cc502309ac380@mail.gmail.com>
	<49AE1F12.3040407@nurfuerspam.de>
Message-ID: <f4eb766f0903032303n129c5167i7f6d841bef1eb691@mail.gmail.com>

On Wed, Mar 4, 2009 at 1:26 AM, Markus Dolze <bsdfan at nurfuerspam.de> wrote:
> Ethan Dicks wrote:
>> ...
>> It really should be either 7 or 8, not 8 _then_ 7. ?Mixed heights
>> _should_ be considered a bug.
>
> I agree with that.
>
>> ...
>> Sounds like an issue to tack onto future discussions of the next
>> incarnation of the client-server protocol - allow the clients to
>> optionally ask for "full height" or "align with the baseline of the
>> font" hbars.
>
> I don't agree here. The way things are displayed is controlled by the server
> and there it should stay (the controllable backlight is already an
> exception).

OK.  Fair enough.  Since there's been some issue raised in the 2006
message with LCD module limitations and the three uses of "solid
block", should it be selectable within LCDd.conf?  Since some hardware
will have problems with the 'seven line' hbar and some will not (not
to mention those modules with character cell spacing on the glass vs
those that can do "seamless" bars), it doesn't seem viable to force
drivers into one height versus another.  As a driver
writer/maintainer, if the recommendation is to support both and check
LCDd.conf, I don't see that as too difficult to support, but my own
preference is for full-height bars.

-ethan

From aeriksson2 at fastmail.fm  Wed Mar  4 12:54:30 2009
From: aeriksson2 at fastmail.fm (aeriksson2 at fastmail.fm)
Date: Wed, 04 Mar 2009 13:54:30 +0100
Subject: [Lcdproc] Increasing the server's receive buffer
In-Reply-To: <25BDE767-5ECB-4D11-87E9-4D19CB06CF86@siliconlandmark.com>
References: <49A8F32F.10800@nurfuerspam.de>
	<20090228091028.C44792C407A@tippex.mynet.homeunix.org>
	<0CCDE7FF-6F93-4F7D-A568-505EDF06DF7B@siliconlandmark.com>
	<49AA7D14.9070508@nurfuerspam.de> <49AAEA98.60406@nurfuerspam.de>
	<20090303101729.6F6532C40B7@tippex.mynet.homeunix.org>
	<25BDE767-5ECB-4D11-87E9-4D19CB06CF86@siliconlandmark.com>
Message-ID: <20090304125430.DCDFA2C40C1@tippex.mynet.homeunix.org>


andy at siliconlandmark.com said:

> Though DMA-like systems are used where performance is critical, these   types
> of systems are often inflexible and of limited functionality in   a networked
> environment. Think of it this way: Besides host-specific   zero-copy sockets,
> what use is DMA on a network? TCP allows the source   of the data to be in a
> geographically separate area (It could be in   outer space, literally), or
> not, from the system running LCDd.

We're not talking about the same thing. I'm not concerned with the IP layer 
(e.g. fragmentation/reassembly). I'm just concerned with how the TCP layer is 
used by the LCDd server and lcdproc client. Or, to put it more succint, how 
the LCDd protocol interacts with the tcp layer. Is there a formal writeup 
of the LCDd protocol somewhere? I've only seem some howtos on how once _could_ 
write clients LCDd would understand. That's far from a formal spec and, to be 
frank, what I've seen lacks quite a bit from a protocol quality point of view. 
I'm hoping that there is a better writeup I've not yet discovered.

>> The only answer I can come up with is that you might want "create  
>> screen + define its content" to be an atomic operation.

> This is a good idea, but for the operation to be truly atomic, it   would
> have to fit in exactly one ethernet frame and not cross any   routers where
> it might get fragmented. Otherwise, you stall waiting   for more data until
> you get the expected number of bytes, which is the   design we have,
> presently.

>> Is that defined anywhere? If that's indeed the case, maybe explicit  
>> barriers in the protocol would be more stable.

> I don't follow. 

Today, we roughly do on the tcp pipe (not having the howto handy):
screen s <args>
widget s w1 <args>
widget s w2 <args>
...


There's no telling what the server does after the first two steps. Will it 
display the partially defined screen? A way to turn this into an atomic unit 
would be to wrap it in "start" "stop" statements.

screen_def_start s
screen s <args>
widget s w1 <args>
widget s w2 <args>
...
screen_def_stop s

Only after having received the stop command would the server act on the wrapped 
commands. That would make the atomic units controlle by the client and, do so 
by dint of the application layer protocol (i.e. not relying on aspects of the 
transport (tcp), e.g. the message interface).

But the first order of business is to find a good protocol spec for the 
existing sitaution. Is there one?

/Anders  




From joris at robijn.net  Wed Mar  4 13:35:39 2009
From: joris at robijn.net (joris at robijn.net)
Date: Wed, 4 Mar 2009 14:35:39 +0100 (CET)
Subject: [Lcdproc] Increasing the server's receive buffer
In-Reply-To: <20090304125430.DCDFA2C40C1@tippex.mynet.homeunix.org>
Message-ID: <20090304133539.6543C1C9DB6@wizard.robijn.net>

Hi Anders

> I'm just concerned with how the TCP layer is 
> used by the LCDd server and lcdproc client. 

I think your'e right the handling of incoming data could be done better
on this point. It's simply choking  in a big lump of data that it cannot
handle. Someone wrote about a modification with a second buffer, I think
he's right. It's been a long while since I had a look at that code, I
vaguely remember what it looks like.

> Is there a formal writeup of the LCDd protocol somewhere?

Check the online manual on the documentation page. It's generated from
docbook documentation.

> There's no telling what the server does after the first two steps. Will it 
> display the partially defined screen? A way to turn this into an atomic unit 
> would be to wrap it in "start" "stop" statements.

The protocol was meant to be used by very simple clients as well. If
they do no return checking things should work (a bit).
It was never meant to be atomic. It's just a (too) simple implementation
of handling incoming data.

Regards,
Joris


From aeriksson2 at fastmail.fm  Wed Mar  4 13:59:45 2009
From: aeriksson2 at fastmail.fm (aeriksson2 at fastmail.fm)
Date: Wed, 04 Mar 2009 14:59:45 +0100
Subject: [Lcdproc] Increasing the server's receive buffer
In-Reply-To: <20090304133539.6543C1C9DB6@wizard.robijn.net>
References: <20090304133539.6543C1C9DB6@wizard.robijn.net>
Message-ID: <20090304135945.CE2992C40C1@tippex.mynet.homeunix.org>

http://lcdproc.sourceforge.net/docs/current-dev.html


Hi Joris,

joris at robijn.net said:
> Hi Anders
>
>> I'm just concerned with how the TCP layer is 
>> used by the LCDd server and lcdproc client. 
>
> I think your'e right the handling of incoming data could be done better on
> this point. It's simply choking  in a big lump of data that it cannot handle.
Now, _why_ does it do that? Reading the protocol spec, no command should be 
bigger than one line... Or? Or is the problem that a client passes >8KB lines?


> Someone wrote about a modification with a second buffer, I think he's right.
> It's been a long while since I had a look at that code, I vaguely remember
> what it looks like.

>> Is there a formal writeup of the LCDd protocol somewhere?

> Check the online manual on the documentation page. It's generated from
> docbook documentation.
Is http://lcdproc.sourceforge.net/docs/current-dev.html, chapter 3, the right 
place to look? 

> There's no telling what the server does after the first two steps. Will it 
> display the partially defined screen? A way to turn this into an atomic unit 
> would be to wrap it in "start" "stop" statements.

> The protocol was meant to be used by very simple clients as well. If they do
> no return checking things should work (a bit). It was never meant to be
> atomic. It's just a (too) simple implementation of handling incoming data.

Sure, I can see where it's cominging from, but as it currently stands, it's 
impossible to create a bug free client from it.

Would it be useful if I review and comment ch3 and we'll work out what the 
weaknesses (spec and/or code) are? 

Rgds,
/Anders



From tfangio at fractech.net  Wed Mar  4 17:47:36 2009
From: tfangio at fractech.net (Topher Fangio)
Date: Wed, 4 Mar 2009 11:47:36 -0600
Subject: [Lcdproc] Hbar missing pixel [was: newbie question]
In-Reply-To: <f4eb766f0903032303n129c5167i7f6d841bef1eb691@mail.gmail.com>
References: <49A57C26.4060808@kc.rr.com> <49A6F548.7090902@kc.rr.com>
	<49AD90A0.4050601@kc.rr.com>
	<EB304894-1ADA-4A55-8EFA-4FD5B33F8036@siliconlandmark.com>
	<f4eb766f0903031256k4569da33mdd2041bf64fe754f@mail.gmail.com>
	<49ADA8BB.6020606@nurfuerspam.de> <49ADBD06.4010109@nurfuerspam.de>
	<f4eb766f0903032011n7926dd5elff7bfc887d5c3ef5@mail.gmail.com>
	<f4eb766f0903032018l1348c564qd69cc502309ac380@mail.gmail.com>
	<49AE1F12.3040407@nurfuerspam.de>
	<f4eb766f0903032303n129c5167i7f6d841bef1eb691@mail.gmail.com>
Message-ID: <C82B89A196535D4696C1D1D998233A138714A241@EXCHCLST01.FRACTECH.LOCAL>

It's been a while since I tested LCDProc with the CFontzPacket driver,
but I do remember experiencing what sounds like what you are describing.
I can definitely check it when I get back to my house this evening.

What version would you like me to test against? CVS Head or 0.5.2?

Topher Fangio

-----Original Message-----
From: lcdproc-bounces at lists.omnipotent.net [mailto:lcdproc-bounces at lists.omnipotent.net] On Behalf Of Ethan Dicks
Sent: Wednesday, March 04, 2009 1:04 AM
To: lcdproc at lists.omnipotent.net
Subject: Re: [Lcdproc] Hbar missing pixel [was: newbie question]

On Wed, Mar 4, 2009 at 1:26 AM, Markus Dolze <bsdfan at nurfuerspam.de> wrote:
> Ethan Dicks wrote:
>> ...
>> It really should be either 7 or 8, not 8 _then_ 7.  Mixed heights
>> _should_ be considered a bug.
>
> I agree with that.
>
>> ...
>> Sounds like an issue to tack onto future discussions of the next
>> incarnation of the client-server protocol - allow the clients to
>> optionally ask for "full height" or "align with the baseline of the
>> font" hbars.
>
> I don't agree here. The way things are displayed is controlled by the server
> and there it should stay (the controllable backlight is already an
> exception).

OK.  Fair enough.  Since there's been some issue raised in the 2006
message with LCD module limitations and the three uses of "solid
block", should it be selectable within LCDd.conf?  Since some hardware
will have problems with the 'seven line' hbar and some will not (not
to mention those modules with character cell spacing on the glass vs
those that can do "seamless" bars), it doesn't seem viable to force
drivers into one height versus another.  As a driver
writer/maintainer, if the recommendation is to support both and check
LCDd.conf, I don't see that as too difficult to support, but my own
preference is for full-height bars.

-ethan
_______________________________________________
LCDproc mailing list
LCDproc at lists.omnipotent.net
http://lists.omnipotent.net/mailman/listinfo/lcdproc

No virus found in this incoming message.
Checked by AVG - www.avg.com
Version: 8.0.237 / Virus Database: 270.11.5/1979 - Release Date: 03/03/09 16:09:00

CONFIDENTIALITY NOTICE:  This email message and any attachments hereto are intended only for use by the addressee(s) named herein and may contain information which is legally privileged, confidential and/or exempt from disclosure under applicable law.  If you are not the intended recipient, or an authorized representative of the intended recipient, of this email message, you are hereby notified that any review, dissemination, distribution, copying, or use (including any reliance thereon) of this email message, and/or any attachment hereto, is strictly prohibited.

Although this transmission and any attachments are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is free from virus or other defect and no responsibility is accepted by the sending company, its subsidiaries and affiliates, as applicable, for any loss or damage arising in any way from its use.

If you have received this email message in error, please immediately notify the sender by return email and permanently delete from your system, the original and any copies of this email and any attachments hereto and any printout hereof.  Unauthorized interception of this email is a violation of federal criminal law.

From joehenley at kc.rr.com  Wed Mar  4 20:22:20 2009
From: joehenley at kc.rr.com (Joe Henley)
Date: Wed, 04 Mar 2009 14:22:20 -0600
Subject: [Lcdproc] newbie question
In-Reply-To: <49AD90A0.4050601@kc.rr.com>
References: <49A57C26.4060808@kc.rr.com> <49A58FDA.5060307@nurfuerspam.de>
	<49A6F548.7090902@kc.rr.com> <49AD90A0.4050601@kc.rr.com>
Message-ID: <49AEE2FC.7080007@kc.rr.com>

Hi all (Markus, Andy, Ethan, et al),

Thanks to all of you for your help.  While I'm still very much a newbie, 
I'm beginning to make some progress.

I dug thru the archives back thru last October and matched picolcd 
related messages here to updates to the picolcd driver for proclcd on 
the sourceforge page.  I'm impressed you folks can do this on a regular 
basis.  I also looked at the various file versions around.

I found only two possible issues:
-- Message on 2/25/09 "PicoLCD 20X4" from Cunniffe; the second item 
related to keypresses getting "missed".  I didn't see anything about it 
in the sourceforge updates.
-- I ran a diff on two versions of picolcd.c files:  the CVS current 
("nightly" file of 3/3/09) versus the mini-box.com source file.  While 
most of the differences are only comments in the files, and the next 
largest "group" looks to be updates since Oct 3, 08, there are still a 
pretty sizable number of differences.  (Please remember that I am NOT a 
C programmer; so these differences may mean nothing.)  But it would 
probably help if someone familiar with C could do a quick diff on those 
files to see if some of the changes from mini-box would be useful here.

I also dug into which problems I was having the most trouble with.  I 
think the second biggest problem (newbie being the first biggest) was 
getting a mix of four various versions of lcdproc/picolcd drivers on my 
machine.  I found I had a mix of the lcdproc which comes with 
mini-MythTV, the 0.5.2 version from the lcdproc site, the 0.5.2 version 
from the mini-box.com site, and the December 27 CVS version from the 
LCDproc site.  None of those are the same!  While it's very confusing 
for a newbie like me, I suspect it's typical of open source code.  "Just 
part of the fun" as they say.  ;-)

I don't know where Nicu Pavel is lately.  I haven't gotten any responses 
back from him on questions about the mini-box version in awhile.  But it 
seems to me that he would be the logical one to look thru the two 
different files (mini-box.com version and LCDproc CVS version), to cull 
out changes/additions to them.  Maybe he could make them the same.

Thanks again for all your help.  I'm making some progress on getting my 
picolcd to work with mini-MythTV and I'm learning alot along the way.

Joe Henley

> Hi Markus,
> I was very encouraged after your initial reply.  Hopefully you'll have 
> some time to reply to these follow-up questions.
> Also, while the the "off-by-one" issue looks to be fixed (per the notes 
> on Sourceforge), have the other items related to the picolcd also been 
> fixed?
> Thanks again for your help.
> Joe Henley
> Joe Henley wrote:
>> Hi Markus,
>> Thanks very much for your reply.
>> Markus Dolze wrote:
>>> Joe Henley wrote:
>>>> Hi,
>>>> I'm a newbie here, so please forgive any un-intended "politically 
>>>> incorrect" items.  Also, I'm not a C programmer, so I'm pretty much 
>>>> dependent upon what I can find at sites like this.
>>>> Is lcdproc still under development?  The last version is from 2007.  
>>>> I see lots and lots of patches; and I see comments about folks not 
>>>> getting things to run when patches overlap.  I see alot of notes 
>>>> about getting patches incorporated, but it seems none do.  I've 
>>>> looked repeatedly at the sourceforge site for updates to the code, 
>>>> but patches I see here don't seem to show up there.
>>> Yes, there is ongoing development. Unlike other projects we use this 
>>> mailing list to submit patches for review. Someone with write access 
>>> commits the patches once they have received feedback.
>> Ah, OK.  As I confessed earlier, I'm a newbie .... does "commit" mean 
>> to incorporate it into the nightly updates?
>>> The changelog since 0.5.2 has grown large. Usually you receive the 
>>> latest code directly from CVS or by using a 'nightly current build' 
>>> from http://lcdproc.sourceforge.net/nightly/.
>> Is that OK now?  I saw a message in the archives that the nightlies 
>> weren't always current.  Since I don't yet know enough about this to 
>> be able to tell when it is, or when it isn't current, I just decided 
>> to avoid them.  Probably the wrong thing to do, huh? ....
>>> Currently our most important maintainer is away, so changes pile up, 
>>> but I commited a few fixes recently.
>>>> I bought a picolcd to use with MythTV and have given up on getting 
>>>> support from mini-box.  I hoped to get some here, so I've lurked 
>>>> abit to see what's happening.  But I must be missing something, 
>>>> because I see alot of folks submitting patches, raising questions 
>>>> and suggesting fixes, but nothing seems to be done to the code.
>>>> What am I missing?  Is there some other place to look (other than 
>>>> here and the sourceforge site)?
>>> As LCDproc is open source anyone can take it and ship modified 
>>> versions. Some Linux distributions may contain additional patches.
>> Yes, that's part of the problem I'm having with mini-box.  They have a 
>> version on their site which they reference as 0.5.2, but which is NOT 
>> the same as what you have here.  It's abit confusing, and very 
>> frustrating, for someone just getting started (like me).
>>>> Thanks for any help/suggestions/guidance/etc.
>>>> Joe Henley
>>>> PS:  Yes, I know I have not indicated my picolcd problems.  But they 
>>>> are  all previously listed here by others, and are still open as far 
>>>> as I can tell.
>>> If you do need help, as on this list. There are people familiar with 
>>> these devices here.
>> Thanks for the offer.  I looked back thru the last 4 or 5 months of 
>> posts in the archives and picked out the problems/patches others had 
>> identified which also looked like ones I'm having.  These include:
>> 10/1/08  pavel      "add support"
>> 11/2/08  marschall  "picolcd build problems"
>> 11/6/08  ekholm     "LCDproc & PicoLCD"
>> 1/13/09  dicks      "19 to 20 character"
>> 2/2/09   de Bruet   "off by one"
>> 2/25/09  de Bruet   various
>> Again, it's a newbie picking these out, so I might be wrong on some.
>> So if these were fixed (I assume that means "committed") then I should 
>> be able to move forward on getting my picolcd 4x20 to work.
>>> Regards,
>>> Markus
>> Oh, while I may be a newbie, I can probably help by doing any testing 
>> you'd like.  I'd be happy to do that.  As indicated before, I have a 
>> picolcd 4x20 from mini-box.  Right now it's connected to a miniMyth 
>> front end running version 0.21.0-53 (kernel is 2.6.25).
>> Thanks again for all your help.  It is very much appreciated.
>> Joe Henley


From vdr at helmutauer.de  Thu Mar  5 12:35:36 2009
From: vdr at helmutauer.de (vdr at helmutauer.de)
Date: Thu,  5 Mar 2009 13:35:36 +0100 (CET)
Subject: [Lcdproc] New Driver - howto submit
Message-ID: <20090305123536.58DB618154971@dd16712.kasserver.com>

Hello List,
I've written a simple driver for the 2x20 Display of a fujitsu siemens activy media center.
What's to do to push it into the lcdproc tree ?
I've attached the patch ...

-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0.5.2-lcd_activy.patch
Type: text/x-patch
Size: 21718 bytes
Desc: not available
URL: <http://lists.omnipotent.net/pipermail/lcdproc/attachments/20090305/b645f1a5/attachment-0001.bin>

From bsdfan at nurfuerspam.de  Thu Mar  5 16:16:35 2009
From: bsdfan at nurfuerspam.de (Markus Dolze)
Date: Thu, 05 Mar 2009 17:16:35 +0100
Subject: [Lcdproc] Hbar missing pixel [was: newbie question]
In-Reply-To: <f4eb766f0903032018l1348c564qd69cc502309ac380@mail.gmail.com>
References: <49A57C26.4060808@kc.rr.com>
	<49A58FDA.5060307@nurfuerspam.de>	<49A6F548.7090902@kc.rr.com>
	<49AD90A0.4050601@kc.rr.com>	<EB304894-1ADA-4A55-8EFA-4FD5B33F8036@siliconlandmark.com>	<f4eb766f0903031256k4569da33mdd2041bf64fe754f@mail.gmail.com>	<49ADA8BB.6020606@nurfuerspam.de>
	<49ADBD06.4010109@nurfuerspam.de>	<f4eb766f0903032011n7926dd5elff7bfc887d5c3ef5@mail.gmail.com>
	<f4eb766f0903032018l1348c564qd69cc502309ac380@mail.gmail.com>
Message-ID: <49AFFAE3.90305@nurfuerspam.de>

Ethan Dicks wrote:
> It really should be either 7 or 8, not 8 _then_ 7.  Mixed heights
> _should_ be considered a bug.
>
>
>   

Nearly all character displays supported implement bars using custom
characters. Only a few use hardware dependent functions to draw bars.
For all those using custom charcters and lib_hbar_static() this sounds
like a good reason to make use of the currently unused 'option' parameter.

The 'option' parameter is set by the server core in render_hbar() and
passed through the driver which can modify it.

Call graph:
render_screen() => render_frame() => render_hbar() => drivers_hbar() =>
drv->hbar() => lib_vbar_static()

The decision if a full height hbar is to be used could be a server
option instead of a compile time switch.

Regards
Markus


From sascha.zielinski at gmx.de  Sat Mar  7 07:01:34 2009
From: sascha.zielinski at gmx.de (Sascha)
Date: Sat, 7 Mar 2009 08:01:34 +0100
Subject: [Lcdproc] lcdproc doesn't switch off my backlight
Message-ID: <200903070801.34452.sascha.zielinski@gmx.de>

Hi,

I set up my lcdproc.conf with these values:

[Load]
Active=true
LowLoad=1.00
HighLoad=5.00

I started lcdproc while my load was under 1 and my Backlight was off. Then I 
started several burnMMX processes and watched my load.
Right after the load goes > 5 the Backlight was starting blinking, I killed 
all burnMMX's and after the load was under 5 my backlight stays on.
After a while all Load values were below 1.0 again and my backlight doesn't 
switch off.

Does lcdpoc use all 3 Load values to check wether to turn the backlight on or 
off? Do the values have to stay at a specific time under the LowLoad?

Regards,
Sascha



From bsdfan at nurfuerspam.de  Sun Mar  8 14:01:31 2009
From: bsdfan at nurfuerspam.de (Markus Dolze)
Date: Sun, 08 Mar 2009 15:01:31 +0100
Subject: [Lcdproc] Patch: MtxOrb adjustable backlight and display detection
Message-ID: <20090308140131.9870@gmx.net>

Hi,

I added a switch to LCDd.conf to turn off the adjustable backlight (which is on by default). If the adjustable backlight is turn off, the driver uses the old way to switch the backlight on or off.

The switch is necessary because there are still some old MtxOrb displays floating around which do not feature an adjustable backlight but also cannot be identified by the driver. Therefore the user has to set this in the config file.

I also reworked the display detection mechanism. Right now it is still part of MtxOrb_get_info, but in the near time it should be split into a separate function called as soon as the connection has been set up.

By putting the diplays model->name information in a global table and adding a 'flags' field to it, we may put our knowledge about displays into that table, e.g. the diplay type, if it has an adjustable backlight, if it supports keys, etc. Right now the flags are still unused.

Please give it a try.

Markus
-------------- next part --------------
A non-text attachment was scrubbed...
Name: MtxOrb-adjbacklight.patch
Type: application/octet-stream
Size: 14057 bytes
Desc: not available
URL: <http://lists.omnipotent.net/pipermail/lcdproc/attachments/20090308/51846b04/attachment.obj>

From bsdfan at nurfuerspam.de  Sun Mar  8 14:18:34 2009
From: bsdfan at nurfuerspam.de (Markus Dolze)
Date: Sun, 08 Mar 2009 15:18:34 +0100
Subject: [Lcdproc] How to retire drivers?
Message-ID: <20090308141834.112800@gmx.net>

Hi,

I would like to add a feature to LCDd to mark drivers as 'deprecated'. We currently have 45+ drivers (not counting sub-drivers and connection types). Some of them are unmaintained, the hardware is not sold anymore or noone is using them (which I just claim - we don't know for sure).

By having this feature we could say "Warning: You are using a driver marked deprecated. It may disappear in the next release".

I thought about how to implement this and figured out two ways:

1. Extend the driver API with an optional function.
2. To use the driver's init()'s return value.

1. We could extend the drivers API to include a function like 'isDeprecated()'. The server would call all drivers upon startup to see if this functions is there and if yes check for a return value. This however would require an API change which will probably not happen soon.

2. The same result could be achieved by modifing the driver's init return values. Recent drivers return '-1' on error and '0' on success. Older drivers (and perhaps those not reviewed by Peter) still return '1' on success.

By setting all drivers to return '0' on init success we could use '1' to signal the driver is deprecated and have the server issue a warning.


Please note what I do not want to force users to buy new hardware by removing a driver. But we do have a lot of drivers and simply don't know if someone is still using them. Even if we call for testers feedback is usually scarce.

So my hope is that users crossing such a warning will report in and complain.

Your thought's?

Markus

From bsdfan at nurfuerspam.de  Sun Mar  8 16:04:22 2009
From: bsdfan at nurfuerspam.de (Markus Dolze)
Date: Sun, 08 Mar 2009 17:04:22 +0100
Subject: [Lcdproc] Patch: Watchdog timer for Crystalfontz Packet
Message-ID: <20090308160422.175630@gmx.net>

Hi,

is anyone interested in having this function?

http://sourceforge.net/tracker2/?func=detail&aid=1989956&group_id=119&atid=300119

If I receive decline or no response within the next 14 days, I will reject that patch, because:

a) The driver directly calls server core functions. I think this should not happen.

b) The patch is potentially dangerous: The driver has no way to request or enforce the heartbeat, instead the heartbeat depends on server, client and screen heartbeat settings. The server would have to be set to enforce the Heartbeat=on, otherwise any client could disable the heartbeat (unintentially) resulting in a system powerdown if the watchdog timeout is less than the screen duration.

To fix a) an API change would be necessary so the heartbeat function does have a return value. The core could then take additional action on depending on the return value much like drivers_icon().

Markus

From ethan.dicks at gmail.com  Sun Mar  8 21:46:20 2009
From: ethan.dicks at gmail.com (Ethan Dicks)
Date: Sun, 8 Mar 2009 16:46:20 -0500
Subject: [Lcdproc] How to retire drivers?
In-Reply-To: <20090308141834.112800@gmx.net>
References: <20090308141834.112800@gmx.net>
Message-ID: <f4eb766f0903081446x6ded744co9ecb18c8e0f73f1c@mail.gmail.com>

On Sun, Mar 8, 2009 at 9:18 AM, Markus Dolze <bsdfan at nurfuerspam.de> wrote:
> Hi,
>
> I would like to add a feature to LCDd to mark drivers as 'deprecated'. We currently have 45+ drivers (not counting sub-drivers and connection types). Some of them are unmaintained, the hardware is not sold anymore or noone is using them (which I just claim - we don't know for sure)...

We do have a lot of drivers, that's certain, and it does make for a
lot of work to make fundamental underlying changes to LCDd.

If you are proposing to mark drivers deprecated in 0.5.x for possible
exclusion in 0.6, I can see how that could be reasonable.  Obviously
anyone who's participating on the list can speak up for any hardware
they presently own and can test.  I have a few back-burner display
projects I'd like to get assembled, all parallel-port-interfaced, most
graphical.  This might help push me to get some of them finished.

So... I'm not opposed to the idea, as long as we have a reasonable
horizon for actually retiring the drivers, not just issuing warnings.

-ethan

From w_smith at compusmiths.com  Sun Mar  8 22:08:12 2009
From: w_smith at compusmiths.com (William P.N. Smith)
Date: Sun, 08 Mar 2009 18:08:12 -0400
Subject: [Lcdproc] How to retire drivers?
In-Reply-To: <f4eb766f0903081446x6ded744co9ecb18c8e0f73f1c@mail.gmail.com>
References: <20090308141834.112800@gmx.net>
	<f4eb766f0903081446x6ded744co9ecb18c8e0f73f1c@mail.gmail.com>
Message-ID: <49B441CC.1020908@compusmiths.com>

Ethan Dicks wrote:
>Markus Dolze <bsdfan at nurfuerspam.de> wrote:

>> I would like to add a feature to LCDd to mark drivers as 'deprecated'. We currently have 45+ drivers (not counting sub-drivers and connection types). Some of them are unmaintained, the hardware is not sold anymore or noone is using them (which I just claim - we don't know for sure)...

> So... I'm not opposed to the idea, as long as we have a reasonable
> horizon for actually retiring the drivers, not just issuing warnings.

How/where would this warning be displayed?  On the LCD during startup? 
Notified back to the client, which hopefully would do "the right thing" 
with it, whatever that was?

I suspect that many folks even if they see the 'warning' will ignore it 
until it's broken in the next release, at which point there will be an 
uproar until either the 'missing' drivers are patched in or another 
5.2.x is released with the features of 6 and the drivers of 5...

Would it be possible to only compile the "most popular" (yeah, I know, 
how do you decide?) drivers into the 6.0 release, but allow people who 
want older drivers to turn them back on with a compile-time switch? 
Yes, those people would have to build from sources or use an older 
version, but it's better than have the drivers disappear "without 
warning", which is what you are going to have no matter _how_ you try to 
warn them...


From bsdfan at nurfuerspam.de  Sun Mar  8 22:30:15 2009
From: bsdfan at nurfuerspam.de (Markus Dolze)
Date: Sun, 08 Mar 2009 23:30:15 +0100
Subject: [Lcdproc] How to retire drivers?
In-Reply-To: <49B441CC.1020908@compusmiths.com>
References: <20090308141834.112800@gmx.net>	<f4eb766f0903081446x6ded744co9ecb18c8e0f73f1c@mail.gmail.com>
	<49B441CC.1020908@compusmiths.com>
Message-ID: <49B446F7.7070802@nurfuerspam.de>

William P.N. Smith wrote:
> Ethan Dicks wrote:
>> Markus Dolze <bsdfan at nurfuerspam.de> wrote:
> 
>>> I would like to add a feature to LCDd to mark drivers as 
>>> 'deprecated'. We currently have 45+ drivers (not counting sub-drivers 
>>> and connection types). Some of them are unmaintained, the hardware is 
>>> not sold anymore or noone is using them (which I just claim - we 
>>> don't know for sure)...
> 
>> So... I'm not opposed to the idea, as long as we have a reasonable
>> horizon for actually retiring the drivers, not just issuing warnings.

My idea was to 'be prepared'. If we ever make a release and want to 
notify users of upcoming removal, there has to be at least one release 
before which contains the possibility to issue such warnings. So why not 
include that change now?

> 
> How/where would this warning be displayed?  On the LCD during startup? 
> Notified back to the client, which hopefully would do "the right thing" 
> with it, whatever that was?

Perhaps not, because the client talks to LCDd without the need to know 
the output device. I thought of issuing a warning through the LCDd 
report functions. Putting it on the startup screen is an additional idea.

> 
> I suspect that many folks even if they see the 'warning' will ignore it 
> until it's broken in the next release, at which point there will be an 
> uproar until either the 'missing' drivers are patched in or another 
> 5.2.x is released with the features of 6 and the drivers of 5...

As happened recently with the usblcd driver.

I could imagine a step-by-step phase out. For example, if we really want 
people to take note of old drivers, LCDd could issue a warning in one 
release. Then exit in the next one but allows operating again by setting 
a 'yes, really use old drivers' switch in the config file and in the 
next release exclude the driver.

> 
> Would it be possible to only compile the "most popular" (yeah, I know, 
> how do you decide?) drivers into the 6.0 release, but allow people who 
> want older drivers to turn them back on with a compile-time switch? Yes, 
> those people would have to build from sources or use an older version, 
> but it's better than have the drivers disappear "without warning", which 
> is what you are going to have no matter _how_ you try to warn them...
> 

The problem is less compiling an existing driver or not but the need to 
maintain the existing code. I have no problem compiling 'all' drivers 
even if I don't use them, but making API changes will perhaps be a 
challenge.

E.g. on FreeBSD, I have switched the port/package from compiling all 
drivers to only those not requiring kernel modules not available on that 
platform.

Markus

From bsdfan at nurfuerspam.de  Sun Mar  8 23:04:19 2009
From: bsdfan at nurfuerspam.de (Markus Dolze)
Date: Mon, 09 Mar 2009 00:04:19 +0100
Subject: [Lcdproc] Increasing the server's receive buffer
In-Reply-To: <20090304135945.CE2992C40C1@tippex.mynet.homeunix.org>
References: <20090304133539.6543C1C9DB6@wizard.robijn.net>
	<20090304135945.CE2992C40C1@tippex.mynet.homeunix.org>
Message-ID: <49B44EF3.1030704@nurfuerspam.de>

aeriksson2 at fastmail.fm wrote:
> http://lcdproc.sourceforge.net/docs/current-dev.html
> 
> 
> Hi Joris,
> 
> joris at robijn.net said:
>> Hi Anders
>>
>>> I'm just concerned with how the TCP layer is 
>>> used by the LCDd server and lcdproc client. 
>> I think your'e right the handling of incoming data could be done better on
>> this point. It's simply choking  in a big lump of data that it cannot handle.
> Now, _why_ does it do that? Reading the protocol spec, no command should be 
> bigger than one line... Or? Or is the problem that a client passes >8KB lines?
> 
> 
>> Someone wrote about a modification with a second buffer, I think he's right.
>> It's been a long while since I had a look at that code, I vaguely remember
>> what it looks like.
> 
>>> Is there a formal writeup of the LCDd protocol somewhere?
> 
>> Check the online manual on the documentation page. It's generated from
>> docbook documentation.
> Is http://lcdproc.sourceforge.net/docs/current-dev.html, chapter 3, the right 
> place to look? 
> 
>> There's no telling what the server does after the first two steps. Will it 
>> display the partially defined screen? A way to turn this into an atomic unit 
>> would be to wrap it in "start" "stop" statements.
> 
>> The protocol was meant to be used by very simple clients as well. If they do
>> no return checking things should work (a bit). It was never meant to be
>> atomic. It's just a (too) simple implementation of handling incoming data.
> 
> Sure, I can see where it's cominging from, but as it currently stands, it's 
> impossible to create a bug free client from it.
> 
> Would it be useful if I review and comment ch3 and we'll work out what the 
> weaknesses (spec and/or code) are? 
> 
> Rgds,
> /Anders
> 

Hi,

the discussion moved to a topic I have neither foreseen nor intended 
when I started this thread.

I was looking for a short-term solution for LCDd's input buffering 
deficiency for which I posted possible solutions on 2009-03-01 and still 
appreciate feedback very much.

Thank you,
Markus

From bsdfan at nurfuerspam.de  Sun Mar  8 23:18:03 2009
From: bsdfan at nurfuerspam.de (Markus Dolze)
Date: Mon, 09 Mar 2009 00:18:03 +0100
Subject: [Lcdproc] New Driver - howto submit
In-Reply-To: <20090305123536.58DB618154971@dd16712.kasserver.com>
References: <20090305123536.58DB618154971@dd16712.kasserver.com>
Message-ID: <49B4522B.80808@nurfuerspam.de>

vdr at helmutauer.de wrote:
> Hello List,
> I've written a simple driver for the 2x20 Display of a fujitsu siemens activy media center.
> What's to do to push it into the lcdproc tree ?
> I've attached the patch ...
>
>   
Hello Helmut,

you hit the right place. This mailing list is where we dicuss the 
LCDproc software and post changes to.

To get your driver into the tree, someone with write access to the 
source code repository has to commit it. There will usually be a review 
before that and maybe others will try it out.

Don't be disappointed if this may take some time (weeks).

I had a quick look at your driver and identified some things I would 
like to comment on. I will write up a list of comments or comment your 
code directly and send it back to the list. Stay tuned.

Regards
Markus

PS: I just guessed the name 'Helmut' from you domain and whois data as 
it is likely not 'vdr'. Correct me if I am wrong.


From stewartputnam at comcast.net  Sun Mar  8 23:41:41 2009
From: stewartputnam at comcast.net (stewartputnam at comcast.net)
Date: Sun, 8 Mar 2009 23:41:41 +0000 (UTC)
Subject: [Lcdproc] Patch: Watchdog timer for Crystalfontz Packet
In-Reply-To: <63013948.827141236553549584.JavaMail.root@sz0098a.emeryville.ca.mail.comcast.net>
Message-ID: <1330271020.837851236555701833.JavaMail.root@sz0098a.emeryville.ca.mail.comcast.net>

I've never used the watchdog / reboot functionality. Is the link you mentioned the same patch offered on the CrystalFontz forums third party software page? ( http://www.crystalfontz.com/forum/showthread.php?t=5853 ) 

Lcdproc seems to me to on the whole welcome advanced do-it-yourself port / controller / lcd work to the degree that the option to wire a suitable CrystalFontz product should not be categorically ruled out. 

A quick glance at the patch tells me that your reservations are on the mark. I think it is kind of funny that with this patch you might wind up with just the right lcdproc & client setup & machine activity: altering heartbeat behavior to unintentionally / sopradically / randomly / unpredictably reboot your machine every million seconds or so. 

To support this feature under lcdproc is problematic. The LCDd core is not designed to have to check for a driver that needs to send a particular packet every so often to avoid rebooting. Replacing drivers_heartbeat with a CFontzPacket_heartbeat that routinely sends the "no-no-don't reboot" packet is one way of getting around this, and I imagine works well enough as long as the LCDd core is routinely sending heartbeats to the module wired to the power button -- but while statistacally / probabalistically functional, maybe proven so gives a particluar install, it is not __gauranteed__. My first attempt at fan management was similarly statistacal / probabalistic by inserting itself in the recurring test_packet() of CFontz633io.c. 

And that is only on the sending side of the equation: without tracking a particular packet for receipt / acknowledgement ( could be done similarly to keypress acknowledgement ) how can one be sure that a particular "no-no-don't reboot" packet wasn't dropped? 

It is similar to fan management in terms of consequences: fan packet failure -> computer overheating ; watchdog packet failure -> unwanted reboots ( which at least <hoot hoot hoot> should't melt your cpu.) Gaurantee it well or pin a lot of WARNING & explanation on it and offer it, duly tagged, on the side? Put the patch in contrib with cautions & testimonials? 

Stewart 

P.S. 
I'm thinking of this today because I'm trying out my fan / temp driver on 64 bit debian Lenny ... 
this table will look mal-aligned, but compare the "98.3%id" to the reported CPU use of my :( "gauranteed" :( fan / temp / datalogging pthreads under top today: 

top - 10:13:03 up 1:46, 6 users, load average: 0.05, 0.04, 0.00 
Tasks: 7 total, 0 running, 7 sleeping, 0 stopped, 0 zombie 
Cpu(s): 1.4%us, 0.3%sy, 0.0%ni, 98.3%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st 
Mem: 2063316k total, 436268k used, 1627048k free, 632k buffers 
Swap: 3068372k total, 0k used, 3068372k free, 210716k cached 
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 
4629 nobody 20 0 56324 1524 1092 S 99.9 0.1 0:00.86 LCDd 
4632 nobody 20 0 56324 1524 1092 S 8.2 0.1 0:00.26 LCDd 
3011 root 20 0 372m 34m 7500 S 2.5 1.7 1:16.01 Xorg 
3351 root 20 0 225m 21m 10m S 0.6 1.1 0:18.84 gnome-terminal 
4631 nobody 20 0 56324 1524 1092 S 0.0 0.1 0:00.00 LCDd 
4633 nobody 20 0 56324 1524 1092 S 0.0 0.1 0:00.00 LCDd 
3361 root 20 0 225m 21m 10m S 0.0 1.1 0:00.00 gnome-terminal 






----- Original Message ----- 
From: "Markus Dolze" <bsdfan at nurfuerspam.de> 
To: lcdproc at lists.omnipotent.net 
Sent: Sunday, March 8, 2009 9:04:22 AM GMT -08:00 US/Canada Pacific 
Subject: [Lcdproc] Patch: Watchdog timer for Crystalfontz Packet 

Hi, 

is anyone interested in having this function? 

http://sourceforge.net/tracker2/?func=detail&aid=1989956&group_id=119&atid=300119 

If I receive decline or no response within the next 14 days, I will reject that patch, because: 

a) The driver directly calls server core functions. I think this should not happen. 

b) The patch is potentially dangerous: The driver has no way to request or enforce the heartbeat, instead the heartbeat depends on server, client and screen heartbeat settings. The server would have to be set to enforce the Heartbeat=on, otherwise any client could disable the heartbeat (unintentially) resulting in a system powerdown if the watchdog timeout is less than the screen duration. 

To fix a) an API change would be necessary so the heartbeat function does have a return value. The core could then take additional action on depending on the return value much like drivers_icon(). 

Markus 
_______________________________________________ 
LCDproc mailing list 
LCDproc at lists.omnipotent.net 
http://lists.omnipotent.net/mailman/listinfo/lcdproc 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omnipotent.net/pipermail/lcdproc/attachments/20090308/2da20dc2/attachment-0001.htm>

From vdr at helmutauer.de  Sun Mar  8 23:43:41 2009
From: vdr at helmutauer.de (Helmut Auer)
Date: Mon, 09 Mar 2009 00:43:41 +0100
Subject: [Lcdproc] New Driver - howto submit
In-Reply-To: <49B4522B.80808@nurfuerspam.de>
References: <20090305123536.58DB618154971@dd16712.kasserver.com>
	<49B4522B.80808@nurfuerspam.de>
Message-ID: <49B4582D.2010706@helmutauer.de>

Hi Markus
> 
> you hit the right place. This mailing list is where we dicuss the 
> LCDproc software and post changes to.
> 
> To get your driver into the tree, someone with write access to the 
> source code repository has to commit it. There will usually be a review 
> before that and maybe others will try it out.
> 
> Don't be disappointed if this may take some time (weeks).
> 
No problem - the driver is running in my own distrie :)

> I had a quick look at your driver and identified some things I would 
> like to comment on. I will write up a list of comments or comment your 
> code directly and send it back to the list. Stay tuned.
> 
> Regards
> Markus
> 
> PS: I just guessed the name 'Helmut' from you domain and whois data as 
> it is likely not 'vdr'. Correct me if I am wrong.
> 
Sure - sorry I forgot that I was using the webmailer, which is missing the signature :)


-- 
Helmut Auer, helmut at helmutauer.de

From joris at robijn.net  Sun Mar  8 23:46:54 2009
From: joris at robijn.net (Joris Robijn)
Date: Mon, 09 Mar 2009 00:46:54 +0100
Subject: [Lcdproc] Patch: Watchdog timer for Crystalfontz Packet
In-Reply-To: <1330271020.837851236555701833.JavaMail.root@sz0098a.emeryville.ca.mail.comcast.net>
References: <63013948.827141236553549584.JavaMail.root@sz0098a.emeryville.ca.mail.comcast.net>,
	<1330271020.837851236555701833.JavaMail.root@sz0098a.emeryville.ca.mail.comcast.net>
Message-ID: <49B466FE.16166.151DAC8@joris.robijn.net>

On 8 Mar 2009 at 23:41, stewartputnam at comcast.net wrote:

> To support this feature under lcdproc is problematic. The LCDd core is not
> designed to have to check for a driver that needs to send a particular
> packet every so often to avoid rebooting. Replacing drivers_heartbeat with
> a CFontzPacket_heartbeat that routinely sends the "no-no-don't reboot"
> packet is one way of getting around this, and I imagine works well enough

Hi Stewart,

Reading your reply, it appears to me this is a feature of the CF display. 
Not the core, but the driver should in that case fascilitate it. The core 
calls the driver's flush 8 times per second, so there is plenty of 
opportunity to send a byte to the display.

Regards,
Joris


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



From stewartputnam at comcast.net  Mon Mar  9 02:27:37 2009
From: stewartputnam at comcast.net (stewartputnam at comcast.net)
Date: Mon, 9 Mar 2009 02:27:37 +0000 (UTC)
Subject: [Lcdproc] LCDd daemon hangs with USB Crystalfontz 634 LCD
In-Reply-To: <49B449DE.4000602@nurfuerspam.de>
Message-ID: <337275825.898941236565657092.JavaMail.root@sz0098a.emeryville.ca.mail.comcast.net>

Error in the nested quotes there I think; not my message. 
That bit was from <Jeff>junk_inbox at verizon.net on 2/10/09 in reply to my suggestions. 
I do not have a 634. I can, however, replicate the same behavior by running the CFontz driver on /dev/null as I recall ;) 

----- Original Message ----- 
From: "Markus Dolze" <bsdfan at nurfuerspam.de> 
To: stewartputnam at comcast.net 
Sent: Sunday, March 8, 2009 3:42:38 PM GMT -08:00 US/Canada Pacific 
Subject: Re: [Lcdproc] LCDd daemon hangs with USB Crystalfontz 634 LCD 

stewartputnam at comcast.net wrote: 
> 
> Indeed, I do still need to follow-up on Marcus' request for additional 
> info - I have not yet had the time to do this as of yet. I hope to be 
> able to do that in the next couple of days. 
> 
> 

Hi Stewart, 

did you found any time to test this? 

Regards 
Markus 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omnipotent.net/pipermail/lcdproc/attachments/20090309/037c3496/attachment.htm>

From duke.lists at gmx.com  Mon Mar  9 06:19:16 2009
From: duke.lists at gmx.com (Duke)
Date: Mon, 09 Mar 2009 02:19:16 -0400
Subject: [Lcdproc] HaveFans in VL-system MPlay with HD44780 driver
Message-ID: <49B4B4E4.6000507@gmx.com>

Hi all,

Please be easy on me, I am just new to the list and also have zero 
knowledge about LCDproc. I found LCDproc when trying to enable the LCD 
on my VL-System Mplay in Ubuntu Intrepid. Everything seems to be fine 
with HD44780 driver, except the fan part. I have no idea how to enable 
the fan controllers. In LCDd.conf, it says:

# Does the display have a fan controller?
#HaveFans=n

I understand "n" as "no", then tried to add HaveFans=y, or HaveFans=yes, 
but it still does not work. The LCD is enabled but the fans do not 
rotate (I set the FanOn=20 and FanOff=1 in C scale, then they should 
run, right?). I also tried HaveFans=1 but still no luck.

Anybody helps please!

Thanks,

D.

From bsdfan at nurfuerspam.de  Mon Mar  9 06:30:38 2009
From: bsdfan at nurfuerspam.de (Markus Dolze)
Date: Mon, 09 Mar 2009 07:30:38 +0100
Subject: [Lcdproc] lcdproc doesn't switch off my backlight
In-Reply-To: <200903070801.34452.sascha.zielinski@gmx.de>
References: <200903070801.34452.sascha.zielinski@gmx.de>
Message-ID: <49B4B78E.6030502@nurfuerspam.de>

Sascha wrote:
> Hi,
>
> I set up my lcdproc.conf with these values:
>
> [Load]
> Active=true
> LowLoad=1.00
> HighLoad=5.00
>
> I started lcdproc while my load was under 1 and my Backlight was off. Then I 
> started several burnMMX processes and watched my load.
> Right after the load goes > 5 the Backlight was starting blinking, I killed 
> all burnMMX's and after the load was under 5 my backlight stays on.
> After a while all Load values were below 1.0 again and my backlight doesn't 
> switch off.
>
> Does lcdpoc use all 3 Load values to check wether to turn the backlight on or 
> off? Do the values have to stay at a specific time under the LowLoad?
>
>
>   

Hi,

lcdproc uses the 1 min avg load value.

The behaviour could best be described as (its the actual code):

if (lowLoad < highLoad) {
        status = (loadmax > lowLoad) ? BACKLIGHT_ON : BACKLIGHT_OFF;
        if (loads[lcd_wid - 2] > highLoad)
            status = BLINK_ON;

In words this means:

    * If you configured /highLoad/ to have a larger value than /lowLoad/
      it is updating the backlight. By setting /highLoad/ to a lower 
      value than /lowLoad/ you can turn the whole feature off.
      Thereotically it would also be disabled if both are set to the
      same value, but I would set it to a lower value to turn it off.
    * BTW: The default value for the backlight is BACKLIGHT_ON, so if
      this feature is turned off, the backlight will always be on.
    * If /maxLoad/ is larger then /lowLoad/ the backlight is set to on,
      otherwise it is turned off. /maxLoad/ is the maximum off all
      displayed load values = maximum off all displayed vBars. If you
      are using this on your 40x4 display it could take a while until
      the high values have moved out of your screen.
    * If the newst (= rightmost) load value if above the /highLoad/
      limit, the display starts blinking. The blinking is turned off if
      the value dropped below the /highLoad/ limit on next screen update.


Works fine for me.

Markus

From bsdfan at nurfuerspam.de  Mon Mar  9 06:50:17 2009
From: bsdfan at nurfuerspam.de (Markus Dolze)
Date: Mon, 09 Mar 2009 07:50:17 +0100
Subject: [Lcdproc] HaveFans in VL-system MPlay with HD44780 driver
In-Reply-To: <49B4B4E4.6000507@gmx.com>
References: <49B4B4E4.6000507@gmx.com>
Message-ID: <49B4BC29.3040604@nurfuerspam.de>

Duke wrote:
> Hi all,
>
> Please be easy on me, I am just new to the list and also have zero 
> knowledge about LCDproc. I found LCDproc when trying to enable the LCD 
> on my VL-System Mplay in Ubuntu Intrepid. Everything seems to be fine 
> with HD44780 driver, except the fan part. I have no idea how to enable 
> the fan controllers. In LCDd.conf, it says:
>
> # Does the display have a fan controller?
> #HaveFans=n
>
> I understand "n" as "no", then tried to add HaveFans=y, or 
> HaveFans=yes, but it still does not work. The LCD is enabled but the 
> fans do not rotate (I set the FanOn=20 and FanOff=1 in C scale, then 
> they should run, right?). I also tried HaveFans=1 but still no luck.
>
> Anybody helps please!
>

Hi,

I am not quite sure, which version of LCDproc you are using. The 
offically included Mplay driver in the most recent development version 
does not have the fan support included, only the display part is working 
I know of versions 0.5.2 floating around patched with a driver that got 
never included by the LCDproc project.

If you are using something that claims to be 'version 0.5.2' you are 
likely running a version patched by your distribution. Other's on this 
list could help anyway.

Regards
Markus


From bsdfan at nurfuerspam.de  Mon Mar  9 07:32:04 2009
From: bsdfan at nurfuerspam.de (Markus Dolze)
Date: Mon, 09 Mar 2009 08:32:04 +0100
Subject: [Lcdproc] imonlcd server driver with icon support
In-Reply-To: <49A47CED.7060101@nurfuerspam.de>
References: <49A47CED.7060101@nurfuerspam.de>
Message-ID: <49B4C5F4.90309@nurfuerspam.de>

Markus Dolze wrote:
> I would like to point your attention to 
> http://sourceforge.net/tracker/index.php?func=detail&aid=2620055&group_id=119&atid=300119 
>
>
> This is the imonlcd driver from codeka.com. It contains a working 
> solution for accessing icons beside the display by using the output() 
> function.
>
> The driver is commented well (including doxygen) but misses 
> documentation. I have not checked anything else yet and would like to 
> hear your comments.
>

I got in touch with Dean and others on this driver and learned that 
there is strong community interest in having this driver included.

However, to speak clearly: I will not add this driver in its current 
state. Because:

   1. It is missing documentation. From previous discussion on this list
      I learned this would help beginners.
   2. There are still a lot of TODOs in the code. And after reviewing
      the driver, I added some more requests to clearify things. It is
      not necessary to get rid of all of them, but at least we should be
      confident with the remaining ones.
   3. The use of /uint64_t/ creates at least portability issues.

I added a some patches to this mail:

    * An mostly empty docbook section on the imonlcd driver [1] and the
      necessary glue to the user guide [2]. It contains some text copied
      over from the imon driver and I added all configuration options
      the driver currently support. However, the text is empty and has
      to be filled in.
    * My updates and comments on the code [3].
    * An update to Makefile.am and acinclude.m4 to test the driver with
      CVS current [4].
    * The build warnings [5] that show up when compiling the driver on
      FreeBSD. Although this may not be a target platform, it indicates
      possible problems that should be clarified / fixed.

[1] imonlcd.docbook
[2] imonlcd-user-guide.patch
[3] imonlcd-0.3-comments.patch
[4] imonlcd-cvs-current.patch
[5] imonlcd-build-warnings.txt

To go on and have this driver included, action by developers, 
maintainers, or any interested person is required. If you are already 
working on this driver, please tell the list.

Regards
Markus
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: imonlcd-user-guide.patch
URL: <http://lists.omnipotent.net/pipermail/lcdproc/attachments/20090309/3e17e195/attachment-0005.txt>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: imonlcd-build-warnings.txt
URL: <http://lists.omnipotent.net/pipermail/lcdproc/attachments/20090309/3e17e195/attachment-0006.txt>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: imonlcd.docbook
URL: <http://lists.omnipotent.net/pipermail/lcdproc/attachments/20090309/3e17e195/attachment-0007.txt>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: imonlcd-0.3-comments.patch
URL: <http://lists.omnipotent.net/pipermail/lcdproc/attachments/20090309/3e17e195/attachment-0008.txt>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: imonlcd-cvs-current.patch
URL: <http://lists.omnipotent.net/pipermail/lcdproc/attachments/20090309/3e17e195/attachment-0009.txt>

From multiroom at sympatico.ca  Mon Mar  9 13:09:00 2009
From: multiroom at sympatico.ca (David Scott)
Date: Mon, 9 Mar 2009 09:09:00 -0400
Subject: [Lcdproc] HaveFans in VL-system MPlay with HD44780 driver
Message-ID: <DJEGLLNGDMGIFNAOLMELOEDFDNAA.multiroom@sympatico.ca>


 Duke,

 Yes you need to set them "y". You just set the startup & shutdown temps in
the conf file and
it takes care of the rest. I have mine come on at 95 and off at 85 (with
TempScale set to 'f'), but the FanMinSpeed is the one you'll
really have to customize. I have two very different fans on the controller
and one will come on at a speed of 20, but the other won't
start unless I set the minimum to 90 (out of 255). The speed values are a
range of 0-255 since the fan controller is capable of variable
speed control. If you don't want to bother you should be able to set the
minimum to 255 and just have them on at full speed all the time.

 Dave


From junk_inbox at verizon.net  Mon Mar  9 14:57:24 2009
From: junk_inbox at verizon.net (Jeff)
Date: Mon, 9 Mar 2009 10:57:24 -0400
Subject: [Lcdproc] LCDd daemon hangs with USB Crystalfontz 634 LCD
In-Reply-To: <337275825.898941236565657092.JavaMail.root@sz0098a.emeryville.ca.mail.comcast.net>
References: <49B449DE.4000602@nurfuerspam.de>
	<337275825.898941236565657092.JavaMail.root@sz0098a.emeryville.ca.mail.comcast.net>
Message-ID: <d569babb0903090757n48c75108m9d5fcab845b2a9e2@mail.gmail.com>

On Sun, Mar 8, 2009 at 10:27 PM, <stewartputnam at comcast.net> wrote:

> Error in the nested quotes there I think; not my message.
> That bit was from <Jeff>junk_inbox at verizon.net on 2/10/09 in reply to my
> suggestions.
> I do not have a 634.  I can, however, replicate the same behavior by
> running the CFontz driver on /dev/null as I recall ;)
>
> ----- Original Message -----
> From: "Markus Dolze" <bsdfan at nurfuerspam.de>
> To: stewartputnam at comcast.net
> Sent: Sunday, March 8, 2009 3:42:38 PM GMT -08:00 US/Canada Pacific
> Subject: Re: [Lcdproc] LCDd daemon hangs with USB Crystalfontz 634 LCD
>
> stewartputnam at comcast.net wrote:
> >
> > Indeed, I do still need to follow-up on Marcus' request for additional
> > info - I have not yet had the time to do this as of yet.  I hope to be
> > able to do that in the next couple of days.
> >
> >
>
> Hi Stewart,
>
> did you found any time to test this?
>
> Regards
> Markus
>
> Markus,

  I too owe you data - sorry, it's been a crazy busy month at work and I've
had little time of my own.

Jeff
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omnipotent.net/pipermail/lcdproc/attachments/20090309/606eced9/attachment.htm>

From ismot at telemail.fi  Mon Mar  9 19:50:18 2009
From: ismot at telemail.fi (Ismo Tanskanen)
Date: Mon, 09 Mar 2009 21:50:18 +0200
Subject: [Lcdproc] How to change characters hex code?
Message-ID: <49B572FA.40900@telemail.fi>

Hi,

I have little problem with my matrix orbital lcd's.

I use mythtv and lcdprog to drive them, and I need scandic characters (?
and ? mostly) to be shown correctly.

My third frontend has imon vfd and it shows them correctly out of box.

But matrix orbital's show odd characters when there should be ? or ?.

In matrix orbital manual, there is hax map to ascii characters, which
shows that corresponding code for ? is 0x0E1 , but in standard character
map it is 0x0E4.

Is there way to change what hex code lcdprog sends to display when "?"
is needed? Is it possible to configure it in LCDd.conf or should I
modify source?

Thanks,

- m_kane


From bsdfan at nurfuerspam.de  Mon Mar  9 20:04:54 2009
From: bsdfan at nurfuerspam.de (Markus Dolze)
Date: Mon, 09 Mar 2009 21:04:54 +0100
Subject: [Lcdproc] Patch: smpload support for FreeBSD
Message-ID: <49B57666.6010409@nurfuerspam.de>

Hi,

While working on the 'lcdproc' client I found that it does not support 
more than 1 CPU for the 'smpload' ('P) screen on FreeBSD. Some month ago 
and now available with FreeBSD 7.1 a new kernel function was introduced 
which allows easy retrieving of the cpu load for every cpu.

Attached is a patch which adds support for the smpload screen for FreeBSD.

Please test and report and errors.

Regards
Markus
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patch-freebsd-smpload.diff
URL: <http://lists.omnipotent.net/pipermail/lcdproc/attachments/20090309/4386b6a1/attachment.txt>

From bsdfan at nurfuerspam.de  Mon Mar  9 20:01:49 2009
From: bsdfan at nurfuerspam.de (Markus Dolze)
Date: Mon, 09 Mar 2009 21:01:49 +0100
Subject: [Lcdproc] SMP CPU monitor counts I/O wait as CPU usage
Message-ID: <49B575AD.2050809@nurfuerspam.de>

Hi,

for some time the Linux lcdproc CPU screens did not report CPU load 
correctly as one user noticed:

 http://sourceforge.net/tracker2/?func=detail&aid=2580087&group_id=119&atid=100119

Attached is a change that should fix it. As I don't run Linux, please 
test and if necessary correct it.

Note that I decided to make the additional variables local instead of 
extending /load_type/ as they are Linux specific.

Regards
Markus
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: machine_Linux.patch
URL: <http://lists.omnipotent.net/pipermail/lcdproc/attachments/20090309/c77c39ba/attachment.txt>

From bsdfan at nurfuerspam.de  Tue Mar 10 21:01:24 2009
From: bsdfan at nurfuerspam.de (Markus Dolze)
Date: Tue, 10 Mar 2009 22:01:24 +0100
Subject: [Lcdproc] [PATCH] FreeBSD's new USB stack support (configure.in
 changes, testing needed)
In-Reply-To: <90B881CB-06A2-4436-8F65-630309EC5279@siliconlandmark.com>
References: <90B881CB-06A2-4436-8F65-630309EC5279@siliconlandmark.com>
Message-ID: <49B6D524.2010204@nurfuerspam.de>

Andre Guibert de Bruet wrote:
> Hi,
>
> I have attached a patch that extends LCDproc's USB support, and allows 
> for its use on the upcoming FreeBSD 8.0 (Presently 8-CURRENT).
>
> This patch changes configure.in as well as all of LCDproc's USB 
> drivers and though I have made every effort to not introduce 
> side-effects, it needs wide-scale testing. For users of non-FreeBSD 
> systems, this patch should not change anything. I have verified this 
> statement with OSX, but I have not tested against any flavor of Linux 
> (I suspect that it should "just work").
>
> For pre-8.0-CURRENT FreeBSD users, the absence of the new USB's 
> stack's headers keeps the present dependance on libusb.
>
> Let me know if this patch works or breaks anything for you.
>
>

Yesterday the new libusb20 was renamed to just libusb, see [1]. The port 
was updated as well, which required only a small change as the port ist 
still based on 0.5.2 which in turn doesn't use pkg-config to detect 
libusb's presence.

This change obsoletes the patch you sent in earlier, but creates the 
need to remove the usage of pkg-config to detect libusb and setting of 
CFLAGS and LDFLAGS. For the port this can be achieved with an extra 
patch like it was done for other programs.

But for the version from CVS you will have to patch manually OR we have 
someone more familiar with autotools than myself to change the way 
autotools detect libusb on FreeBSD. Any help is welcome.

[1] http://svn.freebsd.org/viewvc/base?view=revision&revision=189585

Regards
Markus

From bsdfan at nurfuerspam.de  Tue Mar 10 21:17:19 2009
From: bsdfan at nurfuerspam.de (Markus Dolze)
Date: Tue, 10 Mar 2009 22:17:19 +0100
Subject: [Lcdproc] How to change characters hex code?
In-Reply-To: <49B572FA.40900@telemail.fi>
References: <49B572FA.40900@telemail.fi>
Message-ID: <49B6D8DF.6050003@nurfuerspam.de>

Ismo Tanskanen wrote:
> Hi,
>
> I have little problem with my matrix orbital lcd's.
>
> I use mythtv and lcdprog to drive them, and I need scandic characters (?
> and ? mostly) to be shown correctly.
>
> My third frontend has imon vfd and it shows them correctly out of box.
>
> But matrix orbital's show odd characters when there should be ? or ?.
>
> In matrix orbital manual, there is hax map to ascii characters, which
> shows that corresponding code for ? is 0x0E1 , but in standard character
> map it is 0x0E4.
>
> Is there way to change what hex code lcdprog sends to display when "?"
> is needed? Is it possible to configure it in LCDd.conf or should I
> modify source?
>
>
>   

The Matrix Orbital driver does not contain any character mapping functions.

Unfortunately the character table may differ from one model to another 
and even for the same model with different hardware revisions.

As Matrix Orbital seems to use character displays based on standard 
controllers, it might be possible to reuse the hd44780 character mapping 
tables. I will put this on the to do list. Until then, you will have to 
modify the source and remap those characters you need.

Markus


From bsdfan at nurfuerspam.de  Tue Mar 10 21:36:08 2009
From: bsdfan at nurfuerspam.de (Markus Dolze)
Date: Tue, 10 Mar 2009 22:36:08 +0100
Subject: [Lcdproc] improved imon hbars
In-Reply-To: <20090111142455.2A49E940566@tippex.mynet.homeunix.org>
References: <20090111142455.2A49E940566@tippex.mynet.homeunix.org>
Message-ID: <49B6DD48.9090108@nurfuerspam.de>

aeriksson2 at fastmail.fm wrote:
> I've created this patch to the imon driver.
> Effectively, it uses the vbar characters to paint the non-full cell.
> Apart from a different look, it actually gets more info onto the display.
>
> Any interest in integrating it? 
>
>
>   

Hi Anders,

your patch didn't received any other feedback yet. I don't know if 
people get confused by bars moving in two directions (left/right and 
up/down), but I think it's a nice idea. (I will try that on my hd44780 
as well.)

If you don't object I would like to have this optional for now.

Markus


From bsdfan at nurfuerspam.de  Tue Mar 10 22:26:05 2009
From: bsdfan at nurfuerspam.de (Markus Dolze)
Date: Tue, 10 Mar 2009 23:26:05 +0100
Subject: [Lcdproc] imonlcd server driver with icon support
In-Reply-To: <49A47CED.7060101@nurfuerspam.de>
References: <49A47CED.7060101@nurfuerspam.de>
Message-ID: <49B6E8FD.6000807@nurfuerspam.de>

Hi,

I just want to add the note that the name 'imonlcd' is already in use:

http://www.bytebox.org/imonlcd/

Regards
Markus

From aeriksson2 at fastmail.fm  Tue Mar 10 22:35:36 2009
From: aeriksson2 at fastmail.fm (aeriksson2 at fastmail.fm)
Date: Tue, 10 Mar 2009 23:35:36 +0100
Subject: [Lcdproc] improved imon hbars
In-Reply-To: <49B6DD48.9090108@nurfuerspam.de>
References: <20090111142455.2A49E940566@tippex.mynet.homeunix.org>
	<49B6DD48.9090108@nurfuerspam.de>
Message-ID: <20090310223536.DE2122C40DB@tippex.mynet.homeunix.org>


bsdfan at nurfuerspam.de said:
> aeriksson2 at fastmail.fm wrote:
>> I've created this patch to the imon driver.
>> Effectively, it uses the vbar characters to paint the non-full cell.
>> Apart from a different look, it actually gets more info onto the display.
>>
>> Any interest in integrating it?
>   
> Hi Anders,
> your patch didn't received any other feedback yet. I don't know if  people
> get confused by bars moving in two directions (left/right and  up/down), but
> I think it's a nice idea. (I will try that on my hd44780  as well.)

That's of course a possibility. I've been using it since I anounced it and, to 
me, it makes the smp-load screen nicer. But I'm of course biased.

> If you don't object I would like to have this optional for now.

Sure thing. I'd be happy to get it in, one way or the other. Do you handle 
that, or should I cook a patch where it's an option?

/Anders






From andy at siliconlandmark.com  Wed Mar 11 02:36:32 2009
From: andy at siliconlandmark.com (Andre Guibert de Bruet)
Date: Tue, 10 Mar 2009 22:36:32 -0400
Subject: [Lcdproc] [PATCH] FreeBSD's new USB stack support (configure.in
	changes, testing needed)
In-Reply-To: <49B6D524.2010204@nurfuerspam.de>
References: <90B881CB-06A2-4436-8F65-630309EC5279@siliconlandmark.com>
	<49B6D524.2010204@nurfuerspam.de>
Message-ID: <07301694-25CF-486B-A7DD-32EC5E868D19@siliconlandmark.com>

On Mar 10, 2009, at 5:01 PM, Markus Dolze wrote:
> Andre Guibert de Bruet wrote:
>>
>> I have attached a patch that extends LCDproc's USB support, and  
>> allows for its use on the upcoming FreeBSD 8.0 (Presently 8-CURRENT).
>>
>> For pre-8.0-CURRENT FreeBSD users, the absence of the new USB's  
>> stack's headers keeps the present dependance on libusb.
>>
> Yesterday the new libusb20 was renamed to just libusb, see [1]. The  
> port was updated as well, which required only a small change as the  
> port ist still based on 0.5.2 which in turn doesn't use pkg-config  
> to detect libusb's presence.
>
> This change obsoletes the patch you sent in earlier, but creates the  
> need to remove the usage of pkg-config to detect libusb and setting  
> of CFLAGS and LDFLAGS. For the port this can be achieved with an  
> extra patch like it was done for other programs.

Indeed.

> But for the version from CVS you will have to patch manually OR we  
> have someone more familiar with autotools than myself to change the  
> way autotools detect libusb on FreeBSD. Any help is welcome.

I am by no means an autotools reference, but I'll give it a shot.

Cheers,
Andy

/*  Andre Guibert de Bruet  * 436f 6465 2070 6f65 742e 2042 6974 206a */
/*     Managing Partner     * 6f63 6b65 792e 2053 7973 4164 6d69 6e2e */
/*   GSM: +1 734 846 8758   * 2055 4e49 5820 736c 6575 7468 2e00 0000 */
/* WWW: siliconlandmark.com * C/C++, Java, Perl, PHP, SQL, XHTML, XML */



From bsdfan at nurfuerspam.de  Wed Mar 11 07:37:13 2009
From: bsdfan at nurfuerspam.de (Markus Dolze)
Date: Wed, 11 Mar 2009 08:37:13 +0100
Subject: [Lcdproc] improved imon hbars
In-Reply-To: <20090310223536.DE2122C40DB@tippex.mynet.homeunix.org>
References: <20090111142455.2A49E940566@tippex.mynet.homeunix.org>	<49B6DD48.9090108@nurfuerspam.de>
	<20090310223536.DE2122C40DB@tippex.mynet.homeunix.org>
Message-ID: <49B76A29.3040504@nurfuerspam.de>

aeriksson2 at fastmail.fm wrote:
> bsdfan at nurfuerspam.de said:
>> aeriksson2 at fastmail.fm wrote:
>>> I've created this patch to the imon driver.
>>> Effectively, it uses the vbar characters to paint the non-full cell.
>>> Apart from a different look, it actually gets more info onto the display.
>>>
>>> Any interest in integrating it?
>>   
>> Hi Anders,
>> your patch didn't received any other feedback yet. I don't know if  people
>> get confused by bars moving in two directions (left/right and  up/down), but
>> I think it's a nice idea. (I will try that on my hd44780  as well.)
> 
> That's of course a possibility. I've been using it since I anounced it and, to 
> me, it makes the smp-load screen nicer. But I'm of course biased.
> 
>> If you don't object I would like to have this optional for now.
> 
> Sure thing. I'd be happy to get it in, one way or the other. Do you handle 
> that, or should I cook a patch where it's an option?
> 
> /Anders
> 


For those who don't have an idea what Anders and I are talking about and 
how it looks like I prepared a small video here: 
http://mdolze.gmxhome.de/files/hd44780-hbars_small_Xvid.avi

It shows hd44780 default hBars, Anders' implementation and something 
similar to the current imon hBars in that order.

Beside that from Anders' hBars may be mistaken for 'mini vBars' the imon 
hBars appear messy to me.

Your comments?

Markus


From cmarkle at asperasoft.com  Thu Mar 12 04:48:16 2009
From: cmarkle at asperasoft.com (Chris Markle)
Date: Wed, 11 Mar 2009 21:48:16 -0700
Subject: [Lcdproc] API or command-line tool to send text to LCD via lcdproc?
Message-ID: <7e1093ca0903112148q2aa57a14v5c8e75f176e4eac8@mail.gmail.com>

Very new to lcdproc here... Is there and API or command-line tool to
send arbitrary test / messages to the LCD display via lcdproc? Thanks
in advance...

Chris

From ethan.dicks at gmail.com  Thu Mar 12 05:29:31 2009
From: ethan.dicks at gmail.com (Ethan Dicks)
Date: Thu, 12 Mar 2009 01:29:31 -0400
Subject: [Lcdproc] API or command-line tool to send text to LCD via
	lcdproc?
In-Reply-To: <7e1093ca0903112148q2aa57a14v5c8e75f176e4eac8@mail.gmail.com>
References: <7e1093ca0903112148q2aa57a14v5c8e75f176e4eac8@mail.gmail.com>
Message-ID: <f4eb766f0903112229m6e11a84el80d0d494890ea8c0@mail.gmail.com>

On Thu, Mar 12, 2009 at 12:48 AM, Chris Markle <cmarkle at asperasoft.com> wrote:
> Very new to lcdproc here... Is there and API or command-line tool to
> send arbitrary test / messages to the LCD display via lcdproc? Thanks
> in advance...

LCDproc uses a client-server model where the client opens a network
socket and sends requests to the server to define screens, text and
graph and icon widgets, and such (its API, essentially).  The simplest
command-line tool that can open a socket and keep it open is telnet.
Just try "telnet localhost 13666" and type valid commands to LCDd
(they are all described in the documentation).

The simplest client that ships with LCDd is probably either
clients/examples/tail.pl or, for post-December 2008 CVS releases
(i.e., not the official 0.5.2 release), clients/examples/lcdident.pl
(which I wrote).  Those simple Perl clients open a socket to LCDd and
step through what's required to create text widgets and send text.
tail.pl will let you watch logfiles (or any file you control and could
put your own content into).  lcdident.pl won't let you send strings
you make (it displays the port number and LCD XY geometry), but I
think it's a good example of a minimal client which might be useful as
a starting point if you intend to write your own clients.

-ethan

From cmarkle at asperasoft.com  Thu Mar 12 06:10:23 2009
From: cmarkle at asperasoft.com (Chris Markle)
Date: Wed, 11 Mar 2009 23:10:23 -0700
Subject: [Lcdproc] If my client disconnects,
	will last displayed widget still be shown?
Message-ID: <7e1093ca0903112310w33c27fdcu344ebe51a58f4b40@mail.gmail.com>

Reading about the protocol between lcdproc and the server... If I add
a screen, add a widget in the screen and set some (e.g.,) string in
the widget, I presume it gets displayed right away. if my client the
disconnects from port 13666, will the last-displayed info still be
shown on the LCD? Thanks in advance...

Chris

From malte at maltepoeggel.de  Thu Mar 12 09:36:29 2009
From: malte at maltepoeggel.de (=?iso-8859-1?Q?Malte_P=F6ggel?=)
Date: Thu, 12 Mar 2009 10:36:29 +0100
Subject: [Lcdproc] Command to set / get contrast value for clients
Message-ID: <C00D9A2EFF3641D49D51C32F5007EAA3@subnote1400>

Hi,

is it possible that the client sets the contrast of the lcd?
I want to use my own settings menu and am overwriting the lcdproc default main menu.

Malte
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omnipotent.net/pipermail/lcdproc/attachments/20090312/bdaed18f/attachment.html>

From bsdfan at nurfuerspam.de  Thu Mar 12 17:45:43 2009
From: bsdfan at nurfuerspam.de (Markus Dolze)
Date: Thu, 12 Mar 2009 18:45:43 +0100
Subject: [Lcdproc] If my client disconnects,
 will last displayed widget still be shown?
In-Reply-To: <7e1093ca0903112310w33c27fdcu344ebe51a58f4b40@mail.gmail.com>
References: <7e1093ca0903112310w33c27fdcu344ebe51a58f4b40@mail.gmail.com>
Message-ID: <49B94A47.40708@nurfuerspam.de>

Chris Markle wrote:
> Reading about the protocol between lcdproc and the server... If I add
> a screen, add a widget in the screen and set some (e.g.,) string in
> the widget, I presume it gets displayed right away. if my client the
> disconnects from port 13666, will the last-displayed info still be
> shown on the LCD? Thanks in advance...
>
>
>   
Hi,

no. If your client disconnects it screens are removed from the server 
and the server shows the server screen or switches to the next screen if 
another client is connected.

Markus

From bsdfan at nurfuerspam.de  Thu Mar 12 17:47:27 2009
From: bsdfan at nurfuerspam.de (Markus Dolze)
Date: Thu, 12 Mar 2009 18:47:27 +0100
Subject: [Lcdproc] Command to set / get contrast value for clients
In-Reply-To: <C00D9A2EFF3641D49D51C32F5007EAA3@subnote1400>
References: <C00D9A2EFF3641D49D51C32F5007EAA3@subnote1400>
Message-ID: <49B94AAF.9070609@nurfuerspam.de>

Malte P?ggel wrote:
> Hi,
>  
> is it possible that the client sets the contrast of the lcd?
> I want to use my own settings menu and am overwriting the lcdproc 
> default main menu.
>  
>

Hi,

Currently this is not possible. Those display properties are only 
controlled by the server or driver.

Markus


From bsdfan at nurfuerspam.de  Thu Mar 12 20:47:22 2009
From: bsdfan at nurfuerspam.de (Markus Dolze)
Date: Thu, 12 Mar 2009 21:47:22 +0100
Subject: [Lcdproc] Removal of outdated doc files
Message-ID: <20090312204722.17940@gmx.net>

Hi,

if I receive no objections, I will remove the follwing outdated documentation files:

./README.IRman (historic, installation is handled automatically)
./docs/API-v0.4.txt (historic, old API)
./docs/README.dg (historic)
./docs/README.dg2 (historic)
./docs/README.glcdlib (merged into user-guide)
./docs/hd44780_howto.txt (merged into user-guide)
./docs/menustuff.txt (merged into dev-guide)
./docs/netstuff.txt (historic, old protovol, merged into dev-guide)
./server/drivers/README (historic, describes 0.4 API)
./server/drivers/ideas.txt (historic, implemented in core)

Additionally I will clear:

./BUGS (should only contain bugs in current version)

Regards
Markus

From arybak at radiowy.net  Sun Mar 15 21:14:59 2009
From: arybak at radiowy.net (Adam Rybak)
Date: Sun, 15 Mar 2009 22:14:59 +0100
Subject: [Lcdproc] support for FIC Spectra VFD Support (chip Futaba
	TOSD-5711BB)
Message-ID: <c278d6b00903151414o763fae6ak16d995c0ecd44d38@mail.gmail.com>

I found few posts in january about adding support for this LCD display to
lcd proc. Is this possible? I have this HTPC case for my Media Center system
based on VDR and everythnig works except the LCD driver :(

Ifound that Futaba is supported as serial - maybe it is easy to change input
to USB? Im not familiar with programming.


Regards,
Adam
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omnipotent.net/pipermail/lcdproc/attachments/20090315/599878e3/attachment-0001.htm>

From fblack947 at yahoo.com  Mon Mar 16 21:11:34 2009
From: fblack947 at yahoo.com (jk)
Date: Mon, 16 Mar 2009 14:11:34 -0700 (PDT)
Subject: [Lcdproc] imonlcd server driver with icon support
Message-ID: <987127.56621.qm@web37504.mail.mud.yahoo.com>

Markus,

I'm working on your issues with the imonlcd driver.  

I'm the author of a HOWTO on ubuntu forums which focuses on getting these displays working.  Given the response over there, it's imperative that this device gets support from the next release of lcdproc  (almost 19,000 views for the Ubuntu v8.04 thread and over 2,000 for the recently started v8.10 thread).

-Jonathan



      
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omnipotent.net/pipermail/lcdproc/attachments/20090316/025c812c/attachment.htm>

From john at john-online.co.uk  Mon Mar 16 22:00:51 2009
From: john at john-online.co.uk (John Campbell)
Date: Mon, 16 Mar 2009 22:00:51 -0000
Subject: [Lcdproc] Options set in lcdproc.conf
Message-ID: <003f01c9a682$ab957d70$02c07850$@co.uk>

Hi all,
I have had a search around but cannot seem to find what I?m looking for.
Can someone tell me some more details regarding the option values set in the
lcdproc.conf file (or at least point me to where any docs lie), e.g. what
does the "showinvisible" flag do in the "[cpu]" section?
Any detailed info on these settings would be very welcome.
Thanks
John Campbell

No virus found in this outgoing message.
Checked by AVG - www.avg.com 
Version: 8.0.237 / Virus Database: 270.11.15/2004 - Release Date: 03/16/09
07:04:00
-------------- next part --------------

No virus found in this outgoing message.
Checked by AVG - www.avg.com 
Version: 8.0.237 / Virus Database: 270.11.15/2004 - Release Date: 03/16/09 07:04:00

From epooch at cox.net  Mon Mar 16 22:46:02 2009
From: epooch at cox.net (epooch at cox.net)
Date: Mon, 16 Mar 2009 18:46:02 -0400
Subject: [Lcdproc] imonlcd server driver with icon support
In-Reply-To: <987127.56621.qm@web37504.mail.mud.yahoo.com>
Message-ID: <20090316184602.BCXFR.162007.imail@fed1rmwml33>

I have revised the driver pretty significantly to get it working on Mac OS X with product ids 0x0036 and 0x0038, but cleaned up the common code a lot along the way.  I have some code that fixes significant bugs in the way the driver works.  For instance, the display NEEDS a backing store to prevent constant unnecessary screen refreshes which eventually cause the LCD to freeze up.  Let me know if you want to collaborate at all on this. 

--eric  
---- jk <fblack947 at yahoo.com> wrote: 
> Markus,
> 
> I'm working on your issues with the imonlcd driver.  
> 
> I'm the author of a HOWTO on ubuntu forums which focuses on getting these displays working.  Given the response over there, it's imperative that this device gets support from the next release of lcdproc  (almost 19,000 views for the Ubuntu v8.04 thread and over 2,000 for the recently started v8.10 thread).
> 
> -Jonathan
> 
> 
> 
>       


From fblack947 at yahoo.com  Mon Mar 16 23:05:03 2009
From: fblack947 at yahoo.com (jk)
Date: Mon, 16 Mar 2009 16:05:03 -0700 (PDT)
Subject: [Lcdproc] imonlcd server driver with icon support
References: <20090316184602.BCXFR.162007.imail@fed1rmwml33>
Message-ID: <866157.18238.qm@web37507.mail.mud.yahoo.com>


----- Original Message ----

> From: "epooch at cox.net" <epooch at cox.net>
> To: lcdproc at lists.omnipotent.net; jk <fblack947 at yahoo.com>
> Sent: Monday, March 16, 2009 6:46:02 PM
> Subject: Re: [Lcdproc] imonlcd server driver with icon support
> 
> I have revised the driver pretty significantly to get it working on Mac OS X 
> with product ids 0x0036 and 0x0038, but cleaned up the common code a lot along 
> the way.  I have some code that fixes significant bugs in the way the driver 
> works.  For instance, the display NEEDS a backing store to prevent constant 
> unnecessary screen refreshes which eventually cause the LCD to freeze up.  Let 
> me know if you want to collaborate at all on this. 
> 
> --eric  

Heck yes!  I'm sending you some comments off-list.

-jonathan



      

From bsdfan at nurfuerspam.de  Tue Mar 17 17:46:58 2009
From: bsdfan at nurfuerspam.de (Markus Dolze)
Date: Tue, 17 Mar 2009 18:46:58 +0100
Subject: [Lcdproc] imonlcd server driver with icon support
In-Reply-To: <866157.18238.qm@web37507.mail.mud.yahoo.com>
References: <20090316184602.BCXFR.162007.imail@fed1rmwml33>
	<866157.18238.qm@web37507.mail.mud.yahoo.com>
Message-ID: <49BFE212.9000406@nurfuerspam.de>

jk wrote:
> ----- Original Message ----
>
>   
>> From: "epooch at cox.net" <epooch at cox.net>
>> To: lcdproc at lists.omnipotent.net; jk <fblack947 at yahoo.com>
>> Sent: Monday, March 16, 2009 6:46:02 PM
>> Subject: Re: [Lcdproc] imonlcd server driver with icon support
>>
>> I have revised the driver pretty significantly to get it working on Mac OS X 
>> with product ids 0x0036 and 0x0038, but cleaned up the common code a lot along 
>> the way.  I have some code that fixes significant bugs in the way the driver 
>> works.  For instance, the display NEEDS a backing store to prevent constant 
>> unnecessary screen refreshes which eventually cause the LCD to freeze up.  Let 
>> me know if you want to collaborate at all on this. 
>>
>> --eric  
>>     
>
> Heck yes!  I'm sending you some comments off-list.
>
> -jonathan
>
>   

Please include the list in your communication. Your discussion might be 
useful for other driver developers as well.

Thank you,
Markus

From bsdfan at nurfuerspam.de  Tue Mar 17 17:54:33 2009
From: bsdfan at nurfuerspam.de (Markus Dolze)
Date: Tue, 17 Mar 2009 18:54:33 +0100
Subject: [Lcdproc] New Driver - howto submit
In-Reply-To: <49B4582D.2010706@helmutauer.de>
References: <20090305123536.58DB618154971@dd16712.kasserver.com>	<49B4522B.80808@nurfuerspam.de>
	<49B4582D.2010706@helmutauer.de>
Message-ID: <49BFE3D9.4000507@nurfuerspam.de>

Helmut Auer wrote:
> Hi Markus
>>
>> you hit the right place. This mailing list is where we dicuss the 
>> LCDproc software and post changes to.
>>
>> To get your driver into the tree, someone with write access to the 
>> source code repository has to commit it. There will usually be a 
>> review before that and maybe others will try it out.
>>
>> Don't be disappointed if this may take some time (weeks).
>>
> No problem - the driver is running in my own distrie :)
> 
>> I had a quick look at your driver and identified some things I would 
>> like to comment on. I will write up a list of comments or comment your 
>> code directly and send it back to the list. Stay tuned.
>>
>> Regards
>> Markus
>>
>> PS: I just guessed the name 'Helmut' from you domain and whois data as 
>> it is likely not 'vdr'. Correct me if I am wrong.
>>
> Sure - sorry I forgot that I was using the webmailer, which is missing 
> the signature :)
> 
> 


My first and most important question is: Did you have a look at the 
serialVFD driver?

That one already supports a number of VFD devices connected to a serial 
port and includes command and characters mapping functions.

It is not a problem to add another driver to the 45+ we have, but I 
would like to see if more people use the existing modular drivers.

The serialVFD driver currently is not that well documented as the 
hd44780 and lacks the /output/ function, but that could be changed.

Regards,
Markus

From bsdfan at nurfuerspam.de  Tue Mar 17 17:57:56 2009
From: bsdfan at nurfuerspam.de (Markus Dolze)
Date: Tue, 17 Mar 2009 18:57:56 +0100
Subject: [Lcdproc] SMP CPU monitor counts I/O wait as CPU usage
In-Reply-To: <49B575AD.2050809@nurfuerspam.de>
References: <49B575AD.2050809@nurfuerspam.de>
Message-ID: <49BFE4A4.3070000@nurfuerspam.de>

Markus Dolze wrote:
> for some time the Linux lcdproc CPU screens did not report CPU load 
> correctly as one user noticed:
>
> http://sourceforge.net/tracker2/?func=detail&aid=2580087&group_id=119&atid=100119 
>
>
> Attached is a change that should fix it. As I don't run Linux, please 
> test and if necessary correct it.
>
> Note that I decided to make the additional variables local instead of 
> extending /load_type/ as they are Linux specific.
>
>

No comments?

I was able to verify the wrong behaviour and that my fix really resolves 
it. I will commit the change if I receive no objections.

Regards,
Markus


From fblack947 at yahoo.com  Tue Mar 17 22:10:02 2009
From: fblack947 at yahoo.com (jk)
Date: Tue, 17 Mar 2009 15:10:02 -0700 (PDT)
Subject: [Lcdproc] imonlcd server driver with icon support
References: <20090316184602.BCXFR.162007.imail@fed1rmwml33>
	<866157.18238.qm@web37507.mail.mud.yahoo.com>
	<49BFE212.9000406@nurfuerspam.de>
Message-ID: <873279.8381.qm@web37504.mail.mud.yahoo.com>

There wasn't a whole lot of discussion, just a trading of some personal info...

Attached is a patch which can be applied to the 0.5.2 base to provide support for the SoundGraph iMON LCD devices (15c2:ffdc and 15c2:0038 right now).  It requires lirc >= 0.8.4a (I think).

I've tested this out on my Xubuntu 8.10 system with the FFDC device.
It has not been tested on a 0038 device yet - any takers?

I added support for the 0038 device (the main driver is based on the
FFDC device) and did the documentation.  Different devices are handled
via a new Protocol setting in LCDd.conf.  Currently there is the option
for the two protocols (FFDC and 0038).

Eric did the majority of the coding changes to imonlcd.c from the codeka v0.3 patch:
  *  Removed fixed "96" width listed everywhere
  *  Streamlined config file parsing
  *  Sped up font access
  *  Implemented backing store to avoid unnecessary refreshes
  *  Adjusted p->width and p->height to use character width and height properly  
  *  Fixed long long defines
  *  Replaced send_data() and send_byte_data() with send_packet()
  *  Improved send_command_data()
  *  Reduced functions for basic character drawing - removed draw_char() and draw_string()

Files modified:
      acinclude.m4
  docs/LCDd.8
  docs/lcdproc-user/drivers.docbook
  docs/lcdproc-user/lcdproc-user.docbook
  LCDd.conf
  server/drivers/Makefile.am

Files added:
  docs/lcdproc-user/drivers/imonlcd.docbook
  server/drivers/imonlcd.h
  server/drivers/imonlcd.c

Please let me know if this is working for people, and if we can get it
into the next lcdproc release! (When would that release be?)

-jonathan

===================================

(Advanced users know how to apply the patch, but for everyone else...)
To apply patch, get a new copy of lcdproc v0.5.2:
  wget http://internap.dl.sourceforge.net/sourceforge/lcdproc/lcdproc-0.5.2.tar.gz

Un-tar it, and copy the attached patch into the lcdproc-0.5.2 directory, then apply the patch:
  patch -p1 < lcdproc-0.5.2-imonlcd-0.4.patch

Run aclocal, autoconf, and automake (ignore the warning about IOWarrior.c)
Run configure with --enable-drivers=imonlcd

make it!

To install in Ubuntu:
  sudo make install
  sudo cp scripts/init-LCDd.debian /etc/init.d/LCDd
  sudo chmod +x /etc/init.d/LCDd
  sudo update-rc.d LCDd defaults

  - Make sure to modify /usr/local/etc/LCDd.conf - ensuring that DriverPath=/usr/local/lib/lcdproc/, Driver=imonlcd, and the settings under [imonlcd] are to your liking (particularly the Protocol= parameter).
  - Ensure that lirc_imon is included in /etc/modules
  sudo modprobe lirc_imon
  sudo /etc/init.d/LCDd restart


      
-------------- next part --------------
A non-text attachment was scrubbed...
Name: lcdproc-0.5.2-imonlcd-0.4.patch
Type: text/x-diff
Size: 81824 bytes
Desc: not available
URL: <http://lists.omnipotent.net/pipermail/lcdproc/attachments/20090317/5632dff1/attachment-0001.patch>

From fblack947 at yahoo.com  Wed Mar 18 03:43:54 2009
From: fblack947 at yahoo.com (jk)
Date: Tue, 17 Mar 2009 20:43:54 -0700 (PDT)
Subject: [Lcdproc] imonlcd server driver with icon support
References: <20090316184602.BCXFR.162007.imail@fed1rmwml33>
	<866157.18238.qm@web37507.mail.mud.yahoo.com>
	<49BFE212.9000406@nurfuerspam.de>
Message-ID: <813630.86795.qm@web37502.mail.mud.yahoo.com>

Attached is the patch against the current CVS for the imonlcd driver I posted earlier today.

The patch works with lcdproc, but mythlcdserver doesn't work with the CVS code, so I can't test that out.

Again, this has only been tested (as of now) against a 15c2:ffdc SoundGraph iMon and not the 15c2:0038 version.

-jonathan



      
-------------- next part --------------
A non-text attachment was scrubbed...
Name: lcdproc-CVS-imonlcd-0.4.patch
Type: text/x-diff
Size: 68152 bytes
Desc: not available
URL: <http://lists.omnipotent.net/pipermail/lcdproc/attachments/20090317/579072d2/attachment-0001.patch>

From fblack947 at yahoo.com  Wed Mar 18 04:36:11 2009
From: fblack947 at yahoo.com (jk)
Date: Tue, 17 Mar 2009 21:36:11 -0700 (PDT)
Subject: [Lcdproc] imonlcd server driver with icon support
References: <20090316184602.BCXFR.162007.imail@fed1rmwml33>
	<866157.18238.qm@web37507.mail.mud.yahoo.com>
	<49BFE212.9000406@nurfuerspam.de>
Message-ID: <873203.66129.qm@web37507.mail.mud.yahoo.com>

Apologies - the CVS patch I put up earlier is missing some of the doc files.  No idea why.

Attached is a better patch to the CVS.

generated via: cvs diff -Nu > lcdproc-CVS-imonlcd-0.4.patch
patch command from the lcdproc directory: patch -p0 < lcdproc-CVS-imonlcd-0.4.patch

-jonathan


      
-------------- next part --------------
A non-text attachment was scrubbed...
Name: lcdproc-CVS-imonlcd-0.4.patch
Type: text/x-diff
Size: 70545 bytes
Desc: not available
URL: <http://lists.omnipotent.net/pipermail/lcdproc/attachments/20090317/feca2668/attachment-0001.patch>

From epooch at cox.net  Wed Mar 18 07:02:44 2009
From: epooch at cox.net (Eric Pooch)
Date: Wed, 18 Mar 2009 00:02:44 -0700
Subject: [Lcdproc] imonlcd server driver with icon support
In-Reply-To: <813630.86795.qm@web37502.mail.mud.yahoo.com>
References: <20090316184602.BCXFR.162007.imail@fed1rmwml33>
	<866157.18238.qm@web37507.mail.mud.yahoo.com>
	<49BFE212.9000406@nurfuerspam.de>
	<813630.86795.qm@web37502.mail.mud.yahoo.com>
Message-ID: <D6A755ED-4A82-4800-8A70-7BC1FCE9152B@cox.net>

Here is a patch to Jonathan's patch that removes the built-in font in  
favor of t6963_font.h (which happens to be perfect for the imonlcd).
As a result, it also enables extended characters, icons, and lib_lcd  
functions for hbar and vbar. Please test.
--Eric
  
-------------- next part --------------
A non-text attachment was scrubbed...
Name: lcdproc-CVS-imonlcd_font.patch
Type: application/octet-stream
Size: 11832 bytes
Desc: not available
URL: <http://lists.omnipotent.net/pipermail/lcdproc/attachments/20090318/5e961174/attachment.obj>
-------------- next part --------------


On Mar 17, 2009, at 8:43 PM, jk wrote:

> Attached is the patch against the current CVS for the imonlcd  
> driver I posted earlier today.
>
> The patch works with lcdproc, but mythlcdserver doesn't work with  
> the CVS code, so I can't test that out.
>
> Again, this has only been tested (as of now) against a 15c2:ffdc  
> SoundGraph iMon and not the 15c2:0038 version.
>
> -jonathan
>
>
>
> <lcdproc-CVS- 
> imonlcd-0.4.patch>_______________________________________________
> LCDproc mailing list
> LCDproc at lists.omnipotent.net
> http://lists.omnipotent.net/mailman/listinfo/lcdproc


From fblack947 at yahoo.com  Wed Mar 18 14:57:44 2009
From: fblack947 at yahoo.com (jk)
Date: Wed, 18 Mar 2009 07:57:44 -0700 (PDT)
Subject: [Lcdproc] imonlcd server driver with icon support
References: <20090316184602.BCXFR.162007.imail@fed1rmwml33>
	<866157.18238.qm@web37507.mail.mud.yahoo.com>
	<49BFE212.9000406@nurfuerspam.de>
	<813630.86795.qm@web37502.mail.mud.yahoo.com>
	<D6A755ED-4A82-4800-8A70-7BC1FCE9152B@cox.net>
Message-ID: <845669.8744.qm@web37503.mail.mud.yahoo.com>




----- Original Message ----
> From: Eric Pooch <epooch at cox.net>
> To: jk <fblack947 at yahoo.com>
> Cc: lcdproc at lists.omnipotent.net
> Sent: Wednesday, March 18, 2009 3:02:44 AM
> Subject: Re: [Lcdproc] imonlcd server driver with icon support
> 
> Here is a patch to Jonathan's patch that removes the built-in font in favor of 
> t6963_font.h (which happens to be perfect for the imonlcd).
> As a result, it also enables extended characters, icons, and lib_lcd functions 
> for hbar and vbar. Please test.
> --Eric
> 

No joy with the built-in font.  I just get gobbedly-gook on the screen - even without running an LCD client.


-jonathan



      

From fblack947 at yahoo.com  Wed Mar 18 18:09:56 2009
From: fblack947 at yahoo.com (jk)
Date: Wed, 18 Mar 2009 11:09:56 -0700 (PDT)
Subject: [Lcdproc] imonlcd server driver with icon support
Message-ID: <42366.35161.qm@web37507.mail.mud.yahoo.com>

Attached is the updated patches to CVS, which include Eric's changes to 
which font is used (and a couple o' typos we found).  I've taken the liberty of 
naming this v0.5 of the imonlcd patch.
 
Since the list moderator wouldn't approve my putting both patches into one e-mail, 
the patch for 0.5.2 will be in a following e-mail.

Aesthetically, I prefer Dean's font choices (v0.4).  The colon is a pixel 
higher.  The progress bars are only 4 pixels high.
 
The t6963 font change (v0.5) also causes the right hand side of the "screen" to 
get clipped off.  About 2 pixels worth.  Very noticeable with a real heart 
beating on the right hand side.  Additionally, there's something weird with the 
progress bar - noticeable in lcdproc's CPU screen.  With the new font, there's a 
strange "beta" character hiding behind the progress bar, and the progress bar 
jumps in 6 pixel increments (a character).  With Dean's fonts (v0.4), the 
progress bars move in 1 pixel increments.

These are probably just slight code changes, but I prefer the 0.4 patch for now.

Again, I've only tested this on my 15c2:ffdc display with no client, lcdproc 
client, and mythlcdserver.

mythlcdserver really doesn't like some of the other changes in the current CVS.  
Works fine with patched 0.5.2.

-Jonathan



      
-------------- next part --------------
A non-text attachment was scrubbed...
Name: lcdproc-CVS-imonlcd-0.5.patch
Type: text/x-diff
Size: 64047 bytes
Desc: not available
URL: <http://lists.omnipotent.net/pipermail/lcdproc/attachments/20090318/4c9495b4/attachment-0001.patch>

From fblack947 at yahoo.com  Wed Mar 18 18:10:59 2009
From: fblack947 at yahoo.com (jk)
Date: Wed, 18 Mar 2009 11:10:59 -0700 (PDT)
Subject: [Lcdproc] imonlcd server driver with icon support
Message-ID: <663940.32919.qm@web37505.mail.mud.yahoo.com>

This e-mail includes the imonlcd v0.5 patch to the 0.5.2 release.

-Jonathan



----- Original Message ----
> From: jk <fblack947 at yahoo.com>
> To: lcdproc at lists.omnipotent.net
> Sent: Wednesday, March 18, 2009 2:09:56 PM
> Subject: Re: [Lcdproc] imonlcd server driver with icon support
> 
> Attached is the updated patches to CVS, which include Eric's changes to 
> which font is used (and a couple o' typos we found).  I've taken the liberty of 
> naming this v0.5 of the imonlcd patch.
> 
> Since the list moderator wouldn't approve my putting both patches into one 
> e-mail, 
> the patch for 0.5.2 will be in a following e-mail.
> 
> Aesthetically, I prefer Dean's font choices (v0.4).  The colon is a pixel 
> higher.  The progress bars are only 4 pixels high.
> 
> The t6963 font change (v0.5) also causes the right hand side of the "screen" to 
> get clipped off.  About 2 pixels worth.  Very noticeable with a real heart 
> beating on the right hand side.  Additionally, there's something weird with the 
> progress bar - noticeable in lcdproc's CPU screen.  With the new font, there's a 
> 
> strange "beta" character hiding behind the progress bar, and the progress bar 
> jumps in 6 pixel increments (a character).  With Dean's fonts (v0.4), the 
> progress bars move in 1 pixel increments.
> 
> These are probably just slight code changes, but I prefer the 0.4 patch for now.
> 
> Again, I've only tested this on my 15c2:ffdc display with no client, lcdproc 
> client, and mythlcdserver.
> 
> mythlcdserver really doesn't like some of the other changes in the current CVS.  
> 
> Works fine with patched 0.5.2.
> 
> -Jonathan



      
-------------- next part --------------
A non-text attachment was scrubbed...
Name: lcdproc-0.5.2-imonlcd-0.5.patch
Type: text/x-diff
Size: 75813 bytes
Desc: not available
URL: <http://lists.omnipotent.net/pipermail/lcdproc/attachments/20090318/a0647fff/attachment-0001.patch>

From fblack947 at yahoo.com  Wed Mar 18 22:53:05 2009
From: fblack947 at yahoo.com (jk)
Date: Wed, 18 Mar 2009 15:53:05 -0700 (PDT)
Subject: [Lcdproc] imonlcd server driver with icon support
References: <20090316184602.BCXFR.162007.imail@fed1rmwml33>
	<866157.18238.qm@web37507.mail.mud.yahoo.com>
	<49BFE212.9000406@nurfuerspam.de>
	<813630.86795.qm@web37502.mail.mud.yahoo.com>
	<D6A755ED-4A82-4800-8A70-7BC1FCE9152B@cox.net>
Message-ID: <10929.92261.qm@web37502.mail.mud.yahoo.com>

Attached is imonlcd driver v0.5.1 patch for the current CVS - bugfixes to the last one.

v0.5.1 uses the t6963_font (tweaking the colon by one pixel)

v0.4 uses Dean's font, which doesn't have many extended characters, but I like his progress bars better.  (:})
Similar progress bars could be attained by further modification of t6963_font.h, but that could annoy t6963 users.

The patch which can be applied to lcdproc v0.5.2 will follow in a separate e-mail.

Please test!

-Jonathan


      
-------------- next part --------------
A non-text attachment was scrubbed...
Name: lcdproc-CVS-imonlcd-0.5.1.patch
Type: text/x-diff
Size: 64802 bytes
Desc: not available
URL: <http://lists.omnipotent.net/pipermail/lcdproc/attachments/20090318/0f6d7472/attachment-0001.patch>

From cmarkle at asperasoft.com  Thu Mar 19 01:32:22 2009
From: cmarkle at asperasoft.com (Chris Markle)
Date: Wed, 18 Mar 2009 18:32:22 -0700
Subject: [Lcdproc] Patch to pylcd.c to make get_info function work / get
	called
Message-ID: <7e1093ca0903181832ub3fd0c6w4432353736b3beda@mail.gmail.com>

Hello,

Please consider the following trivial patch to the Pyramid LCD driver
to make the get_info function work. I think in the update to rename
pylcd to pyramid, the function name for get_info got missed and
remained "pylcd_get_info". As such, the Pyramid driver get_info()
function does not get called. Now all it does is return the string
"Pyramid LCD driver", but it's nice to have this working for test
purposes. And I think the original author intended it to work.

Here you go (this was against the latest pylcd.c code from Sourceforge
as-of 3/18/09):

--- pylcd.c     2009-03-18 18:12:33.000000000 -0700
+++ pylcd.c.new 2009-03-18 18:25:21.000000000 -0700
@@ -1263,9 +1263,9 @@
  * \return         Constant string with information.
  */
 MODULE_EXPORT const char *
-pylcd_get_info (Driver *drvthis)
+pyramid_get_info (Driver *drvthis)
 {
-    static char *pylcd_info_string="Pyramid LCD driver";
+    static char *pyramid_info_string="Pyramid LCD driver";

-    return pylcd_info_string;
+    return pyramid_info_string;
 };

Thanks in advance...

Chris Markle

From fblack947 at yahoo.com  Thu Mar 19 03:25:15 2009
From: fblack947 at yahoo.com (jk)
Date: Wed, 18 Mar 2009 20:25:15 -0700 (PDT)
Subject: [Lcdproc] imonlcd server driver with icon support
Message-ID: <256887.53082.qm@web37503.mail.mud.yahoo.com>

Attached is the imonlcd driver v0.5.1 patch to use against lcdproc v0.5.2.  (gzip'd as the moderator of this list won't approve attachments+message > 120kb).
 
(Patch for CVS current in previous e-mail).
 
 > v0.5.1 uses the t6963_font (tweaking the colon by one pixel)
 > 
 > 
 > v0.4 uses Dean's font, which doesn't have many extended characters, but I like 
 
 > his progress bars better.  (:})
 > Similar progress bars could be attained by further modification of 
 t6963_font.h, 
 > but that could annoy t6963 users.
 > 
 > The patch which can be applied to lcdproc v0.5.2 will follow in a separate 
 > e-mail.
 > 
 > Please test!
 > 
 > -Jonathan



      
-------------- next part --------------
A non-text attachment was scrubbed...
Name: lcdproc-0.5.2-imonlcd-0.5.1.patch.gz
Type: application/gzip
Size: 25622 bytes
Desc: not available
URL: <http://lists.omnipotent.net/pipermail/lcdproc/attachments/20090318/46fd1949/attachment-0001.bin>

From bsdfan at nurfuerspam.de  Thu Mar 19 07:05:55 2009
From: bsdfan at nurfuerspam.de (Markus Dolze)
Date: Thu, 19 Mar 2009 08:05:55 +0100
Subject: [Lcdproc] Patch to pylcd.c to make get_info function work /
	get	called
In-Reply-To: <7e1093ca0903181832ub3fd0c6w4432353736b3beda@mail.gmail.com>
References: <7e1093ca0903181832ub3fd0c6w4432353736b3beda@mail.gmail.com>
Message-ID: <20090319070555.232460@gmx.net>

-------- Original-Nachricht --------
> Datum: Wed, 18 Mar 2009 18:32:22 -0700
> Von: Chris Markle <cmarkle at asperasoft.com>
> An: lcdproc at lists.omnipotent.net
> Betreff: [Lcdproc] Patch to pylcd.c to make get_info function work / get	called

> Hello,
> 
> Please consider the following trivial patch to the Pyramid LCD driver
> to make the get_info function work. I think in the update to rename
> pylcd to pyramid, the function name for get_info got missed and
> remained "pylcd_get_info". As such, the Pyramid driver get_info()
> function does not get called. Now all it does is return the string
> "Pyramid LCD driver", but it's nice to have this working for test
> purposes. And I think the original author intended it to work.
> 

Commited to CVS.

CVS history shows the function was correctly renamed but that change was reverted by another update.

Markus

From fblack947 at yahoo.com  Thu Mar 19 13:57:10 2009
From: fblack947 at yahoo.com (jk)
Date: Thu, 19 Mar 2009 06:57:10 -0700 (PDT)
Subject: [Lcdproc] imonlcd server driver with icon support
References: <256887.53082.qm@web37503.mail.mud.yahoo.com>
	<F31C32F0-1762-4317-8250-7A0DDA85BF3E@cox.net>
	<448F0E9D-E2CA-4BC7-B15A-B64224AC5181@cox.net>
Message-ID: <908595.86046.qm@web37503.mail.mud.yahoo.com>


Eric wrote:
-----------------------------------------
> I noticed a problem with t6963_font.  it is a global variable, and a memory hog.
> I may fix this in the future by wrapping it in a function and having imonlcd parse it 
> into bytes at init time, instead of on every imonlcd_chr.
> --Eric

Does it make sense to just translate the extended characters from the t6963 font into Dean's original structure?

Memory management is definitely not my strong point, but Dean's structure should be far more compact than the t6963_font - it'd be parsed into bytes before compile time.

-Jonathan


      

From cmarkle at asperasoft.com  Thu Mar 19 14:15:00 2009
From: cmarkle at asperasoft.com (Chris Markle)
Date: Thu, 19 Mar 2009 07:15:00 -0700
Subject: [Lcdproc] Patch to pylcd.c to make get_info function work / get
	called
In-Reply-To: <20090319070555.232460@gmx.net>
References: <7e1093ca0903181832ub3fd0c6w4432353736b3beda@mail.gmail.com>
	<20090319070555.232460@gmx.net>
Message-ID: <7e1093ca0903190715g7a7311e3qec363559253b7a7f@mail.gmail.com>

Markus,

>> Please consider the following trivial patch to the Pyramid LCD driver
>> to make the get_info function work. [...]
>
> Commited to CVS.
> CVS history shows the function was correctly renamed but that change
> was reverted by another update.

Thanks!

Chris

From fblack947 at yahoo.com  Thu Mar 19 18:17:22 2009
From: fblack947 at yahoo.com (jk)
Date: Thu, 19 Mar 2009 11:17:22 -0700 (PDT)
Subject: [Lcdproc] imonlcd server driver with icon support
References: <256887.53082.qm@web37503.mail.mud.yahoo.com>
	<F31C32F0-1762-4317-8250-7A0DDA85BF3E@cox.net>
	<448F0E9D-E2CA-4BC7-B15A-B64224AC5181@cox.net>
Message-ID: <195936.10155.qm@web37508.mail.mud.yahoo.com>

Attached is a header file for the imonlcd font based on t6963_font.h and Dean's original imonlcd font structure.

Turns out t6963_font is derived from the CP437 character set, which probably isn't ideal.

Does anyone know what character set is assumed by lcdproc?  I.e., in a call to *_chr(), what encoding is assumed for ch?


-Jonathan


      
-------------- next part --------------
A non-text attachment was scrubbed...
Name: imonlcd_font.h
Type: text/x-chdr
Size: 19565 bytes
Desc: not available
URL: <http://lists.omnipotent.net/pipermail/lcdproc/attachments/20090319/0f010683/attachment-0001.h>

From epooch at cox.net  Thu Mar 19 19:39:50 2009
From: epooch at cox.net (epooch at cox.net)
Date: Thu, 19 Mar 2009 12:39:50 -0700
Subject: [Lcdproc] imonlcd server driver with icon support
In-Reply-To: <195936.10155.qm@web37508.mail.mud.yahoo.com>
Message-ID: <20090319153950.4T01H.214701.imail@fed1rmwml40>

Jonathan 
I don't think any assumption is made.  If we are only using one character set, ISO 8859-1 is probably the best choice and is most similar to the euro_charmap in HD44780.  No fancy icons though, they would all go in the 32 escape characters. As you mention, most of the ones defined in the the t6963_font are unnecessary for our purposes. 
As for Dean's font structure, If we know where the character is based on it's ascii coding, we don't need a structure to find it.  since the server core does not get characters passed as int, there is no point in having the key be an int at this point.  Just make the whole font a simple char array. You save 4 bytes per character (depending on your system) of memory too because to don't have the key. 
--Eric 
 

---- jk <fblack947 at yahoo.com> wrote: 
> Attached is a header file for the imonlcd font based on t6963_font.h and Dean's original imonlcd font structure.
> 
> Turns out t6963_font is derived from the CP437 character set, which probably isn't ideal.
> 
> Does anyone know what character set is assumed by lcdproc?  I.e., in a call to *_chr(), what encoding is assumed for ch?
> 
> 
> -Jonathan
> 
> 
>       


From alex at pertelian.com  Thu Mar 19 21:11:39 2009
From: alex at pertelian.com (Pertelian)
Date: Thu, 19 Mar 2009 14:11:39 -0700
Subject: [Lcdproc] Pertelian and LCDProc
Message-ID: <mailman.0.1237497104.3695.lcdproc@lists.omnipotent.net>

 

Hello LCDProc members, moderators, and administrators,

I wasn't sure to who to send this email to so I selected the most like email
address.  I'm Alex Jarzebinski, CEO and President of ForeSight Systems,
makers of the Pertelian LCD.  I was browsing the LCDProc site and realized
that Pertelian is no longer listed as a recommended LCD.  It was some years
ago but after an LCDProc member compiled a quick reference guide on how to
use LCDProc with Pertelian, we were listed as a recommended supplier of
LCD's; we currently count LCDProc users as customers and in fact are still
working with LCDProc developers.  Although we do offer a flagship software
in some ways similar to LCDProc, we have always been proud to offer a self
enclosed, fully packaged, and low-cost LCD solution for this highly
innovative and powerful software package.

 

We're interested in helping LCDProc users find the perfect LCD to be used
with such an incredible application and would like again to be listed as a
potential LCD solution.  In fact, we're happy to explore any potential
partnership with LCDProc in the hopes that we can not only be relied upon as
a cost effective and dependable fully packaged LCD but also as a partner.
We're somewhat of a small company with a strong dedication to our customers
on the forefront of innovation and community development.  We offer a full
API package, OEM partnership support, price specials, volume discounts, and
an open dialog with our hardware and software development teams.  

 

If anyone has any questions, please feel free to visit our websites at
www.pertelian.com <http://www.pertelian.com/>  and www.thepertelianstore.com
<http://www.thepertelianstore.com/> , as well as email me at anytime.  

 

ForeSight Systems LLC

ALEXANDER S. JARZEBINSKI

Chief Executive Officer

(714) 657-2522

Email: alex at pertelian.com

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omnipotent.net/pipermail/lcdproc/attachments/20090319/dd058e07/attachment.htm>

From junk_inbox at verizon.net  Fri Mar 20 03:46:49 2009
From: junk_inbox at verizon.net (Jeff Artz)
Date: Thu, 19 Mar 2009 23:46:49 -0400
Subject: [Lcdproc] LCDd daemon hangs with USB Crystalfontz 634 LCD
References: <4345451E4BEF4958BD79FC703E4B780C@jartzhome>
	<B3875DA949544633A05058507CEEA665@jartzhome>
	<alpine.LNX.1.00.0901291403060.30137@green.pepper>
	<d569babb0901301551n40054a4ei83083d7e2449aad@mail.gmail.com>
	<20090131104931.290160@gmx.net>
	<d569babb0902100840v34c3c11eq446056045e7405b8@mail.gmail.com>
Message-ID: <726882FB000744B6B99A975DD6D0F3C9@jartzhome>

>
> the user privilege is changed after the signal has been sent, so this 
> should not be a problem.
>
> Would you mind sending a log output of LCDd? You will have to rebuild LCDd 
> and use "configure --enable-debug". Then use ReportLevel=5 and 
> ReportToSyslog=yes in your LCDd.conf.
-snip-
>
> The lines wave_to_parent() and child_ok_func() should appear. After this 
> you should not see a process with the parent PID anymore!
>
> Regards
> Markus

Hi Markus,

  Sorry for the long delay, it's been a crazy month...

  The output goes to my /var/log/messages file when 'syslog' logging is 
turned on in Fedora Core 8.  ;-)

  Here is the log output:  (Note: The mythlcdserver was running and 
connected at 23:31:18)

Mar 19 23:31:13 localhost LCDd: LCDd version 0.5dev starting
Mar 19 23:31:13 localhost LCDd: Built on Mar 19 2009, protocol version 0.3, 
API version 0.5
Mar 19 23:31:13 localhost LCDd: Using Configuration File: 
/home/mythtv/lcd/LCDd.conf
Mar 19 23:31:13 localhost LCDd: Set report level to 5, output to syslog
Mar 19 23:31:13 localhost LCDd: Server forking to background
Mar 19 23:31:13 localhost LCDd: parent = 379
Mar 19 23:31:13 localhost LCDd: Listening for queries on 127.0.0.1:13666
Mar 19 23:31:13 localhost LCDd: child = 380
Mar 19 23:31:13 localhost LCDd: CFontz: using Device /dev/lcd
Mar 19 23:31:14 localhost LCDd: Driver [CFontz] loaded
Mar 19 23:31:14 localhost LCDd: Key "Escape" is now reserved in exclusive 
mode by client [-1]
Mar 19 23:31:14 localhost LCDd: Key "Enter" is now reserved in shared mode 
by client [-1]
Mar 19 23:31:14 localhost LCDd: Key "Up" is now reserved in shared mode by 
client [-1]
Mar 19 23:31:14 localhost LCDd: Key "Down" is now reserved in shared mode by 
client [-1]
Mar 19 23:31:14 localhost LCDd: screenlist_switch: switched to screen 
[_server_screen]
Mar 19 23:31:18 localhost LCDd: Connect from host 127.0.0.1:54065 on socket 
8
Mar 19 23:31:18 localhost LCDd: Hello!
Mar 19 23:31:18 localhost LCDd: Client on socket 8 added added screen "Time"
Mar 19 23:31:18 localhost LCDd: Client on socket 8 added added screen "Menu"
Mar 19 23:31:18 localhost LCDd: Client on socket 8 added added screen 
"Music"
Mar 19 23:31:18 localhost LCDd: Client on socket 8 added added screen 
"Channel"
Mar 19 23:31:18 localhost LCDd: Client on socket 8 added added screen 
"Generic"
Mar 19 23:31:18 localhost LCDd: Client on socket 8 added added screen 
"Volume"
Mar 19 23:31:18 localhost LCDd: Client on socket 8 added added screen 
"RecStatus"
Mar 19 23:31:18 localhost LCDd: Key "A" is now reserved in shared mode by 
client [8]
Mar 19 23:31:18 localhost LCDd: Key "B" is now reserved in shared mode by 
client [8]
Mar 19 23:31:18 localhost LCDd: Key "C" is now reserved in shared mode by 
client [8]
Mar 19 23:31:18 localhost LCDd: Key "D" is now reserved in shared mode by 
client [8]
Mar 19 23:31:18 localhost LCDd: Key "E" is now reserved in shared mode by 
client [8]
Mar 19 23:31:18 localhost LCDd: Key "F" is now reserved in shared mode by 
client [8]
Mar 19 23:31:18 localhost LCDd: screenlist_switch: switched to screen [Time]
Mar 19 23:31:23 localhost LCDd: screenlist_switch: switched to screen 
[RecStatus]
Mar 19 23:31:28 localhost LCDd: screenlist_switch: switched to screen [Time]
Mar 19 23:31:33 localhost LCDd: screenlist_switch: switched to screen 
[RecStatus]
Mar 19 23:31:38 localhost LCDd: screenlist_switch: switched to screen [Time]
Mar 19 23:31:43 localhost LCDd: screenlist_switch: switched to screen 
[RecStatus]
Mar 19 23:31:48 localhost LCDd: screenlist_switch: switched to screen [Time]
Mar 19 23:31:53 localhost LCDd: screenlist_switch: switched to screen 
[RecStatus]
Mar 19 23:31:58 localhost LCDd: screenlist_switch: switched to screen [Time]
Mar 19 23:32:03 localhost LCDd: screenlist_switch: switched to screen 
[RecStatus]
Mar 19 23:32:04 localhost LCDd: Server shutting down on SIGTERM
Mar 19 23:32:04 localhost LCDd: Closing driver [CFontz]
Mar 19 23:32:04 localhost LCDd: sock_send: socket write error
Mar 19 23:32:04 localhost LCDd: screenlist_switch: switched to screen 
[_server_screen]
Mar 19 23:32:04 localhost LCDd: Key "A" was reserved in shared mode by 
client [8] and is now released
Mar 19 23:32:04 localhost LCDd: Key "B" was reserved in shared mode by 
client [8] and is now released
Mar 19 23:32:04 localhost LCDd: Key "C" was reserved in shared mode by 
client [8] and is now released
Mar 19 23:32:04 localhost LCDd: Key "D" was reserved in shared mode by 
client [8] and is now released
Mar 19 23:32:04 localhost LCDd: Key "E" was reserved in shared mode by 
client [8] and is now released
Mar 19 23:32:04 localhost LCDd: Key "F" was reserved in shared mode by 
client [8] and is now released
Mar 19 23:32:04 localhost LCDd: Key "Escape" was reserved in exclusive mode 
by client [-1] and is now released
Mar 19 23:32:04 localhost LCDd: Key "Enter" was reserved in shared mode by 
client [-1] and is now released
Mar 19 23:32:04 localhost LCDd: Key "Up" was reserved in shared mode by 
client [-1] and is now released
Mar 19 23:32:04 localhost LCDd: Key "Down" was reserved in shared mode by 
client [-1] and is now released
Mar 19 23:32:04 localhost LCDd: Exiting.
[root at mythbackend log]#

Here's a 'ps -ef' showing the processes:
[root at mythbackend log]# ps -ef |grep LCDd
root       379 32597  0 23:31 pts/1    00:00:00 /usr/local/sbin/LCDd -c 
/home/mythtv/lcd/LCDd.conf
nobody     380   379  0 23:31 ?        00:00:00 /usr/local/sbin/LCDd -c 
/home/mythtv/lcd/LCDd.conf
[root at mythbackend log]#

Jeff 


From bsdfan at nurfuerspam.de  Fri Mar 20 09:56:59 2009
From: bsdfan at nurfuerspam.de (Markus Dolze)
Date: Fri, 20 Mar 2009 10:56:59 +0100
Subject: [Lcdproc] LCDd daemon hangs with USB Crystalfontz 634 LCD
In-Reply-To: <726882FB000744B6B99A975DD6D0F3C9@jartzhome>
References: <4345451E4BEF4958BD79FC703E4B780C@jartzhome>
	<B3875DA949544633A05058507CEEA665@jartzhome>
	<alpine.LNX.1.00.0901291403060.30137@green.pepper>
	<d569babb0901301551n40054a4ei83083d7e2449aad@mail.gmail.com>
	<20090131104931.290160@gmx.net>
	<d569babb0902100840v34c3c11eq446056045e7405b8@mail.gmail.com>
	<726882FB000744B6B99A975DD6D0F3C9@jartzhome>
Message-ID: <20090320095659.247360@gmx.net>


-------- Original-Nachricht --------
> Datum: Thu, 19 Mar 2009 23:46:49 -0400
> Von: "Jeff Artz" <junk_inbox at verizon.net>
> An: "Jeff" <junk_inbox at verizon.net>, "Markus Dolze" <bsdfan at nurfuerspam.de>
> CC: lcdproc at lists.omnipotent.net
> Betreff: Re: [Lcdproc] LCDd daemon hangs with USB Crystalfontz 634 LCD

> >
> > the user privilege is changed after the signal has been sent, so this 
> > should not be a problem.
> >
> > Would you mind sending a log output of LCDd? You will have to rebuild
> LCDd 
> > and use "configure --enable-debug". Then use ReportLevel=5 and 
> > ReportToSyslog=yes in your LCDd.conf.
> -snip-
> >
> > The lines wave_to_parent() and child_ok_func() should appear. After this
> > you should not see a process with the parent PID anymore!
> >
> > Regards
> > Markus
> 
> Hi Markus,
> 
>   Sorry for the long delay, it's been a crazy month...
> 
>   The output goes to my /var/log/messages file when 'syslog' logging is 
> turned on in Fedora Core 8.  ;-)
> 
>   Here is the log output:  (Note: The mythlcdserver was running and 
> connected at 23:31:18)
> 
> Mar 19 23:31:13 localhost LCDd: LCDd version 0.5dev starting
> Mar 19 23:31:13 localhost LCDd: Built on Mar 19 2009, protocol version
> 0.3, 
> API version 0.5
> Mar 19 23:31:13 localhost LCDd: Using Configuration File: 
> /home/mythtv/lcd/LCDd.conf
> Mar 19 23:31:13 localhost LCDd: Set report level to 5, output to syslog
> Mar 19 23:31:13 localhost LCDd: Server forking to background
> Mar 19 23:31:13 localhost LCDd: parent = 379
> Mar 19 23:31:13 localhost LCDd: Listening for queries on 127.0.0.1:13666
> Mar 19 23:31:13 localhost LCDd: child = 380
> Mar 19 23:31:13 localhost LCDd: CFontz: using Device /dev/lcd
> Mar 19 23:31:14 localhost LCDd: Driver [CFontz] loaded
> Mar 19 23:31:14 localhost LCDd: Key "Escape" is now reserved in exclusive 
> mode by client [-1]
> Mar 19 23:31:14 localhost LCDd: Key "Enter" is now reserved in shared mode
> by client [-1]
> Mar 19 23:31:14 localhost LCDd: Key "Up" is now reserved in shared mode by
> client [-1]
> Mar 19 23:31:14 localhost LCDd: Key "Down" is now reserved in shared mode
> by 
> client [-1]
> Mar 19 23:31:14 localhost LCDd: screenlist_switch: switched to screen 
> [_server_screen]
> Mar 19 23:31:18 localhost LCDd: Connect from host 127.0.0.1:54065 on
> socket 
> 8
> Mar 19 23:31:18 localhost LCDd: Hello!
> Mar 19 23:31:18 localhost LCDd: Client on socket 8 added added screen
> "Time"
> Mar 19 23:31:18 localhost LCDd: Client on socket 8 added added screen
> "Menu"
> Mar 19 23:31:18 localhost LCDd: Client on socket 8 added added screen 
> "Music"
> Mar 19 23:31:18 localhost LCDd: Client on socket 8 added added screen 
> "Channel"
> Mar 19 23:31:18 localhost LCDd: Client on socket 8 added added screen 
> "Generic"
> Mar 19 23:31:18 localhost LCDd: Client on socket 8 added added screen 
> "Volume"
> Mar 19 23:31:18 localhost LCDd: Client on socket 8 added added screen 
> "RecStatus"
> Mar 19 23:31:18 localhost LCDd: Key "A" is now reserved in shared mode by 
> client [8]
> Mar 19 23:31:18 localhost LCDd: Key "B" is now reserved in shared mode by 
> client [8]
> Mar 19 23:31:18 localhost LCDd: Key "C" is now reserved in shared mode by 
> client [8]
> Mar 19 23:31:18 localhost LCDd: Key "D" is now reserved in shared mode by 
> client [8]
> Mar 19 23:31:18 localhost LCDd: Key "E" is now reserved in shared mode by 
> client [8]
> Mar 19 23:31:18 localhost LCDd: Key "F" is now reserved in shared mode by 
> client [8]
> Mar 19 23:31:18 localhost LCDd: screenlist_switch: switched to screen
> [Time]
> Mar 19 23:31:23 localhost LCDd: screenlist_switch: switched to screen 
> [RecStatus]
> Mar 19 23:31:28 localhost LCDd: screenlist_switch: switched to screen
> [Time]
> Mar 19 23:31:33 localhost LCDd: screenlist_switch: switched to screen 
> [RecStatus]
> Mar 19 23:31:38 localhost LCDd: screenlist_switch: switched to screen
> [Time]
> Mar 19 23:31:43 localhost LCDd: screenlist_switch: switched to screen 
> [RecStatus]
> Mar 19 23:31:48 localhost LCDd: screenlist_switch: switched to screen
> [Time]
> Mar 19 23:31:53 localhost LCDd: screenlist_switch: switched to screen 
> [RecStatus]
> Mar 19 23:31:58 localhost LCDd: screenlist_switch: switched to screen
> [Time]
> Mar 19 23:32:03 localhost LCDd: screenlist_switch: switched to screen 
> [RecStatus]
> Mar 19 23:32:04 localhost LCDd: Server shutting down on SIGTERM
> Mar 19 23:32:04 localhost LCDd: Closing driver [CFontz]
> Mar 19 23:32:04 localhost LCDd: sock_send: socket write error
> Mar 19 23:32:04 localhost LCDd: screenlist_switch: switched to screen 
> [_server_screen]
> Mar 19 23:32:04 localhost LCDd: Key "A" was reserved in shared mode by 
> client [8] and is now released
> Mar 19 23:32:04 localhost LCDd: Key "B" was reserved in shared mode by 
> client [8] and is now released
> Mar 19 23:32:04 localhost LCDd: Key "C" was reserved in shared mode by 
> client [8] and is now released
> Mar 19 23:32:04 localhost LCDd: Key "D" was reserved in shared mode by 
> client [8] and is now released
> Mar 19 23:32:04 localhost LCDd: Key "E" was reserved in shared mode by 
> client [8] and is now released
> Mar 19 23:32:04 localhost LCDd: Key "F" was reserved in shared mode by 
> client [8] and is now released
> Mar 19 23:32:04 localhost LCDd: Key "Escape" was reserved in exclusive
> mode 
> by client [-1] and is now released
> Mar 19 23:32:04 localhost LCDd: Key "Enter" was reserved in shared mode by
> client [-1] and is now released
> Mar 19 23:32:04 localhost LCDd: Key "Up" was reserved in shared mode by 
> client [-1] and is now released
> Mar 19 23:32:04 localhost LCDd: Key "Down" was reserved in shared mode by 
> client [-1] and is now released
> Mar 19 23:32:04 localhost LCDd: Exiting.
> [root at mythbackend log]#
> 
> Here's a 'ps -ef' showing the processes:
> [root at mythbackend log]# ps -ef |grep LCDd
> root       379 32597  0 23:31 pts/1    00:00:00 /usr/local/sbin/LCDd -c 
> /home/mythtv/lcd/LCDd.conf
> nobody     380   379  0 23:31 ?        00:00:00 /usr/local/sbin/LCDd -c 
> /home/mythtv/lcd/LCDd.conf
> [root at mythbackend log]#
> 
> Jeff 
> 

Hi Jeff,

although the server claims to run at reportlevel 5 it does not output the information I need. You will have to run 'configure' with '--enable-debug' option to enable debug output at reportlevel 5.

The resulting log will be very large. Please send it as an attachment.

Thank you,
Markus

From fblack947 at yahoo.com  Fri Mar 20 16:07:25 2009
From: fblack947 at yahoo.com (jk)
Date: Fri, 20 Mar 2009 09:07:25 -0700 (PDT)
Subject: [Lcdproc] imonlcd server driver with icon support
Message-ID: <599738.37804.qm@web37506.mail.mud.yahoo.com>

Attached is a re-vamped font file for the imonlcd driver.  Also attached is a text file to help
one visualize the characters.

It's still derived from t6963_font.h, but the characters have been re-ordered to match 
ISO 8859-15 encoding.  Most of the control characters in ISO 8859-15 have been filled
with other characters.

This character set provides a choice of vertical progress bars.  On this display, I've found
that horizontal progress bars look better when they are thinner (4 px in height).  I'm currently
undecided on the aesthetics of the vertical progress bars, so this character set has both thinner
and full versions.

I've retained a modified version of Dean's font structure to encode the font.  It should be no larger
than a straight block of chars, but easier to negotiate.

-Jonathan


      
-------------- next part --------------
A non-text attachment was scrubbed...
Name: imonlcd_font.h
Type: text/x-chdr
Size: 25642 bytes
Desc: not available
URL: <http://lists.omnipotent.net/pipermail/lcdproc/attachments/20090320/df9c83c0/attachment-0001.h>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: imonlcd_font_depict.txt
URL: <http://lists.omnipotent.net/pipermail/lcdproc/attachments/20090320/df9c83c0/attachment-0001.txt>

From lists at t3i.nl  Fri Mar 20 19:49:52 2009
From: lists at t3i.nl (theHog)
Date: Fri, 20 Mar 2009 20:49:52 +0100
Subject: [Lcdproc] MtxOrb driver is broken in lcdproc 0.5.2
Message-ID: <E1Lkkj2-0007Un-Jw@tweety.sipo.nl>

Hi,

I found that my Matrix Orbital LCD 2041 does not work correctly with the
0.5.2 version of lcdproc. The protocol that is implemented in the MtxOrb
driver has changed to that of PCB revision 2.0. This protocol is not
completely compatible with older PCB revisions (rev. 1.10-1.30 and rev.
1.50). The result is that, a.o, backlight does not work correctly on LCD
2041's prior to v2.0.

The 0.5.1 version of lcdproc includes a MtxOrb driver that does work correct.
Why didn't the MtxOrb driver maintain compatibility with existing
revisions/protocols? Breaking that is a bad thing...

Are there plans for fixing this issue?

-- theHog


From ethan.dicks at gmail.com  Fri Mar 20 20:00:08 2009
From: ethan.dicks at gmail.com (Ethan Dicks)
Date: Fri, 20 Mar 2009 16:00:08 -0400
Subject: [Lcdproc] MtxOrb driver is broken in lcdproc 0.5.2
In-Reply-To: <E1Lkkj2-0007Un-Jw@tweety.sipo.nl>
References: <E1Lkkj2-0007Un-Jw@tweety.sipo.nl>
Message-ID: <f4eb766f0903201300g668a54b3s47cc46a05c1bd62e@mail.gmail.com>

On Fri, Mar 20, 2009 at 3:49 PM, theHog <lists at t3i.nl> wrote:
> Hi,
>
> I found that my Matrix Orbital LCD 2041 does not work correctly with the
> 0.5.2 version of lcdproc. The protocol that is implemented in the MtxOrb
> driver has changed to that of PCB revision 2.0. This protocol is not
> completely compatible with older PCB revisions (rev. 1.10-1.30 and rev.
> 1.50). The result is that, a.o, backlight does not work correctly on LCD
> 2041's prior to v2.0.

Yes.  That is a known problem.  It's not only the protocol change -
AFAIK, *no* MtxOrb modules work with 0.5.2 (see below).

> The 0.5.1 version of lcdproc includes a MtxOrb driver that does work correct.
> Why didn't the MtxOrb driver maintain compatibility with existing
> revisions/protocols? Breaking that is a bad thing...

There were some changes made between 0.5.1 and 0.5.2 by someone who
did not own the hardware (risky, I know), and a simple typo is sending
the wrong command string which FUBARs the rest of the stream,
resulting in glitched characters.

> Are there plans for fixing this issue?

It was fixed months ago (and tested - I own an ancient VKD204 and now
a newer Matrix Orbital module and have tested it myself, after
debugging the problem and submitting a patch).  The fixed version is
available (along with a recent patch for backlights) by fetching the
CVS HEAD code.  The fix will be included with the 0.5.3 release,
whenever that happens.  It's very unfortunate to have something broken
that badly in a formal release (since so many users want fetchable
packages from their distros), but for now, the only way to get it to
work is to fetch source and build it.

It is possible to twiddle the 0.5.2 source yourself (the fix is
trivial), but for those who only want to fetch pre-compiled packages,
they will have to wait until the project catches up and goes through
the next release cycle (which should involve quite a bit of testing,
I'd say).

-ethan

From bsdfan at nurfuerspam.de  Fri Mar 20 22:46:20 2009
From: bsdfan at nurfuerspam.de (Markus Dolze)
Date: Fri, 20 Mar 2009 23:46:20 +0100
Subject: [Lcdproc] MtxOrb driver is broken in lcdproc 0.5.2
In-Reply-To: <f4eb766f0903201300g668a54b3s47cc46a05c1bd62e@mail.gmail.com>
References: <E1Lkkj2-0007Un-Jw@tweety.sipo.nl>
	<f4eb766f0903201300g668a54b3s47cc46a05c1bd62e@mail.gmail.com>
Message-ID: <20090320224620.100750@gmx.net>

-------- Original-Nachricht --------
> Datum: Fri, 20 Mar 2009 16:00:08 -0400
> Von: Ethan Dicks <ethan.dicks at gmail.com>
> An: theHog <lists at t3i.nl>, lcdproc at lists.omnipotent.net
> Betreff: Re: [Lcdproc] MtxOrb driver is broken in lcdproc 0.5.2

> On Fri, Mar 20, 2009 at 3:49 PM, theHog <lists at t3i.nl> wrote:
> > Hi,
> >
> > I found that my Matrix Orbital LCD 2041 does not work correctly with the
> > 0.5.2 version of lcdproc. The protocol that is implemented in the MtxOrb
> > driver has changed to that of PCB revision 2.0. This protocol is not
> > completely compatible with older PCB revisions (rev. 1.10-1.30 and rev.
> > 1.50). The result is that, a.o, backlight does not work correctly on LCD
> > 2041's prior to v2.0.
> 
> Yes.  That is a known problem.  It's not only the protocol change -
> AFAIK, *no* MtxOrb modules work with 0.5.2 (see below).


@Ethan: Is this really true? Looking at the changes between 0.5.2 and current (see attached patch), there is only one change involving the protocol and that one only affects VKD type displays.

@'theHog': Would you please describe which parts of the protocol are not compatible. Is it just the backlight or something else? The backlight issue is known and a possible solution has been submitted recently (http://lists.omnipotent.net/pipermail/lcdproc/2009-March/012776.html).


> 
> > The 0.5.1 version of lcdproc includes a MtxOrb driver that does work
> correct.
> > Why didn't the MtxOrb driver maintain compatibility with existing
> > revisions/protocols? Breaking that is a bad thing...
> 
> There were some changes made between 0.5.1 and 0.5.2 by someone who
> did not own the hardware (risky, I know), and a simple typo is sending
> the wrong command string which FUBARs the rest of the stream,
> resulting in glitched characters.
> 
> > Are there plans for fixing this issue?
> 
> It was fixed months ago (and tested - I own an ancient VKD204 and now
> a newer Matrix Orbital module and have tested it myself, after
> debugging the problem and submitting a patch).  The fixed version is
> available (along with a recent patch for backlights) by fetching the
> CVS HEAD code.  The fix will be included with the 0.5.3 release,
> whenever that happens.  It's very unfortunate to have something broken
> that badly in a formal release (since so many users want fetchable
> packages from their distros), but for now, the only way to get it to
> work is to fetch source and build it.
> 
> It is possible to twiddle the 0.5.2 source yourself (the fix is
> trivial), but for those who only want to fetch pre-compiled packages,
> they will have to wait until the project catches up and goes through
> the next release cycle (which should involve quite a bit of testing,
> I'd say).
> 

If you point me to the exact source of the problem, I will add a fix to stable-0-5-x so it will show up in the next nightly build.

Markus
-------------- next part --------------
A non-text attachment was scrubbed...
Name: MtxOrb-0.5.2-vs-current.patch
Type: application/octet-stream
Size: 8583 bytes
Desc: not available
URL: <http://lists.omnipotent.net/pipermail/lcdproc/attachments/20090320/553d4f23/attachment.obj>

From bsdfan at nurfuerspam.de  Fri Mar 20 23:13:18 2009
From: bsdfan at nurfuerspam.de (Markus Dolze)
Date: Sat, 21 Mar 2009 00:13:18 +0100
Subject: [Lcdproc] imonlcd server driver with icon support
In-Reply-To: <20090319153950.4T01H.214701.imail@fed1rmwml40>
References: <20090319153950.4T01H.214701.imail@fed1rmwml40>
Message-ID: <20090320231318.100740@gmx.net>


-------- Original-Nachricht --------
> Datum: Thu, 19 Mar 2009 12:39:50 -0700
> Von: epooch at cox.net
> An: LCDproc at lists.omnipotent.net
> Betreff: Re: [Lcdproc] imonlcd server driver with icon support

> Jonathan 
> I don't think any assumption is made.  If we are only using one character
> set, ISO 8859-1 is probably the best choice and is most similar to the
> euro_charmap in HD44780.  No fancy icons though, they would all go in the 32
> escape characters. As you mention, most of the ones defined in the the
> t6963_font are unnecessary for our purposes. 
> As for Dean's font structure, If we know where the character is based on
> it's ascii coding, we don't need a structure to find it.  since the server
> core does not get characters passed as int, there is no point in having the
> key be an int at this point.  Just make the whole font a simple char array.
> You save 4 bytes per character (depending on your system) of memory too
> because to don't have the key. 
> --Eric 
>  
> 
> ---- jk <fblack947 at yahoo.com> wrote: 
> > Attached is a header file for the imonlcd font based on t6963_font.h and
> Dean's original imonlcd font structure.
> > 
> > Turns out t6963_font is derived from the CP437 character set, which
> probably isn't ideal.
> > 
> > Does anyone know what character set is assumed by lcdproc?  I.e., in a
> call to *_chr(), what encoding is assumed for ch?
> > 
> > 
> > -Jonathan
> > 

driver_chr() and driver_string() operate with C 'char' type (typically 8 bit). The strings are read from the network layer (as sent from client) and passed to the display.

Thus, if the client does not use the same character encoding as the display there will be a mismatch. Important is the character encoding used when compiling the client program (or that of the console if a scripting language is used).

For character displays this is a common issue as these often have japanese or other language characters in the 'upper half' of the charset. Additionally these diplays map custom characters to characters 0-7. For this reason we have translation tables for different displays in the hd44780 driver.

As the imonlcd driver has full control over the characters to be displayed you could assume ISO_8859-1 (or ISO_8859-15).

Regards,
Markus

From fabian at danner-urloffen.de  Sat Mar 21 15:08:49 2009
From: fabian at danner-urloffen.de (Fabian Danner)
Date: Sat, 21 Mar 2009 16:08:49 +0100
Subject: [Lcdproc] How to use my lcd display
Message-ID: <200903211608.49798.fabian@danner-urloffen.de>

Hi, 
I have a desktop computer at home, which has a tiny lcd display on the front. 
Which just says POWER ON under linux. I know that it was possible under 
windows to change the text with a program. I don't know what kind of a display 
this thing is. hwinfo  shows me 


14: USB 00.0: 0000 Unclassified device
  [Created at usb.122]                
  UDI: /org/freedesktop/Hal/devices/usb_device_19c2_6a11_noserial_if0
  Unique ID: +rmv.KamvbnmPfVA                                        
  Parent ID: pBe4.kllrQr_lFX9                                        
  SysFS ID: /devices/pci0000:00/0000:00:02.0/usb2/2-5/2-5:1.0        
  SysFS BusID: 2-5:1.0                                               
  Hardware Class: unknown                                            
  Model: "(c)2006 Targa Targa USB Graphic Vacuum Fluorescent Display"
  Hotplug: USB                                                       
  Vendor: usb 0x19c2 "(c)2006 Targa Corporation"                     
  Device: usb 0x6a11 "Targa USB Graphic Vacuum Fluorescent Display"  
  Revision: "1.00"                                                   
  Driver: "usbhid"                                                   
  Driver Modules: "usbhid"                                           
  Speed: 12 Mbps                                                     
  Module Alias: "usb:v19C2p6A11d0100dc00dsc00dp00ic03isc00ip00"      
  Driver Info #0:                                                    
    Driver Status: usbhid is active                                  
    Driver Activation Cmd: "modprobe usbhid"                         
  Config Status: cfg=new, avail=yes, need=no, active=unknown         
  Attached to: #22 (Hub)                                 

from which i think it is the display.
So my question is can I use this device under linux and if so, how?

greetings, f.danner

From fabian at danner-urloffen.de  Sat Mar 21 15:08:49 2009
From: fabian at danner-urloffen.de (Fabian Danner)
Date: Sat, 21 Mar 2009 16:08:49 +0100
Subject: [Lcdproc] How to use my lcd display
Message-ID: <200903211608.49798.fabian@danner-urloffen.de>

Hi, 
I have a desktop computer at home, which has a tiny lcd display on the front. 
Which just says POWER ON under linux. I know that it was possible under 
windows to change the text with a program. I don't know what kind of a display 
this thing is. hwinfo  shows me 


14: USB 00.0: 0000 Unclassified device
  [Created at usb.122]                
  UDI: /org/freedesktop/Hal/devices/usb_device_19c2_6a11_noserial_if0
  Unique ID: +rmv.KamvbnmPfVA                                        
  Parent ID: pBe4.kllrQr_lFX9                                        
  SysFS ID: /devices/pci0000:00/0000:00:02.0/usb2/2-5/2-5:1.0        
  SysFS BusID: 2-5:1.0                                               
  Hardware Class: unknown                                            
  Model: "(c)2006 Targa Targa USB Graphic Vacuum Fluorescent Display"
  Hotplug: USB                                                       
  Vendor: usb 0x19c2 "(c)2006 Targa Corporation"                     
  Device: usb 0x6a11 "Targa USB Graphic Vacuum Fluorescent Display"  
  Revision: "1.00"                                                   
  Driver: "usbhid"                                                   
  Driver Modules: "usbhid"                                           
  Speed: 12 Mbps                                                     
  Module Alias: "usb:v19C2p6A11d0100dc00dsc00dp00ic03isc00ip00"      
  Driver Info #0:                                                    
    Driver Status: usbhid is active                                  
    Driver Activation Cmd: "modprobe usbhid"                         
  Config Status: cfg=new, avail=yes, need=no, active=unknown         
  Attached to: #22 (Hub)                                 

from which i think it is the display.
So my question is can I use this device under linux and if so, how?

greetings, f.danner

From bsdfan at nurfuerspam.de  Sun Mar 22 21:46:22 2009
From: bsdfan at nurfuerspam.de (Markus Dolze)
Date: Sun, 22 Mar 2009 22:46:22 +0100
Subject: [Lcdproc] Patch: smpload support for FreeBSD
In-Reply-To: <49B57666.6010409@nurfuerspam.de>
References: <49B57666.6010409@nurfuerspam.de>
Message-ID: <49C6B1AE.6000509@nurfuerspam.de>

Markus Dolze wrote:
> While working on the 'lcdproc' client I found that it does not support 
> more than 1 CPU for the 'smpload' ('P) screen on FreeBSD. Some month 
> ago and now available with FreeBSD 7.1 a new kernel function was 
> introduced which allows easy retrieving of the cpu load for every cpu.
>
> Attached is a patch which adds support for the smpload screen for 
> FreeBSD.
>

Commited this today.

Report any errors to the mailing list as usual.

Markus

From bsdfan at nurfuerspam.de  Sun Mar 22 21:53:23 2009
From: bsdfan at nurfuerspam.de (Markus Dolze)
Date: Sun, 22 Mar 2009 22:53:23 +0100
Subject: [Lcdproc] [SOLVED] LCDd daemon hangs with USB Crystalfontz 634
 LCD
In-Reply-To: <20090320095659.247360@gmx.net>
References: <4345451E4BEF4958BD79FC703E4B780C@jartzhome>	<B3875DA949544633A05058507CEEA665@jartzhome>	<alpine.LNX.1.00.0901291403060.30137@green.pepper>	<d569babb0901301551n40054a4ei83083d7e2449aad@mail.gmail.com>	<20090131104931.290160@gmx.net>	<d569babb0902100840v34c3c11eq446056045e7405b8@mail.gmail.com>	<726882FB000744B6B99A975DD6D0F3C9@jartzhome>
	<20090320095659.247360@gmx.net>
Message-ID: <49C6B353.5090206@nurfuerspam.de>

Ok, we finally got this working as Jeff reports:

> t's a thing of beauty... ;-)
>
> [mythtv at mythbackend lcdproc]$ /sbin/service LCDd start
> Starting up LCDd:                                          [  OK  ]
> [mythtv at mythbackend lcdproc]$  
>
> No hang anymore! ;-)  Amazing what a difference a single bit can make, 
> eh? ;-) 

While we discussed possible problems, the cause was simply that the 
driver had /stay_in_foreground = 1/ set. The change Jeff has been happy 
about was to set /stay_in_foreground = 0/.

I already commited this to CVS and changed it for the bayrad, ea65 and 
glk drivers as well. I have not yet changed the svga and xosd drivers as 
I don't know how these drivers are supposed to be used.

However, using /stay_in_foreground = 1/ is bogus as I will explain soon.

Regards
Markus

From bsdfan at nurfuerspam.de  Sun Mar 22 22:04:51 2009
From: bsdfan at nurfuerspam.de (Markus Dolze)
Date: Sun, 22 Mar 2009 23:04:51 +0100
Subject: [Lcdproc] Signalling in server/main.c
In-Reply-To: <4985818A.1923.44AE998@joris.robijn.net>
References: <20090131141147.142390@gmx.net>,
	<49847716.3252.3A1226@joris.robijn.net>,
	<20090201095204.173470@gmx.net>
	<4985818A.1923.44AE998@joris.robijn.net>
Message-ID: <49C6B603.1080004@nurfuerspam.de>

Joris Robijn wrote:
> On 1 Feb 2009 at 10:52, Markus Dolze wrote:
> 
>> -------- Original-Nachricht --------
>>> Datum: Sat, 31 Jan 2009 16:06:46 +0100
>>> Von: "Joris Robijn" <joris at robijn.net>
>>> An: lcdproc at lists.omnipotent.net
>>> CC: bsdfan at nurfuerspam.de
>>> Betreff: Re: [Lcdproc] Signalling in server/main.c
>>>> The whole thing is only necessary because fork() happens before the
>>>> drivers are initialized. It was after the initialization before 0.5.0.
>>>>
>>>> Does anybody of the former developers remember why fork() was moved
>>> before
>>>> the initialization?
>>> The server looses the priviledges on the parallel port after the fork.
>>> That's why the drop_privs is done after the fork and after the driver
>>> init.
>>>
>> Hi Joris,
>>
>> that's a good point. But I am not concerned about drop_privs, but about
>> the fork().
>>
>> Currently we do (simplyfied):
>>
>> CHAIN(e, parent_pid = daemonize());
>> install_signal_handlers()
>> CHAIN(e, sock_init(bind_addr, bind_port));
>> // ... Other inits
>> CHAIN(e, server_screen_init());
>> CHAIN_END()
>> wave_to_parent(parent_pid);
>> drop_privs(user);
>>
>>
>> What about:
>>
>> CHAIN(e, sock_init(bind_addr, bind_port));
>> // ... Other inits
>> CHAIN(e, server_screen_init());
>> CHAIN(e, parent_pid = daemonize());
>> install_signal_handlers()
>> CHAIN_END()
>> drop_privs(user);
>>
>> This way we may avoid the signalling at all.
>>
>> Regards,
>> Markus
> 
 > Hi Markus,
 >
 > What I mean is that the gained access to the port is lost at the fork.
 > And after the drop_privs you are no longer root so you cannot get access
 > anymore. That's why the order is like this. All related to the good ol'
 > parallel devices.
 >
 > But I wouldn't rule out the possibility that there's a better way to
 > accomplish the same.
 >
 > Joris
 >
 >
 >

Today I found another thing that got broken by the current order: If the 
driver uses /stay_in_foreground/ variable.

Currently we do:

	if (!foreground_mode) {
		CHAIN(e, parent_pid = daemonize());
	}
	...
	CHAIN(e, init_drivers());
	...
	if (!foreground_mode) {
		/* Tell to parent that startup went OK. */
		wave_to_parent(parent_pid);
	}

If a driver has /stay_in_foreground=1/ set or sets it during init, the 
value of foreground_mode is changed by the call to /init_drivers()/. The 
result is the server does not get signalled and waits in the foreground.

This issue could not be resolved, because upon /init_drivers()/ the 
server has already forked. If it waits like now it can be killed by 
Ctrl-C, but the child controlling the displays keeps running.


I will write a change for this and will sent it for discussion. But any 
idea is welcome right now.

Regards
Markus


From bsdfan at nurfuerspam.de  Sun Mar 22 22:08:49 2009
From: bsdfan at nurfuerspam.de (Markus Dolze)
Date: Sun, 22 Mar 2009 23:08:49 +0100
Subject: [Lcdproc] lcdproc doesn't switch off my backlight
In-Reply-To: <200903221453.01496.sascha.zielinski@gmx.de>
References: <200903070801.34452.sascha.zielinski@gmx.de>
	<49B4B78E.6030502@nurfuerspam.de>
	<200903221453.01496.sascha.zielinski@gmx.de>
Message-ID: <49C6B6F1.5010901@nurfuerspam.de>



Sascha wrote:
> Am Montag 09 M?rz 2009 07:30:38 schrieben Sie:
>> Sascha wrote:
>>> Hi,
>>>
>>> I set up my lcdproc.conf with these values:
>>>
>>> [Load]
>>> Active=true
>>> LowLoad=1.00
>>> HighLoad=5.00
>>>
>>> I started lcdproc while my load was under 1 and my Backlight was off.
>>> Then I started several burnMMX processes and watched my load.
>>> Right after the load goes > 5 the Backlight was starting blinking, I
>>> killed all burnMMX's and after the load was under 5 my backlight stays
>>> on. After a while all Load values were below 1.0 again and my backlight
>>> doesn't switch off.
>>>
>>> Does lcdpoc use all 3 Load values to check wether to turn the backlight
>>> on or off? Do the values have to stay at a specific time under the
>>> LowLoad?
>> Hi,
>>
>> lcdproc uses the 1 min avg load value.
>>
>> The behaviour could best be described as (its the actual code):
>>
>> if (lowLoad < highLoad) {
>>         status = (loadmax > lowLoad) ? BACKLIGHT_ON : BACKLIGHT_OFF;
>>         if (loads[lcd_wid - 2] > highLoad)
>>             status = BLINK_ON;
>>
>> In words this means:
>>
>>     * If you configured /highLoad/ to have a larger value than /lowLoad/
>>       it is updating the backlight. By setting /highLoad/ to a lower
>>       value than /lowLoad/ you can turn the whole feature off.
>>       Thereotically it would also be disabled if both are set to the
>>       same value, but I would set it to a lower value to turn it off.
>>     * BTW: The default value for the backlight is BACKLIGHT_ON, so if
>>       this feature is turned off, the backlight will always be on.
>>     * If /maxLoad/ is larger then /lowLoad/ the backlight is set to on,
>>       otherwise it is turned off. /maxLoad/ is the maximum off all
>>       displayed load values = maximum off all displayed vBars. If you
>>       are using this on your 40x4 display it could take a while until
>>       the high values have moved out of your screen.
>>     * If the newst (= rightmost) load value if above the /highLoad/
>>       limit, the display starts blinking. The blinking is turned off if
>>       the value dropped below the /highLoad/ limit on next screen update.
>>
>>
>> Works fine for me.
>>
>> Markus
> hi,
> 
> thanks for your explanation. This now works correct. I did set the lowLoad to 
> 0, because I want the display to be on, if I sit i my living room.
> I need something like a ccommandline option to toggle the backlight. 
> 
> Regards,
> Sascha
> 
> 

It is currently not possible to switch the backlight for the whole 
server on / off by a single client.

See http://lists.omnipotent.net/pipermail/lcdproc/2009-January/012603.html.

Markus

From bsdfan at nurfuerspam.de  Mon Mar 23 21:18:22 2009
From: bsdfan at nurfuerspam.de (Markus Dolze)
Date: Mon, 23 Mar 2009 22:18:22 +0100
Subject: [Lcdproc] Patch: Watchdog timer for Crystalfontz Packet
In-Reply-To: <20090308160422.175630@gmx.net>
References: <20090308160422.175630@gmx.net>
Message-ID: <49C7FC9E.6050308@nurfuerspam.de>

Markus Dolze wrote:
> is anyone interested in having this function?
>
> http://sourceforge.net/tracker2/?func=detail&aid=1989956&group_id=119&atid=300119
>
> If I receive decline or no response within the next 14 days, I will reject that patch, because:
>
> a) The driver directly calls server core functions. I think this should not happen.
>
> b) The patch is potentially dangerous: The driver has no way to request or enforce the heartbeat, instead the heartbeat depends on server, client and screen heartbeat settings. The server would have to be set to enforce the Heartbeat=on, otherwise any client could disable the heartbeat (unintentially) resulting in a system powerdown if the watchdog timeout is less than the screen duration.
>
> To fix a) an API change would be necessary so the heartbeat function does have a return value. The core could then take additional action on depending on the return value much like drivers_icon().
>   

To sum up after two weeks:

a) Currently the API does not allow drivers to hook up into the 
heartbeat function _and_ have the core do the usual heartbeat in a 
proper way.

b) Using the heartbeat function to implement a watchdog could be done in 
general.

Therefore I will not reject the patch, but defer it until we made the 
API change.

Markus

From bsdfan at nurfuerspam.de  Mon Mar 23 22:13:40 2009
From: bsdfan at nurfuerspam.de (Markus Dolze)
Date: Mon, 23 Mar 2009 23:13:40 +0100
Subject: [Lcdproc] improved imon hbars
In-Reply-To: <20090310223536.DE2122C40DB@tippex.mynet.homeunix.org>
References: <20090111142455.2A49E940566@tippex.mynet.homeunix.org>	<49B6DD48.9090108@nurfuerspam.de>
	<20090310223536.DE2122C40DB@tippex.mynet.homeunix.org>
Message-ID: <49C80994.7070800@nurfuerspam.de>

aeriksson2 at fastmail.fm wrote:
> bsdfan at nurfuerspam.de said:
>> aeriksson2 at fastmail.fm wrote:
>>> I've created this patch to the imon driver.
>>> Effectively, it uses the vbar characters to paint the non-full cell.
>>> Apart from a different look, it actually gets more info onto the display.
>>>
>>> Any interest in integrating it?
>>   
>> Hi Anders,
>> your patch didn't received any other feedback yet. I don't know if  people
>> get confused by bars moving in two directions (left/right and  up/down), but
>> I think it's a nice idea. (I will try that on my hd44780  as well.)
> 
> That's of course a possibility. I've been using it since I anounced it and, to 
> me, it makes the smp-load screen nicer. But I'm of course biased.
> 
>> If you don't object I would like to have this optional for now.
> 
> Sure thing. I'd be happy to get it in, one way or the other. Do you handle 
> that, or should I cook a patch where it's an option?
> 

Hi Anders,

attached you will find a version of your patch that adds the new hBar as 
an optional feature. Looking at my video convinced me to make it on by 
default.

Would you please test it? Especially I am interrested if the old 
behaviour could be restored. For this you will have to do:

export CPPFLAGS="-DIMON_HBARS_OLD"
./configure
make


Markus
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: imon-hbar_v2.patch
URL: <http://lists.omnipotent.net/pipermail/lcdproc/attachments/20090323/08377452/attachment.txt>

From joris at robijn.net  Mon Mar 23 22:19:05 2009
From: joris at robijn.net (Joris Robijn)
Date: Mon, 23 Mar 2009 23:19:05 +0100
Subject: [Lcdproc] Patch: Watchdog timer for Crystalfontz Packet
In-Reply-To: <49C7FC9E.6050308@nurfuerspam.de>
References: <20090308160422.175630@gmx.net>, <49C7FC9E.6050308@nurfuerspam.de>
Message-ID: <49C818E9.11890.CC7937@joris.robijn.net>

On 23 Mar 2009 at 22:18, Markus Dolze wrote:

> b) Using the heartbeat function to implement a watchdog could be done in
> general.

I don't think this is a good idea. Another client might always connect, 
raise a high priority screen and disable the heartbeat for that screen. 
Resulting in a system reboot....

Joris

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



From bsdfan at nurfuerspam.de  Mon Mar 23 22:25:09 2009
From: bsdfan at nurfuerspam.de (Markus Dolze)
Date: Mon, 23 Mar 2009 23:25:09 +0100
Subject: [Lcdproc] Patch: Watchdog timer for Crystalfontz Packet
In-Reply-To: <49C818E9.11890.CC7937@joris.robijn.net>
References: <20090308160422.175630@gmx.net>, <49C7FC9E.6050308@nurfuerspam.de>
	<49C818E9.11890.CC7937@joris.robijn.net>
Message-ID: <49C80C45.8010003@nurfuerspam.de>

Joris Robijn wrote:
> On 23 Mar 2009 at 22:18, Markus Dolze wrote:
> 
>> b) Using the heartbeat function to implement a watchdog could be done in
>> general.
> 
> I don't think this is a good idea. Another client might always connect, 
> raise a high priority screen and disable the heartbeat for that screen. 
> Resulting in a system reboot....
> 
> Joris
> 

Ok.

I was assuming the user has set heartbeat=on in LCDd.conf, overriding 
all client or screen settings.

Markus

From joris at robijn.net  Mon Mar 23 22:29:34 2009
From: joris at robijn.net (Joris Robijn)
Date: Mon, 23 Mar 2009 23:29:34 +0100
Subject: [Lcdproc] Patch: Watchdog timer for Crystalfontz Packet
In-Reply-To: <49C80C45.8010003@nurfuerspam.de>
References: <20090308160422.175630@gmx.net>,
	<49C818E9.11890.CC7937@joris.robijn.net>,
	<49C80C45.8010003@nurfuerspam.de>
Message-ID: <49C81B5E.5324.D61433@joris.robijn.net>

Ah yes that's a possibility.
But the driver could simply always write at least one byte at each flush. 
Even when nothing has changed.

Joris


On 23 Mar 2009 at 23:25, Markus Dolze wrote:

> Joris Robijn wrote:
> > On 23 Mar 2009 at 22:18, Markus Dolze wrote:
> > 
> >> b) Using the heartbeat function to implement a watchdog could be done
> >> in general.
> > 
> > I don't think this is a good idea. Another client might always connect,
> > raise a high priority screen and disable the heartbeat for that screen.
> > Resulting in a system reboot....
> > 
> > Joris
> > 
> 
> Ok.
> 
> I was assuming the user has set heartbeat=on in LCDd.conf, overriding all
> client or screen settings.
> 
> Markus

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



From allsorts at howhill.com  Mon Mar 23 23:18:26 2009
From: allsorts at howhill.com (Dave Liquorice)
Date: Mon, 23 Mar 2009 23:18:26 +0000 (GMT)
Subject: [Lcdproc] Patch: Watchdog timer for Crystalfontz Packet
In-Reply-To: <49C80C45.8010003@nurfuerspam.de>
Message-ID: <mailman.1.1237850314.3695.lcdproc@lists.omnipotent.net>

On Mon, 23 Mar 2009 23:25:09 +0100, Markus Dolze wrote:

>> I don't think this is a good idea. Another client might always connect, 
>> raise a high priority screen and disable the heartbeat for that screen. 
>> Resulting in a system reboot....
> 
> I was assuming the user has set heartbeat=on in LCDd.conf, overriding 
> all client or screen settings.

Bad assumption, I can't stand the heartbeat and turn it off in all but the 
server screen. I can see the system is still "alive" as the screens are 
changing...



From ethan.dicks at gmail.com  Tue Mar 24 01:37:24 2009
From: ethan.dicks at gmail.com (Ethan Dicks)
Date: Mon, 23 Mar 2009 21:37:24 -0400
Subject: [Lcdproc] Patch: Watchdog timer for Crystalfontz Packet
In-Reply-To: <49c818d8.020bca0a.6a58.ffffc73bSMTPIN_ADDED@mx.google.com>
References: <49C80C45.8010003@nurfuerspam.de>
	<49c818d8.020bca0a.6a58.ffffc73bSMTPIN_ADDED@mx.google.com>
Message-ID: <f4eb766f0903231837g4bb27f9ajfa51eb01f70316c7@mail.gmail.com>

On Mon, Mar 23, 2009 at 7:18 PM, Dave Liquorice <allsorts at howhill.com> wrote:
> On Mon, 23 Mar 2009 23:25:09 +0100, Markus Dolze wrote:
>
>>> I don't think this is a good idea. Another client might always connect,
>>> raise a high priority screen and disable the heartbeat for that screen.
>>> Resulting in a system reboot....
>>
>> I was assuming the user has set heartbeat=on in LCDd.conf, overriding
>> all client or screen settings.
>
> Bad assumption, I can't stand the heartbeat and turn it off in all but the
> server screen. I can see the system is still "alive" as the screens are
> changing...

I have it off all the time, myself.  I realize that the original
"purpose" of LCDproc was to have a blinky heart like some HP system,
but I just find it distracting, plus it adds extra traffic when the
server->LCD channel would otherwise be quiet, so it makes debugging
more of a needle-in-the-haystack exercise.

-ethan

From cmarkle at asperasoft.com  Tue Mar 24 04:22:07 2009
From: cmarkle at asperasoft.com (Chris Markle)
Date: Mon, 23 Mar 2009 21:22:07 -0700
Subject: [Lcdproc] Some potential issues with the Pyramid driver...
Message-ID: <7e1093ca0903232122o57d34545k40f3f009eb58f6c0@mail.gmail.com>

Hello,

I am trying to use the Pyramid driver and the lcdproc drivers
infrastructure (from the latest stable level) in basically a command
line program to write simple text strings to the Pyramid LCD. So I am
not running LCDd or lcdproc, kust using the pylcd (Pyramid) driver
from this command line tool. I am happy to show the source if it helps
but basically the program does this:

set_reporting()

config_read_file()

drivers_load_driver('pyramid")

drivers_get_info()

// here we go to output to the LCD
drivers_clear()
drivers_string(1, 1, line1)
drivers_string(1, 2, line2)
drivers_flush()

drivers_unload_all()

Basically this works for me almost all the time, but occasionally the
command takes a long (infinite?) time, at least 10 or more seconds. I
am thinking that the driver is not finishing for some reason.

Are there times when the output to the Pyramid LCD will take a long
time? Is there a bound to how long it will take? (Maybe my 10 seocnd
expectation is too short...)

I do have an strace output that I captured of a failing occurrence
that I will include below. Maybe someone that knows the Pyramid can
tell something from this. I am open as well to other debugging
suggestions...

Thanks in advance.

Chris

* * * strace of "hang" / "took too long case" follows (below this I
will include a working case) (apologies for lack of timestamps - I
will try to get a strace with the timestamps...)

execve("/etc/digiserver/lcd/lcd-print",
["/etc/digiserver/lcd/lcd-print", "-d", "GT - Ship It!",
"A2AB018E8141ACEB699EDE9294BDD1C7"...], [/* 28 vars */]) = 0
brk(0)                                  = 0x9255000
old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS,
-1, 0) = 0xb7f07000
access("/etc/ld.so.preload", R_OK)      = -1 ENOENT (No such file or directory)
open("/etc/ld.so.cache", O_RDONLY)      = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=18192, ...}) = 0
old_mmap(NULL, 18192, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb7f02000
close(3)                                = 0
open("/lib/libdl.so.2", O_RDONLY)       = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\0\f\0\000"...,
512) = 512
fstat64(3, {st_mode=S_IFREG|0755, st_size=14504, ...}) = 0
old_mmap(NULL, 12404, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE,
3, 0) = 0xeb0000
old_mmap(0xeb2000, 8192, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1000) = 0xeb2000
close(3)                                = 0
open("/lib/libc.so.6", O_RDONLY)        = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\nO\1\000"...,
512) = 512
fstat64(3, {st_mode=S_IFREG|0755, st_size=1486436, ...}) = 0
old_mmap(NULL, 1219548, PROT_READ|PROT_EXEC,
MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x11b000
old_mmap(0x23f000, 16384, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x124000) = 0x23f000
old_mmap(0x243000, 7132, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x243000
close(3)                                = 0
old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS,
-1, 0) = 0xb7f01000
set_thread_area({entry_number:-1 -> 6, base_addr:0xb7f016c0,
limit:1048575, seg_32bit:1, contents:0, read_exec_only:0,
limit_in_pages:1, seg_not_present:0, useable:1}) = 0
mprotect(0x23f000, 8192, PROT_READ)     = 0
mprotect(0xeb2000, 4096, PROT_READ)     = 0
mprotect(0xffb000, 4096, PROT_READ)     = 0
munmap(0xb7f02000, 18192)               = 0
fstat64(1, {st_mode=S_IFREG|0644, st_size=1995, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
0) = 0xb7f06000
brk(0)                                  = 0x9255000
brk(0x9276000)                          = 0x9276000
time([1237863139])                      = 1237863139
open("/etc/localtime", O_RDONLY)        = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=1017, ...}) = 0
fstat64(3, {st_mode=S_IFREG|0644, st_size=1017, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
0) = 0xb7f05000
read(3, "TZif\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\4\0\0\0\4\0"...,
4096) = 1017
close(3)                                = 0
munmap(0xb7f05000, 4096)                = 0
stat64("/etc/localtime", {st_mode=S_IFREG|0644, st_size=1017, ...}) = 0
stat64("/etc/localtime", {st_mode=S_IFREG|0644, st_size=1017, ...}) = 0
stat64("/etc/localtime", {st_mode=S_IFREG|0644, st_size=1017, ...}) = 0
socket(PF_FILE, SOCK_DGRAM, 0)          = 3
fcntl64(3, F_SETFD, FD_CLOEXEC)         = 0
connect(3, {sa_family=AF_FILE, path="/dev/log"}, 16) = 0
send(3, "<13>Mar 23 19:52:19 lcd-print: U"..., 91, MSG_NOSIGNAL) = 91
open("/etc/digiserver/lcd/lcd-print.conf", O_RDONLY) = 4
fstat64(4, {st_mode=S_IFREG|0644, st_size=25115, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
0) = 0xb7f05000
read(4, "# LCDd.conf -- configuration fil"..., 4096) = 4096
read(4, "l order  ###\n\n\n## EMAC BayRAD dr"..., 4096) = 4096
read(4, "re are 6 input keys in the CwLnx"..., 4096) = 4096
read(4, "trate of the serial port (0 for "..., 4096) = 4096
read(4, "/Left\n# ForwardKey   Forward(Go "..., 4096) = 4096
read(4, "n\nKey4Light=on\nKey5Light=on\n\n\n\n#"..., 4096) = 4096
read(4, "a non\n# standard keypad.\n# KeyMa"..., 4096) = 539
read(4, "", 4096)                       = 0
close(4)                                = 0
munmap(0xb7f05000, 4096)                = 0
time([1237863139])                      = 1237863139
stat64("/etc/localtime", {st_mode=S_IFREG|0644, st_size=1017, ...}) = 0
stat64("/etc/localtime", {st_mode=S_IFREG|0644, st_size=1017, ...}) = 0
stat64("/etc/localtime", {st_mode=S_IFREG|0644, st_size=1017, ...}) = 0
send(3, "<15>Mar 23 19:52:19 lcd-print: d"..., 101, MSG_NOSIGNAL) = 101
open("/etc/digiserver/lcd/pyramid.so", O_RDONLY) = 4
read(4, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\30\17\0"..., 512) = 512
fstat64(4, {st_mode=S_IFREG|0755, st_size=17407, ...}) = 0
old_mmap(NULL, 16300, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE,
4, 0) = 0x39c000
old_mmap(0x39f000, 4096, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 4, 0x2000) = 0x39f000
close(4)                                = 0
gettimeofday({1237863139, 582132}, NULL) = 0
gettimeofday({1237863139, 582218}, NULL) = 0
time([1237863139])                      = 1237863139
stat64("/etc/localtime", {st_mode=S_IFREG|0644, st_size=1017, ...}) = 0
stat64("/etc/localtime", {st_mode=S_IFREG|0644, st_size=1017, ...}) = 0
stat64("/etc/localtime", {st_mode=S_IFREG|0644, st_size=1017, ...}) = 0
send(3, "<14>Mar 23 19:52:19 lcd-print: p"..., 65, MSG_NOSIGNAL) = 65
open("/dev/ttyUSB0", O_RDWR)            = 4
ioctl(4, SNDCTL_TMR_TIMEBASE or TCGETS, {B115200 -opost -isig -icanon
-echo ...}) = 0
ioctl(4, SNDCTL_TMR_START or TCSETS, {B115200 -opost -isig -icanon
-echo ...}) = 0
ioctl(4, SNDCTL_TMR_TIMEBASE or TCGETS, {B115200 -opost -isig -icanon
-echo ...}) = 0
ioctl(4, TCFLSH, 0)                     = 0
select(5, [4], NULL, NULL, {0, 50000})  = 1 (in [4], left {0, 48000})
read(4, "\2", 1)                        = 1
select(5, [4], NULL, NULL, {0, 48000})  = 1 (in [4], left {0, 48000})
read(4, "N", 1)                         = 1
select(5, [4], NULL, NULL, {0, 48000})  = 1 (in [4], left {0, 48000})
read(4, "0", 1)                         = 1
select(5, [4], NULL, NULL, {0, 48000})  = 1 (in [4], left {0, 48000})
read(4, "\3", 1)                        = 1
select(5, [4], NULL, NULL, {0, 48000})  = 1 (in [4], left {0, 48000})
read(4, "\177", 1)                      = 1
write(4, "\2Q\3P", 4)                   = 4
nanosleep({0, 50000}, NULL)             = 0
nanosleep({0, 600000000}, NULL)         = 0
select(5, [4], NULL, NULL, {0, 48000})  = 1 (in [4], left {0, 48000})
read(4, "\2", 1)                        = 1
select(5, [4], NULL, NULL, {0, 48000})  = 1 (in [4], left {0, 48000})
read(4, "N", 1)                         = 1
select(5, [4], NULL, NULL, {0, 48000})  = 1 (in [4], left {0, 48000})
read(4, "0", 1)                         = 1
select(5, [4], NULL, NULL, {0, 48000})  = 1 (in [4], left {0, 48000})
read(4, "\3", 1)                        = 1
select(5, [4], NULL, NULL, {0, 48000})  = 1 (in [4], left {0, 48000})
read(4, "\177", 1)                      = 1
write(4, "\2Q\3P", 4)                   = 4
nanosleep({0, 50000}, NULL)             = 0
nanosleep({0, 600000000}, NULL)         = 0
select(5, [4], NULL, NULL, {0, 48000})  = 1 (in [4], left {0, 48000})
read(4, "\2", 1)                        = 1
select(5, [4], NULL, NULL, {0, 48000})  = 1 (in [4], left {0, 48000})
read(4, "N", 1)                         = 1
select(5, [4], NULL, NULL, {0, 48000})  = 1 (in [4], left {0, 48000})
read(4, "0", 1)                         = 1
select(5, [4], NULL, NULL, {0, 48000})  = 1 (in [4], left {0, 48000})
read(4, "\3", 1)                        = 1
select(5, [4], NULL, NULL, {0, 48000})  = 1 (in [4], left {0, 48000})
read(4, "\177", 1)                      = 1
write(4, "\2Q\3P", 4)                   = 4
nanosleep({0, 50000}, NULL)             = 0
nanosleep({0, 600000000}, NULL)         = 0
select(5, [4], NULL, NULL, {0, 48000})  = 1 (in [4], left {0, 48000})
read(4, "\2", 1)                        = 1
select(5, [4], NULL, NULL, {0, 48000})  = 1 (in [4], left {0, 48000})
read(4, "N", 1)                         = 1
select(5, [4], NULL, NULL, {0, 48000})  = 1 (in [4], left {0, 48000})
read(4, "0", 1)                         = 1
select(5, [4], NULL, NULL, {0, 48000})  = 1 (in [4], left {0, 48000})
read(4, "\3", 1)                        = 1
select(5, [4], NULL, NULL, {0, 48000})  = 1 (in [4], left {0, 48000})
read(4, "\177", 1)                      = 1
write(4, "\2Q\3P", 4)                   = 4
nanosleep({0, 50000}, NULL)             = 0
nanosleep({0, 600000000}, NULL)         = 0
select(5, [4], NULL, NULL, {0, 48000})  = 1 (in [4], left {0, 48000})
read(4, "\2", 1)                        = 1
select(5, [4], NULL, NULL, {0, 48000})  = 1 (in [4], left {0, 48000})
read(4, "N", 1)                         = 1
select(5, [4], NULL, NULL, {0, 48000})  = 1 (in [4], left {0, 48000})
read(4, "0", 1)                         = 1
select(5, [4], NULL, NULL, {0, 48000})  = 1 (in [4], left {0, 48000})
read(4, "\3", 1)                        = 1
select(5, [4], NULL, NULL, {0, 48000})  = 1 (in [4], left {0, 48000})
read(4, "\177", 1)                      = 1
write(4, "\2Q\3P", 4)                   = 4
nanosleep({0, 50000}, NULL)             = 0
nanosleep({0, 600000000}, NULL)         = 0
select(5, [4], NULL, NULL, {0, 48000})  = 1 (in [4], left {0, 48000})
read(4, "\2", 1)                        = 1
select(5, [4], NULL, NULL, {0, 48000})  = 1 (in [4], left {0, 48000})
read(4, "N", 1)                         = 1
select(5, [4], NULL, NULL, {0, 48000})  = 1 (in [4], left {0, 48000})
read(4, "0", 1)                         = 1
select(5, [4], NULL, NULL, {0, 48000})  = 1 (in [4], left {0, 48000})
read(4, "\3", 1)                        = 1
select(5, [4], NULL, NULL, {0, 48000})  = 1 (in [4], left {0, 48000})
read(4, "\177", 1)                      = 1
write(4, "\2Q\3P", 4)                   = 4
nanosleep({0, 50000}, NULL)             = 0
nanosleep({0, 600000000}, NULL)         = 0
select(5, [4], NULL, NULL, {0, 48000})  = 1 (in [4], left {0, 48000})
read(4, "\2", 1)                        = 1
select(5, [4], NULL, NULL, {0, 48000})  = 1 (in [4], left {0, 48000})
read(4, "N", 1)                         = 1
select(5, [4], NULL, NULL, {0, 48000})  = 1 (in [4], left {0, 48000})
read(4, "0", 1)                         = 1
select(5, [4], NULL, NULL, {0, 48000})  = 1 (in [4], left {0, 48000})
read(4, "\3", 1)                        = 1
select(5, [4], NULL, NULL, {0, 48000})  = 1 (in [4], left {0, 48000})
read(4, "\177", 1)                      = 1
write(4, "\2Q\3P", 4)                   = 4
nanosleep({0, 50000}, NULL)             = 0
nanosleep({0, 600000000}, NULL)         = 0
select(5, [4], NULL, NULL, {0, 48000})  = 1 (in [4], left {0, 48000})
read(4, "\2", 1)                        = 1
select(5, [4], NULL, NULL, {0, 48000})  = 1 (in [4], left {0, 48000})
read(4, "N", 1)                         = 1
select(5, [4], NULL, NULL, {0, 48000})  = 1 (in [4], left {0, 48000})
read(4, "0", 1)                         = 1
select(5, [4], NULL, NULL, {0, 48000})  = 1 (in [4], left {0, 48000})
read(4, "\3", 1)                        = 1
select(5, [4], NULL, NULL, {0, 48000})  = 1 (in [4], left {0, 48000})
read(4, "\177", 1)                      = 1
write(4, "\2Q\3P", 4)                   = 4
nanosleep({0, 50000}, NULL)             = 0
nanosleep({0, 600000000}, NULL)         = 0
select(5, [4], NULL, NULL, {0, 48000})  = 1 (in [4], left {0, 48000})
read(4, "\2", 1)                        = 1
select(5, [4], NULL, NULL, {0, 48000})  = 1 (in [4], left {0, 48000})
read(4, "N", 1)                         = 1
select(5, [4], NULL, NULL, {0, 48000})  = 1 (in [4], left {0, 48000})
read(4, "0", 1)                         = 1
select(5, [4], NULL, NULL, {0, 48000})  = 1 (in [4], left {0, 48000})
read(4, "\3", 1)                        = 1
select(5, [4], NULL, NULL, {0, 48000})  = 1 (in [4], left {0, 48000})
read(4, "\177", 1)                      = 1
write(4, "\2Q\3P", 4)                   = 4
nanosleep({0, 50000}, NULL)             = 0
nanosleep({0, 600000000}, NULL)         = 0
select(5, [4], NULL, NULL, {0, 48000})  = 1 (in [4], left {0, 48000})
read(4, "\2", 1)                        = 1
select(5, [4], NULL, NULL, {0, 48000})  = 1 (in [4], left {0, 48000})
read(4, "N", 1)                         = 1
select(5, [4], NULL, NULL, {0, 48000})  = 1 (in [4], left {0, 48000})
read(4, "0", 1)                         = 1
select(5, [4], NULL, NULL, {0, 48000})  = 1 (in [4], left {0, 48000})
read(4, "\3", 1)                        = 1
select(5, [4], NULL, NULL, {0, 48000})  = 1 (in [4], left {0, 48000})
read(4, "\177", 1)                      = 1
write(4, "\2Q\3P", 4)                   = 4
nanosleep({0, 50000}, NULL)             = 0
nanosleep({0, 600000000}, NULL)         = 0
select(5, [4], NULL, NULL, {0, 48000})  = 1 (in [4], left {0, 48000})
read(4, "\2", 1)                        = 1
select(5, [4], NULL, NULL, {0, 48000})  = 1 (in [4], left {0, 48000})
read(4, "N", 1)                         = 1
select(5, [4], NULL, NULL, {0, 48000})  = 1 (in [4], left {0, 48000})
read(4, "0", 1)                         = 1
select(5, [4], NULL, NULL, {0, 48000})  = 1 (in [4], left {0, 48000})
read(4, "\3", 1)                        = 1
select(5, [4], NULL, NULL, {0, 48000})  = 1 (in [4], left {0, 48000})
read(4, "\177", 1)                      = 1
write(4, "\2Q\3P", 4)                   = 4
nanosleep({0, 50000}, NULL)             = 0
nanosleep({0, 600000000}, NULL)         = 0
select(5, [4], NULL, NULL, {0, 48000})  = 1 (in [4], left {0, 48000})
read(4, "\2", 1)                        = 1
select(5, [4], NULL, NULL, {0, 48000})  = 1 (in [4], left {0, 48000})
read(4, "N", 1)                         = 1
select(5, [4], NULL, NULL, {0, 48000})  = 1 (in [4], left {0, 48000})
read(4, "0", 1)                         = 1
select(5, [4], NULL, NULL, {0, 48000})  = 1 (in [4], left {0, 48000})
read(4, "\3", 1)                        = 1
select(5, [4], NULL, NULL, {0, 48000})  = 1 (in [4], left {0, 48000})
read(4, "\177", 1)                      = 1
write(4, "\2Q\3P", 4)                   = 4
nanosleep({0, 50000}, NULL)             = 0
nanosleep({0, 600000000}, NULL)         = 0
select(5, [4], NULL, NULL, {0, 48000})  = 1 (in [4], left {0, 48000})
read(4, "\2", 1)                        = 1
select(5, [4], NULL, NULL, {0, 48000})  = 1 (in [4], left {0, 48000})
read(4, "N", 1)                         = 1
select(5, [4], NULL, NULL, {0, 48000})  = 1 (in [4], left {0, 48000})
read(4, "0", 1)                         = 1
select(5, [4], NULL, NULL, {0, 48000})  = 1 (in [4], left {0, 48000})
read(4, "\3", 1)                        = 1
select(5, [4], NULL, NULL, {0, 48000})  = 1 (in [4], left {0, 48000})
read(4, "\177", 1)                      = 1
write(4, "\2Q\3P", 4)                   = 4
nanosleep({0, 50000}, NULL)             = 0
nanosleep({0, 600000000}, NULL)         = 0
select(5, [4], NULL, NULL, {0, 48000})  = 1 (in [4], left {0, 48000})
read(4, "\2", 1)                        = 1
select(5, [4], NULL, NULL, {0, 48000})  = 1 (in [4], left {0, 48000})
read(4, "N", 1)                         = 1
select(5, [4], NULL, NULL, {0, 48000})  = 1 (in [4], left {0, 48000})
read(4, "0", 1)                         = 1
select(5, [4], NULL, NULL, {0, 48000})  = 1 (in [4], left {0, 48000})
read(4, "\3", 1)                        = 1
select(5, [4], NULL, NULL, {0, 48000})  = 1 (in [4], left {0, 48000})
read(4, "\177", 1)                      = 1
write(4, "\2Q\3P", 4)                   = 4
nanosleep({0, 50000}, NULL)             = 0
nanosleep({0, 600000000}, NULL)         = 0
select(5, [4], NULL, NULL, {0, 48000})  = 1 (in [4], left {0, 48000})
read(4, "\2", 1)                        = 1
select(5, [4], NULL, NULL, {0, 48000})  = 1 (in [4], left {0, 48000})
read(4, "N", 1)                         = 1
select(5, [4], NULL, NULL, {0, 48000})  = 1 (in [4], left {0, 48000})
read(4, "0", 1)                         = 1
select(5, [4], NULL, NULL, {0, 48000})  = 1 (in [4], left {0, 48000})
read(4, "\3", 1)                        = 1
select(5, [4], NULL, NULL, {0, 48000})  = 1 (in [4], left {0, 48000})
read(4, "\177", 1)                      = 1
write(4, "\2Q\3P", 4)                   = 4
nanosleep({0, 50000}, NULL)             = 0
nanosleep({0, 600000000}, NULL)         = 0
select(5, [4], NULL, NULL, {0, 48000})  = 1 (in [4], left {0, 48000})
read(4, "\2", 1)                        = 1
select(5, [4], NULL, NULL, {0, 48000})  = 1 (in [4], left {0, 48000})
read(4, "N", 1)                         = 1
select(5, [4], NULL, NULL, {0, 48000})  = 1 (in [4], left {0, 48000})
read(4, "0", 1)                         = 1
select(5, [4], NULL, NULL, {0, 48000})  = 1 (in [4], left {0, 48000})
read(4, "\3", 1)                        = 1
select(5, [4], NULL, NULL, {0, 48000})  = 1 (in [4], left {0, 48000})
read(4, "\177", 1)                      = 1
write(4, "\2Q\3P", 4)                   = 4
nanosleep({0, 50000}, NULL)             = 0
nanosleep({0, 600000000}, NULL)         = 0
select(5, [4], NULL, NULL, {0, 48000})  = 1 (in [4], left {0, 48000})
read(4, "\2", 1)                        = 1
select(5, [4], NULL, NULL, {0, 48000})  = 1 (in [4], left {0, 48000})
read(4, "N", 1)                         = 1
select(5, [4], NULL, NULL, {0, 48000})  = 1 (in [4], left {0, 48000})
read(4, "0", 1)                         = 1
select(5, [4], NULL, NULL, {0, 48000})  = 1 (in [4], left {0, 48000})
read(4, "\3", 1)                        = 1
select(5, [4], NULL, NULL, {0, 48000})  = 1 (in [4], left {0, 48000})
read(4, "\177", 1)                      = 1
write(4, "\2Q\3P", 4)                   = 4
nanosleep({0, 50000}, NULL)             = 0
nanosleep({0, 600000000}, NULL)         = 0
select(5, [4], NULL, NULL, {0, 48000})  = 1 (in [4], left {0, 48000})
read(4, "\2", 1)                        = 1
select(5, [4], NULL, NULL, {0, 48000})  = 1 (in [4], left {0, 48000})
read(4, "N", 1)                         = 1
select(5, [4], NULL, NULL, {0, 48000})  = 1 (in [4], left {0, 48000})
read(4, "0", 1)                         = 1
select(5, [4], NULL, NULL, {0, 48000})  = 1 (in [4], left {0, 48000})
read(4, "\3", 1)                        = 1
select(5, [4], NULL, NULL, {0, 48000})  = 1 (in [4], left {0, 48000})
read(4, "\177", 1)                      = 1
write(4, "\2Q\3P", 4)                   = 4
nanosleep({0, 50000}, NULL)             = 0
nanosleep({0, 600000000}, NULL)         = 0
select(5, [4], NULL, NULL, {0, 48000})  = 1 (in [4], left {0, 48000})
read(4, "\2", 1)                        = 1
select(5, [4], NULL, NULL, {0, 48000})  = 1 (in [4], left {0, 48000})
read(4, "N", 1)                         = 1
select(5, [4], NULL, NULL, {0, 48000})  = 1 (in [4], left {0, 48000})
read(4, "0", 1)                         = 1
select(5, [4], NULL, NULL, {0, 48000})  = 1 (in [4], left {0, 48000})
read(4, "\3", 1)                        = 1
select(5, [4], NULL, NULL, {0, 48000})  = 1 (in [4], left {0, 48000})
read(4, "\177", 1)                      = 1
write(4, "\2Q\3P", 4)                   = 4
nanosleep({0, 50000}, NULL)             = 0
nanosleep({0, 600000000}, NULL)         = 0
select(5, [4], NULL, NULL, {0, 48000})  = 1 (in [4], left {0, 48000})
read(4, "\2", 1)                        = 1
select(5, [4], NULL, NULL, {0, 48000})  = 1 (in [4], left {0, 48000})
read(4, "N", 1)                         = 1
select(5, [4], NULL, NULL, {0, 48000})  = 1 (in [4], left {0, 48000})
read(4, "0", 1)                         = 1
select(5, [4], NULL, NULL, {0, 48000})  = 1 (in [4], left {0, 48000})
read(4, "\3", 1)                        = 1
select(5, [4], NULL, NULL, {0, 48000})  = 1 (in [4], left {0, 48000})
read(4, "\177", 1)                      = 1
write(4, "\2Q\3P", 4)                   = 4
nanosleep({0, 50000}, NULL)             = 0
nanosleep({0, 600000000}, NULL)         = 0
select(5, [4], NULL, NULL, {0, 48000})  = 1 (in [4], left {0, 48000})
read(4, "\2", 1)                        = 1
select(5, [4], NULL, NULL, {0, 48000})  = 1 (in [4], left {0, 48000})
read(4, "N", 1)                         = 1
select(5, [4], NULL, NULL, {0, 48000})  = 1 (in [4], left {0, 48000})
read(4, "0", 1)                         = 1
select(5, [4], NULL, NULL, {0, 48000})  = 1 (in [4], left {0, 48000})
read(4, "\3", 1)                        = 1
select(5, [4], NULL, NULL, {0, 48000})  = 1 (in [4], left {0, 48000})
read(4, "\177", 1)                      = 1
write(4, "\2Q\3P", 4)                   = 4
nanosleep({0, 50000}, NULL)             = 0
nanosleep({0, 600000000}, NULL)         = 0
select(5, [4], NULL, NULL, {0, 48000})  = 1 (in [4], left {0, 48000})
read(4, "\2", 1)                        = 1
select(5, [4], NULL, NULL, {0, 48000})  = 1 (in [4], left {0, 48000})
read(4, "N", 1)                         = 1
select(5, [4], NULL, NULL, {0, 48000})  = 1 (in [4], left {0, 48000})
read(4, "0", 1)                         = 1
select(5, [4], NULL, NULL, {0, 48000})  = 1 (in [4], left {0, 48000})
read(4, "\3", 1)                        = 1
select(5, [4], NULL, NULL, {0, 48000})  = 1 (in [4], left {0, 48000})
read(4, "\177", 1)                      = 1
write(4, "\2Q\3P", 4)                   = 4
nanosleep({0, 50000}, NULL)             = 0
nanosleep({0, 600000000}, NULL)         = 0
select(5, [4], NULL, NULL, {0, 48000})  = 0 (Timeout)
write(4, "\2R\3S", 4)                   = 4
nanosleep({0, 50000}, NULL)             = 0
write(4, "\2C0101\3B", 8)               = 8
nanosleep({0, 50000}, NULL)             = 0
write(4, "\2D                              "..., 36) = 36
nanosleep({0, 50000}, NULL)             = 0
write(4, "\2C0101\3B", 8)               = 8
nanosleep({0, 50000}, NULL)             = 0
write(4, "\2M3\3\177", 5)               = 5
nanosleep({0, 50000}, NULL)             = 0
write(4, "\2L11\33\244\33\0369\3\316", 11) = 11
nanosleep({0, 50000}, NULL)             = 0
write(4, "\2L20\33\244\33\0369\3\314", 11) = 11
nanosleep({0, 50000}, NULL)             = 0
write(4, "\2L30\33\244\33\0369\3\315", 11) = 11
nanosleep({0, 50000}, NULL)             = 0
write(4, "\2L40\33\244\33\0369\3\312", 11) = 11
nanosleep({0, 50000}, NULL)             = 0
write(4, "\2L50\33\244\33\0369\3\313", 11) = 11
nanosleep({0, 50000}, NULL)             = 0
write(4, "\2L60\33\244\33\0369\3\310", 11) = 11
nanosleep({0, 50000}, NULL)             = 0
write(4, "\2L70\33\244\33\0369\3\311", 11) = 11
nanosleep({0, 50000}, NULL)             = 0
nanosleep({0, 10000000}, NULL)          = 0
write(4, "\2L10\33\244\33\0369\3\317", 11) = 11
nanosleep({0, 50000}, NULL)             = 0
write(4, "\2L21\33\244\33\0369\3\315", 11) = 11
nanosleep({0, 50000}, NULL)             = 0
write(4, "\2L30\33\244\33\0369\3\315", 11) = 11
nanosleep({0, 50000}, NULL)             = 0
write(4, "\2L40\33\244\33\0369\3\312", 11) = 11
nanosleep({0, 50000}, NULL)             = 0
write(4, "\2L50\33\244\33\0369\3\313", 11) = 11
nanosleep({0, 50000}, NULL)             = 0
write(4, "\2L60\33\244\33\0369\3\310", 11) = 11
nanosleep({0, 50000}, NULL)             = 0
write(4, "\2L70\33\244\33\0369\3\311", 11) = 11
nanosleep({0, 50000}, NULL)             = 0
nanosleep({0, 10000000}, NULL)          = 0
write(4, "\2L10\33\244\33\0369\3\317", 11) = 11
nanosleep({0, 50000}, NULL)             = 0
write(4, "\2L20\33\244\33\0369\3\314", 11) = 11
nanosleep({0, 50000}, NULL)             = 0
write(4, "\2L31\33\244\33\0369\3\314", 11) = 11
nanosleep({0, 50000}, NULL)             = 0
write(4, "\2L40\33\244\33\0369\3\312", 11) = 11
nanosleep({0, 50000}, NULL)             = 0
write(4, "\2L50\33\244\33\0369\3\313", 11) = 11
nanosleep({0, 50000}, NULL)             = 0
write(4, "\2L60\33\244\33\0369\3\310", 11) = 11
nanosleep({0, 50000}, NULL)             = 0
write(4, "\2L70\33\244\33\0369\3\311", 11) = 11
nanosleep({0, 50000}, NULL)             = 0
nanosleep({0, 10000000},  <unfinished ...>

* * * working case follows (took .75 sec or so...)

20:13:09.461338 execve("/etc/digiserver/lcd/lcd-print",
["/etc/digiserver/lcd/lcd-print", "-d", "fjshdfs", "fsjklhfdsjk"], [/*
23 vars */]) = 0
20:13:09.462208 brk(0)                  = 0x93e7000
20:13:09.462392 old_mmap(NULL, 4096, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7f75000
20:13:09.462595 access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No
such file or directory)
20:13:09.462791 open("/etc/ld.so.cache", O_RDONLY) = 3
20:13:09.462934 fstat64(3, {st_mode=S_IFREG|0644, st_size=18192, ...}) = 0
20:13:09.463144 old_mmap(NULL, 18192, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb7f70000
20:13:09.463410 close(3)                = 0
20:13:09.463549 open("/lib/libdl.so.2", O_RDONLY) = 3
20:13:09.464086 read(3,
"\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\0\f\0\000"..., 512) =
512
20:13:09.464416 fstat64(3, {st_mode=S_IFREG|0755, st_size=14504, ...}) = 0
20:13:09.464902 old_mmap(NULL, 12404, PROT_READ|PROT_EXEC,
MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xac7000
20:13:09.465157 old_mmap(0xac9000, 8192, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1000) = 0xac9000
20:13:09.465373 close(3)                = 0
20:13:09.465507 open("/lib/libc.so.6", O_RDONLY) = 3
20:13:09.465772 read(3,
"\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\nO\1\000"..., 512) =
512
20:13:09.465943 fstat64(3, {st_mode=S_IFREG|0755, st_size=1486436, ...}) = 0
20:13:09.466144 old_mmap(NULL, 1219548, PROT_READ|PROT_EXEC,
MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x89c000
20:13:09.466312 old_mmap(0x9c0000, 16384, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x124000) = 0x9c0000
20:13:09.466507 old_mmap(0x9c4000, 7132, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x9c4000
20:13:09.466684 close(3)                = 0
20:13:09.466835 old_mmap(NULL, 4096, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7f6f000
20:13:09.467002 set_thread_area({entry_number:-1 -> 6,
base_addr:0xb7f6f6c0, limit:1048575, seg_32bit:1, contents:0,
read_exec_only:0, limit_in_pages:1, seg_not_present:0, useable:1}) = 0
20:13:09.467371 mprotect(0x9c0000, 8192, PROT_READ) = 0
20:13:09.467536 mprotect(0xac9000, 4096, PROT_READ) = 0
20:13:09.467680 mprotect(0x164000, 4096, PROT_READ) = 0
20:13:09.467809 munmap(0xb7f70000, 18192) = 0
20:13:09.468040 fstat64(1, {st_mode=S_IFREG|0644, st_size=2300, ...}) = 0
20:13:09.468238 mmap2(NULL, 4096, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7f74000
20:13:09.468465 brk(0)                  = 0x93e7000
20:13:09.468574 brk(0x9408000)          = 0x9408000
20:13:09.468706 time([1237864389])      = 1237864389
20:13:09.468840 open("/etc/localtime", O_RDONLY) = 3
20:13:09.468985 fstat64(3, {st_mode=S_IFREG|0644, st_size=1017, ...}) = 0
20:13:09.469173 fstat64(3, {st_mode=S_IFREG|0644, st_size=1017, ...}) = 0
20:13:09.469363 mmap2(NULL, 4096, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7f73000
20:13:09.469482 read(3,
"TZif\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\4\0\0\0\4\0"..., 4096) =
1017
20:13:09.469653 close(3)                = 0
20:13:09.469762 munmap(0xb7f73000, 4096) = 0
20:13:09.469892 stat64("/etc/localtime", {st_mode=S_IFREG|0644,
st_size=1017, ...}) = 0
20:13:09.470114 stat64("/etc/localtime", {st_mode=S_IFREG|0644,
st_size=1017, ...}) = 0
20:13:09.470326 stat64("/etc/localtime", {st_mode=S_IFREG|0644,
st_size=1017, ...}) = 0
20:13:09.470563 socket(PF_FILE, SOCK_DGRAM, 0) = 3
20:13:09.470709 fcntl64(3, F_SETFD, FD_CLOEXEC) = 0
20:13:09.470829 connect(3, {sa_family=AF_FILE, path="/dev/log"}, 16) = 0
20:13:09.470989 send(3, "<13>Mar 23 20:13:09 lcd-print: U"..., 91,
MSG_NOSIGNAL) = 91
20:13:09.471146 open("/etc/digiserver/lcd/lcd-print.conf", O_RDONLY) = 4
20:13:09.471325 fstat64(4, {st_mode=S_IFREG|0644, st_size=25115, ...}) = 0
20:13:09.471517 mmap2(NULL, 4096, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7f73000
20:13:09.471633 read(4, "# LCDd.conf -- configuration fil"..., 4096) = 4096
20:13:09.472066 read(4, "l order  ###\n\n\n## EMAC BayRAD dr"..., 4096) = 4096
20:13:09.472481 read(4, "re are 6 input keys in the CwLnx"..., 4096) = 4096
20:13:09.472937 read(4, "trate of the serial port (0 for "..., 4096) = 4096
20:13:09.473349 read(4, "/Left\n# ForwardKey   Forward(Go "..., 4096) = 4096
20:13:09.473767 read(4, "n\nKey4Light=on\nKey5Light=on\n\n\n\n#"...,
4096) = 4096
20:13:09.474201 read(4, "a non\n# standard keypad.\n# KeyMa"..., 4096) = 539
20:13:09.474384 read(4, "", 4096)       = 0
20:13:09.474498 close(4)                = 0
20:13:09.474607 munmap(0xb7f73000, 4096) = 0
20:13:09.474755 time([1237864389])      = 1237864389
20:13:09.474879 stat64("/etc/localtime", {st_mode=S_IFREG|0644,
st_size=1017, ...}) = 0
20:13:09.475092 stat64("/etc/localtime", {st_mode=S_IFREG|0644,
st_size=1017, ...}) = 0
20:13:09.475309 stat64("/etc/localtime", {st_mode=S_IFREG|0644,
st_size=1017, ...}) = 0
20:13:09.475550 send(3, "<15>Mar 23 20:13:09 lcd-print: d"..., 101,
MSG_NOSIGNAL) = 101
20:13:09.475723 open("/etc/digiserver/lcd/pyramid.so", O_RDONLY) = 4
20:13:09.475883 read(4,
"\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\30\17\0"..., 512) =
512
20:13:09.476045 fstat64(4, {st_mode=S_IFREG|0755, st_size=17407, ...}) = 0
20:13:09.476238 old_mmap(NULL, 16300, PROT_READ|PROT_EXEC,
MAP_PRIVATE|MAP_DENYWRITE, 4, 0) = 0xa42000
20:13:09.476405 old_mmap(0xa45000, 4096, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 4, 0x2000) = 0xa45000
20:13:09.476580 close(4)                = 0
20:13:09.476879 gettimeofday({1237864389, 476938}, NULL) = 0
20:13:09.477001 gettimeofday({1237864389, 477055}, NULL) = 0
20:13:09.477132 time([1237864389])      = 1237864389
20:13:09.477249 stat64("/etc/localtime", {st_mode=S_IFREG|0644,
st_size=1017, ...}) = 0
20:13:09.477461 stat64("/etc/localtime", {st_mode=S_IFREG|0644,
st_size=1017, ...}) = 0
20:13:09.477675 stat64("/etc/localtime", {st_mode=S_IFREG|0644,
st_size=1017, ...}) = 0
20:13:09.477905 send(3, "<14>Mar 23 20:13:09 lcd-print: p"..., 65,
MSG_NOSIGNAL) = 65
20:13:09.478055 open("/dev/ttyUSB0", O_RDWR) = 4
20:13:09.483866 ioctl(4, SNDCTL_TMR_TIMEBASE or TCGETS, {B115200
-opost -isig -icanon -echo ...}) = 0
20:13:09.484075 ioctl(4, SNDCTL_TMR_START or TCSETS, {B115200 -opost
-isig -icanon -echo ...}) = 0
20:13:09.486857 ioctl(4, SNDCTL_TMR_TIMEBASE or TCGETS, {B115200
-opost -isig -icanon -echo ...}) = 0
20:13:09.487001 ioctl(4, TCFLSH, 0)     = 0
20:13:09.487119 select(5, [4], NULL, NULL, {0, 50000}) = 0 (Timeout)
20:13:09.539398 write(4, "\2R\3S", 4)   = 4
20:13:09.539567 nanosleep({0, 50000}, NULL) = 0
20:13:09.543369 write(4, "\2C0101\3B", 8) = 8
20:13:09.543501 nanosleep({0, 50000}, NULL) = 0
20:13:09.547367 write(4, "\2D                              "..., 36) = 36
20:13:09.547515 nanosleep({0, 50000}, NULL) = 0
20:13:09.551367 write(4, "\2C0101\3B", 8) = 8
20:13:09.551497 nanosleep({0, 50000}, NULL) = 0
20:13:09.555370 write(4, "\2M3\3\177", 5) = 5
20:13:09.555498 nanosleep({0, 50000}, NULL) = 0
20:13:09.559368 write(4, "\2L11\33\244^\33\304\3s", 11) = 11
20:13:09.559502 nanosleep({0, 50000}, NULL) = 0
20:13:09.563368 write(4, "\2L20\33\244^\33\304\3q", 11) = 11
20:13:09.563501 nanosleep({0, 50000}, NULL) = 0
20:13:09.567368 write(4, "\2L30\33\244^\33\304\3p", 11) = 11
20:13:09.567501 nanosleep({0, 50000}, NULL) = 0
20:13:09.571367 write(4, "\2L40\33\244^\33\304\3w", 11) = 11
20:13:09.571501 nanosleep({0, 50000}, NULL) = 0
20:13:09.575369 write(4, "\2L50\33\244^\33\304\3v", 11) = 11
20:13:09.575501 nanosleep({0, 50000}, NULL) = 0
20:13:09.579369 write(4, "\2L60\33\244^\33\304\3u", 11) = 11
20:13:09.579498 nanosleep({0, 50000}, NULL) = 0
20:13:09.583369 write(4, "\2L70\33\244^\33\304\3t", 11) = 11
20:13:09.583503 nanosleep({0, 50000}, NULL) = 0
20:13:09.587367 nanosleep({0, 10000000}, NULL) = 0
20:13:09.603374 write(4, "\2L10\33\244^\33\304\3r", 11) = 11
20:13:09.603508 nanosleep({0, 50000}, NULL) = 0
20:13:09.607371 write(4, "\2L21\33\244^\33\304\3p", 11) = 11
20:13:09.607506 nanosleep({0, 50000}, NULL) = 0
20:13:09.611371 write(4, "\2L30\33\244^\33\304\3p", 11) = 11
20:13:09.611504 nanosleep({0, 50000}, NULL) = 0
20:13:09.615371 write(4, "\2L40\33\244^\33\304\3w", 11) = 11
20:13:09.615505 nanosleep({0, 50000}, NULL) = 0
20:13:09.619397 write(4, "\2L50\33\244^\33\304\3v", 11) = 11
20:13:09.619537 nanosleep({0, 50000}, NULL) = 0
20:13:09.623372 write(4, "\2L60\33\244^\33\304\3u", 11) = 11
20:13:09.623505 nanosleep({0, 50000}, NULL) = 0
20:13:09.627372 write(4, "\2L70\33\244^\33\304\3t", 11) = 11
20:13:09.627505 nanosleep({0, 50000}, NULL) = 0
20:13:09.631372 nanosleep({0, 10000000}, NULL) = 0
20:13:09.647377 write(4, "\2L10\33\244^\33\304\3r", 11) = 11
20:13:09.647513 nanosleep({0, 50000}, NULL) = 0
20:13:09.651377 write(4, "\2L20\33\244^\33\304\3q", 11) = 11
20:13:09.651510 nanosleep({0, 50000}, NULL) = 0
20:13:09.655373 write(4, "\2L31\33\244^\33\304\3q", 11) = 11
20:13:09.655507 nanosleep({0, 50000}, NULL) = 0
20:13:09.659373 write(4, "\2L40\33\244^\33\304\3w", 11) = 11
20:13:09.659506 nanosleep({0, 50000}, NULL) = 0
20:13:09.663375 write(4, "\2L50\33\244^\33\304\3v", 11) = 11
20:13:09.663508 nanosleep({0, 50000}, NULL) = 0
20:13:09.667374 write(4, "\2L60\33\244^\33\304\3u", 11) = 11
20:13:09.667507 nanosleep({0, 50000}, NULL) = 0
20:13:09.671374 write(4, "\2L70\33\244^\33\304\3t", 11) = 11
20:13:09.671509 nanosleep({0, 50000}, NULL) = 0
20:13:09.675373 nanosleep({0, 10000000}, NULL) = 0
20:13:09.691376 write(4, "\2L10\33\244^\33\304\3r", 11) = 11
20:13:09.691510 nanosleep({0, 50000}, NULL) = 0
20:13:09.695377 write(4, "\2L20\33\244^\33\304\3q", 11) = 11
20:13:09.695510 nanosleep({0, 50000}, NULL) = 0
20:13:09.699380 write(4, "\2L30\33\244^\33\304\3p", 11) = 11
20:13:09.699513 nanosleep({0, 50000}, NULL) = 0
20:13:09.703378 write(4, "\2L41\33\244^\33\304\3v", 11) = 11
20:13:09.703512 nanosleep({0, 50000}, NULL) = 0
20:13:09.707377 write(4, "\2L50\33\244^\33\304\3v", 11) = 11
20:13:09.707510 nanosleep({0, 50000}, NULL) = 0
20:13:09.711379 write(4, "\2L60\33\244^\33\304\3u", 11) = 11
20:13:09.711512 nanosleep({0, 50000}, NULL) = 0
20:13:09.715377 write(4, "\2L70\33\244^\33\304\3t", 11) = 11
20:13:09.715510 nanosleep({0, 50000}, NULL) = 0
20:13:09.719377 nanosleep({0, 10000000}, NULL) = 0
20:13:09.735378 write(4, "\2L10\33\244^\33\304\3r", 11) = 11
20:13:09.735513 nanosleep({0, 50000}, NULL) = 0
20:13:09.739380 write(4, "\2L20\33\244^\33\304\3q", 11) = 11
20:13:09.739515 nanosleep({0, 50000}, NULL) = 0
20:13:09.743379 write(4, "\2L30\33\244^\33\304\3p", 11) = 11
20:13:09.743513 nanosleep({0, 50000}, NULL) = 0
20:13:09.747382 write(4, "\2L40\33\244^\33\304\3w", 11) = 11
20:13:09.747515 nanosleep({0, 50000}, NULL) = 0
20:13:09.751380 write(4, "\2L51\33\244^\33\304\3w", 11) = 11
20:13:09.751513 nanosleep({0, 50000}, NULL) = 0
20:13:09.755380 write(4, "\2L60\33\244^\33\304\3u", 11) = 11
20:13:09.755513 nanosleep({0, 50000}, NULL) = 0
20:13:09.759381 write(4, "\2L70\33\244^\33\304\3t", 11) = 11
20:13:09.759514 nanosleep({0, 50000}, NULL) = 0
20:13:09.763379 nanosleep({0, 10000000}, NULL) = 0
20:13:09.779382 write(4, "\2L10\33\244^\33\304\3r", 11) = 11
20:13:09.779514 nanosleep({0, 50000}, NULL) = 0
20:13:09.783383 write(4, "\2L20\33\244^\33\304\3q", 11) = 11
20:13:09.783516 nanosleep({0, 50000}, NULL) = 0
20:13:09.787381 write(4, "\2L30\33\244^\33\304\3p", 11) = 11
20:13:09.787514 nanosleep({0, 50000}, NULL) = 0
20:13:09.791382 write(4, "\2L40\33\244^\33\304\3w", 11) = 11
20:13:09.791515 nanosleep({0, 50000}, NULL) = 0
20:13:09.795386 write(4, "\2L50\33\244^\33\304\3v", 11) = 11
20:13:09.795519 nanosleep({0, 50000}, NULL) = 0
20:13:09.799383 write(4, "\2L61\33\244^\33\304\3t", 11) = 11
20:13:09.799517 nanosleep({0, 50000}, NULL) = 0
20:13:09.803382 write(4, "\2L70\33\244^\33\304\3t", 11) = 11
20:13:09.803515 nanosleep({0, 50000}, NULL) = 0
20:13:09.807382 nanosleep({0, 10000000}, NULL) = 0
20:13:09.823384 write(4, "\2L10\33\244^\33\304\3r", 11) = 11
20:13:09.823518 nanosleep({0, 50000}, NULL) = 0
20:13:09.827384 write(4, "\2L20\33\244^\33\304\3q", 11) = 11
20:13:09.827517 nanosleep({0, 50000}, NULL) = 0
20:13:09.831384 write(4, "\2L30\33\244^\33\304\3p", 11) = 11
20:13:09.831519 nanosleep({0, 50000}, NULL) = 0
20:13:09.835385 write(4, "\2L40\33\244^\33\304\3w", 11) = 11
20:13:09.835518 nanosleep({0, 50000}, NULL) = 0
20:13:09.839386 write(4, "\2L50\33\244^\33\304\3v", 11) = 11
20:13:09.839546 nanosleep({0, 50000}, NULL) = 0
20:13:09.843388 write(4, "\2L60\33\244^\33\304\3u", 11) = 11
20:13:09.843522 nanosleep({0, 50000}, NULL) = 0
20:13:09.847387 write(4, "\2L71\33\244^\33\304\3u", 11) = 11
20:13:09.847520 nanosleep({0, 50000}, NULL) = 0
20:13:09.851385 nanosleep({0, 10000000}, NULL) = 0
20:13:09.867387 write(4, "\2L10\33\244^\33\304\3r", 11) = 11
20:13:09.867521 nanosleep({0, 50000}, NULL) = 0
20:13:09.871388 write(4, "\2L20\33\244^\33\304\3q", 11) = 11
20:13:09.871521 nanosleep({0, 50000}, NULL) = 0
20:13:09.875386 write(4, "\2L30\33\244^\33\304\3p", 11) = 11
20:13:09.875516 nanosleep({0, 50000}, NULL) = 0
20:13:09.879387 write(4, "\2L40\33\244^\33\304\3w", 11) = 11
20:13:09.879518 nanosleep({0, 50000}, NULL) = 0
20:13:09.883389 write(4, "\2L50\33\244^\33\304\3v", 11) = 11
20:13:09.883522 nanosleep({0, 50000}, NULL) = 0
20:13:09.887389 write(4, "\2L60\33\244^\33\304\3u", 11) = 11
20:13:09.887522 nanosleep({0, 50000}, NULL) = 0
20:13:09.891393 write(4, "\2L71\33\244^\33\304\3u", 11) = 11
20:13:09.891527 nanosleep({0, 50000}, NULL) = 0
20:13:09.895386 nanosleep({0, 10000000}, NULL) = 0
20:13:09.911390 write(4, "\2L10\33\244^\33\304\3r", 11) = 11
20:13:09.911524 nanosleep({0, 50000}, NULL) = 0
20:13:09.915390 write(4, "\2L20\33\244^\33\304\3q", 11) = 11
20:13:09.915523 nanosleep({0, 50000}, NULL) = 0
20:13:09.919407 write(4, "\2L30\33\244^\33\304\3p", 11) = 11
20:13:09.919542 nanosleep({0, 50000}, NULL) = 0
20:13:09.923392 write(4, "\2L40\33\244^\33\304\3w", 11) = 11
20:13:09.923525 nanosleep({0, 50000}, NULL) = 0
20:13:09.927392 write(4, "\2L50\33\244^\33\304\3v", 11) = 11
20:13:09.927527 nanosleep({0, 50000}, NULL) = 0
20:13:09.931391 write(4, "\2L61\33\244^\33\304\3t", 11) = 11
20:13:09.931524 nanosleep({0, 50000}, NULL) = 0
20:13:09.935392 write(4, "\2L70\33\244^\33\304\3t", 11) = 11
20:13:09.935525 nanosleep({0, 50000}, NULL) = 0
20:13:09.939394 nanosleep({0, 10000000}, NULL) = 0
20:13:09.955393 write(4, "\2L10\33\244^\33\304\3r", 11) = 11
20:13:09.955526 nanosleep({0, 50000}, NULL) = 0
20:13:09.959397 write(4, "\2L20\33\244^\33\304\3q", 11) = 11
20:13:09.959533 nanosleep({0, 50000}, NULL) = 0
20:13:09.963394 write(4, "\2L30\33\244^\33\304\3p", 11) = 11
20:13:09.963527 nanosleep({0, 50000}, NULL) = 0
20:13:09.967394 write(4, "\2L40\33\244^\33\304\3w", 11) = 11
20:13:09.967528 nanosleep({0, 50000}, NULL) = 0
20:13:09.971395 write(4, "\2L51\33\244^\33\304\3w", 11) = 11
20:13:09.971528 nanosleep({0, 50000}, NULL) = 0
20:13:09.975394 write(4, "\2L60\33\244^\33\304\3u", 11) = 11
20:13:09.975525 nanosleep({0, 50000}, NULL) = 0
20:13:09.979394 write(4, "\2L70\33\244^\33\304\3t", 11) = 11
20:13:09.979524 nanosleep({0, 50000}, NULL) = 0
20:13:09.983396 nanosleep({0, 10000000}, NULL) = 0
20:13:09.999396 write(4, "\2L10\33\244^\33\304\3r", 11) = 11
20:13:09.999532 nanosleep({0, 50000}, NULL) = 0
20:13:10.003396 write(4, "\2L20\33\244^\33\304\3q", 11) = 11
20:13:10.003530 nanosleep({0, 50000}, NULL) = 0
20:13:10.007399 write(4, "\2L30\33\244^\33\304\3p", 11) = 11
20:13:10.007533 nanosleep({0, 50000}, NULL) = 0
20:13:10.011396 write(4, "\2L41\33\244^\33\304\3v", 11) = 11
20:13:10.011529 nanosleep({0, 50000}, NULL) = 0
20:13:10.015398 write(4, "\2L50\33\244^\33\304\3v", 11) = 11
20:13:10.015531 nanosleep({0, 50000}, NULL) = 0
20:13:10.019397 write(4, "\2L60\33\244^\33\304\3u", 11) = 11
20:13:10.019531 nanosleep({0, 50000}, NULL) = 0
20:13:10.023406 write(4, "\2L70\33\244^\33\304\3t", 11) = 11
20:13:10.023540 nanosleep({0, 50000}, NULL) = 0
20:13:10.027396 nanosleep({0, 10000000}, NULL) = 0
20:13:10.043423 write(4, "\2L10\33\244^\33\304\3r", 11) = 11
20:13:10.043580 nanosleep({0, 50000}, NULL) = 0
20:13:10.047401 write(4, "\2L20\33\244^\33\304\3q", 11) = 11
20:13:10.047535 nanosleep({0, 50000}, NULL) = 0
20:13:10.051400 write(4, "\2L31\33\244^\33\304\3q", 11) = 11
20:13:10.051534 nanosleep({0, 50000}, NULL) = 0
20:13:10.055403 write(4, "\2L40\33\244^\33\304\3w", 11) = 11
20:13:10.055536 nanosleep({0, 50000}, NULL) = 0
20:13:10.059400 write(4, "\2L50\33\244^\33\304\3v", 11) = 11
20:13:10.059570 nanosleep({0, 50000}, NULL) = 0
20:13:10.063401 write(4, "\2L60\33\244^\33\304\3u", 11) = 11
20:13:10.063534 nanosleep({0, 50000}, NULL) = 0
20:13:10.067401 write(4, "\2L70\33\244^\33\304\3t", 11) = 11
20:13:10.067535 nanosleep({0, 50000}, NULL) = 0
20:13:10.071400 nanosleep({0, 10000000}, NULL) = 0
20:13:10.087402 write(4, "\2L10\33\244^\33\304\3r", 11) = 11
20:13:10.087537 nanosleep({0, 50000}, NULL) = 0
20:13:10.091402 write(4, "\2L21\33\244^\33\304\3p", 11) = 11
20:13:10.091535 nanosleep({0, 50000}, NULL) = 0
20:13:10.095403 write(4, "\2L30\33\244^\33\304\3p", 11) = 11
20:13:10.095537 nanosleep({0, 50000}, NULL) = 0
20:13:10.099403 write(4, "\2L40\33\244^\33\304\3w", 11) = 11
20:13:10.099536 nanosleep({0, 50000}, NULL) = 0
20:13:10.103402 write(4, "\2L50\33\244^\33\304\3v", 11) = 11
20:13:10.103536 nanosleep({0, 50000}, NULL) = 0
20:13:10.107404 write(4, "\2L60\33\244^\33\304\3u", 11) = 11
20:13:10.107537 nanosleep({0, 50000}, NULL) = 0
20:13:10.111404 write(4, "\2L70\33\244^\33\304\3t", 11) = 11
20:13:10.111536 nanosleep({0, 50000}, NULL) = 0
20:13:10.115401 nanosleep({0, 10000000}, NULL) = 0
20:13:10.131407 write(4, "\2L11\33\244^\33\304\3s", 11) = 11
20:13:10.131542 nanosleep({0, 50000}, NULL) = 0
20:13:10.135405 write(4, "\2L20\33\244^\33\304\3q", 11) = 11
20:13:10.135538 nanosleep({0, 50000}, NULL) = 0
20:13:10.139404 write(4, "\2L30\33\244^\33\304\3p", 11) = 11
20:13:10.139538 nanosleep({0, 50000}, NULL) = 0
20:13:10.143405 write(4, "\2L40\33\244^\33\304\3w", 11) = 11
20:13:10.143538 nanosleep({0, 50000}, NULL) = 0
20:13:10.147407 write(4, "\2L50\33\244^\33\304\3v", 11) = 11
20:13:10.147541 nanosleep({0, 50000}, NULL) = 0
20:13:10.151406 write(4, "\2L60\33\244^\33\304\3u", 11) = 11
20:13:10.151540 nanosleep({0, 50000}, NULL) = 0
20:13:10.155406 write(4, "\2L70\33\244^\33\304\3t", 11) = 11
20:13:10.155539 nanosleep({0, 50000}, NULL) = 0
20:13:10.159406 nanosleep({0, 10000000}, NULL) = 0
20:13:10.175408 write(4, "\2L10\33\244^\33\304\3r", 11) = 11
20:13:10.175541 nanosleep({0, 50000}, NULL) = 0
20:13:10.179411 write(4, "\2L20\33\244^\33\304\3q", 11) = 11
20:13:10.179541 nanosleep({0, 50000}, NULL) = 0
20:13:10.183410 write(4, "\2L30\33\244^\33\304\3p", 11) = 11
20:13:10.183543 nanosleep({0, 50000}, NULL) = 0
20:13:10.187408 write(4, "\2L40\33\244^\33\304\3w", 11) = 11
20:13:10.187541 nanosleep({0, 50000}, NULL) = 0
20:13:10.191408 write(4, "\2L50\33\244^\33\304\3v", 11) = 11
20:13:10.191542 nanosleep({0, 50000}, NULL) = 0
20:13:10.195409 write(4, "\2L60\33\244^\33\304\3u", 11) = 11
20:13:10.195542 nanosleep({0, 50000}, NULL) = 0
20:13:10.199410 write(4, "\2L70\33\244^\33\304\3t", 11) = 11
20:13:10.199543 nanosleep({0, 50000}, NULL) = 0
20:13:10.203417 time([1237864390])      = 1237864390
20:13:10.203537 stat64("/etc/localtime", {st_mode=S_IFREG|0644,
st_size=1017, ...}) = 0
20:13:10.203755 stat64("/etc/localtime", {st_mode=S_IFREG|0644,
st_size=1017, ...}) = 0
20:13:10.203975 stat64("/etc/localtime", {st_mode=S_IFREG|0644,
st_size=1017, ...}) = 0
20:13:10.204208 send(3, "<15>Mar 23 20:13:10 lcd-print: p"..., 51,
MSG_NOSIGNAL) = 51
20:13:10.204404 time([1237864390])      = 1237864390
20:13:10.204523 stat64("/etc/localtime", {st_mode=S_IFREG|0644,
st_size=1017, ...}) = 0
20:13:10.204734 stat64("/etc/localtime", {st_mode=S_IFREG|0644,
st_size=1017, ...}) = 0
20:13:10.204946 stat64("/etc/localtime", {st_mode=S_IFREG|0644,
st_size=1017, ...}) = 0
20:13:10.205176 send(3, "<15>Mar 23 20:13:10 lcd-print: p"..., 83,
MSG_NOSIGNAL) = 83
20:13:10.205345 time([1237864390])      = 1237864390
20:13:10.205465 stat64("/etc/localtime", {st_mode=S_IFREG|0644,
st_size=1017, ...}) = 0
20:13:10.205677 stat64("/etc/localtime", {st_mode=S_IFREG|0644,
st_size=1017, ...}) = 0
20:13:10.205888 stat64("/etc/localtime", {st_mode=S_IFREG|0644,
st_size=1017, ...}) = 0
20:13:10.206118 send(3, "<15>Mar 23 20:13:10 lcd-print: d"..., 60,
MSG_NOSIGNAL) = 60
20:13:10.206284 gettimeofday({1237864390, 206340}, NULL) = 0
20:13:10.206403 write(4, "\2C0101\3B", 8) = 8
20:13:10.206538 nanosleep({0, 50000}, NULL) = 0
20:13:10.211411 write(4, "\2Dfjshdfs         fsjklhfdsjk   "..., 36) = 36
20:13:10.211594 nanosleep({0, 50000}, NULL) = 0
20:13:10.215424 write(4, "\2C0000\3B", 8) = 8
20:13:10.215557 nanosleep({0, 50000}, NULL) = 0
20:13:10.219413 write(4, "\2M0\3|", 5)  = 5
20:13:10.219542 nanosleep({0, 50000}, NULL) = 0
20:13:10.223411 close(4)                = 0
20:13:10.225854 munmap(0xa42000, 16300) = 0
20:13:10.226005 write(1, "will output line1: \"fjshdfs\" and"...,
175will output line1: "fjshdfs" and line2: "fsjklhfdsjk" via driver:
pyramid
  conf file: /etc/digiserver/lcd/lcd-print.conf, report level: 5,
syslog/stderr: syslog, debug: true
) = 175
20:13:10.226156 munmap(0xb7f74000, 4096) = 0
20:13:10.226282 exit_group(0)           = ?
Process 7563 detached

From bsdfan at nurfuerspam.de  Tue Mar 24 06:22:28 2009
From: bsdfan at nurfuerspam.de (Markus Dolze)
Date: Tue, 24 Mar 2009 07:22:28 +0100
Subject: [Lcdproc] Patch: Watchdog timer for Crystalfontz Packet
In-Reply-To: <49C80C45.8010003@nurfuerspam.de>
References: <20090308160422.175630@gmx.net>,
	<49C7FC9E.6050308@nurfuerspam.de>	<49C818E9.11890.CC7937@joris.robijn.net>
	<49C80C45.8010003@nurfuerspam.de>
Message-ID: <49C87C24.9080407@nurfuerspam.de>

Markus Dolze wrote:
> Joris Robijn wrote:
>> On 23 Mar 2009 at 22:18, Markus Dolze wrote:
>>
>>> b) Using the heartbeat function to implement a watchdog could be 
>>> done in
>>> general.
>>
>> I don't think this is a good idea. Another client might always 
>> connect, raise a high priority screen and disable the heartbeat for 
>> that screen. Resulting in a system reboot....
>>
>> Joris
>>
>
> Ok.
>
> I was assuming the user has set heartbeat=on in LCDd.conf, overriding 
> all client or screen settings.
>
>

FYI: The artificat has already been postponed on the SF tracker.

Markus

From bsdfan at nurfuerspam.de  Tue Mar 24 06:43:44 2009
From: bsdfan at nurfuerspam.de (Markus Dolze)
Date: Tue, 24 Mar 2009 07:43:44 +0100
Subject: [Lcdproc] Patch: Watchdog timer for Crystalfontz Packet
In-Reply-To: <20090323231852.5454gmx1@mx032.gmx.net>
References: <20090323231852.5454gmx1@mx032.gmx.net>
Message-ID: <49C88120.3040301@nurfuerspam.de>

Dave Liquorice wrote:
> On Mon, 23 Mar 2009 23:25:09 +0100, Markus Dolze wrote:
>
>   
>>> I don't think this is a good idea. Another client might always connect, 
>>> raise a high priority screen and disable the heartbeat for that screen. 
>>> Resulting in a system reboot....
>>>       
>> I was assuming the user has set heartbeat=on in LCDd.conf, overriding 
>> all client or screen settings.
>>     
>
> Bad assumption, I can't stand the heartbeat and turn it off in all but the 
> server screen. I can see the system is still "alive" as the screens are 
> changing...
>
>   

If the CFontz watchdog is implemented in the driver as a hook-up in 
heartbeat, the user must set heartbeat=on, otherwise there is the danger 
of unwanted system reboots as described above. It will be up to the user 
to decide.

I don't like the idea of mixing an additional 'user invisible' feature 
(watchdog) and an 'user visible' one (heartbeat) in one function as 
well, because 'user visible features' are always a matter of personal 
preference and lead to discussions like ours.

The watchdog might be intended for systems _not_ watched by a user. I 
don't know the original author's reasons.

Markus


From bsdfan at nurfuerspam.de  Tue Mar 24 08:04:11 2009
From: bsdfan at nurfuerspam.de (Markus Dolze)
Date: Tue, 24 Mar 2009 09:04:11 +0100
Subject: [Lcdproc] Patch: MtxOrb adjustable backlight and display
	detection
In-Reply-To: <20090308140131.9870@gmx.net>
References: <20090308140131.9870@gmx.net>
Message-ID: <49C893FB.5020909@nurfuerspam.de>

Hi,

I have questions on how the Display On / Off and Set Brightness commands 
of Matrix Orbital displays work:

   1. If I use the 'Display Off' command, does it just turns the
      backlight off like for older versions or does it completely turns
      the display off?
   2. If the display's backlight is off, what happens if I issue a 'Set
      Brightness' command? Does the backlight stays off until a 'Display
      On' command is issued or does the backlight automatically turns on?

Markus


From TELarson at west.com  Tue Mar 24 17:24:13 2009
From: TELarson at west.com (Larson, Timothy E.)
Date: Tue, 24 Mar 2009 12:24:13 -0500
Subject: [Lcdproc] preliminary Solaris patch for review
Message-ID: <226316B3E1F749498E28ACA66321D5BA0EF5746A@oma00cexmbx03.corp.westworlds.com>

With the following patch, and --enable-drivers=all,!mtc_s16209x, I got
today's current branch to compile.  This may not be the right or best way to
do it, I'm just offering this as a starting point.


tim at marcie 126$ diff -ur current current-hacked
diff -ur current/configure.in current-hacked/configure.in
--- current/configure.in        Tue Mar 24 11:04:06 2009
+++ current-hacked/configure.in Tue Mar 24 11:20:16 2009
@@ -164,7 +164,7 @@
 AC_HEADER_DIRENT
 AC_HEADER_STDC
 AC_CHECK_HEADERS(fcntl.h sys/ioctl.h sys/time.h unistd.h sys/io.h errno.h)
-AC_CHECK_HEADERS(limits.h kvm.h sys/param.h sys/dkstat.h)
+AC_CHECK_HEADERS(limits.h kvm.h sys/param.h sys/dkstat.h getopt.h)

 dnl check sys/sysctl.h seperately, as it requires other headers on at least
OpenBSD
 AC_CHECK_HEADERS([sys/sysctl.h], [], [],
diff -ur current/clients/lcdexec/lcdexec.c
current-hacked/clients/lcdexec/lcdexec.c
--- current/clients/lcdexec/lcdexec.c   Tue Mar 24 11:04:06 2009
+++ current-hacked/clients/lcdexec/lcdexec.c    Tue Mar 24 11:23:49 2009
@@ -20,7 +20,9 @@
 #include <time.h>
 #include <sys/wait.h>

+#ifdef HAVE_GETOPT_H
 #include "getopt.h"
+#endif

 #include "shared/str.h"
 #include "shared/report.h"
diff -ur current/clients/lcdproc/main.c
current-hacked/clients/lcdproc/main.c
--- current/clients/lcdproc/main.c      Tue Mar 24 11:04:06 2009
+++ current-hacked/clients/lcdproc/main.c       Tue Mar 24 11:24:18 2009
@@ -1,4 +1,6 @@
+#ifdef HAVE_GETOPT_H
 #include "getopt.h"
+#endif

 #include <stdio.h>
 #include <unistd.h>
diff -ur current/clients/lcdvc/lcdvc.c current-hacked/clients/lcdvc/lcdvc.c
--- current/clients/lcdvc/lcdvc.c       Tue Mar 24 11:04:06 2009
+++ current-hacked/clients/lcdvc/lcdvc.c        Tue Mar 24 11:24:51 2009
@@ -18,7 +18,9 @@
 #include <fcntl.h>
 #include <errno.h>

+#ifdef HAVE_GETOPT_H
 #include "getopt.h"
+#endif

 #include "shared/str.h"
 #include "shared/report.h"
diff -ur current/server/main.c current-hacked/server/main.c
--- current/server/main.c       Tue Mar 24 11:04:07 2009
+++ current-hacked/server/main.c        Tue Mar 24 11:25:27 2009
@@ -46,7 +46,9 @@
 #include <sys/types.h>
 #include <limits.h>

+#ifdef HAVE_GETOPT_H
 #include "getopt.h"
+#endif

 #ifdef HAVE_SYS_TIME_H
 # include <sys/time.h>
diff -ur current/server/drivers/hd44780-ethlcd.c
current-hacked/server/drivers/hd44780-ethlcd.c
--- current/server/drivers/hd44780-ethlcd.c     Tue Mar 24 11:04:07 2009
+++ current-hacked/server/drivers/hd44780-ethlcd.c      Tue Mar 24 11:57:02
2009
@@ -26,7 +26,11 @@
 #include <limits.h>
 #include <fcntl.h>

+#ifndef _POSIX_HOST_NAME_MAX
+#define _POSIX_HOST_NAME_MAX 255
+#endif

+
 void ethlcd_HD44780_senddata(PrivateData *p, unsigned char displayID,
unsigned char flags, unsigned char ch);
 unsigned char ethlcd_HD44780_scankeypad(PrivateData *p);
 void ethlcd_HD44780_backlight(PrivateData *p, unsigned char state);
diff -ur current/server/drivers/irtrans.c
current-hacked/server/drivers/irtrans.c
--- current/server/drivers/irtrans.c    Tue Mar 24 11:04:07 2009
+++ current-hacked/server/drivers/irtrans.c     Tue Mar 24 12:00:22 2009
@@ -53,7 +53,11 @@
 #include "report.h"
 //#include "drv_base.h"

+#ifndef INADDR_NONE
+#define INADDR_NONE ((unsigned long) -1)
+#endif

+
 // Variables
 // TODO init


The mtc_s16209x issue has to do with use of flock vs fcntl.  That looked a
little more complicated than I wanted to delve into right now.

Tim

--
      Tim Larson??????? AMT2 Unix Systems Administrator
???       InterCall, a division of West Corporation

Be always sure you are right, then go ahead. - David Crockett


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 9455 bytes
Desc: not available
URL: <http://lists.omnipotent.net/pipermail/lcdproc/attachments/20090324/034cf60a/attachment.bin>

From junk_inbox at verizon.net  Wed Mar 25 03:10:42 2009
From: junk_inbox at verizon.net (Jeff)
Date: Tue, 24 Mar 2009 23:10:42 -0400
Subject: [Lcdproc] Custom Characters
Message-ID: <d569babb0903242010m3c89d849j8a856bf11a274b3d@mail.gmail.com>

Hi, I'm trying to understand a few limitations of lcdproc regarding custom
characters - are they intentional, or are there 'workarounds' with the
'output' command or similar?

I'm trying to enhance the Myth TV LCD support, but am finding it difficult
to do effectively as lcdproc seems to be a limiting factor by not allowing
the client to (re)define the custom characters. Being able to do this would
would make the display SO MUCH more flexible.

I'd also like to suggest an improvement to the 'bignum' function to allow
additional optional parameters to specify the width and height of the bignum
character, as well as a 'row' number.  This would allow a 2x3 number to be
drawn on lines 1,2,3 or 2,3,4 of a 4-line display, or a 2-line bignum to be
drawn on 1,2 or 2,3 or 3,4... etc.  Adding MUCH more flexibility.   However,
if the above (being able to (re)define the custom characters on-the-fly) is
implemented, this could just be done 'manually' in the client.

Note: The displays I'm currently working with are HD44780 20x4 and
CrystalFontz 634 (20x4) - both have 8 custom definable characters.  I have
done programming of HD44780 displays using micro controllers and have done
some very nice displays utilizing the custom characters.  I just wish I
could do the same with lcdproc.

Thanks for your replies, and I hope I haven't offended anyone, just trying
to understand the reasoning for not being able to define the custom
characters from an lcdproc client.

Jeff
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omnipotent.net/pipermail/lcdproc/attachments/20090324/a68568a1/attachment-0001.htm>

From fblack947 at yahoo.com  Wed Mar 25 14:49:50 2009
From: fblack947 at yahoo.com (jk)
Date: Wed, 25 Mar 2009 07:49:50 -0700 (PDT)
Subject: [Lcdproc] Custom Characters
In-Reply-To: <d569babb0903242010m3c89d849j8a856bf11a274b3d@mail.gmail.com>
References: <d569babb0903242010m3c89d849j8a856bf11a274b3d@mail.gmail.com>
Message-ID: <596287.70159.qm@web37506.mail.mud.yahoo.com>

Jeff,

I'm relatively new to this group, but I've been working on the SoundGraph iMon LCD driver recently.

My
only use for my LCD is myth, so I have a bit of familiarity there.  I'm
also sure others will chime in if I'm mistaken in my response, below.




________________________________
From: Jeff <junk_inbox at verizon.net>
To: lcdproc at lists.omnipotent.net
Sent: Tuesday, March 24, 2009 11:10:42 PM
Subject: [Lcdproc] Custom Characters

> Hi, I'm trying to understand a few limitations of lcdproc regarding custom characters - are they intentional, 
> or are there 'workarounds' with the 'output' command or similar?  

The current API, v0.5 can be found in the docs folder from lcdproc's CVS.
The API gives the provision for each driver specifying driver_set_char() and driver_get_free_chars() functions.

The get_free_chars() function returns the number of free characters available.

The set_char() function takes a pointer to an unsigned char array, each byte representing one line of pixels on the display.

The client must determine how many pixels are actually represented on the screen via calls to cellwidth() and cellheight(), and send the character correctly.

ISSUE:  
  * I guess it's assumed that this character is then displayed via a call to the chr() (or string()) functions, but I'm not sure how one would know which character number to send - wouldn't it vary for each display?
  * Not all of the drivers currently support this functionality.  However, if myth were to make good use of it, I'd guess the drivers would be rather quickly updated... :}

The icon() function is intended for the display to depict named icons (described in server/drivers/lcd.h):

/* Icons. If a driver does not support an icon, it can return -1 from the
 * icon function, and let the core place a replacement character.
 */
/* Icons below are one character wide */
#define ICON_BLOCK_FILLED    0x100
#define ICON_HEART_OPEN        0x108
#define ICON_HEART_FILLED    0x109
#define ICON_ARROW_UP        0x110
#define ICON_ARROW_DOWN        0x111
#define ICON_ARROW_LEFT        0x112
#define ICON_ARROW_RIGHT    0x113
#define ICON_CHECKBOX_OFF    0x120
#define ICON_CHECKBOX_ON    0x121
#define ICON_CHECKBOX_GRAY    0x122
#define ICON_SELECTOR_AT_LEFT    0x128
#define ICON_SELECTOR_AT_RIGHT    0x129
#define ICON_ELLIPSIS        0x130

/* Icons below are two characters wide */
#define ICON_STOP        0x200    /* should look like  []  */
#define ICON_PAUSE        0x201    /* should look like  ||  */
#define ICON_PLAY        0x202    /* should look like  >   */
#define ICON_PLAYR        0x203    /* should llok like  <   */
#define ICON_FF            0x204    /* should look like  >>  */
#define ICON_FR            0x205    /* should look like  <<  */
#define ICON_NEXT        0x206    /* should look like  >|  */
#define ICON_PREV        0x207    /* should look like  |<  */
#define ICON_REC        0x208    /* should look like  ()  */

Finally, the output() function.  I believe this is intended to be used to turn random icons on the screen on and off.  The iMon LCD has a ton of them. See the image here: http://www.soundgraph.com/Eng_/Products/oem3.aspx

ISSUE: the output icons are highly driver dependent, and there are no standard "states".


> I'd also like to suggest an improvement to the 'bignum' function to allow additional optional parameters
> to specify the width and height of the bignum character, as well as a 'row' number.  This would allow a 
> 2x3 number to be drawn on lines 1,2,3 or 2,3,4 of a 4-line display, or a 2-line bignum to be drawn on
> 1,2 or 2,3 or 3,4... etc.  Adding MUCH more flexibility.   However, if the above (being able to (re)define
> the custom characters on-the-fly) is implemented, this could just be done 'manually' in the client.

This sounds valid, but would change the API.  See notes below...

> Thanks for your replies, and I hope I haven't offended anyone, just
trying to understand the reasoning for 
> not being able to define the
custom characters from an lcdproc client.
> 
> Jeff 

I doubt you're offending anyone, but this might:  The biggest problem with lcdproc right now is that the current release is two years old, and there appears to be little movement to formalize the next release.  I think the main reason for this is that lcdproc's development community has declined, and the project admins have gone missing - one in recent months, but the rest for years.  In fact, it looks like Markus is the only active developer left.  

It's a pretty tall task coordinating what looks to be around 45 separate drivers, with LCD devices coming and going and changing protocols far faster than this tiny community can keep up.  Trying to do an API update?  Yikes.

-Jonathan



      
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omnipotent.net/pipermail/lcdproc/attachments/20090325/a7163f37/attachment.htm>

From junk_inbox at verizon.net  Thu Mar 26 16:46:16 2009
From: junk_inbox at verizon.net (Jeff)
Date: Thu, 26 Mar 2009 12:46:16 -0400
Subject: [Lcdproc] Custom Characters
In-Reply-To: <596287.70159.qm@web37506.mail.mud.yahoo.com>
References: <d569babb0903242010m3c89d849j8a856bf11a274b3d@mail.gmail.com>
	<596287.70159.qm@web37506.mail.mud.yahoo.com>
Message-ID: <d569babb0903260946y38d239f3i364ae1ec6ca2ad89@mail.gmail.com>

Jonathan,

  Thanks for the response! ;-)  My replies are below:

The current API, v0.5 can be found in the docs folder from lcdproc's CVS.
> The API gives the provision for each driver specifying driver_set_char()
> and driver_get_free_chars() functions.
>
>From what I understand these functions are not available to *clients* though
- so unless I were to patch the lcdproc server source code, they could not
be (re)defined from a client.

(Note: For both the HD44780 and CrystalFontz displays, the custom characters
are mapped to 'ascii' characters 0 thru 7)


> The icon() function is intended for the display to depict named icons
> (described in server/drivers/lcd.h):
>
I know about the 'icons' - but I'd like to be able to define my own
characters/icons...  Which isn't currently possible from what I can tell.
:-(

Finally, the output() function.  I believe this is intended to be used to
> turn random icons on the screen on and off.  The iMon LCD has a ton of
> them. See the image here:
> http://www.soundgraph.com/Eng_/Products/oem3.aspx
>
> ISSUE: the output icons are highly driver dependent, and there are no
> standard "states".
>
Yep - I also have a case with the same iMon display (Antec Fusion Black 430)
- which I have attempted to get working with lcdproc way back when I bought
the case (approx 1.5 yrs ago), and ended up shelving the attempts because of
other priorities, and the box has since been temporarily recycled for
testing W7...  ;-)

If the "output" function can be used with HD44780 displays to issue 'direct'
commands to the LCD, then I have no issue whatsoever - I can define the
custom characters that way. ;-)   But if it can't, then I'm back to the
dilemma...

> I'd also like to suggest an improvement to the 'bignum' function to allow
> additional optional parameters
> > to specify the width and height of the bignum character, as well as a
> 'row' number.  This would allow a
> > 2x3 number to be drawn on lines 1,2,3 or 2,3,4 of a 4-line display, or a
> 2-line bignum to be drawn on
> > 1,2 or 2,3 or 3,4... etc.  Adding MUCH more flexibility.   However, if
> the above (being able to (re)define
> > the custom characters on-the-fly) is implemented, this could just be done
> 'manually' in the client.
>
> This sounds valid, but would change the API.  See notes below...
>
Would it though?  I mean - I don't claim to be a C++ expert, but I thought a
function could have optional arguments - if so, couldn't the additional
arguments be optional, and if they're not present, operate in the 'standard'
mode of 'full height of the display, biggest char that can be fit on the
display', but if the optional arguments for width, height and row are
present, use that mode instead.

I doubt you're offending anyone, but this might:  The biggest problem with
> lcdproc right now is that the current release is two years old, and there
> appears to be little movement to formalize the next release.  I think the
> main reason for this is that lcdproc's development community has declined,
> and the project admins have gone missing - one in recent months, but the
> rest for years.  In fact, it looks like Markus is the only active developer
> left.
>
Markus has been a great help, and very patient with me in getting the
debugging info he needed to resolve my CF634 startup hang.  But once I got
it to him, he was very quick to resolve the issue and even commit it to CVS.
;-)   (THANKS AGAIN!)


> It's a pretty tall task coordinating what looks to be around 45 separate
> drivers, with LCD devices coming and going and changing protocols far faster
> than this tiny community can keep up.  Trying to do an API update?  Yikes.
>
I understand - Like I said, I'm not expecting a complete re-write of
lcdproc...  Just trying to figure out if there's a reason for not being able
to (re)define the custom characters from a client other than 'nobody has
submitted a patch to do so'... ;-)

If need be, I can just create patches to provide the functionality that I
need/desire.  I would rather see them as integrated features in lcdproc than
a 'hack' if you know what I mean... ;-)


> -Jonathan
>

Jeff
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omnipotent.net/pipermail/lcdproc/attachments/20090326/9993ffca/attachment.htm>

From ethan.dicks at gmail.com  Thu Mar 26 17:15:43 2009
From: ethan.dicks at gmail.com (Ethan Dicks)
Date: Thu, 26 Mar 2009 13:15:43 -0400
Subject: [Lcdproc] Custom Characters
In-Reply-To: <d569babb0903260946y38d239f3i364ae1ec6ca2ad89@mail.gmail.com>
References: <d569babb0903242010m3c89d849j8a856bf11a274b3d@mail.gmail.com>
	<596287.70159.qm@web37506.mail.mud.yahoo.com>
	<d569babb0903260946y38d239f3i364ae1ec6ca2ad89@mail.gmail.com>
Message-ID: <f4eb766f0903261015v3da18eb2rb8df2ed2f354a0cd@mail.gmail.com>

2009/3/26 Jeff <junk_inbox at verizon.net>:
>> The current API, v0.5 can be found in the docs folder from lcdproc's CVS.
>> The API gives the provision for each driver specifying driver_set_char()
>> and driver_get_free_chars() functions.
>
> From what I understand these functions are not available to *clients* though
> - so unless I were to patch the lcdproc server source code, they could not
> be (re)defined from a client.

Yes... those functions are not available through the client-server
API.  You'd have to do more than a little tweak to make them so.

> (Note: For both the HD44780 and CrystalFontz displays, the custom characters
> are mapped to 'ascii' characters 0 thru 7)

Yes, and that's one of the problems with custom chars - different
displays have been known to put them in other places in the character
set.

>> The icon() function is intended for the display to depict named icons
>> (described in server/drivers/lcd.h):
>
> I know about the 'icons' - but I'd like to be able to define my own
> characters/icons...? Which isn't currently possible from what I can tell.
> :-(

No.  'icons' was never designed to allow clients to make up their own
characters, just to 'light up' things that already existed on the
display.

One of the elements that I'd like to see in the future is to be able
to somewhere (at the server level if needed) define "large" bitmapped
icons for graphical displays - one example would be a weather client
that would have a bunch of pre-coded weather symbols (sunny, cloudy,
rainy...) that could be simply triggered from the client - the symbols
themselves could be as tall as the display and perhaps square (so,
say, 32x32 or 64x64 for some of the common graphical display types).
You could still render text on the screen, but you could also have a
symbol at one end of the display or the other that could quickly show
the user what the general weather was like.  This same graphical icon
could be used for CPU status displays (normal, warning, error) with
universal signs like the european 'caution' sign, etc.  It would be
even more effective with color displays, but most graphical display I
know about are monochrome (so far).

So I'm willing to accept server-defined icons, but the mechanism
should be flexible enough that the client can "ask" the server "can
you draw the following icons or not?" and the client can adapt to the
limitations or features of the active display.

>> Finally, the output() function.? I believe this is intended to be used to
>> turn random icons on the screen on and off.? The iMon LCD has a ton of them.
>> See the image here: http://www.soundgraph.com/Eng_/Products/oem3.aspx
>>
>> ISSUE: the output icons are highly driver dependent, and there are no
>> standard "states".

Output is also used to control peripheral status LEDs that some
displays have next to the textual display.  They have always been
highly driver-dependent since there is no standard from manufacturer
to manufacturer.  Perhaps in the future, 'output' should be expanded
to take something more complicated than a 31-bit number.

> If the "output" function can be used with HD44780 displays to issue 'direct'
> commands to the LCD, then I have no issue whatsoever - I can define the
> custom characters that way. ;-)?? But if it can't, then I'm back to the
> dilemma...

While it would be possible to do such a thing, the low refresh rate
(8Hz) and the limited amount of information that can be passed (a
single 31-bit number) makes that a poor channel to try to directly
control hardware registers over.

>> > I'd also like to suggest an improvement to the 'bignum' function to
>> > allow additional optional parameters...
>> This sounds valid, but would change the API.? See notes below...
>
> Would it though?? I mean - I don't claim to be a C++ expert, but I thought a
> function could have optional arguments - if so, couldn't the additional
> arguments be optional, and if they're not present, operate in the 'standard'
> mode of 'full height of the display, biggest char that can be fit on the
> display', but if the optional arguments for width, height and row are
> present, use that mode instead.

C++ has nothing to do with it (LCDd is written in C anyway, but that's
not the problem).

The problem is that the protocol itself, the textual discussion over
the socket between the clients and the server does not allow for
optional arguments.  It _could_ if the parser were more sophisticated,
but right now, if you were to extend 'bignum' to take additional
arguments, it would be, IMO, easy to enhance LCDd, and easy to write
clients that know about the enhancements, but if you have someone
using an older version of LCDd and they try to use an enhanced client,
you will get errors bouncing from LCDd leading to unsatisfied user
expectations.

The only thing that clients can do right now is check the string from
the server about what version of the client-server protocol is valid.
Many, many things are possible when one just bumps up that number, but
it is not going to happen until the next full release of the code
(i.e., 0.6.x).  I'm all in favor of exploring many, many feature and
protocol enhancements at that point, but I think we should all pull
together to release a driver and bugfix release of 0.5.3 first.

>> I doubt you're offending anyone, but this might:? The biggest problem with
>> lcdproc right now is that the current release is two years old, and there
>> appears to be little movement to formalize the next release...
>> It's a pretty tall task coordinating what looks to be around 45 separate
>> drivers, with LCD devices coming and going and changing protocols far faster
>> than this tiny community can keep up.? Trying to do an API update?? Yikes.

I'm very much in favor of picking a date in the next couple of months
and targeting cleanup operations towards a 0.5.3 release.  I myself
have a couple things on my plate to get done for that, and lots of
testing (since I have over a dozen display types on hand).  Even now,
I have a couple of Matrix Orbital things I need to carve out some time
to test, not including some other driver work.
I got some feedback on my request for who on the list has any model of
Matrix Orbital display so that we can get that driver tested on as
many hardware variants as possible (since that was an issue with
0.5.2).  Perhaps what we need to do is to create a signup sheet for
all the drivers that are going to be supported by 0.5.3 and get names
down for who owns what and can test.  I think it would make the most
sense to use some facet of sourceforge to track that.  Perhaps record
who, what driver(s), what model(s), and a "last verified" date to be
able to expire people who move on.  Besides changing participants, I
think the large number of drivers is turning into a liability when
even considering pushing out a new release.  LCDproc never did have a
rapid update schedule, but two years is too long between updates these
days - we should be targeting a schedule that more closely resembles
the release schedule for the major distros if LCDproc is going to stay
relevant.

The codebase in CVS is pretty close to ready to go, I think.  What we
need is a) a commitment to release 0.5.3, b) a date to push out either
a pre-0.5.3 or an 0.5.3-rc, and c) a list of who can test what so we
don't let things fall through the cracks.  It might be a good time for
that proposal to flag orphan drivers for eventual retirement.  If
nobody signs up for testing something, that would be a good reason to
consider retirement.

So let's get working on 0.5.3 so that we can open the floor for 0.6.0 proposals.

-ethan

From bsdfan at nurfuerspam.de  Thu Mar 26 17:50:54 2009
From: bsdfan at nurfuerspam.de (Markus Dolze)
Date: Thu, 26 Mar 2009 18:50:54 +0100
Subject: [Lcdproc] Custom Characters
In-Reply-To: <d569babb0903260946y38d239f3i364ae1ec6ca2ad89@mail.gmail.com>
References: <d569babb0903242010m3c89d849j8a856bf11a274b3d@mail.gmail.com>	<596287.70159.qm@web37506.mail.mud.yahoo.com>
	<d569babb0903260946y38d239f3i364ae1ec6ca2ad89@mail.gmail.com>
Message-ID: <49CBC07E.8030802@nurfuerspam.de>

Hi,

Jeff wrote:
> Jonathan,
>
>   Thanks for the response! ;-)  My replies are below:
>
>     The current API, v0.5 can be found in the docs folder from
>     lcdproc's CVS.
>     The API gives the provision for each driver specifying
>     driver_set_char() and driver_get_free_chars() functions.
>
> From what I understand these functions are not available to *clients* 
> though - so unless I were to patch the lcdproc server source code, 
> they could not be (re)defined from a client.
>
> (Note: For both the HD44780 and CrystalFontz displays, the custom 
> characters are mapped to 'ascii' characters 0 thru 7)

This applies to nearly all character displays based on 'standard 
controllers' like the hd44780, even if there is some other controller 
attached to which you talk using a serial or USB port.

One problem with custom characters (CCs) is that they are used 
internally by the driver for icons, hBars, and vBars. Even if you could 
define your own CC from a client, you would need special precautions in 
either the client or drivers because they would be overwritten by the 
driver every time it has to display an icon or bargraph. This is 
relevant, because your client might not be the only one connected and 
the server will cycle through the client's screens.

Looking at the 'pyramid' driver you will find a function 
'pyramid_init_custom1', which is triggered by 'output' and places some 
non-standard icons as CC. This is possible because Pyramid uses their 
own client with their own product, but this is nothing I would like to 
integrate in a 'standard' driver just for a single client application.

>  
>
>     The icon() function is intended for the display to depict named
>     icons (described in server/drivers/lcd.h):
>
> I know about the 'icons' - but I'd like to be able to define my own 
> characters/icons...  Which isn't currently possible from what I can 
> tell. :-(

Well, in the meantime if you need a fixed set of icons which could be of 
use for other's, you could define additional icons in core and the 
drivers you use. And if they are not useful for other, you can roll your 
own patched version.

...
>
> If the "output" function can be used with HD44780 displays to issue 
> 'direct' commands to the LCD, then I have no issue whatsoever - I can 
> define the custom characters that way. ;-)   But if it can't, then I'm 
> back to the dilemma...

The hd44780_output talks to the parallel port using the same data pins 
as the display, but you can't trigger the control lines as you would 
need to send commands to the display. Additionally you can only send 4 
bytes (sizeof(int)) during one screen rendering, which makes it unusable 
to pass longer commands like defining a custom icon to the display.

> ...
>
>     I doubt you're offending anyone, but this might:  The biggest
>     problem with lcdproc right now is that the current release is two
>     years old, and there appears to be little movement to formalize
>     the next release.  I think the main reason for this is that
>     lcdproc's development community has declined, and the project
>     admins have gone missing - one in recent months, but the rest for
>     years.  In fact, it looks like Markus is the only active developer
>     left. 
>
> Markus has been a great help, and very patient with me in getting the 
> debugging info he needed to resolve my CF634 startup hang.  But once I 
> got it to him, he was very quick to resolve the issue and even commit 
> it to CVS. ;-)   (THANKS AGAIN!)

If you look at LCDproc's history you can always see people come and go. 
If someone which has driven the project for more than 4 years suddenly 
disappears, what's to expect? There *are* still admins and developers 
around and they accomplish some work. I hear the question about a new 
release getting louder every week, but please be patient.


Regards,
Markus

From fblack947 at yahoo.com  Thu Mar 26 18:01:41 2009
From: fblack947 at yahoo.com (jk)
Date: Thu, 26 Mar 2009 11:01:41 -0700 (PDT)
Subject: [Lcdproc] Custom Characters
In-Reply-To: <f4eb766f0903261015v3da18eb2rb8df2ed2f354a0cd@mail.gmail.com>
References: <d569babb0903242010m3c89d849j8a856bf11a274b3d@mail.gmail.com>
	<596287.70159.qm@web37506.mail.mud.yahoo.com>
	<d569babb0903260946y38d239f3i364ae1ec6ca2ad89@mail.gmail.com>
	<f4eb766f0903261015v3da18eb2rb8df2ed2f354a0cd@mail.gmail.com>
Message-ID: <247368.25977.qm@web37508.mail.mud.yahoo.com>


> >> The current API, v0.5 can be found in the docs folder from lcdproc's CVS.

> >> The API gives the provision for each driver specifying driver_set_char()
> >> and driver_get_free_chars() functions.
> >
> > From what I understand these functions are not available to *clients* though
> > - so unless I were to patch the lcdproc server source code, they could not
> > be (re)defined from a client.
> 
> Yes... those functions are not available through the client-server
> API.  You'd have to do more than a little tweak to make them so.
> 

Oops.  You can definitely tell that I've been focusing on the driver side.

<snip>

> 
> So let's get working on 0.5.3 so that we can open the floor for 0.6.0 proposals.
> 

I'm definitely willing to help out with that, as I'd really like to see the imonlcd driver get into the release, and I'd like for lcdproc to have more regular updates.

> If you look at LCDproc's history you can always see people come and go. If 
> someone which has driven the project for more than 4 years suddenly disappears, 
> what's to expect? There *are* still admins and developers around and they 
> accomplish some work. I hear the question about a new release getting louder 
> every week, but please be patient.

No worries!  From my work over the past couple of weeks, and a review of the e-mail list archives, it's very apparent that you've done a great job stepping in after others' sudden disappearances.  Thanks.

-Jonathan


      

From TELarson at west.com  Thu Mar 26 18:59:55 2009
From: TELarson at west.com (Larson, Timothy E.)
Date: Thu, 26 Mar 2009 13:59:55 -0500
Subject: [Lcdproc] Custom Characters
In-Reply-To: <f4eb766f0903261015v3da18eb2rb8df2ed2f354a0cd@mail.gmail.com>
References: <d569babb0903242010m3c89d849j8a856bf11a274b3d@mail.gmail.com>
	<596287.70159.qm@web37506.mail.mud.yahoo.com>
	<d569babb0903260946y38d239f3i364ae1ec6ca2ad89@mail.gmail.com>
	<f4eb766f0903261015v3da18eb2rb8df2ed2f354a0cd@mail.gmail.com>
Message-ID: <226316B3E1F749498E28ACA66321D5BA0EF5747C@oma00cexmbx03.corp.westworlds.com>

> I'm very much in favor of picking a date in the next couple of months
> and targeting cleanup operations towards a 0.5.3 release.  I myself

I'm very much in favor of that, too.  I am committed to getting the next
release imported to pkgsrc, IF I can get it to build on my pkgsrc-using
systems.  (Due to hardware failures, that means Solaris 9 right now.  If I
can find the time to fix those issues, I have NetBSD as well.)  I submitted
a patch for this the other day.  I'll continue running smoketests and do
whatever I can to help those who actually know what they're doing.


Tim
--
      Tim Larson??????? AMT2 Unix Systems Administrator
???       InterCall, a division of West Corporation

Be always sure you are right, then go ahead. - David Crockett

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 9455 bytes
Desc: not available
URL: <http://lists.omnipotent.net/pipermail/lcdproc/attachments/20090326/91828715/attachment.bin>

From bsdfan at nurfuerspam.de  Thu Mar 26 20:08:47 2009
From: bsdfan at nurfuerspam.de (Markus Dolze)
Date: Thu, 26 Mar 2009 21:08:47 +0100
Subject: [Lcdproc] HD44780 40x4 with Backlight and winamp wiring
In-Reply-To: <49A4782D.30609@nurfuerspam.de>
References: <9185341920196262063@unknownmsgid>	<200902061027.56222.sascha.zielinski@gmx.de>	<49960372.9080003@nurfuerspam.de>	<200902240336.07806.sascha.zielinski@gmx.de>
	<49A4782D.30609@nurfuerspam.de>
Message-ID: <49CBE0CF.9070906@nurfuerspam.de>

Markus Dolze wrote:
> Sascha wrote:
>>
>> Yeah! :D It took a long time but my Backlight lights up. I had to 
>> make a new cable.
>> Thank you for all you help. I will now play around with the settings.
>>
>> And thanks one more for your help :)
>>
>>
>>   
> Attached is the patch mentioned above. The important modification is 
> that the EN2 line is set if two displays are attached (as given by the 
> 'vSpan' option). This now works independent of the availability of the 
> backlight.
>
> Any comments?
>
> Markus

Hi,

attached is an updated version of the backlight patch for hd44780-winamp.

Regards
Markus

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: hd44780-winamp-wiring.patch
URL: <http://lists.omnipotent.net/pipermail/lcdproc/attachments/20090326/35d6037f/attachment-0001.txt>

From bsdfan at nurfuerspam.de  Thu Mar 26 20:09:58 2009
From: bsdfan at nurfuerspam.de (Markus Dolze)
Date: Thu, 26 Mar 2009 21:09:58 +0100
Subject: [Lcdproc] Increasing the server's receive buffer
In-Reply-To: <0CCDE7FF-6F93-4F7D-A568-505EDF06DF7B@siliconlandmark.com>
References: <49A8F32F.10800@nurfuerspam.de>
	<20090228091028.C44792C407A@tippex.mynet.homeunix.org>
	<0CCDE7FF-6F93-4F7D-A568-505EDF06DF7B@siliconlandmark.com>
Message-ID: <49CBE116.2020702@nurfuerspam.de>

Andre Guibert de Bruet wrote:
> 
> It then becomes advisable to make "buffer" MAXMSG+1 in size in order to 
> prevent the buffer[nbytes] = '\0' code on line 419 from writing one byte 
> past the end of the buffer and corrupting the stack.
> 

Fixed this in CVS.

Regards,
Markus

From rje at crystalfontz.com  Thu Mar 26 21:48:57 2009
From: rje at crystalfontz.com (Rob Emanuele)
Date: Thu, 26 Mar 2009 14:48:57 -0700
Subject: [Lcdproc] Patch: Watchdog timer for Crystalfontz Packet
In-Reply-To: <49C88120.3040301@nurfuerspam.de>
References: <20090323231852.5454gmx1@mx032.gmx.net>
	<49C88120.3040301@nurfuerspam.de>
Message-ID: <c8284b5b0903261448r2ef8554dld2ee5373284294fb@mail.gmail.com>

The intention of this patch was to provide a use with a method for
rebooting a seldom-watched server in lieu of having a network aware
PDU available.  In my case I have a server at a co-location facility
for personal use.  If it gets hung, this patch enables the LCD module
to reset the system.  I cannot aways get to the co-location facility
in the event of a failure so this covers that need nicely.

--Rob

On Mon, Mar 23, 2009 at 11:43 PM, Markus Dolze <bsdfan at nurfuerspam.de> wrote:
> Dave Liquorice wrote:
>>
>> On Mon, 23 Mar 2009 23:25:09 +0100, Markus Dolze wrote:
>>
>>
>>>>
>>>> I don't think this is a good idea. Another client might always connect,
>>>> raise a high priority screen and disable the heartbeat for that screen.
>>>> Resulting in a system reboot....
>>>>
>>>
>>> I was assuming the user has set heartbeat=on in LCDd.conf, overriding all
>>> client or screen settings.
>>>
>>
>> Bad assumption, I can't stand the heartbeat and turn it off in all but the
>> server screen. I can see the system is still "alive" as the screens are
>> changing...
>>
>>
>
> If the CFontz watchdog is implemented in the driver as a hook-up in
> heartbeat, the user must set heartbeat=on, otherwise there is the danger of
> unwanted system reboots as described above. It will be up to the user to
> decide.
>
> I don't like the idea of mixing an additional 'user invisible' feature
> (watchdog) and an 'user visible' one (heartbeat) in one function as well,
> because 'user visible features' are always a matter of personal preference
> and lead to discussions like ours.
>
> The watchdog might be intended for systems _not_ watched by a user. I don't
> know the original author's reasons.
>
> Markus
>
> _______________________________________________
> LCDproc mailing list
> LCDproc at lists.omnipotent.net
> http://lists.omnipotent.net/mailman/listinfo/lcdproc
>

From sascha.zielinski at gmx.de  Mon Mar 30 14:44:12 2009
From: sascha.zielinski at gmx.de (Sascha)
Date: Mon, 30 Mar 2009 16:44:12 +0200
Subject: [Lcdproc]  HD44780 40x4 with Backlight and winamp wiring
Message-ID: <200903301644.12721.sascha.zielinski@gmx.de>

Markus Dolze wrote:
>> Sascha wrote:
>>>
>>> Yeah! :D It took a long time but my Backlight lights up. I had to 
>>> make a new cable.
>>> Thank you for all you help. I will now play around with the settings.
>>>
>>> And thanks one more for your help :)
>>>
>>>
>>>   
>> Attached is the patch mentioned above. The important modification is 
>> that the EN2 line is set if two displays are attached (as given by the 
>> 'vSpan' option). This now works independent of the availability of the 
>> backlight.
>>
>> Any comments?
>>
>> Markus
>
>Hi,
>
>attached is an updated version of the backlight patch for hd44780-winamp.
>
>Regards
>Markus
Hi,

I can't find any error with this patch. Let me know if I have to look for something special.

Regards,
Sascha
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omnipotent.net/pipermail/lcdproc/attachments/20090330/efcf8208/attachment.htm>

From sascha.zielinski at gmx.de  Mon Mar 30 14:53:06 2009
From: sascha.zielinski at gmx.de (Sascha)
Date: Mon, 30 Mar 2009 16:53:06 +0200
Subject: [Lcdproc]  SMP CPU monitor counts I/O wait as CPU usage
Message-ID: <200903301653.06636.sascha.zielinski@gmx.de>

Markus Dolze wrote:
>Markus Dolze wrote:
>> for some time the Linux lcdproc CPU screens did not report CPU load 
>> correctly as one user noticed:
>>
>> http://sourceforge.net/tracker2/?func=detail&aid=2580087&group_id=119&atid=100119 
>>
>>
>> Attached is a change that should fix it. As I don't run Linux, please 
>> test and if necessary correct it.
>>
>> Note that I decided to make the additional variables local instead of 
>> extending /load_type/ as they are Linux specific.
>>
>>
>
>No comments?
>
>I was able to verify the wrong behaviour and that my fix really resolves 
>it. I will commit the change if I receive no objections.
>
>Regards,
>Markus
Hi,

Does this patch also may correct my CPU graph "problem"? I see every 2-4
seconds two bars, which have have the height of my lcd.

Regards,
Sascha
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omnipotent.net/pipermail/lcdproc/attachments/20090330/68c6a940/attachment-0001.htm>

From ethan.dicks at gmail.com  Tue Mar 31 04:53:41 2009
From: ethan.dicks at gmail.com (Ethan Dicks)
Date: Tue, 31 Mar 2009 00:53:41 -0400
Subject: [Lcdproc] Patch: MtxOrb adjustable backlight and display
	detection
In-Reply-To: <49C893FB.5020909@nurfuerspam.de>
References: <20090308140131.9870@gmx.net> <49C893FB.5020909@nurfuerspam.de>
Message-ID: <f4eb766f0903302153v12d88d55pcdec394966940ce6@mail.gmail.com>

On Tue, Mar 24, 2009 at 4:04 AM, Markus Dolze <bsdfan at nurfuerspam.de> wrote:
> Hi,
>
> I have questions on how the Display On / Off and Set Brightness commands of
> Matrix Orbital displays work:
>
> ?1. If I use the 'Display Off' command, does it just turns the
> ? ? backlight off like for older versions or does it completely turns
> ? ? the display off?
> ?2. If the display's backlight is off, what happens if I issue a 'Set
> ? ? Brightness' command? Does the backlight stays off until a 'Display
> ? ? On' command is issued or does the backlight automatically turns on?

Hi, Markus,

I've restored my dev environment to functionality and spent some time
tonight throwing some command strings at my LK204-7T-1U (the
recently-manufactured Matrix Orbital display with the built-in LEDs on
GPOs 1-6, the color backlight, and built-in keypad).  Here's what I
observe...

I send "display off", the display goes off *and* the backlight goes
off.  I had to send both a "backlight brightness" _and_ a "display on"
command to see chars again.  It does not matter which is sent first,
but both have to be sent.

When the backlight is off sending a "set brightness" does not turn the
backlight on right away.  It stays off until the "display on" is sent.

This is the only Matrix Orbital textual LCD I have (an "LKD").  My
other textual MO display is that VFD display that "doesn't like" the
newer LCD commands (but worked fine the last time I tested it as a
"VKD" type display).

I hope this is the sort of information you were looking for.  Let me
know if you need anything other sequences of commands sent.  Now that
I have my dev laptop back, it shouldn't take a week to get you an
answer.

-ethan

From aeriksson2 at fastmail.fm  Tue Mar 31 17:30:53 2009
From: aeriksson2 at fastmail.fm (aeriksson2 at fastmail.fm)
Date: Tue, 31 Mar 2009 19:30:53 +0200
Subject: [Lcdproc] improved imon hbars
In-Reply-To: <49C80994.7070800@nurfuerspam.de>
References: <20090111142455.2A49E940566@tippex.mynet.homeunix.org>
	<49B6DD48.9090108@nurfuerspam.de>
	<20090310223536.DE2122C40DB@tippex.mynet.homeunix.org>
	<49C80994.7070800@nurfuerspam.de>
Message-ID: <20090331173053.6E24593C47B@tippex.mynet.homeunix.org>



Hi Markus,

Pardon the delay. I've been offline.

bsdfan at nurfuerspam.de said:
> Hi Anders,
> attached you will find a version of your patch that adds the new hBar as  an
> optional feature. Looking at my video convinced me to make it on by  default.

> Would you please test it? Especially I am interrested if the old  behaviour
> could be restored. For this you will have to do:

> export CPPFLAGS="-DIMON_HBARS_OLD" 
> ./configure 
> make 

I checked and it appears to work as expected. However, why do you want to 
make this a compile time decision? If it is to be configurable at all, I'd 
wote for a runtime config option. What do you expect distros to choose when 
they compile it for the masses?

Additionally, the logic tricks my head with the ifNdef of an OLD thing. To me, 
it seems more natural if the old cruft stuff is NOT ifdeffed out, and you leave
the "standard" stuff free from ifdefs. But this is just cosmetical.

/Anders





From TELarson at west.com  Tue Mar 31 17:37:45 2009
From: TELarson at west.com (Larson, Timothy E.)
Date: Tue, 31 Mar 2009 12:37:45 -0500
Subject: [Lcdproc] preliminary Solaris patch for review
In-Reply-To: <226316B3E1F749498E28ACA66321D5BA0EF5746A@oma00cexmbx03.corp.westworlds.com>
References: <226316B3E1F749498E28ACA66321D5BA0EF5746A@oma00cexmbx03.corp.westworlds.com>
Message-ID: <226316B3E1F749498E28ACA66321D5BA0EF57493@oma00cexmbx03.corp.westworlds.com>

> With the following patch, and --enable-drivers=all,!mtc_s16209x, I got
> today's current branch to compile.  This may not be the right or best way
> to do it, I'm just offering this as a starting point.
[snip]

Did this go through?  I haven't seen any discussion.

Thanks,
Tim

--
      Tim Larson        AMT2 Unix Systems Administrator
          InterCall, a division of West Corporation

Be always sure you are right, then go ahead. - David Crockett


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 9455 bytes
Desc: not available
URL: <http://lists.omnipotent.net/pipermail/lcdproc/attachments/20090331/ffc7c8ad/attachment.bin>