From jack at jackpot.uk.net  Mon Sep  1 03:33:14 2008
From: jack at jackpot.uk.net (Jack Cleaver)
Date: Mon, 01 Sep 2008 10:33:14 +0100
Subject: [Lcdproc] PATCH: Memory leak in PicoLCD driver
Message-ID: <48BBB6DA.6010100@jackpot.uk.net>

Hi,

I'm offering the attached patch for the picoLCD driver.

I'm no great shakes as a C/Linux coder, not having worked in C for over
15 years. I'd therefore appreciate if someone could verify by inspection
that what appears to be an obvious leak really is a leak, and that this
patch fixes it (without breaking something else).

JackC.

jackc at virya:~/Projects/lcdproc-0.5.2/server/drivers$ diff picolcd.c-orig 
picolcd.c
303a304
 >       char * retval = NULL;
329a331,333
 >
 >                       if (strlen(keystr))
 >                               retval = keystr;
333d336
<                       return NULL;
342,345c345
<       if (! strlen(keystr))
<               return NULL;
<
<       return keystr;
---
 >       return retval;

From herdler at gmx.de  Mon Sep  1 17:06:36 2008
From: herdler at gmx.de (Stefan Herdler)
Date: Tue, 02 Sep 2008 01:06:36 +0200
Subject: [Lcdproc] BIGNUMs and larger display sizes
In-Reply-To: <f4eb766f0808301735g3e10f504q109fadda13567f2a@mail.gmail.com>
References: <20080830070635.GA23305@usap.gov>
	<48B9D944.4050109@gmx.de>	<f4eb766f0808301726k3f53793dqc6f6f96da29ae3d@mail.gmail.com>
	<f4eb766f0808301735g3e10f504q109fadda13567f2a@mail.gmail.com>
Message-ID: <48BC757C.60706@gmx.de>

Hi Ethan,

Ethan Dicks wrote:
>
> I've been hoping that others would be reading this and express
> opinions, but so far, that hasn't happened.  I may just post a
> fresh message with the title "proposal to change the protocol
> number" or some such to grab some attention, because the
> more I think about it, the more I prefer that path, especially
> since the 0.5.2 release has some real problems (specifically
> with Matrix Orbital displays), and it's been so long since that
> release came out that we _should_ be gearing up for another
> release soon, I'd hope.
>   
Well, I think you have to wait until peter shows up again.
>>  Btw.: A good way controlling the "special icons" on
>> some (imon, ...) VFDs is still missing.
>>     
>
> True, but I don't have a display like that to fiddle with, so I'll
> have to leave that to others.
>
>   
I too.

Client definable usercharacters would be nice eye-candy too. They would 
work on many displays.
But I really don't know how to deal with them and embedded functions 
like heartbeat.
>>>  I was thinking about something like showing the channel-number as BIGNUM on
>>> the top and channel-name below.
>>>       
>
> Channel-number?  Oh... you must be thinking of a TV-oriented client.
>   
I was actually thinking about the clients for MythTV or VDR.
But there are many other uses for such a feature...

Regards
Stefan

From ethan.dicks at gmail.com  Mon Sep  1 21:56:32 2008
From: ethan.dicks at gmail.com (Ethan Dicks)
Date: Tue, 2 Sep 2008 15:56:32 +1200
Subject: [Lcdproc] OSX + MtxOrb Driver
In-Reply-To: <0854553D-8AF9-43E6-B4C2-2E97875B3427@gmail.com>
References: <AA2A95BB-7983-448D-8249-5B54BF044680@gmail.com>
	<f4eb766f0808311849t17eae61ar2b280de97503a364@mail.gmail.com>
	<0854553D-8AF9-43E6-B4C2-2E97875B3427@gmail.com>
Message-ID: <f4eb766f0809012056v6bf52fb3g645c97ac28d1b6@mail.gmail.com>

On Tue, Sep 2, 2008 at 2:18 PM, Kevin Ogden <kdogden at gmail.com> wrote:

(BTW, I copied the lcdproc list back in because these are the sort of
questions that are good to have on the list archives - folks find the
initial questions and get frustrated when the answers are off-list and
not archived).

> On Aug 31, 2008, at 9:49 PM, Ethan Dicks wrote:
>>
>> On 8/31/08, Kevin Ogden <kdogden at gmail.com> wrote:
>>> Hey, how hard would it be for the MtxOrb driver support straight serial
>>> LCD's under OSX?
>>
>> It should already.  I was using such a setup last year on my Macbook Pro.
>
> Do the macbooks have serial ports?  Or were you using a USB<->serial dongle?

USB<->serial dongle... in that case, a "GUC232A" which took a bit of plist
fiddling to install. :-/

> I need to pick up a more modern board eventually.  This Intel D865GSA is
> pretty quirky.

I haven't done much with MacOS on non-Apple hardware - just one
install to prove to myself it worked.

>>> When I tried running LCDd w/ a properly setup config file it just kinda sits
>>> there...

>> How are you invoking it?
>
> /usr/local/sbin/LCDd -d MtxOrb

One thing to try is to test-run LCDd from your build directory - one thing
that _can_ occasionally happen is that LCDd can't find its libraries.  If
you sit in the top of your build directory and run it as...

./server/LCDd -c ./LCDd.conf -d MtxOrb

... it will use a local copy of the LCDd.conf and should always be
able to find the driver files.

Also, you can invoke it with "-r 5" to crank up the logging level, but
I always compile with debugging turned on, since I do development,
and I don't recall what the default code will log if you _don't_ enable
debugging.

> It looks like it wants to think about working but nothing happens with the
> LCD.  My config file is pointing at the right device and everything.

Looking at the startup messages from _my_ LCDd, it should be
setting contrast, turning off wrap and the cursor, etc., then quickly
blasting out the "welcome" message and going to the "0 clients/
0 screens" screen and idling.

> Not that it makes much difference but it's an LK202-25 serial 20x2 instead
> of the LK204 20x4.

There is a difference in internal RAM addressing on a HD44780 between
2 lines and 4 lines, but the MtxOrb backpack ought to be the one worrying
about that, not LCDd.

> Call me sick but I have a VAX 4000-200 running NetBSD that I use as an end
> table/space heater.  It's fun to hack on though.  I have an old VAXstation
> 3100 in the closet that runs Ultrix that I fire up every once in a while.

Nice.  I don't have any modernish VAXen that small - I have a couple of
VAXstation 2000s and a couple of MicroVAX IIs, but those top out with
so little memory that they really only run stuff from the 1980s well.

>> The two most important things to share are the command line you are
>> using to invoke LCDd and your LCDd.conf.
>
> I'll see if I can dig up the LCDd.conf tonight.... it's stock except for
> telling it to use the MtxOrb driver, setting it for 20x2 and pointing it at
> /dev/tty.serial1 for the serial port.  Baud rate is the default 19200.

That all sounds right.

>>> The display is an old serial MtxOrb LK204 20x2 LCD.
>
> I used to use it all the time with LCDproc on my old FreeBSD box.  It worked
> great in my old Sun Ultra 2 running Slowlaris as well.  Unfortunately I
> don't have that box anymore.  Probably the last really interesting SPARC
> desktop.

I have a wad of SPARC hardware as well, but only a rackmount Netra
(telco-version of an Ultra 60, but that does _not_ support a graphical
console - there's sheet metal in front of the keyboard and video card
ports) with an UltraSPARC.  I got it to twiddle with Solaris 10.

Long ago, back in the LCDproc 0.3.x days, I started to port LCDproc
to Solaris, but it was monolithic, not client-server, so the sticking point
was that Solaris didn't put anywhere near the amount of useful into
into /proc, and my kernel fiddling only coughed up about 60% of
the desired info for the standard LCDproc client screen.  Now, of
course, with the client-server model, it pushes all that difficulty to
the lcdproc client program, not that it matters to me much; I only
run 'lcdproc' (the client) to test things like the "K" clock.  In normal
operation, I'm usually running my own clients to monitor things
around the office and the local weather and play tunes on XMMS.

> I don't know what it is about serial and parallel ports but they usually
> just plain always work.  I can NEVER say that about USB.

I'm in agreement there.

> Onboard serial port on the Intel D865GSA motherboard.  It only has one but
> I'm not using it for anything at the moment.

Got it.  I didn't understand what your platform was at first.

> I've got a couple of 4-port PCI serial cards in my closet but I doubt they
> are supported by OSX.  Might be funny to try though.... dangle a couple
> VT220's off the OSX box LOL  Hell they might work, they're pretty standard
> 16550 UARTs.

I have used 8-port PCI serial cards under ancient (pre-9) versions of
RedHat Linux.  Fortunately, I haven't had to update that machine in
several years, but when I did install the card, it was a right pain.

> I had similar issues with FreeBSD a while back with various USB devices.  I
> guess hot pluggable devices were an afterthought with UNIX.  I don't know
> too many VAX/PDP11 Unibus/QBUS machines that had any hot pluggable ANYTHING
> except maybe terminals and SCSI drives and even that half the time could
> cause kernel panics.
>
> Damn, I sound old....  I'm not even 27....

Heh... I used to twiddle with that era gear when it was new or nearly new.  I'm
not quite as young as you, but I get the sentiment.  I cut my teeth on
that stuff
when I was 18 - my first UNIX install was Ultrix 1.1 (4.2BSD with lots of
vendor extensions to simplify life with DEC peripherals) onto a VAX-11/730.

Some parts of "the good old days" I don't miss.  ;-)

I suppose if I ever got really, really bored, I could port LCDd to VMS.
Except for our VAX8300, for which we never bought a DMB32, so
only had the console ports, we always had plenty of serial ports on
our VAXen.  I would have _loved_ to have had LCDproc running on
something, say, about 10 years before it eventually came out.  I was
working in a 100% DEC shop at the time, and it would have been
a fun thing to have running in the machine room.  I can do it now,
but there's not as much point to it (of course, the easy way to do it
now is to run VMS under simh).

>> If you do have slightly-out-of-date code, the symptoms,
>> for Matrix Orbital displays, would be random character flashing
>> on an otherwise-working screen, not complete freeze-up.
>
> Like extra 'V' characters on the display with an occasional weird character
> thrown in?

Yep.  Go get a copy of the code that's less than three months old and
that problem should vanish.

>> You could also grab the code, compile the Matrix Orbital driver
>> for debugging, and post the results of just starting LCDd with
>> debug level set to '5'...
>
> If I get a chance, I'll try that tonight.

That's probably a good next step.

Cheers,

-ethan

From jack at jackpot.uk.net  Tue Sep  2 04:24:01 2008
From: jack at jackpot.uk.net (Jack Cleaver)
Date: Tue, 02 Sep 2008 11:24:01 +0100
Subject: [Lcdproc] PicoLCD driver for LCDProc
Message-ID: <48BD1441.2010106@jackpot.uk.net>

Hi,

Yesterday I submitted a patch to the LCDProc mailing list fixing a
memory leak in the picolcd driver. It hasn't been picked up yet -
perhaps I submitted it in the wrong way, or in the wrong place (I
appreciate that 24 hours is not a long time to wait, though). Before
submitting my next patch, I'm seeking guidance on patch submission.

I've now coded an enhancement for this driver to enable it to read the
IR sensor. The reason for doing this is that (as far as I can see) only
one client can "own" the picolcd USB device at once; so if both display
and IR capabilities are required, then the same client software must
manage both. My  "itch" is getting picoLCD working with MythTV, and
MythTV requires LCDProc to handle the display. So For MythTV, any IR
handler for the picoLCD must be incorporated into the LCDProc driver, as
far as I can see.

The patch works like this: when a IR event is detected, the event is
transcribed into a LIRC-compatible packet, and passed to LIRC on a
configurable server and port using UDP. "Transcribed" means:

- An initial "sync" space is added, because iTuner apparently
   deigns to return this interval in the USB packet (I need to test
   this conjecture with more different remotes).
- The arity of the MARK/SPACE signals is inverted, because LIRC
   expects active-low signalling.
- The values of the signals are scaled: iTuner returns data
   representing microsecond intervals, whereas LIRC expects
   intervals denoted in jiffies (1/16384 seconds).

I don't think any other LCDProc driver passes IR events to LIRC; but
perhaps no other supported device restricts IR and display clients to
using the same non-shareable device handle. If this is too hacky for
LCDProc to accept as a patch, no worries; "it works for me" (tm).

P.S. It would be nice if keypad events could also be passed through LIRC
as if they were IR events. However this evidently isn't the LCDProc way;
so I think the proper way to get this functionality would be to write an
LCDProc client that fields keypad events, transforms them into simulated
  IR events, and passes them to LIRC using UDP. In this way (and with a
suitable lircd.conf), a program such as MythTV could field events from
the keypad or an IR remote interchangeably. This enhancement would be
independent of the picoLCD; effectively it would amount to a LCDProc
"driver" for LIRC.

Regards,
Jack Cleaver.

From herdler at gmx.de  Tue Sep  2 17:10:25 2008
From: herdler at gmx.de (Stefan Herdler)
Date: Wed, 03 Sep 2008 01:10:25 +0200
Subject: [Lcdproc] PicoLCD driver for LCDProc
In-Reply-To: <48BD1441.2010106@jackpot.uk.net>
References: <48BD1441.2010106@jackpot.uk.net>
Message-ID: <48BDC7E1.8020408@gmx.de>

Hi Jack,

Jack Cleaver wrote:
> Yesterday I submitted a patch to the LCDProc mailing list fixing a
> memory leak in the picolcd driver. It hasn't been picked up yet -
> perhaps I submitted it in the wrong way, or in the wrong place (I
> appreciate that 24 hours is not a long time to wait, though). Before
> submitting my next patch, I'm seeking guidance on patch submission.
>
The list is the right way to submit Patches for LCDproc.

The appearance of the LCDproc-maintainer (Peter Marschall) got rare in 
the last few months. His last mail on the list is from about one month ago.

There is one patch from me still pending too.

So be patient and hope the best. (In fact, that's the only thing we can do.)

Regards
Stefan

From rbu at gentoo.org  Tue Sep  2 18:10:58 2008
From: rbu at gentoo.org (Robert Buchholz)
Date: Wed, 3 Sep 2008 02:10:58 +0200
Subject: [Lcdproc] PicoLCD driver for LCDProc
In-Reply-To: <48BD1441.2010106@jackpot.uk.net>
References: <48BD1441.2010106@jackpot.uk.net>
Message-ID: <200809030211.01296.rbu@gentoo.org>

On Tuesday 02 September 2008, Jack Cleaver wrote:
> Yesterday I submitted a patch to the LCDProc mailing list fixing a
> memory leak in the picolcd driver. It hasn't been picked up yet -
> perhaps I submitted it in the wrong way, or in the wrong place (I
> appreciate that 24 hours is not a long time to wait, though). Before
> submitting my next patch, I'm seeking guidance on patch submission.

In general, unified diffs (diff -u, or what cvs diff / svn diff produce) 
and diffs attached to a mail (versus inline copy) are probably 
preferable since they are easier to handle.



Regards,
Robert
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.omnipotent.net/pipermail/lcdproc/attachments/20080903/d7acd7ba/attachment.pgp>

From kdogden at gmail.com  Tue Sep  2 18:52:16 2008
From: kdogden at gmail.com (Kevin Ogden)
Date: Tue, 2 Sep 2008 20:52:16 -0400
Subject: [Lcdproc] OSX + MtxOrb Driver
In-Reply-To: <f4eb766f0809012056v6bf52fb3g645c97ac28d1b6@mail.gmail.com>
References: <AA2A95BB-7983-448D-8249-5B54BF044680@gmail.com>
	<f4eb766f0808311849t17eae61ar2b280de97503a364@mail.gmail.com>
	<0854553D-8AF9-43E6-B4C2-2E97875B3427@gmail.com>
	<f4eb766f0809012056v6bf52fb3g645c97ac28d1b6@mail.gmail.com>
Message-ID: <CD47DE76-F80F-4BC3-9AC7-0CD8707DF8BE@gmail.com>

>
>>> You could also grab the code, compile the Matrix Orbital driver
>>> for debugging, and post the results of just starting LCDd with
>>> debug level set to '5'...
>>
>> If I get a chance, I'll try that tonight.
>
> That's probably a good next step.

I've attached a copy of my LCDd.conf and the debug log.  It looks  
like it died really early on.... right about here:

driver_store_private_ptr(driver=[MtxOrb], ptr=0x306e40)
MtxOrb: init(0x306be0)
MtxOrb: using Device /dev/tty.serial1
MtxOrb_init: Brightness (in config) is '1000'
MtxOrb_init: OffBrightness (in config) is '0'

That's where it hangs.  Kinda odd.

After killing LCDd I can talk to the port with screen just fine and  
write text to the display.

Any ideas?

--Kevin

-------------- next part --------------
A non-text attachment was scrubbed...
Name: kdo-LCDd.conf
Type: application/octet-stream
Size: 27194 bytes
Desc: not available
URL: <http://lists.omnipotent.net/pipermail/lcdproc/attachments/20080902/194763c4/attachment-0001.obj>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: kdo-DebugLog-OSX-MtxOrb.txt
URL: <http://lists.omnipotent.net/pipermail/lcdproc/attachments/20080902/194763c4/attachment-0001.txt>

From kdogden at gmail.com  Tue Sep  2 19:08:05 2008
From: kdogden at gmail.com (Kevin Ogden)
Date: Tue, 2 Sep 2008 21:08:05 -0400
Subject: [Lcdproc] OSX + MtxOrb Driver
In-Reply-To: <f4eb766f0809012056v6bf52fb3g645c97ac28d1b6@mail.gmail.com>
References: <AA2A95BB-7983-448D-8249-5B54BF044680@gmail.com>
	<f4eb766f0808311849t17eae61ar2b280de97503a364@mail.gmail.com>
	<0854553D-8AF9-43E6-B4C2-2E97875B3427@gmail.com>
	<f4eb766f0809012056v6bf52fb3g645c97ac28d1b6@mail.gmail.com>
Message-ID: <A16F130A-760D-4434-BCA2-7D3EF80370CA@gmail.com>


>
>>> You could also grab the code, compile the Matrix Orbital driver
>>> for debugging, and post the results of just starting LCDd with
>>> debug level set to '5'...
>>
>> If I get a chance, I'll try that tonight.
>
> That's probably a good next step.
>

Here's another thing I just tried....

I ran 'screen /dev/tty.serial1 19200'

Then I wrote some text on the display THEN I ran LCDd with screen  
still running and it produced the log I just attached.  It looks like  
it really thought it was doing something but nothing made it to the  
LCD obviously.

--Kevin

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: kdo-DebugLog2-OSX-MtxOrb.txt
URL: <http://lists.omnipotent.net/pipermail/lcdproc/attachments/20080902/9dc49a6c/attachment-0001.txt>
-------------- next part --------------





From ethan.dicks at gmail.com  Tue Sep  2 19:10:00 2008
From: ethan.dicks at gmail.com (Ethan Dicks)
Date: Wed, 3 Sep 2008 13:10:00 +1200
Subject: [Lcdproc] OSX + MtxOrb Driver
In-Reply-To: <CD47DE76-F80F-4BC3-9AC7-0CD8707DF8BE@gmail.com>
References: <AA2A95BB-7983-448D-8249-5B54BF044680@gmail.com>
	<f4eb766f0808311849t17eae61ar2b280de97503a364@mail.gmail.com>
	<0854553D-8AF9-43E6-B4C2-2E97875B3427@gmail.com>
	<f4eb766f0809012056v6bf52fb3g645c97ac28d1b6@mail.gmail.com>
	<CD47DE76-F80F-4BC3-9AC7-0CD8707DF8BE@gmail.com>
Message-ID: <f4eb766f0809021810p3470e0c4r729093dff19b0b8@mail.gmail.com>

On Wed, Sep 3, 2008 at 12:52 PM, Kevin Ogden <kdogden at gmail.com> wrote:
> I've attached a copy of my LCDd.conf and the debug log.  It looks like it
> died really early on.... right about here:
>
> driver_store_private_ptr(driver=[MtxOrb], ptr=0x306e40)
> MtxOrb: init(0x306be0)
> MtxOrb: using Device /dev/tty.serial1
> MtxOrb_init: Brightness (in config) is '1000'
> MtxOrb_init: OffBrightness (in config) is '0'
>
> That's where it hangs.  Kinda odd.
>
> After killing LCDd I can talk to the port with screen just fine and write
> text to the display.

>From looking at your LCDd.conf and your debug output and MtxOrb.c,
it appears to me that the next bit of driver code that executes after your
last line of text is the open().  If the open() returns -1, the driver
will report
the error.  If the open returns anything else, it logs "... opened
display on <device>".
Since neither one is showing up, my guess is that open isn't returning
at all, thus the hang.

Why that should happen, I'm not sure, unless there's some chance
it's related to permissions or ownership.

One thing I've done in the past under Linux is to use 'strace' to see what's
going on at a library-call level.  I don't know off the top of my head if strace
is available for OSX, but that could be useful to find out.

-ethan

From ethan.dicks at gmail.com  Tue Sep  2 19:19:24 2008
From: ethan.dicks at gmail.com (Ethan Dicks)
Date: Wed, 3 Sep 2008 13:19:24 +1200
Subject: [Lcdproc] OSX + MtxOrb Driver
In-Reply-To: <f4eb766f0809021810p3470e0c4r729093dff19b0b8@mail.gmail.com>
References: <AA2A95BB-7983-448D-8249-5B54BF044680@gmail.com>
	<f4eb766f0808311849t17eae61ar2b280de97503a364@mail.gmail.com>
	<0854553D-8AF9-43E6-B4C2-2E97875B3427@gmail.com>
	<f4eb766f0809012056v6bf52fb3g645c97ac28d1b6@mail.gmail.com>
	<CD47DE76-F80F-4BC3-9AC7-0CD8707DF8BE@gmail.com>
	<f4eb766f0809021810p3470e0c4r729093dff19b0b8@mail.gmail.com>
Message-ID: <f4eb766f0809021819n467f0d39n5933746c2bef4d11@mail.gmail.com>

On Wed, Sep 3, 2008 at 1:10 PM, Ethan Dicks <ethan.dicks at gmail.com> wrote:
> From looking at your LCDd.conf and your debug output and MtxOrb.c,
> it appears to me that the next bit of driver code that executes after your
> last line of text is the open().  If the open() returns -1, the driver
> will report the error.  If the open returns anything else, it
> logs "... opened display on <device>".
>
> Since neither one is showing up, my guess is that open isn't returning
> at all, thus the hang.
>
> Why that should happen, I'm not sure, unless there's some chance
> it's related to permissions or ownership.

One thought - if I spotted it correctly, in your LCDd.conf, LCDd is
running as the user 'nobody', not you.  Perhaps 'nobody' can't
open the device, but you can, thus "screen" works, but LCDd
doesn't?

I looked at my 'nobody' entry on my Mac laptop...

  nobody:*:-2:-2:Unprivileged User:/:/usr/bin/false

Does yours look like that?

-ethan

From kdogden at gmail.com  Tue Sep  2 19:40:06 2008
From: kdogden at gmail.com (Kevin Ogden)
Date: Tue, 2 Sep 2008 21:40:06 -0400
Subject: [Lcdproc] OSX + MtxOrb Driver
In-Reply-To: <f4eb766f0809021819n467f0d39n5933746c2bef4d11@mail.gmail.com>
References: <AA2A95BB-7983-448D-8249-5B54BF044680@gmail.com>
	<f4eb766f0808311849t17eae61ar2b280de97503a364@mail.gmail.com>
	<0854553D-8AF9-43E6-B4C2-2E97875B3427@gmail.com>
	<f4eb766f0809012056v6bf52fb3g645c97ac28d1b6@mail.gmail.com>
	<CD47DE76-F80F-4BC3-9AC7-0CD8707DF8BE@gmail.com>
	<f4eb766f0809021810p3470e0c4r729093dff19b0b8@mail.gmail.com>
	<f4eb766f0809021819n467f0d39n5933746c2bef4d11@mail.gmail.com>
Message-ID: <BD366CF7-4CE0-4984-9ACF-FF3FB834F9DA@gmail.com>


>
> One thought - if I spotted it correctly, in your LCDd.conf, LCDd is
> running as the user 'nobody', not you.  Perhaps 'nobody' can't
> open the device, but you can, thus "screen" works, but LCDd
> doesn't?
>
> I looked at my 'nobody' entry on my Mac laptop...
>
>   nobody:*:-2:-2:Unprivileged User:/:/usr/bin/false
>
> Does yours look like that?

Yep it does.  I just tried having LCDd drop to my user account and I  
set myself as the owner of /dev/tty.serial1 and tried setting  
permissions to 666 and 777.  Still hangs.  Weirdness....

--Kevin

From ethan.dicks at gmail.com  Tue Sep  2 19:54:02 2008
From: ethan.dicks at gmail.com (Ethan Dicks)
Date: Wed, 3 Sep 2008 13:54:02 +1200
Subject: [Lcdproc] OSX + MtxOrb Driver
In-Reply-To: <f4eb766f0809021810p3470e0c4r729093dff19b0b8@mail.gmail.com>
References: <AA2A95BB-7983-448D-8249-5B54BF044680@gmail.com>
	<f4eb766f0808311849t17eae61ar2b280de97503a364@mail.gmail.com>
	<0854553D-8AF9-43E6-B4C2-2E97875B3427@gmail.com>
	<f4eb766f0809012056v6bf52fb3g645c97ac28d1b6@mail.gmail.com>
	<CD47DE76-F80F-4BC3-9AC7-0CD8707DF8BE@gmail.com>
	<f4eb766f0809021810p3470e0c4r729093dff19b0b8@mail.gmail.com>
Message-ID: <f4eb766f0809021854n2655c12fhe60535c015709c64@mail.gmail.com>

On Wed, Sep 3, 2008 at 1:10 PM, Ethan Dicks <ethan.dicks at gmail.com> wrote:
> From looking at your LCDd.conf and your debug output and MtxOrb.c,
> it appears to me that the next bit of driver code that executes after your
> last line of text is the open()...

Kevin,

Googling for "OS X serial open hang", I found this...

  <http://osdir.com/ml/hardware.avr.avrdude.devel/2006-03/msg00014.html>

Try adding "O_NDELAY" to the open() call.  I can imagine if the
OSX serial driver is expecting "DCD" to be asserted (because it
thinks you "must" have a modem on that port), things wouldn't
go well.

-ethan

From kdogden at gmail.com  Tue Sep  2 20:46:13 2008
From: kdogden at gmail.com (Kevin Ogden)
Date: Tue, 2 Sep 2008 22:46:13 -0400
Subject: [Lcdproc] OSX + MtxOrb Driver
Message-ID: <2763384F-D1BB-4269-BB39-6CA32F64B10D@gmail.com>


On Sep 2, 2008, at 9:54 PM, Ethan Dicks wrote:
> On Wed, Sep 3, 2008 at 1:10 PM, Ethan Dicks <ethan.dicks at gmail.com>  
> wrote:
>> From looking at your LCDd.conf and your debug output and MtxOrb.c,
>> it appears to me that the next bit of driver code that executes  
>> after your
>> last line of text is the open()...
>
> Kevin,
>
> Googling for "OS X serial open hang", I found this...
>
>   <http://osdir.com/ml/hardware.avr.avrdude.devel/2006-03/ 
> msg00014.html>
>
> Try adding "O_NDELAY" to the open() call.  I can imagine if the
> OSX serial driver is expecting "DCD" to be asserted (because it
> thinks you "must" have a modem on that port), things wouldn't
> go well.

Holy sh*t, good catch!  It's actually almost working now.

Now I'm using the latest nightly.  After adding O_NDELAY to the open  
call it displays text on the LCD but there characters replaced by "V"  
characters usually followed by a straight double vertical line  
characters (in the server screen) or a "V" followed by an underscore  
or a single vertical line.....  sometimes with nothing after it....  
it's kinda weird.  This is what is was doing under FreeBSD as well.

Thanks man.  It looks real close now.

--Kevin D. Ogden






From jack at jackpot.uk.net  Wed Sep  3 03:18:42 2008
From: jack at jackpot.uk.net (Jack Cleaver)
Date: Wed, 03 Sep 2008 10:18:42 +0100
Subject: [Lcdproc] PicoLCD driver for LCDProc
In-Reply-To: <200809030211.01296.rbu@gentoo.org>
References: <48BD1441.2010106@jackpot.uk.net>
	<200809030211.01296.rbu@gentoo.org>
Message-ID: <48BE5672.6090206@jackpot.uk.net>

Robert Buchholz wrote:
> On Tuesday 02 September 2008, Jack Cleaver wrote:
>> Yesterday I submitted a patch to the LCDProc mailing list fixing a
>> memory leak in the picolcd driver. It hasn't been picked up yet -
>> perhaps I submitted it in the wrong way, or in the wrong place (I
>> appreciate that 24 hours is not a long time to wait, though). Before
>> submitting my next patch, I'm seeking guidance on patch submission.
> 
> In general, unified diffs (diff -u, or what cvs diff / svn diff produce) 
> and diffs attached to a mail (versus inline copy) are probably 
> preferable since they are easier to handle.

OK, thanks, Stefan and Robert.

-- 
Jack.

From kdogden at gmail.com  Wed Sep  3 20:58:09 2008
From: kdogden at gmail.com (Kevin Ogden)
Date: Wed, 3 Sep 2008 22:58:09 -0400
Subject: [Lcdproc] OSX + MtxOrb Driver
In-Reply-To: <f4eb766f0809031848l55150281p62cff779977cb49e@mail.gmail.com>
References: <AA2A95BB-7983-448D-8249-5B54BF044680@gmail.com>
	<0854553D-8AF9-43E6-B4C2-2E97875B3427@gmail.com>
	<f4eb766f0809012056v6bf52fb3g645c97ac28d1b6@mail.gmail.com>
	<CD47DE76-F80F-4BC3-9AC7-0CD8707DF8BE@gmail.com>
	<f4eb766f0809021810p3470e0c4r729093dff19b0b8@mail.gmail.com>
	<f4eb766f0809021854n2655c12fhe60535c015709c64@mail.gmail.com>
	<CFDFE163-4172-4F1F-9966-134EE0D7133C@gmail.com>
	<f4eb766f0809031554n42ae31e4x6fefcb3de0053b15@mail.gmail.com>
	<f4eb766f0809031729r775344dcl8d3e7ba7e559fae6@mail.gmail.com>
	<9DB932F0-5779-4064-A6AE-40E0173CC726@gmail.com>
	<f4eb766f0809031848l55150281p62cff779977cb49e@mail.gmail.com>
Message-ID: <2E0CCCF4-FB07-4927-8F5E-FD9D550B389A@gmail.com>

AWESOME!  OK, it's working now, I've attached a diff with all the  
mangling of MtxOrb.c I've done along with my LCDd.conf.

It's now working flawlessly under OSX with my old Matrix Orbital  
LK202-25 display with no extra 'V' characters or anything.  Looking  
at the manual, it said the backlight command was 254 66 0, which in  
hex is FE 42 0.  Along with the GPO patch and a slight addition  
relating to DCD using '/dev/tty.serial1' on my generic P4 running OSX  
it's working fine.

I think you said that O_NDELAY flag to the open call may not be  
necessary if you use /dev/cu.serial1 though.  I really don't want to  
mess with it at the moment now that it's working though.

Thanks for all your help!  I appreciate it, my cool little red LCD  
display is now doing something useful!

--Kevin

On Sep 3, 2008, at 9:48 PM, Ethan Dicks wrote:

> On 9/4/08, Kevin Ogden <kdogden at gmail.com> wrote:
>> Unfortunately the GPO patch didn't help.
>
> OK.  Then ensure you have the right type setting in your config.   
> You don't
> have a VFD, so your choices should be lcd or lkd.  Try both.
>
> Also... check in MtxOrb.c to ensure you have the right code for
> setting the backlight, etc... looking at MtxOrb_backlight, I see
> that if type is "VKD" (mine), it sends 0xFE 'Y'.  That's the one I
> could test.  If you have any other kind, it sends 0xFE 0x99.  I'm
> guessing that is wrong.  I think you said you have an older manual;
> but check for the backlight command in what you have (I still have
> my original paper manual from 1999, which is good, because that
> one isn't available online).
>
> I have a memory when we were debugging the backlight routine
> (because another maintainer accidentally put in hex instead of
> decimal), I only "fixed" the code I could test - i.e. for VKD.  Even
> though LCDproc started with MtxOrb as the only supported
> module, over 10 years, folks have drifted to other modules
> and I am one of the few maintainers (only one left?) with an MO
> module, and I have a rare and expensive one at that (it was $130
> in 2000, IIRC; thankfully, my employer at the time paid for it, and
> the drive-bay mounting bracket).
>
> I'm thinking we probably just have to tune the backlight code
> to handle the cases I couldn't test for.
>
>>  The display is an old LK202-25 with 6 GPOs.  After setting GPOs  
>> to 6 the
>> first two and last two characters in the server screen are a V  
>> followed by a
>> double vertical line character.
>>
>>  After setting GPOs to 0 the first character is a K and so is the  
>> last
>> character in the server screen.
>
> Is zero a valid choice?  Normally, I thought the possibilities were
> like 1, 2, or 6?
>
> Anyway, "K" is the random letter when GPOs is wrong, so you were
> probably OK before.
>
>> If I took a short video clip with my digital camera of the display
>> and sent it to you, would that help any?
>
> Not really... I'm on a low-bandwidth, 12-hour-a-day sat feed.
>
>>  I also tried playing with the GPO value setting just for giggles  
>> and had no
>> luck.
>
> OK.
>
> Check your code and your backlight command...
>
> -ethan


From kdogden at gmail.com  Wed Sep  3 20:59:07 2008
From: kdogden at gmail.com (Kevin Ogden)
Date: Wed, 3 Sep 2008 22:59:07 -0400
Subject: [Lcdproc] OSX + MtxOrb Driver
Message-ID: <6343A64A-4BED-4C02-8E77-E91DC5A6B5D2@gmail.com>

Oops, forgot to attach patch and LCDd.conf.... --Kevin

-------------- next part --------------
A non-text attachment was scrubbed...
Name: kdo-osx-lk202-patch.diff
Type: application/octet-stream
Size: 2442 bytes
Desc: not available
URL: <http://lists.omnipotent.net/pipermail/lcdproc/attachments/20080903/c9953282/attachment-0002.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: LCDd.conf
Type: application/octet-stream
Size: 27202 bytes
Desc: not available
URL: <http://lists.omnipotent.net/pipermail/lcdproc/attachments/20080903/c9953282/attachment-0003.obj>
-------------- next part --------------




From jack at jackpot.uk.net  Sun Sep  7 09:08:02 2008
From: jack at jackpot.uk.net (Jack Cleaver)
Date: Sun, 07 Sep 2008 16:08:02 +0100
Subject: [Lcdproc] PATCH: Enable picolcd to pass IR codes to LIRC via UDP
Message-ID: <48C3EE52.1090204@jackpot.uk.net>

Hi,

I have coded a patch (attached) that enables picolcd to send IR codes to
LIRC.

PicoLCD IR packets don't include a sync pulse, and they don't include a
gap trailer; these have to be synthesized, and that requires divination
(guessing) of where a code begins and ends, and I presume my guesswork
is fallible.

The synthesized gap seems to be interfering with detection of repeat
codes, at least with some of my remotes; and that in turn seems to be
interfering with the correct operation of irrecord. So I'm not sure that
this patch is ready for prime-time, but I don't know how to go forward.
I'd welcome comments, if anyone cares to inspect my code (Nicu? Woody?).

Anyway, this is the only way I know to get picolcd remote codes into
LIRC. And given a lircd.conf that matches your remote, it seems to be
reliable (so far).

-- 
Jack.
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: picolcd.h.diff
URL: <http://lists.omnipotent.net/pipermail/lcdproc/attachments/20080907/9faf391e/attachment.txt>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: picolcd.c.diff
URL: <http://lists.omnipotent.net/pipermail/lcdproc/attachments/20080907/9faf391e/attachment-0001.txt>

From guy.widloecher at gmail.com  Wed Sep 10 03:34:55 2008
From: guy.widloecher at gmail.com (Guy Widloecher)
Date: Wed, 10 Sep 2008 11:34:55 +0200
Subject: [Lcdproc] hd44780-lcm162.c / hd44780-lcm162.h
Message-ID: <8db3d6360809100234p73df9cbfpbc03bc02a78b3c0a@mail.gmail.com>

Hello,

I'm looking for the files hd44780-lcm162.c / hd44780-lcm162.h (module for
LCM-162 / hd44780).

These files were made by Clemens Zauner and he wrote about them in a post on
Thu Jun 14 14:30:03 2007
http://lists.omnipotent.net/pipermail/lcdproc/2007-June/011816.html

I tried to contact Clemens without any success, so if somebody on the list
knows where to find them, I'll be very happy.

Best regards,
Guy Widloecher
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omnipotent.net/pipermail/lcdproc/attachments/20080910/6f181311/attachment.htm>

From lingxiaoheng at gmail.com  Wed Sep 10 04:16:11 2008
From: lingxiaoheng at gmail.com (Ling Xiaoheng)
Date: Wed, 10 Sep 2008 18:16:11 +0800
Subject: [Lcdproc] How can I driver EZIO-100/MTB134 in Lcdproc
Message-ID: <a61030fc0809100316w6d96294ai9fbf66bef5b38550@mail.gmail.com>

Hey,
    I'm using EZIO-100 for my lcd display,but I read document but
can't find any useful information about EZIO-100/MTB134.Searched via
Google and Maillist,I find:
http://lists.omnipotent.net/pipermail/lcdproc/2007-May/011770.html
http://lists.omnipotent.net/pipermail/lcdproc/2007-May/011779.html
http://lists.omnipotent.net/pipermail/lcdproc/2004-January/008503.html

but in the mail,they said:
I have had a qucik glance at the code, which made me not integrate
it into LCDproc CVS in its current state.
Here's why:
* the code is written for the driver API of LCDproc v0.4.x
  This version of LCDproc is un-maintained since a long tine.
  Please have a look at
    http://lcdproc.sourceforge.net/docs/current-dev.html#driver-api
  to learn about the cnew driver API.
* It completely lacks documentation. Please see
    http://lcdproc.sourceforge.net/docs/current-dev.html#add-your-driver
  and especially
    http://lcdproc.sourceforge.net/docs/current-dev.html#documentation
  to find out what is required.

Does LCDproc v0.5.2 support EZIO now?If not who can give me some idea?
Thanks. =)

-- 
Regards

linyin.8800.org

From m.krepp at nynex.de  Wed Sep 10 09:46:40 2008
From: m.krepp at nynex.de (Matthias Krepp)
Date: Wed, 10 Sep 2008 17:46:40 +0200
Subject: [Lcdproc] Heartbeat, Hello, Goodbye options
Message-ID: <C410E390CC5B29489B9D31F1D75393EE119A6458ED@evolution.NYNEXHOME.local>

Hey there,

Im trying to get lcdproc to run on my debian server.
First of all I have used the 5.2 version, but as far as I figured out, I cant
turn the "heartbeat" off. I saw on the earlier user-guides that this option
can be used, so I tried the earlier versions as well (5.0).

But the heartbeat option doesnt work there either, so Im confused right now,
if I did something wrong or if its not possible. I have read a lot of comments
about it, but none of them really gave me an answer to my question.

I guess in version 4.x it works (I didnt get my tyan driver to work there yet),
 but I would like to use one of the latest versions. In user-guide 5.0 the heartbeat
option is shown, so it should work right ?

Also the "Hello" and "GoodBye" options dont work. Its weird because the server
is loading my LCDd.conf file without any errors and it works well with the other options,
 but not one of the options I mentioned.

It would be nice if somebody could tell me in which version the mentioned options really
work and which not.

Thanks in advance.

Matthias Krepp

From amb at gedanken.demon.co.uk  Sun Sep  7 03:11:14 2008
From: amb at gedanken.demon.co.uk (Andrew M. Bishop)
Date: Sun, 07 Sep 2008 10:11:14 +0100
Subject: [Lcdproc] Bug with numeric priorities
Message-ID: <votzcma8yt.fsf@gedanken.demon.co.uk>

[Resent after subscribing to the lcdproc list, an older duplicate
 message is still waiting for moderator approval]

I have been using LCDproc for a while on Debian (version 0.4.5) and
have just tried updating to version 0.5.2. What I have found during
this changeover is a bug in LCDd that means that the numeric
priorities have never worked since the named priorities were added.

If a numeric priority of 128 is used (for example) then only one
screen will display, they don't rotate like they should (since 128 is
the same as 'info').

Based on the CVS files on SourceForge
http://lcdproc.cvs.sourceforge.net/lcdproc/lcdproc/server/commands/screen_commands.c?view=log
I can see that from revision 1.4 in Feb 2003 that the new code was
added, but it contains a logical error.

This is the code in question:

  196 		/* Handle the "priority" parameter*/
  197 		else if (strcmp (p, "priority") == 0) {
  198 			if (argc > i + 1) {
  199 				i++;
  200 				debug (RPT_DEBUG, "screen_set: priority=\"%s\"", argv[i]);
  201 
  202 				/* first try to interpret it as a number */
  203 				number = atoi (argv[i]);
  204 				if (number > 0) {
  205 					if (number <= 64) {
  206 						s->priority = PRI_FOREGROUND;
  207 					} else if (number < 192) {
  208 						s->priority = PRI_INFO;
  209 					} else {
  210 						s->priority = PRI_BACKGROUND;
  211 					}
  212 				} else {
  213 					/* Try if it is a priority class */
  214 					number = screen_pri_name_to_pri (argv[i]);
  215 				}
  216 				if (number >= 0) {
  217 					s->priority = number;
  218 					sock_send_string(c->sock, "success\n");
  219 				} else {
  220 					sock_send_string(c->sock, "huh?  invalid argument at -priority\n");
  221 				}
  222 			} else {
  223 				sock_send_string (c->sock, "huh?  -priority requires a parameter\n");
  224 			}
  225 		}


If the priority value given is numeric then the variable 'number' will
be given its value on line 203.  Line 204 will detect this and the
code from lines 205-211 will correctly decode 'number' into a priority
class and set the priority of the screen.  If it is not numeric then
line 214 will convert the string to a priority class and store it in
the variable 'number'.  Line 216 detects if a valid priority has been
given and sets the priority of the screen.

The problem is that the numeric value on line 203 in the variable
'number' is unchanged by the code in lines 205-211.  In lines 216, 217
the screen priority is set to the original numeric value and not the
priority class.  The code in lines 205 to 211 is useless code, the
priority set here is overwritten on line 217.

The change is simple though; on lines 206, 208, 210 's->priority'
should be replaced by 'number'.

The bug can be verified with unmodified code by using priority 2 which
maps to PRI_INFO and the screens rotate.  Using priority 128 which
should map to PRI_INFO and only one screen is shown, they don't
rotate.

-- 
Andrew.
----------------------------------------------------------------------
Andrew M. Bishop                             amb at gedanken.demon.co.uk
                                      http://www.gedanken.demon.co.uk/

From seemanta at gmail.com  Fri Sep 12 03:23:43 2008
From: seemanta at gmail.com (seemanta at gmail.com)
Date: Fri, 12 Sep 2008 14:53:43 +0530
Subject: [Lcdproc] LCDProc hardware connections...
Message-ID: <133979c50809120223s6b8b9ec8k90f5c53afb0f9839@mail.gmail.com>

Hi,
I am interested in building my own LCDproc for my PC. However, while
there was a lot of documentation on the software part of it, I was not
able to
find much about how to make the connections between the PC and the
LCD. I may not be looking at the correct place. I understand that
there are
options to use the serial port, parallel port or even the usb port.
But where do I find specific details about the connections ?

It would be great if you can point me to the correct location.

thanks in advance!
Seemanta

From kripton at kripserver.net  Fri Sep 12 09:15:37 2008
From: kripton at kripserver.net (Jannis Achstetter)
Date: Fri, 12 Sep 2008 17:15:37 +0200
Subject: [Lcdproc] LCDProc hardware connections...
In-Reply-To: <133979c50809120223s6b8b9ec8k90f5c53afb0f9839@mail.gmail.com>
References: <133979c50809120223s6b8b9ec8k90f5c53afb0f9839@mail.gmail.com>
Message-ID: <48CA8799.2000409@kripserver.net>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hello,

seemanta at gmail.com schrieb:
> Hi,
> I am interested in building my own LCDproc for my PC. However, while
> there was a lot of documentation on the software part of it, I was not
> able to
> find much about how to make the connections between the PC and the
> LCD. I may not be looking at the correct place. I understand that
> there are
> options to use the serial port, parallel port or even the usb port.
> But where do I find specific details about the connections ?
> 
> It would be great if you can point me to the correct location.


the kind of connection you have to use depends on the kind of hardware
and driver you want to use. For the HD44780 and compatibles, take a look
here:
http://lcdproc.sourceforge.net/docs/current-user.html#hd44780-connections

Here is all the documentation with all drivers listed:
http://lcdproc.sourceforge.net/docs/current-user.html

Jannis
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkjKh5gACgkQeYlewm37lbjQhwCfeLasZGIMNgSQvaPHgNhchU+m
AJMAnjipyoXdtk9w/nNzuAx0Jwa46JoK
=Tbzu
-----END PGP SIGNATURE-----

From rbu at gentoo.org  Fri Sep 12 10:39:02 2008
From: rbu at gentoo.org (Robert Buchholz)
Date: Fri, 12 Sep 2008 18:39:02 +0200
Subject: [Lcdproc] Patches for iMON LCD (for example in Antec Fusion
	Black)
In-Reply-To: <479BE7C4.6020206@codeka.com>
References: <001b01c7ee1a$433f22c0$c9bd6840$@com>
	<200801261836.52208.rbu@gentoo.org> <479BE7C4.6020206@codeka.com>
Message-ID: <200809121839.04589.rbu@gentoo.org>

On Sunday 27 January 2008, Dean Harding wrote:
> Robert Buchholz wrote:
> > On Saturday 08 September 2007, Dean Harding wrote:
> > I have some user request for inclusion of the driver in Gentoo, but
> > I'd like to see it included in upstream CVS first. The only
> > concerns right now with your patch are the missing documentation.
> > Can you update your patch so Peter would consider committing it?
> > Besides that, what is the status of it (open issues, TODOs)?
> >
> > Just for all others, the most current version I found is here:
> >   http://codeka.com/blogs/imon/lcdproc-0.5.2-imonlcd-0.3.patch
>
> I've set up some forums on my site (http://codeka.com/forums/) where
> you can post questions, etc.
>
> As for open issues, the main one is support for non-ASCII characters.
> I've got glyphs for some characters, but the problem at the moment is
> encoding. I need to implement some method to specify the encoding of
> the incoming text and translate it to UTF-8 or something so I can
> choose the correct glyph.
>
> Other than that, some people are reporting issues with stability
> (though I have a feeling it may be hardware related -- it's not
> exactly high quality) which I'm also working on. One of the things
> I'm thinking of doing is making the "RENDER_FREQ" parameter, which is
> currently #defined in server/main.h to 8, a configurable parameter.
> The reason is that the iMON LCD is very heavy on the USB, and it
> artificially raises the system's load because of all the data that is
> written to it. Setting RENDER_FREQ to 1 seems to help, so that was
> something else I wanted to do.

Any progress on your work?


> But in any case, if you direct your users to
> http://codeka.com/forums/, I'll be more than happy to help out with
> anything.

We are now shipping the imon patch in Gentoo, and I wonder if it'll be 
included in CVS HEAD. Peter?


-R.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.omnipotent.net/pipermail/lcdproc/attachments/20080912/33a114bb/attachment.pgp>

From bogdan_radulescu99 at yahoo.com  Mon Sep 15 03:05:34 2008
From: bogdan_radulescu99 at yahoo.com (Bogdan Radulescu)
Date: Mon, 15 Sep 2008 02:05:34 -0700 (PDT)
Subject: [Lcdproc] LCDProc hardware connections...
In-Reply-To: <133979c50809120223s6b8b9ec8k90f5c53afb0f9839@mail.gmail.com>
Message-ID: <200605.4731.qm@web30203.mail.mud.yahoo.com>

You should look at the LCD documentation!

If you have a MatrixOrbital you are luck because it has lots of good documentation and it's very easy to connect to serial and with for that you should be careful with power becasue it's easy to brick it.

Different models connect in different ways so the LCD manufacturer should provide all the info you need.



--- On Fri, 9/12/08, seemanta at gmail.com <seemanta at gmail.com> wrote:

> From: seemanta at gmail.com <seemanta at gmail.com>
> Subject: [Lcdproc] LCDProc hardware connections...
> To: lcdproc at lists.omnipotent.net
> Date: Friday, September 12, 2008, 12:23 PM
> Hi,
> I am interested in building my own LCDproc for my PC.
> However, while
> there was a lot of documentation on the software part of
> it, I was not
> able to
> find much about how to make the connections between the PC
> and the
> LCD. I may not be looking at the correct place. I
> understand that
> there are
> options to use the serial port, parallel port or even the
> usb port.
> But where do I find specific details about the connections
> ?
> 
> It would be great if you can point me to the correct
> location.
> 
> thanks in advance!
> Seemanta
> _______________________________________________
> LCDproc mailing list
> LCDproc at lists.omnipotent.net
> http://lists.omnipotent.net/mailman/listinfo/lcdproc


      

From peter at adpm.de  Mon Sep 15 10:27:53 2008
From: peter at adpm.de (Peter Marschall)
Date: Mon, 15 Sep 2008 18:27:53 +0200
Subject: [Lcdproc] How can I driver EZIO-100/MTB134 in Lcdproc
In-Reply-To: <a61030fc0809100316w6d96294ai9fbf66bef5b38550@mail.gmail.com>
References: <a61030fc0809100316w6d96294ai9fbf66bef5b38550@mail.gmail.com>
Message-ID: <200809151827.53530.peter@adpm.de>

Hi,

On Wednesday, 10. September 2008, Ling Xiaoheng wrote:
> Hey,
>     I'm using EZIO-100 for my lcd display,but I read document but
> can't find any useful information about EZIO-100/MTB134.Searched via
> Google and Maillist,I find:
> http://lists.omnipotent.net/pipermail/lcdproc/2007-May/011770.html
> http://lists.omnipotent.net/pipermail/lcdproc/2007-May/011779.html
> http://lists.omnipotent.net/pipermail/lcdproc/2004-January/008503.html
>
> but in the mail,they said:
> I have had a qucik glance at the code, which made me not integrate
> it into LCDproc CVS in its current state.
> Here's why:
> * the code is written for the driver API of LCDproc v0.4.x
>   This version of LCDproc is un-maintained since a long tine.
>   Please have a look at
>     http://lcdproc.sourceforge.net/docs/current-dev.html#driver-api
>   to learn about the cnew driver API.
> * It completely lacks documentation. Please see
>     http://lcdproc.sourceforge.net/docs/current-dev.html#add-your-driver
>   and especially
>     http://lcdproc.sourceforge.net/docs/current-dev.html#documentation
>   to find out what is required.
>
> Does LCDproc v0.5.2 support EZIO now?If not who can give me some idea?

No, LCDproc does not yet support EZIO now.
The issues that I had were not addressed in a followup patch.
IIRC the author went completely silent instead.

I think th patch was attached to the posting to the mailing list.
If you are interested in getting the support for EZIO into LCDproc,
you may update the patch so that it gets "include-able".

Regards
PEter

-- 
Peter Marschall
peter at adpm.de

From peter at adpm.de  Mon Sep 15 10:42:32 2008
From: peter at adpm.de (Peter Marschall)
Date: Mon, 15 Sep 2008 18:42:32 +0200
Subject: [Lcdproc] LCDProc on OS X 10.5
In-Reply-To: <42B18A8261FAE0428A17F9A6A539339E0DEB4FDFFF@EXCHCLST01.FRACTECH.LOCAL>
References: <42B18A8261FAE0428A17F9A6A539339E0DEB336218@EXCHCLST01.FRACTECH.LOCAL>
	<37EE90CD-9B97-4E4D-817C-3C0B455255EC@mail.fractech.net>
	<42B18A8261FAE0428A17F9A6A539339E0DEB4FDFFF@EXCHCLST01.FRACTECH.LOCAL>
Message-ID: <200809151842.32833.peter@adpm.de>

Hi,

On Thursday, 7. August 2008, Topher Fangio wrote:
> I believe the attached patch should work correctly. As much as I could
> test, it works on my OS X 10.5 machine and does nothing on my Debian box.
> If anyone could test the patch on previous versions of OS X, it would be
> very helpful.
>
> All you should have to do is download the latest source (0.5.2), download
> the patch into the clients/lcdproc/ directory, then run the following
> command:
>
> patch -p0 < leopard.patch
>
> Thanks and please let me know if there is anything else I can do!

Sorry for the late reply.

Patch is committed to CVS.

But I am curious: 
Is the DEPRECATED_IN_MAC_OS_X_VERSION_10_5_AND_LATER
an official one by Apple (distributed in the header files)
or did you create it for yourself ?

Regards
Peter

-- 
Peter Marschall
peter at adpm.de

From peter at adpm.de  Mon Sep 15 10:54:56 2008
From: peter at adpm.de (Peter Marschall)
Date: Mon, 15 Sep 2008 18:54:56 +0200
Subject: [Lcdproc] Heartbeat, Hello, Goodbye options
In-Reply-To: <C410E390CC5B29489B9D31F1D75393EE119A6458ED@evolution.NYNEXHOME.local>
References: <C410E390CC5B29489B9D31F1D75393EE119A6458ED@evolution.NYNEXHOME.local>
Message-ID: <200809151854.57272.peter@adpm.de>

Hi,

On Wednesday, 10. September 2008, Matthias Krepp wrote:

> Im trying to get lcdproc to run on my debian server.
> First of all I have used the 5.2 version, but as far as I figured out, I
> cant turn the "heartbeat" off. I saw on the earlier user-guides that this
> option can be used, so I tried the earlier versions as well (5.0).
>
> But the heartbeat option doesnt work there either, so Im confused right
> now, if I did something wrong or if its not possible. I have read a lot of
> comments about it, but none of them really gave me an answer to my
> question.
>
> I guess in version 4.x it works (I didnt get my tyan driver to work there
> yet), but I would like to use one of the latest versions. In user-guide 5.0
> the heartbeat option is shown, so it should work right ?
>
> Also the "Hello" and "GoodBye" options dont work. Its weird because the
> server is loading my LCDd.conf file without any errors and it works well
> with the other options, but not one of the options I mentioned.
>
> It would be nice if somebody could tell me in which version the mentioned
> options really work and which not.

"GoodBye" was part of the 0.5.2 release
"Hello" is part of the unreleased development version.

I tested a few minutes ago: both work on my system.

Plase grab one of the nightly snapshots to give the
development version a try.
(There's nothing to fear, it's mostly bug fixes and new drivers)

If it still does not work then please post more information about
your configuration to the list.

Regards
Peter

-- 
Peter Marschall
peter at adpm.de

From peter at adpm.de  Mon Sep 15 11:07:27 2008
From: peter at adpm.de (Peter Marschall)
Date: Mon, 15 Sep 2008 19:07:27 +0200
Subject: [Lcdproc] svga question
In-Reply-To: <49AE49CC-355A-4E71-A35D-D0E7A4DCFC6D@sbcglobal.net>
References: <49AE49CC-355A-4E71-A35D-D0E7A4DCFC6D@sbcglobal.net>
Message-ID: <200809151907.27355.peter@adpm.de>

Hi,

On Monday, 4. August 2008, Dustin Smous wrote:
> With the svga driver, is it possible to use a secondary vga controller??
>
> I have a small vga screen, and a spare vga card, and wanted to use it
> for LCDproc...

The svga driver uses svgalib from http://www.svgalib.org
Its features completely dpend on the features the library offers.

Maybe you can have a look there!
(Although I personally don't beleive it)

Regards
Peter


-- 
Peter Marschall
peter at adpm.de

From tfangio at fractech.net  Mon Sep 15 13:00:45 2008
From: tfangio at fractech.net (Topher Fangio)
Date: Mon, 15 Sep 2008 14:00:45 -0500
Subject: [Lcdproc] LCDProc on OS X 10.5
In-Reply-To: <200809151842.32833.peter@adpm.de>
References: <42B18A8261FAE0428A17F9A6A539339E0DEB336218@EXCHCLST01.FRACTECH.LOCAL>
	<37EE90CD-9B97-4E4D-817C-3C0B455255EC@mail.fractech.net>
	<42B18A8261FAE0428A17F9A6A539339E0DEB4FDFFF@EXCHCLST01.FRACTECH.LOCAL>
	<200809151842.32833.peter@adpm.de>
Message-ID: <42B18A8261FAE0428A17F9A6A539339E0F902CAD26@EXCHCLST01.FRACTECH.LOCAL>

I don't remember which file, but it is in the official headers. I will try to look
it up tonight when I get home. Also, I am very close to getting the ruby library
finished that I have been working on for a while, so I will probably send a message
with a link and a description of what it does so long as nobody has any objections.

Topher Fangio

-----Original Message-----
From: lcdproc-bounces at lists.omnipotent.net [mailto:lcdproc-bounces at lists.omnipotent.net] On Behalf Of Peter Marschall
Sent: Monday, September 15, 2008 11:43 AM
To: lcdproc at lists.omnipotent.net
Subject: Re: [Lcdproc] LCDProc on OS X 10.5

Hi,

On Thursday, 7. August 2008, Topher Fangio wrote:
> I believe the attached patch should work correctly. As much as I could
> test, it works on my OS X 10.5 machine and does nothing on my Debian box.
> If anyone could test the patch on previous versions of OS X, it would be
> very helpful.
>
> All you should have to do is download the latest source (0.5.2), download
> the patch into the clients/lcdproc/ directory, then run the following
> command:
>
> patch -p0 < leopard.patch
>
> Thanks and please let me know if there is anything else I can do!

Sorry for the late reply.

Patch is committed to CVS.

But I am curious:
Is the DEPRECATED_IN_MAC_OS_X_VERSION_10_5_AND_LATER
an official one by Apple (distributed in the header files)
or did you create it for yourself ?

Regards
Peter

--
Peter Marschall
peter at adpm.de
_______________________________________________
LCDproc mailing list
LCDproc at lists.omnipotent.net
http://lists.omnipotent.net/mailman/listinfo/lcdproc

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 ethan.dicks at gmail.com  Mon Sep 15 22:35:02 2008
From: ethan.dicks at gmail.com (Ethan Dicks)
Date: Tue, 16 Sep 2008 04:35:02 +0000
Subject: [Lcdproc] Strangeness with BIGNUMs on 2x20 display
Message-ID: <f4eb766f0809152135m79ab4de2sac4ac836864a2289@mail.gmail.com>

Hi, All,

Working with Nicu to get around some issues with a picoLCD 2x20, I've
run into a problem that looks to be in the BIGNUM library.

Based on the performance characteristics of my LCD, lib_adv_bignum()
has correctly identified it as having "6 or more" soft chars.  The
display I get for "6", for example, though, has a garbage character on
the top right.  Checking the pattern...

                {{3     ,5      ,7},/*6*/
                {3      ,4      ,2},
                {"   "},
                {"   "}},

There's a '7' in the top right spot.  That seems odd because further
down in the code, it _definitely_ sets chars 0-5...

                for (i = 0; i < 6 ; i++) { // put the customcharacters
into the display
                        drvthis->set_char(drvthis, offset+i, bignum[i]);
                }

I have not worked with 2-line displays much.  Can anyone provide any
historical perspective for this code issue?  Was this code originally
designed for a display with 8 soft chars and not completely dumbed
down?  Are there any displays with 6 or 7 but not 8 soft chars (or was
this an attempt to leave the heartbeat slot alone)?

I found this while tracking down a different problem - with this
driver, there seems to be a problem sending a character 0x00 in the
data stream.  Normally this isn't seen, but it is with BIGNUMs.  I
have been over picolcd.c, and there doesn't seem to be any obvious
place that the code is stopping early because of a null character in
the data stream, and likewise, I've been over the code in usblib
0.1.12 and not found anything exceedingly obvious, but the behavior
nonetheless points to *some* bit of code stopping at a null.

I'm not seeing the same behavior (i.e., BIGNUMs not working because of
the use of 0x00) with MtxOrb, 44780-usb4lcd, or my own
as-yet-unreleased jw002 driver.  In terms of transport-layer code,
MtxOrb and jw002 are serial, and 44780-usb4lcd is USB, but that one
uses a completely different method of talking to the display than
picoLCD, so that should help narrow down the search.

Is anyone else fiddling with BIGNUMs?  This is far from the first
message I've posted recently on the topic, and I've gotten very little
response previously.

-ethan

From peter at adpm.de  Tue Sep 16 08:47:22 2008
From: peter at adpm.de (Peter Marschall)
Date: Tue, 16 Sep 2008 16:47:22 +0200
Subject: [Lcdproc] Strangeness with BIGNUMs on 2x20 display
In-Reply-To: <f4eb766f0809152135m79ab4de2sac4ac836864a2289@mail.gmail.com>
References: <f4eb766f0809152135m79ab4de2sac4ac836864a2289@mail.gmail.com>
Message-ID: <200809161647.22879.peter@adpm.de>

Hi Ethan,

On Tuesday, 16. September 2008, Ethan Dicks wrote:
> Working with Nicu to get around some issues with a picoLCD 2x20, I've
> run into a problem that looks to be in the BIGNUM library.
>
> Based on the performance characteristics of my LCD, lib_adv_bignum()
> has correctly identified it as having "6 or more" soft chars.  The
> display I get for "6", for example, though, has a garbage character on
> the top right.  Checking the pattern...
>
>                 {{3     ,5      ,7},/*6*/
>                 {3      ,4      ,2},
>                 {"   "},
>                 {"   "}},

Right, the 7 is definitely wrong.
When we have only 6 custom characters counted 0 - 5,
then 7 is off by two.

The code for this function was provided as a whole
(including the error).

Looking at the defined shapes, and the definition
of the 5 remainig characters, I changed the 7 to a
space (' '). This makes the horizontal line on the
top of 6 similar to the one for 5.

Fix is already committed to CVS.

Thanks for reporting the issue.

> I found this while tracking down a different problem - with this
> driver, there seems to be a problem sending a character 0x00 in the
> data stream.  Normally this isn't seen, but it is with BIGNUMs.  I
> have been over picolcd.c, and there doesn't seem to be any obvious
> place that the code is stopping early because of a null character in
> the data stream, and likewise, I've been over the code in usblib
> 0.1.12 and not found anything exceedingly obvious, but the behavior
> nonetheless points to *some* bit of code stopping at a null.
>
> I'm not seeing the same behavior (i.e., BIGNUMs not working because of
> the use of 0x00) with MtxOrb, 44780-usb4lcd, or my own
> as-yet-unreleased jw002 driver.  In terms of transport-layer code,
> MtxOrb and jw002 are serial, and 44780-usb4lcd is USB, but that one
> uses a completely different method of talking to the display than
> picoLCD, so that should help narrow down the search.
>
> Is anyone else fiddling with BIGNUMs?  This is far from the first
> message I've posted recently on the topic, and I've gotten very little
> response previously.

Sorry for not answering earlier.
RL has kept me busy.

Regards
Peter

-- 
Peter Marschall
peter at adpm.de

From peter at adpm.de  Tue Sep 16 09:58:48 2008
From: peter at adpm.de (Peter Marschall)
Date: Tue, 16 Sep 2008 17:58:48 +0200
Subject: [Lcdproc] PATCH: Memory leak in PicoLCD driver
In-Reply-To: <48BBB6DA.6010100@jackpot.uk.net>
References: <48BBB6DA.6010100@jackpot.uk.net>
Message-ID: <200809161758.48741.peter@adpm.de>

Hi Jack,

On Monday, 1. September 2008, Jack Cleaver wrote:
> I'm offering the attached patch for the picoLCD driver.
>
> I'm no great shakes as a C/Linux coder, not having worked in C for over
> 15 years. I'd therefore appreciate if someone could verify by inspection
> that what appears to be an obvious leak really is a leak, and that this
> patch fixes it (without breaking something else).
>
> JackC.
>
> jackc at virya:~/Projects/lcdproc-0.5.2/server/drivers$ diff picolcd.c-orig
> picolcd.c
> 303a304
>
>  >       char * retval = NULL;
>
> 329a331,333
>
>  >                       if (strlen(keystr))
>  >                               retval = keystr;
>
> 333d336
> <                       return NULL;
> 342,345c345
> <       if (! strlen(keystr))
> <               return NULL;
> <
> <       return keystr;
> ---
>
>  >       return retval;
>

Maybe I am a bit dim today, but I fail to see the issue in the original
version, while I see problems in your version.

Original says:
	if length of variable keystr is 0,
		then return the NULL pointer to the caller
		to indicate no key was pressed.
	otherwise return the contents of the variable keystr 
	to the caller to indicate that a key was pressed and which one.

The patch replaces this with:
	Create a new variable retval and preset it with the NULL pointer.
	If length of variable keystr differs from 0,
		then assign the conntents of the variable keystr to
		the variable retval;
	return the NULL pointer to the caller

retval is only used on initialization, and on assignment from keystr.
It is not returned either.
What is it good for ?

With your solution the function returns NULL all the time indicating that no 
key was pressed. I guess this is not what you intended.


But you are right, there is a memory leak, and even worse
writing to unallocated memory  in this function.

The solution of returning two keys combined with '+'
is at least strange, because this behaviour is not
defined in LCDd.
A solution that queues keys and sends them back one by one
is IMHO more appropriate.

Regards
Peter

-- 
Peter Marschall
peter at adpm.de

From ethan.dicks at gmail.com  Tue Sep 16 13:17:41 2008
From: ethan.dicks at gmail.com (Ethan Dicks)
Date: Tue, 16 Sep 2008 19:17:41 +0000
Subject: [Lcdproc] Strangeness with BIGNUMs on 2x20 display
In-Reply-To: <200809161647.22879.peter@adpm.de>
References: <f4eb766f0809152135m79ab4de2sac4ac836864a2289@mail.gmail.com>
	<200809161647.22879.peter@adpm.de>
Message-ID: <f4eb766f0809161217ucbbda52hcf8a407bc83f192e@mail.gmail.com>

On 9/16/08, Peter Marschall <peter at adpm.de> wrote:
> Hi Ethan,
.
.
.
> Right, the 7 is definitely wrong.
>  When we have only 6 custom characters counted 0 - 5,
>  then 7 is off by two.

Exactly.

>  The code for this function was provided as a whole
>  (including the error).
>
>  Looking at the defined shapes, and the definition
>  of the 5 remainig characters, I changed the 7 to a
>  space (' '). This makes the horizontal line on the
>  top of 6 similar to the one for 5.

That was how I fixed it locally.  It seemed to look right.

>  Fix is already committed to CVS.

Perfect.  Saves me sending in a patch.

>  Thanks for reporting the issue.

You bet.

-ethan

From peter at adpm.de  Wed Sep 17 00:34:14 2008
From: peter at adpm.de (Peter Marschall)
Date: Wed, 17 Sep 2008 08:34:14 +0200
Subject: [Lcdproc] Bug with numeric priorities
In-Reply-To: <votzcma8yt.fsf@gedanken.demon.co.uk>
References: <votzcma8yt.fsf@gedanken.demon.co.uk>
Message-ID: <200809170834.14914.peter@adpm.de>

Hi,

On Sunday, 7. September 2008, Andrew M. Bishop wrote:
> [Resent after subscribing to the lcdproc list, an older duplicate
>  message is still waiting for moderator approval]
>
> I have been using LCDproc for a while on Debian (version 0.4.5) and
> have just tried updating to version 0.5.2. What I have found during
> this changeover is a bug in LCDd that means that the numeric
> priorities have never worked since the named priorities were added.
>
> If a numeric priority of 128 is used (for example) then only one
> screen will display, they don't rotate like they should (since 128 is
> the same as 'info').
>
> [...]
> 
> The change is simple though; on lines 206, 208, 210 's->priority'
> should be replaced by 'number'.
>
> The bug can be verified with unmodified code by using priority 2 which
> maps to PRI_INFO and the screens rotate.  Using priority 128 which
> should map to PRI_INFO and only one screen is shown, they don't
> rotate.

you're right.

Your proposed fix has been committed to CVS.

Thanks for reporting the issue
Peter

-- 
Peter Marschall
peter at adpm.de

From peter at adpm.de  Wed Sep 17 00:41:55 2008
From: peter at adpm.de (Peter Marschall)
Date: Wed, 17 Sep 2008 08:41:55 +0200
Subject: [Lcdproc] PATCH: Memory leak in PicoLCD driver
In-Reply-To: <48CFFA5C.1080705@jackpot.uk.net>
References: <48BBB6DA.6010100@jackpot.uk.net>
	<200809161758.48741.peter@adpm.de>
	<48CFFA5C.1080705@jackpot.uk.net>
Message-ID: <200809170841.55577.peter@adpm.de>

Hi,

please keep replies to the list.

On Tuesday, 16. September 2008, you wrote:
> Peter Marschall wrote:
> > On Monday, 1. September 2008, Jack Cleaver wrote:
> >> I'm offering the attached patch for the picoLCD driver.
> >>
> >> [ ... ]
> >
> > retval is only used on initialization, and on assignment from keystr.
> >  It is not returned either. What is it good for ?
>
> As I said, my C is rusty, so perhaps I have misunderstood you. However
> it seems clear to me that retval is indeed returned, at the last
> statement in the function. It returns a pointer to the value from the
> key_matrix that had been assigned to keystr.
>
> > With your solution the function returns NULL all the time indicating
> > that no key was pressed. I guess this is not what you intended.
>
> If I insert a debug line immediately before the return statement
> (conditional on retval not being NULL), then press the Up button, it
> shows that "Up" is being returned.
>

Oops, I overlook the final "return retval" line in your original patch.
(The classical diff output format is really hard to read)

but even then, I think it only adds a variable that is used for the same 
purpose as keystr.

That's why I prefer to leave this patch out.

O.K.?

> My true concern, however, has been to add to the driver the ability to
> decode IR events and pass them to LIRC, because this device uses a
> single USB channel for the keypad and the IR sensor. As a consequence,
> it seems that only one piece of code can "own" the device at one time.
> It follows that if picolcd.so is loaded, then either it sends IR codes
> to LIRC, or the sensor is effectively disabled.
>
> I have written the IR sensor code, and I am using it successfully; but I
> wanted to get this memory leak out of the way as a separate patch,
> before submitting the IR sensor patch. The keystroke-queueing problem
> isn't within the scope of the itch I am scratching.

I will respond to your patch in a separate mail.

Regards
Peter


-- 
Peter Marschall
peter at adpm.de

From peter at adpm.de  Wed Sep 17 01:18:29 2008
From: peter at adpm.de (Peter Marschall)
Date: Wed, 17 Sep 2008 09:18:29 +0200
Subject: [Lcdproc] PATCH: Enable picolcd to pass IR codes to LIRC via UDP
In-Reply-To: <48C3EE52.1090204@jackpot.uk.net>
References: <48C3EE52.1090204@jackpot.uk.net>
Message-ID: <200809170918.30169.peter@adpm.de>

Hi Jack,

On Sunday, 7. September 2008, Jack Cleaver wrote:
> I have coded a patch (attached) that enables picolcd to send IR codes to
> LIRC.
>
> PicoLCD IR packets don't include a sync pulse, and they don't include a
> gap trailer; these have to be synthesized, and that requires divination
> (guessing) of where a code begins and ends, and I presume my guesswork
> is fallible.
>
> The synthesized gap seems to be interfering with detection of repeat
> codes, at least with some of my remotes; and that in turn seems to be
> interfering with the correct operation of irrecord. So I'm not sure that
> this patch is ready for prime-time, but I don't know how to go forward.
> I'd welcome comments, if anyone cares to inspect my code (Nicu? Woody?).
>
> Anyway, this is the only way I know to get picolcd remote codes into
> LIRC. And given a lircd.conf that matches your remote, it seems to be
> reliable (so far).

I really appreciate your patch, and I'd happily include it into LCDproc.

But I'd rather have two changes before I commit it to the CVS:

* Documentation
  http://lcdproc.sourceforge.net/docs/current-dev.html#documentation
  states what LCDproc expects in the case of new drivers.
  Please extend your patch to at least update the files
  picold.docbook and LCDd.conf with the new options.

  It would be great if you also give the docbook page a short overhaul
  to correct omissions and errors that are evident to a picolcd owner.

- option to switch it off
  While your patch is surely a big improvement for users that
  use LCDproc togethr with lirc, I'd like to have this extension optional.
  Can you change your patch so that in the absence of one or both
  "Lirc..." options it does not try to connect to lirc and does
  not send the keys to lirc ?

And while I am nit-picking: the static variables you defined should go into 
the PrivateData structure.

Please don't let you discourage by my remarks.
The aptch is a good addition to LCDproc. It only needs a bit polishing.

Regards
Peter





-- 
Peter Marschall
peter at adpm.de

From peter at adpm.de  Wed Sep 17 01:19:45 2008
From: peter at adpm.de (Peter Marschall)
Date: Wed, 17 Sep 2008 09:19:45 +0200
Subject: [Lcdproc] PicoLCD driver for LCDProc
In-Reply-To: <48BDC7E1.8020408@gmx.de>
References: <48BD1441.2010106@jackpot.uk.net> <48BDC7E1.8020408@gmx.de>
Message-ID: <200809170919.45565.peter@adpm.de>

Hi Stefan,

On Wednesday, 3. September 2008, Stefan Herdler wrote:
> There is one patch from me still pending too.

Hmm, I don't find it in my inbox, maybe I accidentially deletd it.
Would you mind to re-post it ?

Thanks in advance
PEter

-- 
Peter Marschall
peter at adpm.de

From jack at jackpot.uk.net  Wed Sep 17 02:08:22 2008
From: jack at jackpot.uk.net (Jack Cleaver)
Date: Wed, 17 Sep 2008 09:08:22 +0100
Subject: [Lcdproc] PATCH: Memory leak in PicoLCD driver
In-Reply-To: <200809170841.55577.peter@adpm.de>
References: <48BBB6DA.6010100@jackpot.uk.net>
	<200809161758.48741.peter@adpm.de>
	<48CFFA5C.1080705@jackpot.uk.net>
	<200809170841.55577.peter@adpm.de>
Message-ID: <48D0BAF6.9010508@jackpot.uk.net>

Peter Marschall wrote:
> Hi,
> 
> please keep replies to the list.
> 
> On Tuesday, 16. September 2008, you wrote:
>> Peter Marschall wrote:
>>> On Monday, 1. September 2008, Jack Cleaver wrote:
>>>> I'm offering the attached patch for the picoLCD driver.
>>>> 
>>>> [ ... ]
>>> retval is only used on initialization, and on assignment from
>>> keystr. It is not returned either. What is it good for ?
>> As I said, my C is rusty, so perhaps I have misunderstood you.
>> However it seems clear to me that retval is indeed returned, at the
>> last statement in the function. It returns a pointer to the value
>> from the key_matrix that had been assigned to keystr.
>> 
>>> With your solution the function returns NULL all the time
>>> indicating that no key was pressed. I guess this is not what you
>>> intended.
>> If I insert a debug line immediately before the return statement 
>> (conditional on retval not being NULL), then press the Up button,
>> it shows that "Up" is being returned.
>> 
> 
> Oops, I overlook the final "return retval" line in your original
> patch. (The classical diff output format is really hard to read)
> 
> but even then, I think it only adds a variable that is used for the
> same purpose as keystr.
> 
> That's why I prefer to leave this patch out.
> 
> O.K.?

I wonder if perhaps I have generated the diff against the wrong version
of the source; or perhaps in some other respect, my inexperience has
resulted in you seeing different code from me?

I think I'll try again to make this change against a new version of the
source, and produce a new diff using the approved flags.

-- 
Jack.

From jack at jackpot.uk.net  Wed Sep 17 02:15:16 2008
From: jack at jackpot.uk.net (Jack Cleaver)
Date: Wed, 17 Sep 2008 09:15:16 +0100
Subject: [Lcdproc] PATCH: Enable picolcd to pass IR codes to LIRC via UDP
In-Reply-To: <200809170918.30169.peter@adpm.de>
References: <48C3EE52.1090204@jackpot.uk.net>
	<200809170918.30169.peter@adpm.de>
Message-ID: <48D0BC94.90503@jackpot.uk.net>

Peter Marschall wrote:
> Hi Jack,
> 
> On Sunday, 7. September 2008, Jack Cleaver wrote:
>> I have coded a patch (attached) that enables picolcd to send IR
>> codes to LIRC.
>> 
>> PicoLCD IR packets don't include a sync pulse, and they don't
>> include a gap trailer; these have to be synthesized, and that
>> requires divination (guessing) of where a code begins and ends, and
>> I presume my guesswork is fallible.
>> 
>> The synthesized gap seems to be interfering with detection of
>> repeat codes, at least with some of my remotes; and that in turn
>> seems to be interfering with the correct operation of irrecord. So
>> I'm not sure that this patch is ready for prime-time, but I don't
>> know how to go forward. I'd welcome comments, if anyone cares to
>> inspect my code (Nicu? Woody?).
>> 
>> Anyway, this is the only way I know to get picolcd remote codes
>> into LIRC. And given a lircd.conf that matches your remote, it
>> seems to be reliable (so far).
> 
> I really appreciate your patch, and I'd happily include it into
> LCDproc.
> 
> But I'd rather have two changes before I commit it to the CVS:
> 
> * Documentation 
> http://lcdproc.sourceforge.net/docs/current-dev.html#documentation 
> states what LCDproc expects in the case of new drivers. Please extend
> your patch to at least update the files picold.docbook and LCDd.conf
> with the new options.

Will do.
> 
> It would be great if you also give the docbook page a short overhaul 
> to correct omissions and errors that are evident to a picolcd owner.

Yes.
> 
> - option to switch it off While your patch is surely a big
> improvement for users that use LCDproc togethr with lirc, I'd like to
> have this extension optional. Can you change your patch so that in
> the absence of one or both "Lirc..." options it does not try to
> connect to lirc and does not send the keys to lirc ?

You are right to want it made optional, and it shall be done as you request.
> 
> And while I am nit-picking: the static variables you defined should
> go into the PrivateData structure.

OK. Thanks for your comments; I'll be back shortly.
> 
> Please don't let you discourage by my remarks. The aptch is a good
> addition to LCDproc. It only needs a bit polishing.
> 
Not discouraged,
-- 
Jack.

From peter at adpm.de  Wed Sep 17 02:57:59 2008
From: peter at adpm.de (Peter Marschall)
Date: Wed, 17 Sep 2008 10:57:59 +0200
Subject: [Lcdproc] hd44780-lcm162.c / hd44780-lcm162.h
In-Reply-To: <8db3d6360809100234p73df9cbfpbc03bc02a78b3c0a@mail.gmail.com>
References: <8db3d6360809100234p73df9cbfpbc03bc02a78b3c0a@mail.gmail.com>
Message-ID: <200809171057.59695.peter@adpm.de>

Hi,

On Wednesday, 10. September 2008, Guy Widloecher wrote:
> I'm looking for the files hd44780-lcm162.c / hd44780-lcm162.h (module for
> LCM-162 / hd44780).
>
> These files were made by Clemens Zauner and he wrote about them in a post
> on Thu Jun 14 14:30:03 2007
> http://lists.omnipotent.net/pipermail/lcdproc/2007-June/011816.html

IIRC these files were only mentiond in the mail back then,
but they have not been sent to the mailing list.

Regards
Peter

-- 
Peter Marschall
peter at adpm.de

From jack at jackpot.uk.net  Wed Sep 17 06:07:16 2008
From: jack at jackpot.uk.net (Jack Cleaver)
Date: Wed, 17 Sep 2008 13:07:16 +0100
Subject: [Lcdproc] [Fwd: Re:  PATCH: Memory leak in PicoLCD driver]
Message-ID: <48D0F2F4.3010408@jackpot.uk.net>

Aieee! I originally sent this just to Peter by mistake; it should have
gone to the list, of course.

Peter Marschall wrote:
> Hi,
> 
> please keep replies to the list.
> 
> On Tuesday, 16. September 2008, you wrote:
>> Peter Marschall wrote:
>>> On Monday, 1. September 2008, Jack Cleaver wrote:
>>>> I'm offering the attached patch for the picoLCD driver.
>>>> 
>>>> [ ... ]
>>> retval is only used on initialization, and on assignment from 
>>> keystr. It is not returned either. What is it good for ?
>> As I said, my C is rusty, so perhaps I have misunderstood you. 
>> However it seems clear to me that retval is indeed returned, at the
>>  last statement in the function. It returns a pointer to the value
>>  from the key_matrix that had been assigned to keystr.
>> 
>>> With your solution the function returns NULL all the time 
>>> indicating that no key was pressed. I guess this is not what you
>>>  intended.
>> If I insert a debug line immediately before the return statement 
>> (conditional on retval not being NULL), then press the Up button, 
>> it shows that "Up" is being returned.
>> 
> 
> Oops, I overlook the final "return retval" line in your original 
> patch. (The classical diff output format is really hard to read)
> 
> but even then, I think it only adds a variable that is used for the 
> same purpose as keystr.
> 
> That's why I prefer to leave this patch out.
> 
> O.K.?

After looking more closely I now understand your objection, and I hope
this patch is better. There is no new variable this time, and the fix
for the leak is simpler and cleaner. I made the diff against a fresh
copy of the 0.5.2 code taken from sourceforge.

-- 
Jack.


-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: picolcd.c.diff
URL: <http://lists.omnipotent.net/pipermail/lcdproc/attachments/20080917/323019a5/attachment.txt>

From peter at adpm.de  Wed Sep 17 08:12:22 2008
From: peter at adpm.de (Peter Marschall)
Date: Wed, 17 Sep 2008 16:12:22 +0200
Subject: [Lcdproc] ethlcd
In-Reply-To: <48AC661D.2060301@skyboo.net>
References: <48AC661D.2060301@skyboo.net>
Message-ID: <200809171612.22518.peter@adpm.de>

Hi Manio,

On Wednesday, 20. August 2008, manio wrote:
> First of all i need to write something about ethlcd. ethlcd is open
> source/harware a project which grow in my mind some time ago and now it
> is ready and blinking on my desk :)
> The HD44780 display is controlled via Atmel's ATmega microcontroller.
> There is also a ethernet chip (ENC28J60). So from lcdproc point of view
> a LCD is accessible via TCP socket. The device is powered via PoE, so to
> LCD display is only needed a UTP cable :)
> It has also a 6 buttons, backlight control and a beeper.
> Photos, schematics, pcb and more are on project homepage:
> http://manio.skyboo.net/ethlcd/
>
> Of course i wrote a driver - i was trying to preserve the rules in
> developer's documentation but now i realized, that one thing is shurely
> need to do - i have 3 global variables, which should be moved into
> driver's space. I've attached the diff against current CVS revision as a
> attachment to this message. Please look at it - i am open to any
> comments, especially from developers - i'll try to fix the code in the
> way you like. And after that i'll be very happy if there will be a
> possibility to merge it in CVS current tree :)
> Because of the hardware the driver is just another connection type of
> HD44780 - so it is written like for instance hd44780-ftdi and so - but
> it is called of course hd44780-ethlcd. Unfortunatelly - there is one
> thing to note: on my stable debian box it is unable to test the automake
> and autoconf when fetched from CVS. The debian's version differs from
> recomended - and i think this is the problem. The only SVN versions,
> which are compiling are nightly snapshots (with automake and autoconf
> done automagicaly) - so for now it is hard to test that aspect (automake
> and autoconf) of my diff file. Please also tell me how should be done
> the enabling of driver compilation - for now i've added the "if
> $enabled-ethlcd" but this test is performed in configure script - need
> it to be? - maybe just compile it like other hd44780 drivers - like
> 4bit, winamp or 8bit?

sorry for the late answer.

I have committed your driver to CVS with a few changes:
- "Device" as the key for the address in LCDd.conf.
  If possible, I'd like to keep as little different
  keys as possible.
  Having a sperate key for the "device" of each connection type
  doesn't help much I tink
- converted global variables in hd44780-ethlcd.c to members of
  the ProvateData struct or removed them altogether.
- added the infrastructure for --disable-ethlcd 
  I was pondering making something like this for all of the
  hd44780 connection types. So, I started with this one.
  By default the connection type is included in hd44780, 
  but it can be left out at compile time.

The result compiles fine. Lacking the hardware I cannot test it.
Please test and report feedback.

A few suggestions for improvement.
- please have a look how server/drivers/hd44780-lcd2usb.c handles
  brightnes and backlight.
  This is the way it is done in various other drivers.
  It offers more flexibility than completely turning off the
  backlight (which sometimes makes displays unreadable)
- If you extend the documentation a bit, it does not hurt.
  I added the short chapters for most non-parallel-port connections
  in hd44780.docbook to have the other connection types at
  least described a bit.
  Having a real desciption that is come kind of counterpart
  to the parallel-port connection types.

Thanks for supporting LCDproc
Peter

-- 
Peter Marschall
peter at adpm.de

From peter at adpm.de  Wed Sep 17 09:55:00 2008
From: peter at adpm.de (Peter Marschall)
Date: Wed, 17 Sep 2008 17:55:00 +0200
Subject: [Lcdproc] [Fwd: Re:  PATCH: Memory leak in PicoLCD driver]
In-Reply-To: <48D0F2F4.3010408@jackpot.uk.net>
References: <48D0F2F4.3010408@jackpot.uk.net>
Message-ID: <200809171755.01139.peter@adpm.de>

Hi,

> After looking more closely I now understand your objection, and I hope
> this patch is better. There is no new variable this time, and the fix
> for the leak is simpler and cleaner. I made the diff against a fresh
> copy of the 0.5.2 code taken from sourceforge.

Looking at the patch I think I see where the problem is.
You diff'ed against 0.5.2 while I was always looking at 
the current CVS as visible in the nightly tar balls
available at http://lcdproc.sourceforge.net/nightly/.

CVS already contains parts of your patch and closed the
leak using a different approach.
Looking through your mail I committed a safer check for
the length of keystr and committed it to CVS.

It will be in tonight's tar ball.

Regards
Peter 

-- 
Peter Marschall
peter at adpm.de

From peter at adpm.de  Wed Sep 17 11:19:41 2008
From: peter at adpm.de (Peter Marschall)
Date: Wed, 17 Sep 2008 19:19:41 +0200
Subject: [Lcdproc] OSX + MtxOrb Driver
In-Reply-To: <2E0CCCF4-FB07-4927-8F5E-FD9D550B389A@gmail.com>
References: <AA2A95BB-7983-448D-8249-5B54BF044680@gmail.com>
	<f4eb766f0809031848l55150281p62cff779977cb49e@mail.gmail.com>
	<2E0CCCF4-FB07-4927-8F5E-FD9D550B389A@gmail.com>
Message-ID: <200809171919.42066.peter@adpm.de>

Hi Kevin,

On Thursday, 4. September 2008, Kevin Ogden wrote:
> AWESOME!  OK, it's working now, I've attached a diff with all the
> mangling of MtxOrb.c I've done along with my LCDd.conf.
>
> It's now working flawlessly under OSX with my old Matrix Orbital
> LK202-25 display with no extra 'V' characters or anything.  Looking
> at the manual, it said the backlight command was 254 66 0, which in
> hex is FE 42 0.  Along with the GPO patch and a slight addition
> relating to DCD using '/dev/tty.serial1' on my generic P4 running OSX
> it's working fine.

I'd rather not apply the patch you virtually attached to this mail
in its current form.

I consider the patch a mix that tries to tackle multiple issues at once:
- backlight command
- new option GPOs
- ONDELAY

Let's start with the backlight command:
Although the command in LCDproc is called MtxOrb_backlight,
it does not switch the backlight on & off, but simulates this
only by changing the brightness of the display: When set 
to on, the value of the config setting "Brightness" is used,
while when set to off, "OffBrightness" is used.
This allows more flexibility, and makes newer revisions of
LK202-25 (and others) displays work where the x42 command 
is called "display off" (and does that).
Unfortunately this command is not documented (maby not even
implemented) in some older revisions of LK202-25.
What exact revision do you own ?
What are the symptoms you experience when you change
the value back to its original value ?

Do I need to tell that I hate the various different revisions
of manuals for each of the zillions of MatrixOrbital display
types. If thy only had a consistent notation for the commands:
sometimes hex, sometimes decimal, sometimes ASCII, ...
I literally spent weeks finding the compromise that is currently in LCDproc.
(Not even MatroxOrbital was able to provide me with a concise
set of commands available in what revison of what display type)


Now to the GPOs option:
If possible, I'd like to avoid creating new options that
may break the behaviour of  existing implementations.
Is it really necessary ?
Can't int be inferred from the display type?

If it is necessary, can you define it in a way that keeps 
the default values to those hat are currently used as the
values for the different display types (for compatibility's sake) ?

And can you pleas add the necessary documentation to 
docs/lcdproc-user/drivers/mtxorb.docbook
so that other users can profit from your work ?

> I think you said that O_NDELAY flag to the open call may not be
> necessary if you use /dev/cu.serial1 though.  I really don't want to
> mess with it at the moment now that it's working though.

Would you mind testing this ?

I'd rather not apply the patch blindly because it helps you
but may hurt other users with different operating systems.
Especially as Ethan wrote that it works for /dev/cu.serial1
without the patch.

So,with respect to the GPOs I am open fr a patch that keeps
compatibility and contains documentation,
with respect to O_NDELAY I am very dubious,
and with respect to the backlights, I need more information.

Regards
PEter


-- 
Peter Marschall
peter at adpm.de

From jack at jackpot.uk.net  Wed Sep 17 12:07:03 2008
From: jack at jackpot.uk.net (Jack Cleaver)
Date: Wed, 17 Sep 2008 19:07:03 +0100
Subject: [Lcdproc] PATCH: Enable picolcd to pass IR codes to LIRC via UDP
	(redone)
Message-ID: <48D14747.4030603@jackpot.uk.net>

OK, I've redone my patch to enable picolcd to send IR codes to LIRC.

- The revised patch was made against this base:
http://lcdproc.sourceforge.net/nightly/lcdproc-CVS-current.tar.gz
- IR functionality can be enabled in the config, default is off.
- Sync and gap lengths are now configurable.
- Added sample stanzas to LCDd.conf.
- Updated the docbook to describe the new config options, and to reflect
   my reservations about the sync and gap.
- I've inspected the existing docbook notes for picolcd, and I'm not
   aware of any deficiencies in them.

Thank you for being patient with this noob, and I'm sorry for wasting
your time by making patches against the wrong base. If I've done it
right this time, then that means I've learned, and hopefully will cause
less hassle to people next time I try my hand at contributing.

-- 
Jack.
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: LCDd.conf.diff
URL: <http://lists.omnipotent.net/pipermail/lcdproc/attachments/20080917/53024a9b/attachment-0004.txt>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: picolcd.c.diff
URL: <http://lists.omnipotent.net/pipermail/lcdproc/attachments/20080917/53024a9b/attachment-0005.txt>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: picolcd.h.diff
URL: <http://lists.omnipotent.net/pipermail/lcdproc/attachments/20080917/53024a9b/attachment-0006.txt>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: picolcd.docbook.diff
URL: <http://lists.omnipotent.net/pipermail/lcdproc/attachments/20080917/53024a9b/attachment-0007.txt>

From kdogden at gmail.com  Wed Sep 17 12:21:14 2008
From: kdogden at gmail.com (Kevin Ogden)
Date: Wed, 17 Sep 2008 14:21:14 -0400
Subject: [Lcdproc] OSX + MtxOrb Driver
In-Reply-To: <200809171919.42066.peter@adpm.de>
References: <AA2A95BB-7983-448D-8249-5B54BF044680@gmail.com>
	<f4eb766f0809031848l55150281p62cff779977cb49e@mail.gmail.com>
	<2E0CCCF4-FB07-4927-8F5E-FD9D550B389A@gmail.com>
	<200809171919.42066.peter@adpm.de>
Message-ID: <79AECF96-30D2-41DE-AB2A-7033894D2A3D@gmail.com>


>
> I'd rather not apply the patch you virtually attached to this mail
> in its current form.

I wouldn't either, it's disgusting.  I was just trying to show what I  
ended up changing to get it to work on my odd machine with my poorly  
documented LCD hardware.  I'm a far from elegant C coder.  I do more  
in LISP and TCL than anything else.  I wasn't really trying to submit  
an "official" patch ;-)

> I consider the patch a mix that tries to tackle multiple issues at  
> once:
> - backlight command
> - new option GPOs
> - ONDELAY
>
> Let's start with the backlight command:
> Although the command in LCDproc is called MtxOrb_backlight,
> it does not switch the backlight on & off, but simulates this
> only by changing the brightness of the display: When set
> to on, the value of the config setting "Brightness" is used,
> while when set to off, "OffBrightness" is used.
> This allows more flexibility, and makes newer revisions of
> LK202-25 (and others) displays work where the x42 command
> is called "display off" (and does that).
> Unfortunately this command is not documented (maby not even
> implemented) in some older revisions of LK202-25.

It seems that this product line received several nearly-compatible  
revisions.  Changing the MtxOrb_backlight command to x42 seemed to  
work for me though.

> What exact revision do you own ?

It's pretty damn old.  I think I bought it in 2001 or 2002.  Not sure  
of the rev number but I could probably find out for you tonight.

> What are the symptoms you experience when you change
> the value back to its original value ?

A "V" replacing the character at the beginning and end of most  
screens and occasionally a couple scattered throughout the display.   
Sometimes the "V" was followed by an underscore or vertical line  
character.  If I just sent some text to the display via screen  
(screen /dev/tty.serial1 19200) there was no garbage characters.

> Do I need to tell that I hate the various different revisions
> of manuals for each of the zillions of MatrixOrbital display
> types. If thy only had a consistent notation for the commands:
> sometimes hex, sometimes decimal, sometimes ASCII, ...
> I literally spent weeks finding the compromise that is currently in  
> LCDproc.
> (Not even MatroxOrbital was able to provide me with a concise
> set of commands available in what revison of what display type)

I feel your pain.  I was getting really frustrated with this myself.   
I was getting ready to just say screw it and write a simple uptime/ 
cpu graph toy in TCL and just throw in a couple of LCD commands I  
really needed (for clearing the screen, contrast, etc.).

It's a real pretty little red display with GPOs and keypad input BUT  
was really expensive and poorly documented.

> If it is necessary, can you define it in a way that keeps
> the default values to those hat are currently used as the
> values for the different display types (for compatibility's sake) ?
>
> And can you pleas add the necessary documentation to
> docs/lcdproc-user/drivers/mtxorb.docbook
> so that other users can profit from your work ?

The GPO patch was someone else's work that was dug up on the  
archives.  Ethan pointed it out to me and it didn't quite solve the  
problem I was having but I left it in because to me it seemed to make  
sense.  Anything that gives me options I can tweak without  
recompiling is a good thing IMHO.

>> I think you said that O_NDELAY flag to the open call may not be
>> necessary if you use /dev/cu.serial1 though.  I really don't want to
>> mess with it at the moment now that it's working though.
>
> Would you mind testing this ?

I can probably test it sometime tonight or tomorrow.

> I'd rather not apply the patch blindly because it helps you
> but may hurt other users with different operating systems.
> Especially as Ethan wrote that it works for /dev/cu.serial1
> without the patch.

I can test it.  Hopefully it works fine without that change and I  
suspect it will.  I was just trying everything I could to make this  
go and this probably wasn't necessary but that's where I started when  
trying to get this display going.  I didn't know the cu.serial1  
device even existed until I went looking for it after it was  
mentioned.  It kinda makes sense, under FreeBSD, my serial port is / 
dev/cuad0.

> So,with respect to the GPOs I am open fr a patch that keeps
> compatibility and contains documentation,
> with respect to O_NDELAY I am very dubious,
> and with respect to the backlights, I need more information.

I don't think O_NDELAY is quite necessary but the backlight command  
hack DID solve my problem with this display under both FreeBSD and  
MacOS X.

Thanks,
Kevin D. Ogden

From tfangio at fractech.net  Wed Sep 17 23:45:47 2008
From: tfangio at fractech.net (Topher Fangio)
Date: Thu, 18 Sep 2008 00:45:47 -0500
Subject: [Lcdproc] Ruby LCDProc Library and weird display bug
Message-ID: <42B18A8261FAE0428A17F9A6A539339E0F9044F7BD@EXCHCLST01.FRACTECH.LOCAL>

Hello all,

I have just released version 0.1.0 of the library that I have been working on for some time
and I would really love to get some feedback from the community. The design goals are to
make it very easy for developers to create programs written in Ruby that operate any LCD
connected to LCDd in an object-oriented way, and for me to learn more about Ruby.

It can be downloaded from https://sourceforge.net/projects/lcdproc-ruby/

To use the library, first install Ruby (if you don't already have it), download the latest zip
file from the site above and extract it. Then, open a console and cd to the extraction
directory and you can begin playing around.

The most useful things are the examples, tests, and scripts.

To run an example, type "ruby examples/clock.rb" or any other program in the examples
directory (2 as of right now).

To run a test, simply type "rake -T" to see a list of the tests and "rake test:basic" to
execute it.

You can also use the scripts which provide some great utilities to LCDProc.

scripts/telnet.rb allows you to connect to a LCDd server and type commands. It's fairly
simplistic in that you can't backspace or use the arrow keys, so be careful of what you
type, but it does the trick.

scripts/console.rb is an interactive ruby console with all of the LCDProc-Ruby libraries
loaded. It is more useful than telnet.rb in that it uses irb as the underlying base, so it
supports backspace, previous commands, and tab completion; however, since it is an
irb console, you can't simply type LCDProc commands, you have to use the library.

The documentation is still in the works, but provides enough information to get started.
Take a look at the LCDProc::Client class, or the examples, to see how to connect. By
default, Client.new attempts to connect to localhost on port 13666, which should work
for most people.

A few notes:
 1) I have only one LCD to test with, so if you discover any problems, I would greatly
     appreciate any help you can provide as to how to fix it (patches would be great)!

2) I have tested this with a fairly recent version of LCDProc, 0.5.2, but not the CVS
    version.

3) I am sure there are bugs that I will find, in fact, I think there is one with the
    KeyEvent, so if it gives you any trouble, it's probably broken...I'll fix it soon.

4) If there is something that the library does not support that you really really need
    and can't wait for me to implement, you can always call send_command yourself
    and send regular LCDd commands to the server, however, I would highly
    recommend against it as it should be fairly easy to implement it correctly.

Please let me know if you have any problems by e-mailing me directly or posting in
the forum provided by SourceForge. I don't want to hijack this mailing list for my
own project ;-)

=====

Now...on to the question I had at the moment for this list:

When I was creating the clock example for my library, I noticed that if I added a
"num" to the screen it began blinking rapidly. It is even more noticeable if I add
a "num" of 10 (colon) to the screen as you can see it flicker.

I tried sending a regular command directly to LCDd instead of going through my
library and experienced the same issue.

How can I assist in troubleshooting this problem? Might it be a problem with the
driver that I am using (CFontzPacket) or possibly the display itself? I haven't noticed
any other widgets causing this problem.

I can attach my LCDd.conf if needed, but it is pretty standard.

I have a CrystalFontz CFA635 display connected via a serial port to a debian server
running kernel 2.6.18-4-686.

Thanks for your help and I hope I can help contribute to this project some more!

(I am a software developer and I know a tiny bit of C, so if you can point me in
the correct direction, I can probably help debug the issue).

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 bsdfan at nurfuerspam.de  Fri Sep 19 11:21:22 2008
From: bsdfan at nurfuerspam.de (Markus Dolze)
Date: Fri, 19 Sep 2008 19:21:22 +0200
Subject: [Lcdproc] ethlcd
In-Reply-To: <200809171612.22518.peter@adpm.de>
References: <48AC661D.2060301@skyboo.net> <200809171612.22518.peter@adpm.de>
Message-ID: <48D3DF92.30306@nurfuerspam.de>

Peter Marschall wrote:
> Hi Manio,
>
> On Wednesday, 20. August 2008, manio wrote:
>   
>> First of all i need to write something about ethlcd. ethlcd is open
>> source/harware a project which grow in my mind some time ago and now it
>> is ready and blinking on my desk :)
>> The HD44780 display is controlled via Atmel's ATmega microcontroller.
>> There is also a ethernet chip (ENC28J60). So from lcdproc point of view
>> a LCD is accessible via TCP socket. The device is powered via PoE, so to
>> LCD display is only needed a UTP cable :)
>> It has also a 6 buttons, backlight control and a beeper.
>> Photos, schematics, pcb and more are on project homepage:
>> http://manio.skyboo.net/ethlcd/
>>
>>     
> sorry for the late answer.
>
> I have committed your driver to CVS with a few changes:
> - "Device" as the key for the address in LCDd.conf.
>   If possible, I'd like to keep as little different
>   keys as possible.
>   Having a sperate key for the "device" of each connection type
>   doesn't help much I tink
>
>   
The use of HOST_NAME_MAX does not seem to be portable (see attached 
build log). On FreeBSD HOST_NAME_MAX is deprecated.

One option on FreeBSD would be to use _POSIX_HOST_NAME_MAX which is 
defined in <limits.h>.

BTW:
--disable-ethlcd does work well.

Regards
Markus Dolze


-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: FreeBSD-7.0-RELEASE-p3-i386-current-smoke-make.log
URL: <http://lists.omnipotent.net/pipermail/lcdproc/attachments/20080919/b923465d/attachment.txt>

From peter at adpm.de  Fri Sep 19 11:25:34 2008
From: peter at adpm.de (Peter Marschall)
Date: Fri, 19 Sep 2008 19:25:34 +0200
Subject: [Lcdproc] PATCH: Enable picolcd to pass IR codes to LIRC via
	UDP (redone)
In-Reply-To: <48D14747.4030603@jackpot.uk.net>
References: <48D14747.4030603@jackpot.uk.net>
Message-ID: <200809191925.34363.peter@adpm.de>

Hi Jack,

On Wednesday, 17. September 2008, Jack Cleaver wrote:
> OK, I've redone my patch to enable picolcd to send IR codes to LIRC.
>
> - The revised patch was made against this base:
> http://lcdproc.sourceforge.net/nightly/lcdproc-CVS-current.tar.gz
> - IR functionality can be enabled in the config, default is off.
> - Sync and gap lengths are now configurable.
> - Added sample stanzas to LCDd.conf.
> - Updated the docbook to describe the new config options, and to reflect
>    my reservations about the sync and gap.
> - I've inspected the existing docbook notes for picolcd, and I'm not
>    aware of any deficiencies in them.

I have committed your patch with a few changes and given the picolcd
driver a slight overhaul.

Changes compared yo your version:
- No config option "irenabled"
  Sending to LIRC is triggered by setting LircHost to a nonempty value
- LircHost instead of LircAddress
  This now should support host names as well !!!
- less variables in PrivateData
  Some variables you had stored in PrivateData which were never
  used after initialisation have been converted to local variables
  in the respective functions.

It compiles cleanly.
Without having a picolcd I cannot test it more.
Please test it and report feedback.

One more question:
Is p->gap really necessary ?
Is it a variable that needs to keep its value across
multiple calls of ir_transcode() ?
If not it can be converted to a local variable in it_transcode.

Thanks for supporting lcdproc
Peter
  
-- 
Peter Marschall
peter at adpm.de

From peter at adpm.de  Fri Sep 19 11:52:28 2008
From: peter at adpm.de (Peter Marschall)
Date: Fri, 19 Sep 2008 19:52:28 +0200
Subject: [Lcdproc] USB CS-LCD for HD44780 module
In-Reply-To: <20080804093056.141fd086.didik@dsp.itb.ac.id>
References: <20080801193505.27c779f0.didik@dsp.itb.ac.id>
	<200808031929.16232.peter@adpm.de>
	<20080804093056.141fd086.didik@dsp.itb.ac.id>
Message-ID: <200809191952.28798.peter@adpm.de>

Hi,

sorry for the late answer,

On Monday, 4. August 2008, Eko Didik Widianto wrote:
> Yes, off course. i wrote hd44780-cslcd.[c,h] to drive that interface and it
> will be called as cslcd in ConnectionType at hd44780 context. it's stable
> now. i want to share those files (and the neccessary patch file) to this
> project.

If you still want your connection type be included into mainline LCDproc,
please send the patches to current CVS to the LCDproc mailing list.

Please don't forget to not only send the code, but also the necessary 
documentation.
Plase have a look at
http://lcdproc.sourceforge.net/docs/current-dev.html#documentation
for what is expected.
As yours is "only" an extension of an existing driver, you don't need
to write a new file for the hd44780 driver; simply extend the existing
one with the information of your driver (you may look at ethlcd as an example)

Regards
Peter

-- 
Peter Marschall
peter at adpm.de

From manio at skyboo.net  Fri Sep 19 13:07:23 2008
From: manio at skyboo.net (manio)
Date: Fri, 19 Sep 2008 21:07:23 +0200
Subject: [Lcdproc] ethlcd
In-Reply-To: <48D3DF92.30306@nurfuerspam.de>
References: <48AC661D.2060301@skyboo.net> <200809171612.22518.peter@adpm.de>
	<48D3DF92.30306@nurfuerspam.de>
Message-ID: <48D3F86B.2080407@skyboo.net>

Markus Dolze wrote:
> The use of HOST_NAME_MAX does not seem to be portable (see attached 
> build log). On FreeBSD HOST_NAME_MAX is deprecated.
>
> One option on FreeBSD would be to use _POSIX_HOST_NAME_MAX which is 
> defined in <limits.h>.

Yes, you're right - it work well on my system, and i hope it will also 
on others...
Thank for tip :)

regards,
manio

From peter at adpm.de  Sat Sep 20 01:51:53 2008
From: peter at adpm.de (Peter Marschall)
Date: Sat, 20 Sep 2008 09:51:53 +0200
Subject: [Lcdproc] ethlcd
In-Reply-To: <48D3DF92.30306@nurfuerspam.de>
References: <48AC661D.2060301@skyboo.net> <200809171612.22518.peter@adpm.de>
	<48D3DF92.30306@nurfuerspam.de>
Message-ID: <200809200951.53400.peter@adpm.de>

Hi Markus,

On Friday, 19. September 2008, Markus Dolze wrote:
> The use of HOST_NAME_MAX does not seem to be portable (see attached
> build log). On FreeBSD HOST_NAME_MAX is deprecated.
>
> One option on FreeBSD would be to use _POSIX_HOST_NAME_MAX which is
> defined in <limits.h>.

Thank you for reporting it.
I commit the change to CVS.

> BTW:
> --disable-ethlcd does work well.

Good to know, thanks

> Regards
> Markus Dolze

Thanks again
Peter

-- 
Peter Marschall
peter at adpm.de

From jack at jackpot.uk.net  Sat Sep 20 03:44:33 2008
From: jack at jackpot.uk.net (Jack Cleaver)
Date: Sat, 20 Sep 2008 10:44:33 +0100
Subject: [Lcdproc] PATCH: Enable picolcd to pass IR codes to LIRC via
 UDP (redone)
In-Reply-To: <200809191925.34363.peter@adpm.de>
References: <48D14747.4030603@jackpot.uk.net>
	<200809191925.34363.peter@adpm.de>
Message-ID: <48D4C601.4020401@jackpot.uk.net>

Peter Marschall wrote:
> Hi Jack,
> 
> On Wednesday, 17. September 2008, Jack Cleaver wrote:
>> OK, I've redone my patch to enable picolcd to send IR codes to 
>> LIRC.
>> 
>> - The revised patch was made against this base: 
>> http://lcdproc.sourceforge.net/nightly/lcdproc-CVS-current.tar.gz -
>>  IR functionality can be enabled in the config, default is off. - 
>> Sync and gap lengths are now configurable. - Added sample stanzas 
>> to LCDd.conf. - Updated the docbook to describe the new config 
>> options, and to reflect my reservations about the sync and gap. - 
>> I've inspected the existing docbook notes for picolcd, and I'm not
>>  aware of any deficiencies in them.
> 
> I have committed your patch with a few changes and given the picolcd
>  driver a slight overhaul.

Thanks.
> 
> Changes compared yo your version: - No config option "irenabled" 
> Sending to LIRC is triggered by setting LircHost to a nonempty value

Fair enough.

> - LircHost instead of LircAddress This now should support host names 
> as well !!!

Good.

> - less variables in PrivateData Some variables you had stored in 
> PrivateData which were never used after initialisation have been 
> converted to local variables in the respective functions.

OK, I understand.
> 
> It compiles cleanly. Without having a picolcd I cannot test it more.
>  Please test it and report feedback.

OK, later today.
> 
> One more question: Is p->gap really necessary ? Is it a variable that
>  needs to keep its value across multiple calls of ir_transcode() ?

Yes, it is a kind of running total: a single IR command can (and
generally will) produce multiple events, each event presenting one
buffer that needs to be transcoded. A typical IR command requires (I
think) seven buffers (only repeat codes fit in a single buffer). The
actual 'length' of one command is the sum of the durations of the marks
and spaces from all the buffers comprising that command.
The final gap g, after all buffers have been processed, is the value
     g = f - sum(d)
where f is a notional fixed duration shared by all commands, and sum(d)
is the sum of the durations of all the mark and space intervals
comprising one command.

HTH.
-- 
Jack.

From peter at adpm.de  Sat Sep 20 12:33:07 2008
From: peter at adpm.de (Peter Marschall)
Date: Sat, 20 Sep 2008 20:33:07 +0200
Subject: [Lcdproc] PATCH: Enable picolcd to pass IR codes to LIRC via
	UDP (redone)
In-Reply-To: <48D4C601.4020401@jackpot.uk.net>
References: <48D14747.4030603@jackpot.uk.net>
	<200809191925.34363.peter@adpm.de>
	<48D4C601.4020401@jackpot.uk.net>
Message-ID: <200809202033.07838.peter@adpm.de>

On Saturday, 20. September 2008, Jack Cleaver wrote:
> Peter Marschall wrote:
> >[...]
> >
> > One more question: Is p->gap really necessary ? Is it a variable that
> >  needs to keep its value across multiple calls of ir_transcode() ?
>
> Yes, it is a kind of running total: a single IR command can (and
> generally will) produce multiple events, each event presenting one
> buffer that needs to be transcoded. A typical IR command requires (I
> think) seven buffers (only repeat codes fit in a single buffer). The
> actual 'length' of one command is the sum of the durations of the marks
> and spaces from all the buffers comprising that command.
> The final gap g, after all buffers have been processed, is the value
>      g = f - sum(d)
> where f is a notional fixed duration shared by all commands, and sum(d)
> is the sum of the durations of all the mark and space intervals
> comprising one command.
>
> HTH.
Yepp, it helped.
We need to keep gap a member of PrivateData.

Awaiting your Feedback.
Peter

-- 
Peter Marschall
peter at adpm.de

From peter at adpm.de  Sat Sep 20 12:37:20 2008
From: peter at adpm.de (Peter Marschall)
Date: Sat, 20 Sep 2008 20:37:20 +0200
Subject: [Lcdproc] ethlcd
In-Reply-To: <48D3F794.4020603@skyboo.net>
References: <48AC661D.2060301@skyboo.net> <200809191945.37315.peter@adpm.de>
	<48D3F794.4020603@skyboo.net>
Message-ID: <200809202037.20818.peter@adpm.de>

Hi,

On Friday, 19. September 2008, you wrote:
> Peter Marschall wrote:
> > I did the commit on 17.9. ;-)
>
> I know that - i mean on page the current snapshots didn't generate
> past 16.09. I always downloaded it because of the autoconf made
> automagicaly (as you wrote) :)
> unfortunatelly here is the problem:
> The distributions were last generated on Tue Sep 16 00:03:48 PDT 2008 .
Strange.
Since these uploads weren't done by me, I need to contact Guillaume Filion.

I have made a short addition to configure.in that should make it work with
automake 1.10 & autoconf 2.61 from Debian testing.
(It did not throw a warning when running sh ./autogen.sh in order to
create configure & the Makefile.in's; and configure as well as make
ran without any noticeable regressions too)

Maybe it helps you testing latest LCDproc in your environment.


> > What about cut & paste from your website ;-)
> > (ideally with some images [e.g. the schematics image])
>
> yeah, why not, indeed? :)
> i'll think about it :)
>
> ps. could you please make a change in CVS to use a _POSIX_HOST_NAME_MAX
> and include <limits.h> as the Markus Dolze report on maillist?
> it work well on my system :)
>
> thanks and regards,
> manio



-- 
Peter Marschall
peter at adpm.de

From jack at jackpot.uk.net  Sat Sep 20 12:37:49 2008
From: jack at jackpot.uk.net (Jack Cleaver)
Date: Sat, 20 Sep 2008 19:37:49 +0100
Subject: [Lcdproc] PATCH: Enable picolcd to pass IR codes to LIRC via
 UDP (redone)
In-Reply-To: <200809202033.07838.peter@adpm.de>
References: <48D14747.4030603@jackpot.uk.net>	<200809191925.34363.peter@adpm.de>	<48D4C601.4020401@jackpot.uk.net>
	<200809202033.07838.peter@adpm.de>
Message-ID: <48D542FD.8080007@jackpot.uk.net>

Peter Marschall wrote:
> 
> Awaiting your Feedback.

OK. I'm not going to try to build and test software tonight, it's too 
late and I get error-prone. Tomorrow.

-- 
Jack.


From manio at skyboo.net  Sun Sep 21 10:28:22 2008
From: manio at skyboo.net (manio)
Date: Sun, 21 Sep 2008 18:28:22 +0200
Subject: [Lcdproc] ethlcd
In-Reply-To: <200809202037.20818.peter@adpm.de>
References: <48AC661D.2060301@skyboo.net> <200809191945.37315.peter@adpm.de>
	<48D3F794.4020603@skyboo.net> <200809202037.20818.peter@adpm.de>
Message-ID: <48D67626.9030300@skyboo.net>

Peter Marschall wrote:
>> I know that - i mean on page the current snapshots didn't generate
>> past 16.09. I always downloaded it because of the autoconf made
>> automagicaly (as you wrote) :)
>> unfortunatelly here is the problem:
>> The distributions were last generated on Tue Sep 16 00:03:48 PDT 2008 .
>>     
> Strange.
> Since these uploads weren't done by me, I need to contact Guillaume Filion.
>   
now it works - thanks :)
> I have made a short addition to configure.in that should make it work with
> automake 1.10 & autoconf 2.61 from Debian testing.
> (It did not throw a warning when running sh ./autogen.sh in order to
> create configure & the Makefile.in's; and configure as well as make
> ran without any noticeable regressions too)
>
> Maybe it helps you testing latest LCDproc in your environment.
>   
Thank you - now auto* tools works on my testing debian :)
I've compiled the version from CVS and nightly build as well.
... so i am confirming, that the new ethlcd driver works as it should
thank you very much :)

regards,
manio

From jack at jackpot.uk.net  Sun Sep 21 11:15:55 2008
From: jack at jackpot.uk.net (Jack Cleaver)
Date: Sun, 21 Sep 2008 18:15:55 +0100
Subject: [Lcdproc] PATCH: Enable picolcd to pass IR codes to LIRC via
 UDP (redone)
In-Reply-To: <48D542FD.8080007@jackpot.uk.net>
References: <48D14747.4030603@jackpot.uk.net>	<200809191925.34363.peter@adpm.de>	<48D4C601.4020401@jackpot.uk.net>	<200809202033.07838.peter@adpm.de>
	<48D542FD.8080007@jackpot.uk.net>
Message-ID: <48D6814B.5020403@jackpot.uk.net>

Jack Cleaver wrote:
> Peter Marschall wrote:
>> 
>> Awaiting your Feedback.
> 
> OK. I'm not going to try to build and test software tonight, it's too
>  late and I get error-prone. Tomorrow.
> 
Once I have this driver grabbing the device correctly, the rest of the
logic works. Screens are displayed, the config is parsed correctly, IR
codes are sent to LIRC, and button-presses are detected.

The claim-and-detach logic for the USB interface isn't working properly
(for me) at bootup, because the hid driver has got the device. This used
to work.

It works if I change the code so the driver doesn't bail out after
failing to set the configuration, and goes on with detaching the hid
driver. But I can't see anything that has changed in that regard since I
had code that worked, so I'm not uploading a patch (for now).

I've been tinkering with my hardware. That's the only thing I can see
that has changed since yesterday, but I can't see why that would affect
anything.

Is anyone else testing this?
-- 
Jack.

From ethan.dicks at gmail.com  Sun Sep 21 11:33:51 2008
From: ethan.dicks at gmail.com (Ethan Dicks)
Date: Sun, 21 Sep 2008 17:33:51 +0000
Subject: [Lcdproc] PATCH: Enable picolcd to pass IR codes to LIRC via
	UDP (redone)
In-Reply-To: <48D6814B.5020403@jackpot.uk.net>
References: <48D14747.4030603@jackpot.uk.net>
	<200809191925.34363.peter@adpm.de> <48D4C601.4020401@jackpot.uk.net>
	<200809202033.07838.peter@adpm.de> <48D542FD.8080007@jackpot.uk.net>
	<48D6814B.5020403@jackpot.uk.net>
Message-ID: <f4eb766f0809211033j4eb60c58w4e52b26956a62803@mail.gmail.com>

On Sun, Sep 21, 2008 at 5:15 PM, Jack Cleaver <jack at jackpot.uk.net> wrote:
> The claim-and-detach logic for the USB interface isn't working properly
> (for me) at bootup, because the hid driver has got the device. This used
> to work.
>
> It works if I change the code so the driver doesn't bail out after
> failing to set the configuration, and goes on with detaching the hid
> driver. But I can't see anything that has changed in that regard since I
> had code that worked, so I'm not uploading a patch (for now).
>
> I've been tinkering with my hardware. That's the only thing I can see
> that has changed since yesterday, but I can't see why that would affect
> anything.
>
> Is anyone else testing this?

I have been working on the picolcd driver myself, but I don't have LIRC set up
(yet), so I haven't tested that portion of things.

I personally noticed some oddnesses with the claim-and-detach logic.  Working
with Nicu and stepping through the logic in usblib, I came up with an init
sequence that works for me, but I don't know that it's the "right thing to do".

My test environment is usblib 0.12 and a very recent nightly of LCDproc on
a RedHat Enterprise Linux desktop (2.6.9-55.0.9.ELsmp).  Given that I
use RHES for work, I won't be dropping Debian or Ubuntu or anything else
on it... I have nothing against other distros (I started with Slackware over 15
years ago), but nobody is paying me to run anything other than RedHat right
now.

Anyway, here's what I have _after_ the existing code that opens the
device and checks the device tree for picoLCD_VENDOR/picoLCD_DEVICE
(note that I do _not_ call usb_set_configuration() - if I do that, things never
work right).

  if (pd->lcd != NULL) {
    debug(RPT_DEBUG, "%s: opening device succeeded", drvthis->name);

    char driver[1024];
    rtn = usb_get_driver_np(pd->lcd, 0, driver, sizeof(driver));
    if (rtn == 0) {
      report(RPT_WARNING, "Interface claimed by '%s', attempting to
detach it", driver);
      rtn = usb_detach_kernel_driver_np(pd->lcd, 0);
      report(RPT_WARNING, "usb_detach_kernel_driver_np() returned %d", rtn);
    }

    rtn = usb_claim_interface(pd->lcd, 0);
    if (rtn != 0) {
      printf("usb_claim_interface() failed, returned %d, errno %d", rtn, errno);
      return -1;
    }

    usleep(100);
    if (usb_set_altinterface(pd->lcd, 0) < 0)
      report(RPT_WARNING, "%s: unable to set alternate configuration",
drvthis->name);
    } else {
      report(RPT_ERR, "%s: no device found", drvthis->name);
      return -1;
    }

It's pretty straightforward and it does work on my RHEL system, but one
thing that's odd... according to log messages, the first time I start up LCDd
after I've plugged in the picolcd, it tells me that the reliquishing driver is
'usbhid'... ok... great.  The odd part is _after_ that, every time I start up
LCDd, until I unplug the devlce and plug it back in, I get garbage for an
owner.  I would have thought that the device would be unowned after
LCDd takes it from usbhid the first time, and that usb_get_driver_np()
would return some sort of status that _nobody_ owned the picolcd, but
it appears to be not so.

If this sequence really is doing the right thing rather than just "not breaking"
on my system, I can submit a patch for that part of picolcd.c.  I'm also
quite happy to test other arrangements on my system to ensure they work
in this environment.

-ethan

From jack at jackpot.uk.net  Sun Sep 21 13:43:45 2008
From: jack at jackpot.uk.net (Jack Cleaver)
Date: Sun, 21 Sep 2008 20:43:45 +0100
Subject: [Lcdproc] PATCH: Enable picolcd to pass IR codes to LIRC via
 UDP (redone)
In-Reply-To: <f4eb766f0809211033j4eb60c58w4e52b26956a62803@mail.gmail.com>
References: <48D14747.4030603@jackpot.uk.net>	<200809191925.34363.peter@adpm.de>
	<48D4C601.4020401@jackpot.uk.net>	<200809202033.07838.peter@adpm.de>
	<48D542FD.8080007@jackpot.uk.net>	<48D6814B.5020403@jackpot.uk.net>
	<f4eb766f0809211033j4eb60c58w4e52b26956a62803@mail.gmail.com>
Message-ID: <48D6A3F1.6020204@jackpot.uk.net>

Ethan Dicks wrote:
> On Sun, Sep 21, 2008 at 5:15 PM, Jack Cleaver <jack at jackpot.uk.net> 
> wrote:
>> The claim-and-detach logic for the USB interface isn't working 
>> properly (for me) at bootup, because the hid driver has got the 
>> device. This used to work.
>> 
>> It works if I change the code so the driver doesn't bail out after
>>  failing to set the configuration, and goes on with detaching the 
>> hid driver. But I can't see anything that has changed in that 
>> regard since I had code that worked, so I'm not uploading a patch 
>> (for now).
>> 
>> I've been tinkering with my hardware. That's the only thing I can 
>> see that has changed since yesterday, but I can't see why that 
>> would affect anything.
>> 
>> Is anyone else testing this?
> 
> I have been working on the picolcd driver myself, but I don't have 
> LIRC set up (yet), so I haven't tested that portion of things.
> 
> I personally noticed some oddnesses with the claim-and-detach logic. 
> Working with Nicu and stepping through the logic in usblib, I came up
>  with an init sequence that works for me, but I don't know that it's 
> the "right thing to do".
> 
> My test environment is usblib 0.12 and a very recent nightly of 
> LCDproc on a RedHat Enterprise Linux desktop (2.6.9-55.0.9.ELsmp). 
> Given that I use RHES for work, I won't be dropping Debian or Ubuntu 
> or anything else on it... I have nothing against other distros (I 
> started with Slackware over 15 years ago), but nobody is paying me to
>  run anything other than RedHat right now.
> 
> Anyway, here's what I have _after_ the existing code that opens the 
> device and checks the device tree for picoLCD_VENDOR/picoLCD_DEVICE 
> (note that I do _not_ call usb_set_configuration() - if I do that, 
> things never work right).

Oh - cool! OK, I also can't see why the usb_set_configuration() call is
needed; everything works fine if it isn't called. But I've never coded
against USB before.

I'll compare what you have shown with what I have working (tomorrow);
perhaps we can come up with something we're both happy with, and submit it.

> 
> It's pretty straightforward and it does work on my RHEL system, but 
> one thing that's odd... according to log messages, the first time I 
> start up LCDd after I've plugged in the picolcd, it tells me that the
>  reliquishing driver is 'usbhid'... ok... great.  The odd part is 
> _after_ that, every time I start up LCDd, until I unplug the devlce 
> and plug it back in, I get garbage for an owner.

Oh - I'll see if I can replicate that.

> I would have thought that the device would be unowned after LCDd 
> takes it from usbhid the first time, and that usb_get_driver_np() 
> would return some sort of status that _nobody_ owned the picolcd, but
>  it appears to be not so.
> 
> If this sequence really is doing the right thing rather than just 
> "not breaking" on my system, I can submit a patch for that part of 
> picolcd.c.  I'm also quite happy to test other arrangements on my 
> system to ensure they work in this environment.

Great. I only have one test environment, the picolcd is built-in (M300),
and I don't know anyone else that's using this gear that I can ask to
test my code.

Thanks for the feedback.

-- 
Jack.


From ethan.dicks at gmail.com  Sun Sep 21 13:52:57 2008
From: ethan.dicks at gmail.com (Ethan Dicks)
Date: Sun, 21 Sep 2008 19:52:57 +0000
Subject: [Lcdproc] PATCH: Enable picolcd to pass IR codes to LIRC via
	UDP (redone)
In-Reply-To: <48D6A3F1.6020204@jackpot.uk.net>
References: <48D14747.4030603@jackpot.uk.net>
	<200809191925.34363.peter@adpm.de> <48D4C601.4020401@jackpot.uk.net>
	<200809202033.07838.peter@adpm.de> <48D542FD.8080007@jackpot.uk.net>
	<48D6814B.5020403@jackpot.uk.net>
	<f4eb766f0809211033j4eb60c58w4e52b26956a62803@mail.gmail.com>
	<48D6A3F1.6020204@jackpot.uk.net>
Message-ID: <f4eb766f0809211252n3fc867eer336f85747d609ba9@mail.gmail.com>

On Sun, Sep 21, 2008 at 7:43 PM, Jack Cleaver <jack at jackpot.uk.net> wrote:
> Oh - cool! OK, I also can't see why the usb_set_configuration() call is
> needed; everything works fine if it isn't called. But I've never coded
> against USB before.

All of my usblib experience is with LCDproc (i.e., not all that much).  Prior
to the picolcd, I've done a bit with the usb4lcd, and everything else is either
serial or parallel attached (though I have constructed a few MCU-based serial
interfaces myself).

> I'll compare what you have shown with what I have working (tomorrow);
> perhaps we can come up with something we're both happy with, and submit it.

That sounds great.  I'll write you off-line with my 24/7 e-mail address.

> Great. I only have one test environment, the picolcd is built-in (M300),
> and I don't know anyone else that's using this gear that I can ask to
> test my code.

Nicu sent me a picolcd a while back to help with driver work, so mine
is just standalone.

> Thanks for the feedback.

You bet.

-ethan

From peter at adpm.de  Sun Sep 21 14:25:17 2008
From: peter at adpm.de (Peter Marschall)
Date: Sun, 21 Sep 2008 22:25:17 +0200
Subject: [Lcdproc] PATCH: Enable picolcd to pass IR codes to LIRC via
	UDP (redone)
In-Reply-To: <48D6814B.5020403@jackpot.uk.net>
References: <48D14747.4030603@jackpot.uk.net> <48D542FD.8080007@jackpot.uk.net>
	<48D6814B.5020403@jackpot.uk.net>
Message-ID: <200809212225.17456.peter@adpm.de>

Hi,

On Sunday, 21. September 2008, Jack Cleaver wrote:
> Once I have this driver grabbing the device correctly, the rest of the
> logic works. Screens are displayed, the config is parsed correctly, IR
> codes are sent to LIRC, and button-presses are detected.

This is good news.
Thanks for the feedback.

> The claim-and-detach logic for the USB interface isn't working properly
> (for me) at bootup, because the hid driver has got the device. This used
> to work.
>
> It works if I change the code so the driver doesn't bail out after
> failing to set the configuration, and goes on with detaching the hid
> driver. But I can't see anything that has changed in that regard since I
> had code that worked, so I'm not uploading a patch (for now).

Strange. But I guess I am not the culprit.
I didn't fidddle with this part of the code.

Regards
PEter
-- 
Peter Marschall
peter at adpm.de

From brylozketrzyn at gmail.com  Tue Sep 23 01:11:15 2008
From: brylozketrzyn at gmail.com (=?utf-8?q?Micha=C5=82_Wi=C5=9Bniewski?=)
Date: Tue, 23 Sep 2008 09:11:15 +0200
Subject: [Lcdproc] [LCDproc][server] refresh rate etc.
Message-ID: <200809230911.16310.brylozketrzyn@wp.pl>

Hello
Is there any possibility to make refresh rate configurable in LCDd/conf file? 
It can be also negotiated with client app - some of them may need very quick 
refresh rate (VU meters) and others may need very slow (i.e. progress bar of 
any movie player). Moreover, scrolling text may be easier to read at slow 
rate... I've spotted, that hbar of width 1 is not displaying; it became 
visible after setting its width to at least 2. Poblem spotted @hd44780, other 
drivers may work properly. What can i do?
-- 
Michal "enkidu" Wisniewski
DS2 21A

From peter at adpm.de  Wed Sep 24 12:36:09 2008
From: peter at adpm.de (Peter Marschall)
Date: Wed, 24 Sep 2008 20:36:09 +0200
Subject: [Lcdproc] [LCDproc][server] refresh rate etc.
In-Reply-To: <200809230911.16310.brylozketrzyn@wp.pl>
References: <200809230911.16310.brylozketrzyn@wp.pl>
Message-ID: <200809242036.09469.peter@adpm.de>

Hi,

On Tuesday, 23. September 2008, Micha? Wi?niewski wrote:
> Is there any possibility to make refresh rate configurable in LCDd/conf
> file? It can be also negotiated with client app - some of them may need
> very quick refresh rate (VU meters) and others may need very slow (i.e.
> progress bar of any movie player). Moreover, scrolling text may be easier
> to read at slow rate... I've spotted, that hbar of width 1 is not
> displaying; it became visible after setting its width to at least 2. Poblem
> spotted @hd44780, other drivers may work properly. What can i do?

the refresh rate in the server is fixed: 1/8 s

But you can virtually slow it down in the client
if you wait long enough between any two screen updates.

Regards
Peter
-- 
Peter Marschall
peter at adpm.de

From fred.welland at gmail.com  Fri Sep 26 07:28:21 2008
From: fred.welland at gmail.com (Fred Welland)
Date: Fri, 26 Sep 2008 09:28:21 -0400
Subject: [Lcdproc] picoLCD and back lighting???
Message-ID: <812fb8370809260628m54e711f4l34051c1c2ed92783@mail.gmail.com>

Hi,

A few days ago I got a picoLCD 4X20 sideshow (the usb one).

It works great for the most part.

One issue I have is that when I plug it in -- it has a nice bright &
contrasting display with a hardware welcome message.   Once I load LCDd, it
gets DIM.  I still have blue with white foreground lettering.  But it seems
the backlight if turned off.

The 'Contrast' setting in the [picolcd] section does affect the 'color' of
the lettering (0 lettering gets darker, 1000 lettering is white)

There is a 'Backlight' setting in both [picolcd] and [server]  but that
doesn't seem to have any affect.

Is there a way to get the backlight to turn back on?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omnipotent.net/pipermail/lcdproc/attachments/20080926/5f22bc12/attachment.htm>

From andy at siliconlandmark.com  Fri Sep 26 13:40:31 2008
From: andy at siliconlandmark.com (Andre Guibert de Bruet)
Date: Fri, 26 Sep 2008 15:40:31 -0400
Subject: [Lcdproc] LCDProc on OS X 10.5
Message-ID: <C19CE82A-A185-4FEA-94CE-2E39D2356B88@siliconlandmark.com>

Hi,

I have attached a patch against CVS HEAD that tweaks Topher Fangio's  
fix for the lack of kvm.h on OS X 10.5.0 and newer. One needs to  
include /usr/include/available.h before one can start using  
__DEPRECATED_IN_MAC_OS_X_VERSION_10_5_AND_LATER. Strangely enough,  
Apple's official headers also define  
DEPRECATED_IN_MAC_OS_X_VERSION_10_5_AND_LATER in /usr/include/ 
AvailabilityMacros.h. I opted to use the prefixed macro in my patch.

With the attached patch, my vanilla development system builds lcdproc  
properly.

Regards,

/*  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 */



-------------- next part --------------
A non-text attachment was scrubbed...
Name: machine_Darwin.c.10.5.diff
Type: application/octet-stream
Size: 622 bytes
Desc: not available
URL: <http://lists.omnipotent.net/pipermail/lcdproc/attachments/20080926/66bbbd40/attachment.obj>
-------------- next part --------------




From fred.welland at gmail.com  Sat Sep 27 12:08:15 2008
From: fred.welland at gmail.com (Fred Welland)
Date: Sat, 27 Sep 2008 14:08:15 -0400
Subject: [Lcdproc] picoLCD and back lighting???
In-Reply-To: <48DD682B.9090406@stuffofmine.com>
References: <812fb8370809260628m54e711f4l34051c1c2ed92783@mail.gmail.com>
	<48DD682B.9090406@stuffofmine.com>
Message-ID: <812fb8370809271108i23decffci30c658723c2221a2@mail.gmail.com>

That s a bummer!!

hope a fix is available soon...



On Fri, Sep 26, 2008 at 6:54 PM, Bob Wiegand <bob_ml at stuffofmine.com> wrote:

> Fred Welland wrote:
>
>> Hi,
>>
>> A few days ago I got a picoLCD 4X20 sideshow (the usb one).
>>
>> It works great for the most part.
>>
>> One issue I have is that when I plug it in -- it has a nice bright &
>> contrasting display with a hardware welcome message.   Once I load LCDd, it
>> gets DIM.  I still have blue with white foreground lettering.  But it seems
>> the backlight if turned off.
>>
>> The 'Contrast' setting in the [picolcd] section does affect the 'color' of
>> the lettering (0 lettering gets darker, 1000 lettering is white)
>>
>> There is a 'Backlight' setting in both [picolcd] and [server]  but that
>> doesn't seem to have any affect.
>>
>> Is there a way to get the backlight to turn back on?
>>
>
> I sent a question about this to Mini-Box and they answered that it will
> be fixed in a future version. They didn't indicate when exactly.
>
> Bob
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omnipotent.net/pipermail/lcdproc/attachments/20080927/13b212fc/attachment.htm>

From epooch at cox.net  Sat Sep 27 13:34:58 2008
From: epooch at cox.net (Eric Pooch)
Date: Sat, 27 Sep 2008 12:34:58 -0700
Subject: [Lcdproc] LCDProc on OS X 10.5
Message-ID: <2EBDC194-BDB4-44C1-9D43-B90695A8567C@cox.net>

Sorry, I have been out of the loop for a while.

include kvm.h was erroneously left in the machine_Darwin.c after I  
changed the way memory information was obtained.  I have removed the  
include and tested on earlier versions of mac os x with no problems.   
It really is not needed.  Patch file enclosed.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: darwin_kvm.patch
Type: application/octet-stream
Size: 335 bytes
Desc: not available
URL: <http://lists.omnipotent.net/pipermail/lcdproc/attachments/20080927/8678b10c/attachment.obj>

From epooch at cox.net  Sun Sep 28 00:40:50 2008
From: epooch at cox.net (Eric Pooch)
Date: Sat, 27 Sep 2008 23:40:50 -0700
Subject: [Lcdproc] serialPOS update patch
Message-ID: <188B7212-97B5-457A-9609-CCCD5F2E074B@cox.net>

This patch fixes a few bugs when using bignum,  cleans up some code,  
and should add functionality for Epson ESC/POS and Logic Controls POS  
displays.
--Eric
-------------- next part --------------
A non-text attachment was scrubbed...
Name: serialPOS2.patch
Type: application/octet-stream
Size: 12270 bytes
Desc: not available
URL: <http://lists.omnipotent.net/pipermail/lcdproc/attachments/20080927/9ab58d2d/attachment-0001.obj>

From epooch at cox.net  Mon Sep 29 13:48:34 2008
From: epooch at cox.net (epooch at cox.net)
Date: Mon, 29 Sep 2008 12:48:34 -0700
Subject: [Lcdproc] No configure warning if no pkg-config
Message-ID: <20080929154834.HT6UK.528898.imail@fed1rmwml45>

I experienced a problem this weekend while trying to compile libusb dependent drivers in lcdproc.  Previously, I did not have any problems compiling these drivers.
The problem is that if pkg-config is not installed, the configuration proceeds with no warnings or errors, even if libusb is explicitly enabled. There is no indication of  a problem or what it is until the complier gives warnings about certain drivers needing libusb.  However, because I was only compiling the HD44780 USB drivers, there wasn't even a compiler warning!  My USB HD44780 driver just would not get compiled.
There is no documentation about requiring pkg-config for libusb in either INSTALL or CHANGES
I may make a patch, but I wanted to make sure this was mentioned on the list in case anybody else has the same problem. 
The solution is simple- just install pkg-config and set the relevant environment variable to its path.
This was a problem in Mac OS X 10.4.8 where pkg-config is not installed by the development tools.
Thanks --Eric

From w_smith at compusmiths.com  Tue Sep 30 04:45:48 2008
From: w_smith at compusmiths.com (William P.N. Smith)
Date: Tue, 30 Sep 2008 06:45:48 -0400
Subject: [Lcdproc] MiniBox PicoLCD USB Backlight (etc)
Message-ID: <48E2035C.4080606@compusmiths.com>

Fred Welland and Bob Wiegand discussed the (ahem) misfeatures of the 
Mini-Box PicoLCD (USB Version).  It almost looks like the drivers were 
written for one of the other flavors of PicoLCD...

Hmm, mine also switches the backlight to "low" intensity, and goes out 
after a while, and doesn't light up the keys, and has other misfeatures.

Strange that they didn't mention that in the advertisements.  Maybe it 
works better on Vista (sigh).  I'll check the sacrificial Vista machine 
for compatibility.

There was mention of an SDK, anyone seen anything like that?

[Since it's not currently useful, I could lend mine to the developers if 
they'd like to play with real hardware...]

William Smith
ComputerSmiths Consulting, Inc.

From w_smith at compusmiths.com  Tue Sep 30 05:46:13 2008
From: w_smith at compusmiths.com (William P.N. Smith)
Date: Tue, 30 Sep 2008 07:46:13 -0400
Subject: [Lcdproc] [Fwd: [support #48412]: PicoLCD on Linux?]
Message-ID: <48E21185.4060409@compusmiths.com>

 From Mini-Box tech support, FYI:

-------- Original Message --------
Subject: [support #48412]: PicoLCD on Linux?
Date: Tue, 30 Sep 2008 04:36:34 -0700
From: customer-support at mini-box.com
Reply-To: customer-support at mini-box.com
To: w_smith at compusmiths.com
References: <48E1F486.4040703 at compusmiths.com>

Dear Sir,

   At the end of this week, we will release a new version of the driver 
which will solve this issue. Should you need other details, please 
contact us!

Best Regards,
Cristi Ciubotaru.



From fred.welland at gmail.com  Tue Sep 30 06:48:16 2008
From: fred.welland at gmail.com (Fred Welland)
Date: Tue, 30 Sep 2008 08:48:16 -0400
Subject: [Lcdproc] [Fwd: [support #48412]: PicoLCD on Linux?]
In-Reply-To: <48E21185.4060409@compusmiths.com>
References: <48E21185.4060409@compusmiths.com>
Message-ID: <812fb8370809300548x14dc0d2o25aa03ecc2819be5@mail.gmail.com>

Well that is a bit promising...

And to the guy that was gonna try vista -- lemme us know the results -- I
don't even have a vista machine

(and the keys have a back light on/in them???)


On Tue, Sep 30, 2008 at 7:46 AM, William P.N. Smith <w_smith at compusmiths.com
> wrote:

> From Mini-Box tech support, FYI:
>
> -------- Original Message --------
> Subject: [support #48412]: PicoLCD on Linux?
> Date: Tue, 30 Sep 2008 04:36:34 -0700
> From: customer-support at mini-box.com
> Reply-To: customer-support at mini-box.com
> To: w_smith at compusmiths.com
> References: <48E1F486.4040703 at compusmiths.com>
>
> Dear Sir,
>
>  At the end of this week, we will release a new version of the driver which
> will solve this issue. Should you need other details, please contact us!
>
> Best Regards,
> Cristi Ciubotaru.
>
>
> _______________________________________________
> 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/20080930/f03ff211/attachment.htm>