From joris at robijn.net  Sun Feb  1 10:03:38 2009
From: joris at robijn.net (Joris Robijn)
Date: Sun, 01 Feb 2009 11:03:38 +0100
Subject: [Lcdproc] Signalling in server/main.c
In-Reply-To: <20090201095204.173470@gmx.net>
References: <20090131141147.142390@gmx.net>,
	<49847716.3252.3A1226@joris.robijn.net>,
	<20090201095204.173470@gmx.net>
Message-ID: <4985818A.1923.44AE998@joris.robijn.net>

Hi Markus,

What I mean is that the gained access to the port is lost at the fork. 
And after the drop_privs you are no longer root so you cannot get access 
anymore. That's why the order is like this. All related to the good ol' 
parallel devices.

But I wouldn't rule out the possibility that there's a better way to 
accomplish the same. 

Joris



On 1 Feb 2009 at 10:52, Markus Dolze wrote:

> -------- Original-Nachricht --------
> > Datum: Sat, 31 Jan 2009 16:06:46 +0100
> > Von: "Joris Robijn" <joris at robijn.net>
> > An: lcdproc at lists.omnipotent.net
> > CC: bsdfan at nurfuerspam.de
> > Betreff: Re: [Lcdproc] Signalling in server/main.c
> 
> > > The whole thing is only necessary because fork() happens before the
> > > drivers are initialized. It was after the initialization before 0.5.0.
> > > 
> > > Does anybody of the former developers remember why fork() was moved
> > before
> > > the initialization?
> > 
> > The server looses the priviledges on the parallel port after the fork.
> > That's why the drop_privs is done after the fork and after the driver
> > init.
> > 
> 
> Hi Joris,
> 
> that's a good point. But I am not concerned about drop_privs, but about
> the fork().
> 
> Currently we do (simplyfied):
> 
> CHAIN(e, parent_pid = daemonize());
> install_signal_handlers()
> CHAIN(e, sock_init(bind_addr, bind_port));
> // ... Other inits
> CHAIN(e, server_screen_init());
> CHAIN_END()
> wave_to_parent(parent_pid);
> drop_privs(user);
> 
> 
> What about:
> 
> CHAIN(e, sock_init(bind_addr, bind_port));
> // ... Other inits
> CHAIN(e, server_screen_init());
> CHAIN(e, parent_pid = daemonize());
> install_signal_handlers()
> CHAIN_END()
> drop_privs(user);
> 
> This way we may avoid the signalling at all.
> 
> Regards,
> Markus

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



From stewartputnam at comcast.net  Mon Feb  2 00:25:02 2009
From: stewartputnam at comcast.net (stewartputnam at comcast.net)
Date: Mon, 2 Feb 2009 00:25:02 +0000 (UTC)
Subject: [Lcdproc] LCDd daemon hangs with USB Crystalfontz 634 LCD
In-Reply-To: <B3875DA949544633A05058507CEEA665@jartzhome>
Message-ID: <1429105799.157921233534302448.JavaMail.root@sz0098a.emeryville.ca.mail.comcast.net>


----- Original Message ----- 
From: "Jeff Artz" <junk_inbox at verizon.net> 
To: "lcdproc" <lcdproc at lists.omnipotent.net> 
Sent: Wednesday, January 28, 2009 9:21:21 PM GMT -08:00 US/Canada Pacific 
Subject: Re: [Lcdproc] LCDd daemon hangs with USB Crystalfontz 634 LCD 


Does anybody have anything to suggest? It's now been a month since I posted my issue, but haven't even gotten a single response... 

:-( 

Jeff 


----- Original Message ----- 
From: Jeff Artz 
To: lcdproc 
Sent: Sunday, December 28, 2008 11:07 PM 
Subject: [Lcdproc] LCDd daemon hangs with USB Crystalfontz 634 LCD 


So, to help troubleshoot, I changed the ReportLevel to 5, and here's what I get to stdout: 
[mythtv at mythbackend etc]$ sudo /sbin/service LCDd start 
Starting up LCDd: LCDd version 0.5.2 starting 
Built on Dec 22 2008, protocol version 0.3, API version 0.5 
Using Configuration File: /home/mythtv/lcd/LCDd.conf 
Set report level to 5, output to stderr 
Server forking to background 
Listening for queries on 127.0.0.1:13666 
screenlist_init() 
driver_load(name="CFontz", filename="/home/mythtv/lcd/CFontz.so") 
CFontz: using Device /dev/lcd 
Excuse me, this strikes me as too simple to be the answer. It popped out to me only after downloading the latest 634*.pdf form CF... 

I've used three CrystalFontz proucts, never a 634, and debian. All three use the /drivers/usb/serial/ftdi_sio kernel module (CONFIG_USB_SERIAL_FTDI_SIO=m). The device nodes appear as /dev/ttyUSB{n} This is always kernel, not distribution, dependent? Do any distributions customze that part of the kernel or create symlinks? Does the 634 use the same usb-serial converter as the 631, 633, & 635? 

usbcore: registered new driver usbserial 
drivers/usb/serial/usb-serial.c: USB Serial Driver core 
drivers/usb/serial/usb-serial.c: USB Serial support registered for FTDI USB Serial Device 
ftdi_sio 2-3:1.0: usb_probe_interface 
ftdi_sio 2-3:1.0: usb_probe_interface - got id 
ftdi_sio 2-3:1.0: FTDI USB Serial Device converter detected 
drivers/usb/serial/ftdi_sio.c: Detected FT8U232AM 
usb 2-3: FTDI USB Serial Device converter now attached to ttyUSB0 
usbcore: registered new driver ftdi_sio 
drivers/usb/serial/ftdi_sio.c: v1.4.3:USB FTDI Serial Converters Driver 

I've not used any module that appears as /dev/lcd. 
Um, er, I speculate that some modules do ? Some must (or used to ?) for that to appear as a default in [driver] sections of LCDd.conf, yes? 

If this is the cause of Jeff Artz hang: how many others give lcdproc a try but do not go as far as signing up to this list & submitting ReportLev=5 logs & resubmitting a mont later? Should /dev/lcd be replaced in some [driver] sectiens of the default / example / distribution LCDd.conf? 



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

From andy at siliconlandmark.com  Mon Feb  2 02:17:44 2009
From: andy at siliconlandmark.com (Andre Guibert de Bruet)
Date: Sun, 1 Feb 2009 21:17:44 -0500
Subject: [Lcdproc] [PATCH] PicoLCD off-by-one causes last char to get
	chopped off in picoLCD_string()
Message-ID: <75BFC17F-FBBB-4BA0-B610-D6FD12751992@siliconlandmark.com>

Hi,

I found the cause of the bug that causes the last character to get  
chopped off on the PicoLCD devices. It turns out it was an off-by-one  
error in picoLCD_string() in the section that enforces line length on  
the desired output.

Please review and commit the attached patch.

Cheers,
Andy

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


-------------- next part --------------
A non-text attachment was scrubbed...
Name: picolcd.offbyone.patch
Type: application/octet-stream
Size: 634 bytes
Desc: not available
URL: <http://lists.omnipotent.net/pipermail/lcdproc/attachments/20090201/806f1646/attachment.obj>
-------------- next part --------------


From sascha.zielinski at gmx.de  Mon Feb  2 19:58:35 2009
From: sascha.zielinski at gmx.de (Sascha)
Date: Mon, 2 Feb 2009 20:58:35 +0100
Subject: [Lcdproc] HD44780 40x4 with Backlight and winamp wiring
In-Reply-To: <20090201094412.173500@gmx.net>
References: <9185341920196262063@unknownmsgid>
	<200901311935.34256.sascha.zielinski@gmx.de>
	<20090201094412.173500@gmx.net>
Message-ID: <200902022058.35436.sascha.zielinski@gmx.de>

> > HI,, your Patch works fine I successfully patched and compiled LCDproc
> > from
> > CVS. My Display is working now.
> >
> > Am I right that there's no solution for the swithchable backlight in a
> > 40x4
> > LCD at this time? I would love to get that working. Is it possible to
> > make the
> > BL Pin adressable like in lcdtime?
> >
> > Sascha Zielinski
>
> Hi,
>
> there is currently no configuration setting for this. If you do not have
> the extra output latch, you can modify the winamp driver to use its pin for
> the backlight.
>
> In hd44780-winamp.c change line 194 from
> p->backlight_bit = (state?0:nSEL);
> to
> p->backlight_bit = (state?0:LF);
>
> For now you will have to do this whenever you update lcdproc.
>
> You need to modify your display connections like this:
> 1. Connect the backlight transistor to parallel port pin 14 (LF)
> 2. Connect the diplay's pin 10 (RW) to ground.
>
> Additionally you should put "OutputPort=no" in you LCDd.conf.
>
> Regards
> Markus

Hi, today I connected LCD Pin 10 (RW) to GND and The BL Pin to Pin 14. I tried 
the change you mentioned with and without your previosly Patch(I guess without 
would be right?).
I double checked all wire connections, but my LCD shows only the first 
controller (2 lines on top) and the Backlight doesn't light up. I also tried 
the three options in the menu(off, on, controlable by LCDd-Clients?), but 
nothing has changed.
Thx for your Help so far.

Sascha Zielinski

From bsdfan at nurfuerspam.de  Wed Feb  4 07:18:33 2009
From: bsdfan at nurfuerspam.de (Markus Dolze)
Date: Wed, 04 Feb 2009 08:18:33 +0100
Subject: [Lcdproc] [PATCH] FreeBSD's new USB stack support (configure.in
 changes, testing needed)
In-Reply-To: <90B881CB-06A2-4436-8F65-630309EC5279@siliconlandmark.com>
References: <90B881CB-06A2-4436-8F65-630309EC5279@siliconlandmark.com>
Message-ID: <49894149.7020502@nurfuerspam.de>

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

the patch does not work for me. I took the change to install FreeBSD 
200812 snapshot (with old usb) and installed the lcdproc port. 
Everything looked fine then. After that I deinstalled lcdproc and libusb 
and rebuilt the kernel with USB2 support and rebuild lcdproc-current 
with your patch.

While the patch correctly detects the libusb20_compat01 header, the 
configure script uses pkg-config to detect whether libusb (SF) is 
installed or not and enables / disables drivers accordingly.

As I had no libusb installed (I thought it shall use the new FreeBSD's 
one) all drivers using USB were still disabled. See this excerpt from 
configure output (note that the FreeBSD lcdproc port currently does not 
use libftdi, I just left it in)

...
checking if libusb support has been enabled... yes
checking for pkg-config... /usr/local/bin/pkg-config
checking pkg-config is at least version 0.9.0... yes
checking for LIBUSB... no
checking for libusb20.h... yes
checking for libusb20_compat01.h... yes
checking if libftdi support has been enabled... yes
checking for LIBFTDI... no
configure: checking which drivers to compile...
configure: WARNING: The i2500vfd driver needs the ftdi library
configure: WARNING: The IOWarrior driver needs the libusb library.
configure: WARNING: The lis driver needs the ftdi library
configure: WARNING: The picolcd driver needs the libusb library.
configure: WARNING: The shuttleVFD driver needs the libusb library.
...

As you can see, picolcd, shuttleVFD and IOWarrior are not enabled. 
Additionally all hd44780- drivers using libusb (bwct, lcd2usb, ...) are 
not enabled.

I would like to discuss if is makes sense to be able to disable and 
enable USB support on FreeBSD 8 like it is now possible for lcdproc with 
libusb.

Regards
Markus

From andy at siliconlandmark.com  Wed Feb  4 22:05:34 2009
From: andy at siliconlandmark.com (Andre Guibert de Bruet)
Date: Wed, 4 Feb 2009 17:05:34 -0500
Subject: [Lcdproc] [PATCH] FreeBSD's new USB stack support (configure.in
	changes, testing needed)
In-Reply-To: <49894149.7020502@nurfuerspam.de>
References: <90B881CB-06A2-4436-8F65-630309EC5279@siliconlandmark.com>
	<49894149.7020502@nurfuerspam.de>
Message-ID: <6635478E-2C8C-4EB5-88A4-6F020B991CF8@siliconlandmark.com>

On Feb 4, 2009, at 2:18 AM, Markus Dolze wrote:

> Andre Guibert de Bruet wrote:
>>
>> I have attached a patch that extends LCDproc's USB support, and  
>> allows for its use on the upcoming FreeBSD 8.0 (Presently 8-CURRENT).
>>
>> This patch changes configure.in as well as all of LCDproc's USB  
>> drivers and though I have made every effort to not introduce side- 
>> effects, it needs wide-scale testing. For users of non-FreeBSD  
>> systems, this patch should not change anything. I have verified  
>> this statement with OSX, but I have not tested against any flavor  
>> of Linux (I suspect that it should "just work").
>>
>> For pre-8.0-CURRENT FreeBSD users, the absence of the new USB's  
>> stack's headers keeps the present dependance on libusb.
>>
>> Let me know if this patch works or breaks anything for you.
>
> the patch does not work for me. I took the change to install FreeBSD  
> 200812 snapshot (with old usb) and installed the lcdproc port.  
> Everything looked fine then. After that I deinstalled lcdproc and  
> libusb and rebuilt the kernel with USB2 support and rebuild lcdproc- 
> current with your patch.
>
> While the patch correctly detects the libusb20_compat01 header, the  
> configure script uses pkg-config to detect whether libusb (SF) is  
> installed or not and enables / disables drivers accordingly.

Mea culpa. To get everything to work, I had to hack up a /usr/local/ 
libdata/pkgconfig/libusb.pc file that looked like:

# -- 8< --
# Package Information for pkg-config

prefix=/usr/
exec_prefix=${prefix}
libdir=${exec_prefix}/lib
includedir=${prefix}/include

Name: libusb
Description: libusb 2.0
Version: 2.0
Libs: -L${libdir} -lusb20
Cflags: -I${includedir}
# -- 8< --

LCDproc can't be the only piece of software using pkg-config to detect  
libusb presence. I realize that their new USB stack isn't the default  
yet (From the list feedback, that should happen real soon), so libusb  
from ports is still the way to go...

> As I had no libusb installed (I thought it shall use the new  
> FreeBSD's one) all drivers using USB were still disabled. See this  
> excerpt from configure output (note that the FreeBSD lcdproc port  
> currently does not use libftdi, I just left it in)
>
> ...
> checking if libusb support has been enabled... yes
> checking for pkg-config... /usr/local/bin/pkg-config
> checking pkg-config is at least version 0.9.0... yes
> checking for LIBUSB... no
> checking for libusb20.h... yes
> checking for libusb20_compat01.h... yes
> checking if libftdi support has been enabled... yes
> checking for LIBFTDI... no
> configure: checking which drivers to compile...
> configure: WARNING: The i2500vfd driver needs the ftdi library
> configure: WARNING: The IOWarrior driver needs the libusb library.
> configure: WARNING: The lis driver needs the ftdi library
> configure: WARNING: The picolcd driver needs the libusb library.
> configure: WARNING: The shuttleVFD driver needs the libusb library.
> ...
>
> As you can see, picolcd, shuttleVFD and IOWarrior are not enabled.  
> Additionally all hd44780- drivers using libusb (bwct, lcd2usb, ...)  
> are not enabled.
>
> I would like to discuss if is makes sense to be able to disable and  
> enable USB support on FreeBSD 8 like it is now possible for lcdproc  
> with libusb.


I am open for suggestions. I can make configure.in grok a --enable- 
freebsd8-libusb (Or whatever) option or hack the libusb check to  
perform some scary voodoo that will support the target.

Andy

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



From bsdfan at nurfuerspam.de  Thu Feb  5 07:10:12 2009
From: bsdfan at nurfuerspam.de (Markus Dolze)
Date: Thu, 05 Feb 2009 08:10:12 +0100
Subject: [Lcdproc] [PATCH] PicoLCD off-by-one causes last char to get
 chopped off in picoLCD_string()
In-Reply-To: <75BFC17F-FBBB-4BA0-B610-D6FD12751992@siliconlandmark.com>
References: <75BFC17F-FBBB-4BA0-B610-D6FD12751992@siliconlandmark.com>
Message-ID: <498A90D4.8050805@nurfuerspam.de>

Andre Guibert de Bruet wrote:
> Hi,
>
> I found the cause of the bug that causes the last character to get 
> chopped off on the PicoLCD devices. It turns out it was an off-by-one 
> error in picoLCD_string() in the section that enforces line length on 
> the desired output.
>
> Please review and commit the attached patch.
Thank you for spotting this. Although I cannot test your patch, I tested 
picoLCD_string() separately and created a slightly different patch.


Imagine you want to write the text "test" two times at position 5 on a 
1x12 display. The result should be "1234testtest".
width = 12, x = 5, len = 8;

current code:
    if (len + x > p->width)
        len = p->width - x;

with values:
    if (8 + 5 > 12)   // true
       len = 12 - 5;   // = 7, wrong

It is not only the length that is calculated incorrectly, but the 
condition triggers incorrectly as well.

If you apply my patch, the 1-to-0 conversion is done before, resulting in:

    x--;   // 4
    if ((8 + 4) > 12)   //false, len stays 8

Suppose we want to write the same text twice at position 6, resulting in 
"12345testtes":
width = 12, x = 6, len = 8;

    x--;   // 5
    if ((8 + 5) > 12)   // true
       len = 12 - 5;   // = 7, correct

Please test if the attached patch works for you.

Regards
Markus
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: picolcd.offbyone-2.diff
URL: <http://lists.omnipotent.net/pipermail/lcdproc/attachments/20090205/af247029/attachment.txt>

From listen at sowas.org  Thu Feb  5 13:22:21 2009
From: listen at sowas.org (Dirk Mueller)
Date: Thu, 5 Feb 2009 14:22:21 +0100
Subject: [Lcdproc] usblcd with lcdproc >= 0.5
Message-ID: <200902051422.21195.listen@sowas.org>

Hi,

I own a usb lcd conector from www.usblcd.de.
Lcdproc supported this type of lcd connector since version 0.4.4.

Today I tried lcdproc 0.5.2 and I was not able to get it running. Looks like 
the usblcd code was removed from version 0.5.0.

There is no information about this in the release notes. Am I right, is it not 
longer supported?

Regards,

Dirk

From bsdfan at nurfuerspam.de  Thu Feb  5 18:39:22 2009
From: bsdfan at nurfuerspam.de (Markus Dolze)
Date: Thu, 05 Feb 2009 19:39:22 +0100
Subject: [Lcdproc] usblcd with lcdproc >= 0.5
In-Reply-To: <200902051422.21195.listen@sowas.org>
References: <200902051422.21195.listen@sowas.org>
Message-ID: <498B325A.3050500@nurfuerspam.de>

Dirk Mueller wrote:
> Hi,
>
> I own a usb lcd conector from www.usblcd.de.
> Lcdproc supported this type of lcd connector since version 0.4.4.
>
> Today I tried lcdproc 0.5.2 and I was not able to get it running. Looks like 
> the usblcd code was removed from version 0.5.0.
>
> There is no information about this in the release notes. Am I right, is it not 
> longer supported?
>
> Regards,
>
> Dirk
>   
Hello Dirk,

according to CVS this driver (actually it was a connection type of the 
hd44780 driver) has been removed 6 years ago and was only available in 
the 0.4.4 and 0.4.5 releases.

Regards
Markus


From listen at sowas.org  Thu Feb  5 19:30:49 2009
From: listen at sowas.org (Dirk Mueller)
Date: Thu, 5 Feb 2009 20:30:49 +0100
Subject: [Lcdproc] usblcd with lcdproc >= 0.5
In-Reply-To: <498B325A.3050500@nurfuerspam.de>
References: <200902051422.21195.listen@sowas.org>
	<498B325A.3050500@nurfuerspam.de>
Message-ID: <200902052030.50105.listen@sowas.org>

Hi Markus,

> according to CVS this driver (actually it was a connection type of the
> hd44780 driver) has been removed 6 years ago and was only available in
> the 0.4.4 and 0.4.5 releases.

ok, like I assumed.
Do you know why it has been removed?

Thanks

Dirk

P.S. I have 0.4.5 running


From Mark.Vallevand at UNISYS.com  Thu Feb  5 21:27:57 2009
From: Mark.Vallevand at UNISYS.com (Vallevand, Mark K)
Date: Thu, 5 Feb 2009 15:27:57 -0600
Subject: [Lcdproc] Big bug in server/main.c
In-Reply-To: <CE091CB077F4A74A9CBA33A4E4A8A3BF123D5607@USEA-EXCH4.na.uis.unisys.com>
References: <CE091CB077F4A74A9CBA33A4E4A8A3BF123D5607@USEA-EXCH4.na.uis.unisys.com>
Message-ID: <CE091CB077F4A74A9CBA33A4E4A8A3BF125603A7@USEA-EXCH4.na.uis.unisys.com>

Any comments on this bug?  I'd hate to see it get lost.

 

Regards.
Mark K Vallevand

"I got free checking at Bear Stearns!"

THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY
MATERIAL and is thus for use only by the intended recipient. If you
received this in error, please contact the sender and delete the e-mail
and its attachments from all computers.

________________________________

From: lcdproc-bounces at lists.omnipotent.net
[mailto:lcdproc-bounces at lists.omnipotent.net] On Behalf Of Vallevand,
Mark K
Sent: Thursday, January 29, 2009 9:06 AM
To: lcdproc at lists.omnipotent.net
Subject: [Lcdproc] Big bug in server/main.c

 

While testing with my embedded Linux and also on SUSE 11 Linux, I found
that if time goes backwards, LCDd will stall until time catches up.  Try
it.  Set the time back 2 minutes.  For 2 minutes LCDd does nothing.
Here's the fix.

 

server/main.c

813c813

<                        if ((t_diff + 1) > (LONG_MAX / 1e6)) {

---

>                        if ( ((t_diff + 1) > (LONG_MAX / 1e6)) ||
(t_diff<0) ) {

If someone has the time, this really should be rewritten to use
something not based on the time and date of Linux.  But, this fix
suffices and we are now using it.

Regards.
Mark K Vallevand

"I got free checking at Bear Stearns!"

THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY
MATERIAL and is thus for use only by the intended recipient. If you
received this in error, please contact the sender and delete the e-mail
and its attachments from all computers.

 

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

From bsdfan at nurfuerspam.de  Fri Feb  6 07:13:59 2009
From: bsdfan at nurfuerspam.de (Markus Dolze)
Date: Fri, 06 Feb 2009 08:13:59 +0100
Subject: [Lcdproc] Big bug in server/main.c
In-Reply-To: <CE091CB077F4A74A9CBA33A4E4A8A3BF125603A7@USEA-EXCH4.na.uis.unisys.com>
References: <CE091CB077F4A74A9CBA33A4E4A8A3BF123D5607@USEA-EXCH4.na.uis.unisys.com>
	<CE091CB077F4A74A9CBA33A4E4A8A3BF125603A7@USEA-EXCH4.na.uis.unisys.com>
Message-ID: <20090206071359.97450@gmx.net>

-------- Original-Nachricht --------
> Datum: Thu, 5 Feb 2009 15:27:57 -0600
> Von: "Vallevand, Mark K" <Mark.Vallevand at UNISYS.com>
> An: lcdproc at lists.omnipotent.net
> Betreff: Re: [Lcdproc] Big bug in server/main.c

> Any comments on this bug?  I'd hate to see it get lost.
> 

I tested it already and found no problems. Despite that it's pending.

You asked if someone would like to write some time independent code. This will likely not happen as LCDd tries to do its best to create a fixed display refresh rate. This requires timing.

Regards
Markus

From bsdfan at nurfuerspam.de  Fri Feb  6 10:50:34 2009
From: bsdfan at nurfuerspam.de (Markus Dolze)
Date: Fri, 06 Feb 2009 11:50:34 +0100
Subject: [Lcdproc] usblcd with lcdproc >= 0.5
In-Reply-To: <200902052030.50105.listen@sowas.org>
References: <200902051422.21195.listen@sowas.org>
	<498B325A.3050500@nurfuerspam.de> <200902052030.50105.listen@sowas.org>
Message-ID: <20090206105034.136120@gmx.net>

-------- Original-Nachricht --------
> Datum: Thu, 5 Feb 2009 20:30:49 +0100
> Von: Dirk Mueller <listen at sowas.org>
> An: lcdproc at lists.omnipotent.net
> Betreff: Re: [Lcdproc] usblcd with lcdproc >= 0.5

> Hi Markus,
> 
> > according to CVS this driver (actually it was a connection type of the
> > hd44780 driver) has been removed 6 years ago and was only available in
> > the 0.4.4 and 0.4.5 releases.
> 
> ok, like I assumed.
> Do you know why it has been removed?
> 
> Thanks
> 
> Dirk
> 
> P.S. I have 0.4.5 running
> 

Hello Dirk,

after reading more change logs I think it might be an accident. The driver was added to the stable-0-4-4 branch. At that time, the 0.5 line already existed, but the driver was never added to it.

I tried to look up some information in www.usblcd.de but found that all content has been removed. The internet archive shows this happened mid of 2007. So I guess these devices are not sold anymore.

It should not be that hard to resurrect the driver for 0.5.

But maybe someone involved with 0.4 can comment on that?


BTW: The 'anslcd' driver shares the same fate.

Regards
Markus

From listen at sowas.org  Fri Feb  6 11:49:17 2009
From: listen at sowas.org (Dirk Mueller)
Date: Fri, 6 Feb 2009 12:49:17 +0100
Subject: [Lcdproc] usblcd with lcdproc >= 0.5
In-Reply-To: <20090206105034.136120@gmx.net>
References: <200902051422.21195.listen@sowas.org>
	<200902052030.50105.listen@sowas.org>
	<20090206105034.136120@gmx.net>
Message-ID: <200902061249.17913.listen@sowas.org>

Hi Markus,

> after reading more change logs I think it might be an accident. The driver
> was added to the stable-0-4-4 branch. At that time, the 0.5 line already
> existed, but the driver was never added to it.

as far as I know this work was done by the developer of the usb port itself. 
His name is Robin Adams.

> I tried to look up some information in www.usblcd.de but found that all
> content has been removed. The internet archive shows this happened mid of
> 2007. So I guess these devices are not sold anymore.

Looks like only a few people bought this connector.

> It should not be that hard to resurrect the driver for 0.5.

sounds good :-)

Thanks for your help

Dirk



From Mark.Vallevand at UNISYS.com  Fri Feb  6 15:07:31 2009
From: Mark.Vallevand at UNISYS.com (Vallevand, Mark K)
Date: Fri, 6 Feb 2009 09:07:31 -0600
Subject: [Lcdproc] Big bug in server/main.c
In-Reply-To: <20090206071359.97450@gmx.net>
References: <CE091CB077F4A74A9CBA33A4E4A8A3BF123D5607@USEA-EXCH4.na.uis.unisys.com><CE091CB077F4A74A9CBA33A4E4A8A3BF125603A7@USEA-EXCH4.na.uis.unisys.com>
	<20090206071359.97450@gmx.net>
Message-ID: <CE091CB077F4A74A9CBA33A4E4A8A3BF1258F0B4@USEA-EXCH4.na.uis.unisys.com>

Thanks.

I've tried it on two different flavors of Linux with completely
different hardware.  Time goes backwards, LCDd stalls.  It probably is
different on other OSes.  For us, it was really serious.  When LCDd
stalled it cascaded into a series of errors that took lots of time to
figure out.

Thanks again.

Regards.
Mark K Vallevand

"I got free checking at Bear Stearns!"

THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY
MATERIAL and is thus for use only by the intended recipient. If you
received this in error, please contact the sender and delete the e-mail
and its attachments from all computers.


-----Original Message-----
From: lcdproc-bounces at lists.omnipotent.net
[mailto:lcdproc-bounces at lists.omnipotent.net] On Behalf Of Markus Dolze
Sent: Friday, February 06, 2009 1:14 AM
To: Vallevand, Mark K; lcdproc at lists.omnipotent.net
Subject: Re: [Lcdproc] Big bug in server/main.c

-------- Original-Nachricht --------
> Datum: Thu, 5 Feb 2009 15:27:57 -0600
> Von: "Vallevand, Mark K" <Mark.Vallevand at UNISYS.com>
> An: lcdproc at lists.omnipotent.net
> Betreff: Re: [Lcdproc] Big bug in server/main.c

> Any comments on this bug?  I'd hate to see it get lost.
> 

I tested it already and found no problems. Despite that it's pending.

You asked if someone would like to write some time independent code.
This will likely not happen as LCDd tries to do its best to create a
fixed display refresh rate. This requires timing.

Regards
Markus
_______________________________________________
LCDproc mailing list
LCDproc at lists.omnipotent.net
http://lists.omnipotent.net/mailman/listinfo/lcdproc

From andy at siliconlandmark.com  Fri Feb  6 16:08:19 2009
From: andy at siliconlandmark.com (Andre Guibert de Bruet)
Date: Fri, 6 Feb 2009 11:08:19 -0500
Subject: [Lcdproc] Big bug in server/main.c
In-Reply-To: <CE091CB077F4A74A9CBA33A4E4A8A3BF1258F0B4@USEA-EXCH4.na.uis.unisys.com>
References: <CE091CB077F4A74A9CBA33A4E4A8A3BF123D5607@USEA-EXCH4.na.uis.unisys.com><CE091CB077F4A74A9CBA33A4E4A8A3BF125603A7@USEA-EXCH4.na.uis.unisys.com>
	<20090206071359.97450@gmx.net>
	<CE091CB077F4A74A9CBA33A4E4A8A3BF1258F0B4@USEA-EXCH4.na.uis.unisys.com>
Message-ID: <2932C589-B9B5-494B-89D2-864B5DDE7F6E@siliconlandmark.com>

On Feb 6, 2009, at 10:07 AM, Vallevand, Mark K wrote:

> I've tried it on two different flavors of Linux with completely
> different hardware.  Time goes backwards, LCDd stalls.  It probably is
> different on other OSes.  For us, it was really serious.  When LCDd
> stalled it cascaded into a series of errors that took lots of time to
> figure out.

Your patch appears to address this particular issue.

What is worrisome about the scenario that you have brought forward is  
that time generally never runs backwards, unless you use something  
other than ntpd to adjust the hardware clock (ntpd skews the clock).  
Is the sporadic availability of a "reliable" time source (Such as an  
NTP server or a user keying in "current time") an inherent integration  
constraint?

Cheers,
Andy

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

From Mark.Vallevand at UNISYS.com  Fri Feb  6 17:10:36 2009
From: Mark.Vallevand at UNISYS.com (Vallevand, Mark K)
Date: Fri, 6 Feb 2009 11:10:36 -0600
Subject: [Lcdproc] Big bug in server/main.c
In-Reply-To: <2932C589-B9B5-494B-89D2-864B5DDE7F6E@siliconlandmark.com>
References: <CE091CB077F4A74A9CBA33A4E4A8A3BF123D5607@USEA-EXCH4.na.uis.unisys.com><CE091CB077F4A74A9CBA33A4E4A8A3BF125603A7@USEA-EXCH4.na.uis.unisys.com>
	<20090206071359.97450@gmx.net>
	<CE091CB077F4A74A9CBA33A4E4A8A3BF1258F0B4@USEA-EXCH4.na.uis.unisys.com>
	<2932C589-B9B5-494B-89D2-864B5DDE7F6E@siliconlandmark.com>
Message-ID: <CE091CB077F4A74A9CBA33A4E4A8A3BF1258F50F@USEA-EXCH4.na.uis.unisys.com>

We are using lcdproc on an embedded Linux system.  Lots of 'normal'
things just aren't there.  Using ntpd or any other software to skew time
can't be done.  Our time must be sync'd to the time in an external
source and our software just sets that time into Linux at a certain
point in our processing.  We just use the time for logging and certainly
don't code to use the current time for any measurements.

I was surprised that lcdproc used the time in this way.  I expected
something like clock(), but perhaps there are reasons for doing it as
its done.  I'm just glad I found it.

The serious issue wasn't LCDd stalling as much as the way sockets was
working.  In some cases the recvfrom() function generates a signal when
a shutdown() is done from the other end.  We didn't handle the signal.
The default action for that particular signal was to terminate the
program.  So, one of our programs terminated when LCDd woke up and
shutdown() the socket.  And, while time was 'catching up' the LCD
screens and menu system didn't respond.  Since our LCD isn't regularly
used, no one cared much about that.  But, when one of our programs
crashed, we stopped doing our function and that got lots of attention.

Regards.
Mark K Vallevand

"I got free checking at Bear Stearns!"

THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY
MATERIAL and is thus for use only by the intended recipient. If you
received this in error, please contact the sender and delete the e-mail
and its attachments from all computers.


-----Original Message-----
From: Andre Guibert de Bruet [mailto:andy at siliconlandmark.com] 
Sent: Friday, February 06, 2009 10:08 AM
To: Vallevand, Mark K
Cc: lcdproc at lists.omnipotent.net
Subject: Re: [Lcdproc] Big bug in server/main.c

On Feb 6, 2009, at 10:07 AM, Vallevand, Mark K wrote:

> I've tried it on two different flavors of Linux with completely
> different hardware.  Time goes backwards, LCDd stalls.  It probably is
> different on other OSes.  For us, it was really serious.  When LCDd
> stalled it cascaded into a series of errors that took lots of time to
> figure out.

Your patch appears to address this particular issue.

What is worrisome about the scenario that you have brought forward is  
that time generally never runs backwards, unless you use something  
other than ntpd to adjust the hardware clock (ntpd skews the clock).  
Is the sporadic availability of a "reliable" time source (Such as an  
NTP server or a user keying in "current time") an inherent integration  
constraint?

Cheers,
Andy

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

From listen at sowas.org  Sat Feb  7 15:47:24 2009
From: listen at sowas.org (Dirk Mueller)
Date: Sat, 7 Feb 2009 16:47:24 +0100
Subject: [Lcdproc] usblcd with lcdproc >= 0.5
In-Reply-To: <20090207104033.190730@gmx.net>
References: <200902051422.21195.listen@sowas.org>
	<200902061249.17913.listen@sowas.org>
	<20090207104033.190730@gmx.net>
Message-ID: <200902071647.24181.listen@sowas.org>

Hi Markus,

> attached you will find the usblcd driver modified for the cvs version of
> lcdproc.
>
> The patch compiles, but I cannot test with a real display. Therefore I
> appreciate your help. Please report back if the driver works for you.

thanks a lot for the patch. I just tested it and I have now a working version 
of LCDproc 0.5dev with usblcd.

Do need more information before applying this patch to the current version?

Best regards

Dirk



From bsdfan at nurfuerspam.de  Sat Feb  7 21:54:41 2009
From: bsdfan at nurfuerspam.de (Markus Dolze)
Date: Sat, 07 Feb 2009 22:54:41 +0100
Subject: [Lcdproc] usblcd with lcdproc >= 0.5
In-Reply-To: <200902071647.24181.listen@sowas.org>
References: <200902051422.21195.listen@sowas.org>
	<200902061249.17913.listen@sowas.org>	<20090207104033.190730@gmx.net>
	<200902071647.24181.listen@sowas.org>
Message-ID: <20090207215441.114770@gmx.net>

-------- Original-Nachricht --------
> Datum: Sat, 7 Feb 2009 16:47:24 +0100
> Von: Dirk Mueller <listen at sowas.org>
> An: lcdproc at lists.omnipotent.net
> Betreff: Re: [Lcdproc] usblcd with lcdproc >= 0.5

> Hi Markus,
> 
> > attached you will find the usblcd driver modified for the cvs version of
> > lcdproc.
> >
> > The patch compiles, but I cannot test with a real display. Therefore I
> > appreciate your help. Please report back if the driver works for you.
> 
> thanks a lot for the patch. I just tested it and I have now a working
> version 
> of LCDproc 0.5dev with usblcd.

This is good news.

> 
> Do need more information before applying this patch to the current
> version?
> 

I will submit it for review to the mailing list within the next days. But I have to update the documentation before.

Regards,
Markus

From ethan.dicks at gmail.com  Sat Feb  7 23:27:05 2009
From: ethan.dicks at gmail.com (Ethan Dicks)
Date: Sat, 7 Feb 2009 18:27:05 -0500
Subject: [Lcdproc] New drivers for Hyundai HG12603 / JW-002 24x8
Message-ID: <f4eb766f0902071527x432057c7jfc8c05e9284ea576@mail.gmail.com>

All,

I have my new JW-002 driver code cleaned up to the point where I want
to submit a first cut.  For those that don't happen to have one of
these, it appears to be originally from an AT&T/Lucent telephone
product, but gained fame about 5-6 years ago as an inexpensive
large-format textual display sold as a bare surplus item, or as an
attachment to homemade MP3 player, the PJRC.

The attached driver handles the basic 24x8 display formatting, the
built-in LED as an "output", hbars, vbars, the optional 12-key keypad,
and bignums.  The display itself is implemented with a lot of local
RAM and a graphic (KS107) controller, so it can, in effect, have as
many user-definable characters as desired.  I've implemented the
driver with 28 defined user-definable characters to work with, for an
as-yet-unposted patch to the bignum library to give this display a
much smoother bignum implementation than is possible with 7-8 user
definable characters (such as any HD44780-based display).  Down the
road, I'd like to add code to this driver to allow it to be used as
8x24 _and_ 24x8 (portrait mode and landscape mode), but if I don't get
something out now, who knows when I'll get things "done" enough to
post.

Here's a few links for the curious:

  <http://www.pjrc.com/store/mp3_display.html>
  <http://www.pjrc.com/tech/mp3/index.html>
  <http://www.pjrc.com/tech/mp3/firmware.html>
  <http://www.pjrc.com/tech/mp3/pushbutton_info.html>
  <http://www.pjrc.com/tech/mp3/lcd_protocol.html>

I doubt anyone else will be able to test this, but if you _do_ have a
JW-002 display, give it a whirl.   If a display this size is
appealing, I have one or two spares I could sell, or you could buy a
complete display with keypad and replacement firmware from the PJRC
links above.

I am attaching patches against a recent CVS HEAD fetch.

It's been a while since I've submitted code for an entire driver, so
please let me know if I've forgotten anything, and I can submit what
is required.

-ethan
-------------- next part --------------
/*
    This is the LCDproc driver for Hyundai HG12603A equipped with
    PJRC firmware (http://www.pjrc.com/tech/mp3/pushbutton_info.html)

    The HG12603(A) is a 2"x4" LCD panel with a Samsung KS107B controller,
    driven by an on-board 8051-family microcontroller.  Normally, the
    KS107B would make this a graphical LCD, but the actual pixels on
    the glass are diced up into 8 lines of 24 5x7 character areas. 

    This LCD module seems to have originally been used in some sort of
    AT&T telephone product, but has been available for a number of years
    in the surplus channel, typically selling for between $20 and $50,
    depending on quantity and if it was being sold as a bare module or
    with the necessary circuitry to interface to a host machine.

    The most visible use of this LCD module has been the PJRC MP3 player
    (http://www.pjrc.com/tech/mp3/index.html).  The original AT&T firmware
    was severely limited as to what it could do.  Paul Stoffregen of PJRC
    has made replacement firmware available in the public domain.  Owners
    of "stock" HG12603A modules (also sold as "JW-002" modules) can either
    download Paul's firmware from his site and burn their own chips, or
    more simply, purchase a chip ready to drop into a stock display.

    The PJRC firmware takes care of the command set, but the module itself
    needs a few external components added to it for easy PC use.  The
    HG12603A requires a Vee of about -7V for LCD contrast.  In addition,
    the serial interface to the 8051 microcontroller is at TTL levels
    (0 and +5VDC), not RS-232 levels (+/- 3-12VDC).  Fortunately, it's
    easy to tap off the charge pump caps of an ordinary MAX232A chip for
    Vee, making the interface a single chip and a few caps.  As a bonus.
    the PJRC software uses the 8051 I/O lines present on the 17-pin
    connector to scan a 3x4 keypad matrix.

    Paul has also made the schematics to a level shifter/Vee supply/keypad
    available on his website - http://www.pjrc.com/tech/mp3/pushbutton_info.html
    If you have your own HG12603A/JW-002 module, you can roll your own,
    or, as of this writing, it's still possible to buy a ready-to-plug-in
    LCD module *with* a "pushbutton adaptor board" and cables directly
    from PJRC - http://www.pjrc.com/store/mp3_display.html

    While the PJRC display was really designed to work hand-in-hand with
    the PJRC MP3 player, an intelligent, serially interfaced, 8x24 character
    display with 12 buttons is a luxury compared to the standard LCDproc
    4x20 display with 0-5 buttons.


    Applicable external links:
    - http://www.pjrc.com/tech/mp3/index.html
    - http://www.pjrc.com/store/mp3_display.html
    - http://www.pjrc.com/tech/mp3/firmware.html
    - http://www.pjrc.com/tech/mp3/lcd_protocol.html

    Copyright (C) 2008, 2009, Ethan Dicks

    This program is free software; you can redistribute it and/or modify
    it under the terms of the GNU General Public License as published by
    the Free Software Foundation; either version 2 of the License, or
    any later version.

    This program is distributed in the hope that it will be useful,
    but WITHOUT ANY WARRANTY; without even the implied warranty of
    MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
    GNU General Public License for more details.

    You should have received a copy of the GNU General Public License
    along with this program; if not, write to the Free Software
    Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301
*/

#include <stdlib.h>
#include <stdio.h>
#include <unistd.h>
#include <sys/types.h>
#include <sys/time.h>
#include <termios.h>
#include <fcntl.h>
#include <string.h>
#include <errno.h>
#include <syslog.h>
#include <ctype.h>
#include <sys/poll.h>

#ifdef HAVE_CONFIG_H
# include "config.h"
#endif

#include "lcd.h"
#include "lcd_lib.h"
#include "jw002.h"
#include "adv_bignum.h"

#include "report.h"


/* PJRC firmware supports an optional 3x4 keypad matrix */
#define MAX_KEY_MAP	12

// Don't forget to define key mappings in LCDd.conf: KeyMap_A=Enter, ...
// otherwise you will not get your keypad working.

/*
 * The JW-002 driver depends on the four standard firmware fonts
 * to implement vbar, hbar, and bignum.  None of the standard fonts
 * happen to have the standard LCDproc heartbeat chars, so we define
 * those ourselves.
 *
 * For the same reason, we don't use the hardware clear but rather
 * empty the internal frame buffer.  The frame buffer holds all
 * the requested changes until the server asks us to flush the
 * changes to the display.  This also permits us to do an
 * incremental update and reduce the number of characters to be
 * sent to the display across the serial link.
 *
 * In order to display graphic widgets, we define and use our own
 * custom characters.  To avoid multiple definitions of the same
 * custom characters, we use a caching mechanism that remembers
 * what is currently defined.  In order to avoid always redefining
 * the same custom character at the beginning of the table, we
 * rotate the beginning of the table.  This is supposed to reduce
 * the number of character redefinitions and make the caching more
 * effective.  The overall goal is to reduce the number of
 * characters sent to the display.
 *
 * (TODO: a totally custom RAM-resident font that gets loaded once)
 */


/* Constants for userdefchar_mode */
#define NUM_CCs		28   // max. number of custom characters
#define CC_OFFSET	192  // first custom char

typedef enum {
	standard,	/* only char 0 is used for heartbeat */
	vbar,		/* vertical bars */
	hbar,		/* horizontal bars */
	custom,		/* custom settings */
	bignum,		/* big numbers */
	bigchar		/* big characters */
} CGmode;


typedef struct {
	int fd;			/* The LCD file descriptor */
	
	/* dimensions */
	int width, height;
	int cellwidth, cellheight;
	int xoff, yoff;

	/* framebuffer and buffer for old LCD contents */
	unsigned char *framebuf;
	unsigned char *backingstore;

	/* defineable characters */
	CGmode ccmode;
	int font;		/* font number */

	int output_state;	/* static data from jw002_output */
	int contrast;		/* static data from set/get_contrast */
	int brightness;
	int offbrightness;

	/* the keymap */
	char *keymap[MAX_KEY_MAP];
	int keys;
	int keypad_test_mode;

	char info[255];		/* static data from jw002_get_info */
} PrivateData;


/* Vars for the server core */
MODULE_EXPORT char *api_version = API_VERSION;
MODULE_EXPORT int stay_in_foreground = 0;
MODULE_EXPORT int supports_multiple = 1;
MODULE_EXPORT char *symbol_prefix = "jw002_";

static void jw002_hardware_clear(Driver *drvthis);
static void jw002_linewrap(Driver *drvthis, int on);
static void jw002_autoscroll(Driver *drvthis, int on);
//static void jw002_cursorblink(Driver *drvthis, int on);
static void jw002_cursor_goto(Driver *drvthis, int x, int y);


/* Parse one key from the configfile */
static char
jw002_parse_keypad_setting (Driver *drvthis, char *keyname, char default_value)
{
	char return_val = 0;
	const char *s;
	char buf[255];

	s = drvthis->config_get_string(drvthis->name, keyname, 0, NULL);
	if (s != NULL) {
		strncpy(buf, s, sizeof(buf));
		buf[sizeof(buf)-1] = '\0';
		return_val = buf[0];
	} else {
		return_val = default_value;
	}
	return return_val;
}


/**
 * Initialize the driver.
 * \param drvthis  Pointer to driver structure.
 * \retval 0   Success.
 * \retval <0  Error.
 */
MODULE_EXPORT int
jw002_init (Driver *drvthis)
{
	struct termios portset;

	char device[256] = DEFAULT_DEVICE;
	int speed = DEFAULT_SPEED;
	char size[256] = DEFAULT_SIZE;
	int tmp, w, h, xoff, yoff;

        PrivateData *p;

	/* Alocate and store private data */
        p = (PrivateData *) malloc(sizeof(PrivateData));
	if (p == NULL)
	        return -1;
	if (drvthis->store_private_ptr(drvthis, p))
	        return -1;

	/* Initialise the PrivateData structure */
	p->fd = -1;

	p->width      = JW002_DEFAULT_WIDTH;
	p->height     = JW002_DEFAULT_HEIGHT;
	p->cellwidth  = JW002_DEFAULT_CELLWIDTH;
	p->cellheight = JW002_DEFAULT_CELLHEIGHT;

	p->framebuf = NULL;
	p->backingstore = NULL;

	p->output_state = -1;	/* static data from jw002_output */
	p->keypad_test_mode = 0;

	debug(RPT_INFO, "jw002: init(%p)", drvthis);

	/* READ CONFIG FILE */

	/* Get serial device to use */
	strncpy(device, drvthis->config_get_string(drvthis->name, "Device", 0, DEFAULT_DEVICE), sizeof(device));
	device[sizeof(device)-1] = '\0';
	report(RPT_INFO, "%s: using Device %s", drvthis->name, device);

	/* Get display size */
	strncpy(size, drvthis->config_get_string(drvthis->name, "Size", 0, DEFAULT_SIZE), sizeof(size));
	size[sizeof(size)-1] = '\0';
	if ((sscanf(size, "%dx%d", &w, &h) != 2)
	    || (w <= 0) || (w > LCD_MAX_WIDTH)
	    || (h <= 0) || (h > LCD_MAX_HEIGHT)) {
		report(RPT_WARNING, "%s: cannot read Size: %s; using default %s",
				drvthis->name, size, DEFAULT_SIZE);
		sscanf(DEFAULT_SIZE , "%dx%d", &w, &h);
	}
	p->width = w;
	p->height = h;

	/* Get font number (0-3 are ROM fonts, 4-31 are RAM fonts) */
	tmp = drvthis->config_get_int(drvthis->name, "Font", 0, JW002_DEFAULT_FONT);
	if (tmp < 0 || tmp >= JW002_MAX_FONT) {
		report(RPT_WARNING, "%s: Font numbers range from 0-31.  Font number %d is invalid; using font 0",
				drvthis->name, tmp);

		tmp = 0;
	}
	p->font = tmp;

// jw-002 interface speed is compiled into the firmware - default is 19200
	/* Get speed */
	tmp = drvthis->config_get_int(drvthis->name, "Speed", 0, DEFAULT_SPEED);
	switch (tmp) {
		case 1200:
			speed = B1200;
			break;
		case 2400:
			speed = B2400;
			break;
		case 9600:
			speed = B9600;
			break;
		case 19200:
			speed = B19200;
			break;
		default:
			speed = B19200;
			report(RPT_WARNING, "%s: Speed must be 1200, 2400, 9600 or 19200; using default %d",
					drvthis->name, tmp);
	}

	/* Get keypad settings */

	/* Get offsets */
	xoff = drvthis->config_get_int(drvthis->name, "X_offset", 0, DEFAULT_XOFFSET);
	yoff = drvthis->config_get_int(drvthis->name, "Y_offset", 0, DEFAULT_YOFFSET);

	if (xoff < 0 || xoff + p->width > LCD_MAX_WIDTH) {
		report(RPT_WARNING, "%s:  X offset of %d invalid.  Ignoring X offset request",
				drvthis->name, xoff);
		xoff = 0;
	}

	if (yoff < 0 || yoff + p->height > LCD_MAX_HEIGHT) {
		report(RPT_WARNING, "%s:  Y offset of %d invalid.  Ignoring Y offset request",
				drvthis->name, xoff);
		yoff = 0;
	}
	p->xoff = xoff;
	p->yoff = yoff;

	/* keypad test mode? */
	if (drvthis->config_get_bool(drvthis->name, "keypad_test_mode", 0, 0)) {
		fprintf(stdout, "jw-002: Entering keypad test mode...\n");
		p->keypad_test_mode = 1;
		stay_in_foreground = 1;
	}

	if (!p->keypad_test_mode) {
		/* We don't send any chars to the server in keypad test mode.
		 * So there's no need to get them from the configfile in keypad
		 * test mode.
		 */

		int i;

		/* assume no mapped keys */
		p->keys = 0;

		/* read the keymap */
		for (i = 0; i < MAX_KEY_MAP; i++) {
			char buf[40];
			const char *s;

			/* First fill with NULL; */
			p->keymap[i] = NULL;

			/* Read config value */
			sprintf(buf, "KeyMap_%c", i+'A');
			s = drvthis->config_get_string(drvthis->name, buf, 0, NULL);

			/* Was a key specified in the config file ? */
			if (s != NULL) {
				p->keys++;
				p->keymap[i] = strdup(s);
				report(RPT_INFO, "%s: Key '%c' mapped to \"%s\"",
					drvthis->name, i+'A', s );
			}
		}
	}
	/* End of config file parsing */

	/* Set up io port correctly, and open it... */
//	p->fd = open(device, O_RDWR | O_NOCTTY);
	p->fd = open(device, O_RDWR | O_NOCTTY | O_NDELAY);
	if (p->fd == -1) {
		report(RPT_ERR, "%s: open(%s) failed (%s)", drvthis->name, device, strerror(errno));
		if (errno == EACCES)
			report(RPT_ERR, "%s: %s device could not be opened...", drvthis->name, device);
  		return -1;
	}
	report(RPT_INFO, "%s: opened display on %s", drvthis->name, device);

	tcgetattr(p->fd, &portset);

	// THIS ALL COMMENTED OUT BECAUSE WE NEED TO SET TIMEOUTS
	/* We use RAW mode */
#ifdef HAVE_CFMAKERAW_NOT
	/* The easy way */
	cfmakeraw(&portset);
#else
	/* The hard way */
	portset.c_iflag &= ~( IGNBRK | BRKINT | PARMRK | ISTRIP
	                      | INLCR | IGNCR | ICRNL | IXON );
	portset.c_oflag &= ~OPOST;
	portset.c_lflag &= ~( ECHO | ECHONL | ICANON | ISIG | IEXTEN );
	portset.c_cflag &= ~( CSIZE | PARENB | CRTSCTS );
	portset.c_cflag |= CS8 | CREAD | CLOCAL;
	portset.c_cc[VMIN] = 1;
	portset.c_cc[VTIME] = 3;
#endif

	/* Set port speed */
	cfsetospeed(&portset, speed);
	cfsetispeed(&portset, B0);

	/* Do it... */
	tcsetattr(p->fd, TCSANOW, &portset);

	/* Make sure the frame buffer is there... */
	p->framebuf = (unsigned char *) calloc(p->width * p->height, 1);
	if (p->framebuf == NULL) {
		report(RPT_ERR, "%s: unable to create framebuffer", drvthis->name);
		return -1;
	}
	memset(p->framebuf, ' ', p->width * p->height);

	/* make sure the framebuffer backing store is there... */
	p->backingstore = (unsigned char *) malloc(p->width * p->height);
	if (p->backingstore == NULL) {
		report(RPT_ERR, "%s: unable to create framebuffer backing store", drvthis->name);
		return -1;
	}
	memset(p->backingstore, ' ', p->width * p->height);

	/* set initial LCD configuration */
	jw002_init_keys(drvthis);
	jw002_hardware_clear(drvthis);  // clear screen and set font from p->font
	jw002_linewrap(drvthis, 0);  // turn off linewrap _and_ autoscroll

	report(RPT_DEBUG, "%s: init() done", drvthis->name);

	return 1;
}


/**
 * Close the driver (do necessary clean-up).
 * \param drvthis  Pointer to driver structure.
 */
MODULE_EXPORT void
jw002_close (Driver *drvthis)
{
        PrivateData *p = drvthis->private_data;

	if (p != NULL) {
		if (p->fd >= 0)
			close(p->fd);

		if (p->framebuf)
			free(p->framebuf);
		p->framebuf = NULL;

		if (p->backingstore)
			free(p->backingstore);
		p->backingstore = NULL;

        	free(p);
	}	
	drvthis->store_private_ptr(drvthis, NULL);
	debug(RPT_DEBUG, "jw002: closed");
}


/**
 * Return the display width in characters.
 * \param drvthis  Pointer to driver structure.
 * \return  Number of characters the display is wide.
 */
MODULE_EXPORT int
jw002_width (Driver *drvthis)
{
        PrivateData *p = drvthis->private_data;

        return p->width;
}


/**
 * Return the display height in characters.
 * \param drvthis  Pointer to driver structure.
 * \return  Number of characters the display is high.
 */
MODULE_EXPORT int
jw002_height (Driver *drvthis)
{
        PrivateData *p = drvthis->private_data;

	return p->height;
}


/**
 * Return the width of a character in pixels.
 * \param drvthis  Pointer to driver structure.
 * \return  Number of pixel columns a character cell is wide.
 */
MODULE_EXPORT int
jw002_cellwidth (Driver *drvthis)
{
	PrivateData *p = drvthis->private_data;

	return p->cellwidth;
}


/**
 * Return the height of a character in pixels.
 * \param drvthis  Pointer to driver structure.
 * \return  Number of pixel lines a character cell is high.
 */
MODULE_EXPORT int
jw002_cellheight (Driver *drvthis)
{
	PrivateData *p = drvthis->private_data;

	return p->cellheight;
}


/**
 * Print a string on the screen at position (x,y).
 * The upper-left corner is (1,1), the lower-right corner is (p->width, p->height).
 * \param drvthis  Pointer to driver structure.
 * \param x        Horizontal character position (column).
 * \param y        Vertical character position (row).
 * \param string   String that gets written.
 */
MODULE_EXPORT void
jw002_string (Driver *drvthis, int x, int y, const char string[])
{
	PrivateData *p = drvthis->private_data;
	int i;

	/* Convert 1-based coords to 0-based... */
	x--;
	y--;

	if ((y < 0) || (y >= p->height))
		return;

	for (i = 0; (string[i] != '\0') && (x < p->width); i++, x++) {
		/* Check for buffer overflows... */
		if (x >= 0)
			p->framebuf[(y * p->width) + x] = string[i];
	}

	debug(RPT_DEBUG, "jw002: printed string at (%d,%d)", x, y);
}


/**
 * Clear the screen.
 * \param drvthis  Pointer to driver structure.
 */
MODULE_EXPORT void
jw002_clear (Driver *drvthis)
{
        PrivateData *p = drvthis->private_data;

	/* set hbar/vbar/bignum mode back to normal character display */
	p->ccmode = standard;

	/* replace all chars in framebuf with spaces */
	memset(p->framebuf, ' ', (p->width * p->height));

	/* make backing store differ from framebuf so it all gets cleared by jw002_flush */
	//memset(p->backingstore, 0xFE, (p->width * p->height));

	debug(RPT_DEBUG, "jw002: cleared screen");
}


/**
 * Flush data on screen to the LCD.
 * \param drvthis  Pointer to driver structure.
 *
 * The one possible trick is that we want to display chars 0-5 here (for
 * hbars), which could be interpreted as control chars.  The technique
 * for printing out low chars is...
 *
 * Display Byte 0 to 31
 *   Some control characters (ascii 0 to 31) have special functions, and if
 *   a PC terminal emulation program is also receiving the communication, it
 *   may respond to control characters. To cause the board to display
 *   characters 0 to 31, send a 0x5C followed by the control character plus 32.
 */

MODULE_EXPORT void
jw002_flush (Driver *drvthis)
{
        PrivateData *p = drvthis->private_data;
	int modified = 0;
	int i, j;

	for (i = 0; i < p->height; i++) {
		// set  pointers to start of the line in frame buffer & backing store
		unsigned char *sp = p->framebuf + (i * p->width);
		unsigned char *sq = p->backingstore + (i * p->width);

		// set  pointers to end of the line in frame buffer & backing store
		unsigned char *ep = sp + (p->width - 1);
		unsigned char *eq = sq + (p->width - 1);
		int length = 0;

		debug(RPT_DEBUG, "Framebuf: '%.*s'", p->width, sp);
		debug(RPT_DEBUG, "Backingstore: '%.*s'", p->width, sq);

		/* Strategy:
		 * - not more than one update command per line
		 * - leave out leading and trailing parts that are identical
		 */

		// skip over leading identical portions of the line
		for (j = 0; (sp <= ep) && (*sp == *sq); sp++, sq++, j++)
			;

		// skip over trailing identical portions of the line
		for (length = p->width - j; (length > 0) && (*ep == *eq); ep--, eq--, length--)
			;

		/* there are differences, ... */
		if (length > 0) {
			unsigned char out[length+2];
			unsigned char safeout[length+2 * 2]; // room to include escape char for out-of-band chars
			unsigned char rawchar;

			memcpy(out, sp, length);

			unsigned char *rawp, *safep;  // point to each of our two line buffers
			rawp = out;
			safep = safeout;
			while (rawp < out + length) {
				// grab a char and check to see if it's "printable" or not
				rawchar = *rawp++;
				// look for 0x5C, 0x00-0x1F, 0x80-0x9F
				if (rawchar == 0x5C || rawchar < 0x20 || (rawchar > 0x7F && rawchar < 0xA0) ) {
					*safep++ = 0x5C;  // throw in escape char
					if (rawchar < 0x20) {
						rawchar += 0x20;  // scoot low chars up to printable range
					}
					if (rawchar > 0x7F) {
						rawchar -= 0x20;  // scoot down high chars down to printable range
					}
				}
				*safep++ = rawchar;  // copy char to output buffer
			}

			debug(RPT_DEBUG, "%s: l=%d c=%d count=%d string='%.*s'",
			      __FUNCTION__, i, j, length, length, sp);

			jw002_cursor_goto(drvthis, j+1, i+1);

			length = safep - safeout;  // new length is however many chars we wrote to our OOB buffer
			write(p->fd, safeout, length);
			modified++;
		}      
	}	// i < p->height

	if (modified)
		memcpy(p->backingstore, p->framebuf, p->width * p->height);

	debug(RPT_DEBUG, "jw002: frame buffer flushed");
}


/**
 * Print a character on the screen at position (x,y).
 * The upper-left corner is (1,1), the lower-right corner is (p->width, p->height).
 * \param drvthis  Pointer to driver structure.
 * \param x        Horizontal character position (column).
 * \param y        Vertical character position (row).
 * \param c        Character that gets written.
 */
MODULE_EXPORT void
jw002_chr (Driver *drvthis, int x, int y, char c)
{
        PrivateData *p = drvthis->private_data;

	/* Convert 1-based coords to 0-based... */
	x--;
	y--;

	if ((x >= 0) && (y >= 0) && (x < p->width) && (y < p->height))
	                p->framebuf[(y * p->width) + x] = c;

	debug(RPT_DEBUG, "writing character %02X to position (%d,%d)", c, x, y);
}

/**
 * Set output port(s).
 *
 *  External input/output control (protocol version 1 and later only)
 *     Control extra I/O on CPU. All signals are active low, electrical
 *     ground is active '1', electrical 5V is inactive '0'. (refer to
 *     Tom's LCD Modification page for more information.
 *
 *     http://www.wiresncode.com/projects/pjrcmp3/display-mods/
 *
 *  Transmit:
 *      0x5C 0x4A <command> <state>
 *      command = '0' control LED on front panel
 *      command = '1' control pin 7 on CPU (use with care, may crash non-modified hardware)
 *      command = '2' control pin 8 on CPU (use with care, may crash non-modified hardware)
 *      command = '4' read LED on front panel (will turn led off and always read '0')
 *      command = '5' read pin 7 on CPU (will always read '0' on non-modified hardware)
 *      command = '6' read pin 8 on CPU (will always read '0' on non-modified hardware)
 *      state = '0' for inactive (electrical 5V)
 *      state = '1' for active (electrical ground)
 *      (state is ignored for read, but must be supplied)
 *
 * \param drvthis  Pointer to driver structure.
 * \param state    Integer with bits representing port states.
 */
MODULE_EXPORT void
jw002_output (Driver *drvthis, int state)
{
        PrivateData *p = drvthis->private_data;
        unsigned char out[5] = { '\\', 'J', '0', '0' };  // pre-load with LED "off" msg

	/* only deal with main LED (bit 1) */
	if (state < 2) {
		// remember the state
		p->output_state = state;

		// set up the output command
		out[3] = (state & 1) ? '1' : '0';

		// send command to jw002 and log that we did it
        	debug(RPT_DEBUG, "jw002: setting LED to %d", state & 1);
		// //write(p->fd, out, 4);


	} else {
		/* throw a debug msg if they are trying to manipulate control pins 7 or 8 */
		debug(RPT_DEBUG, "jw002: output control requires a modified LCD module");
	}
}


/**
 * Clear the LCD using its hardware command
 * \param drvthis  Pointer to driver structure.
 */
static void
jw002_hardware_clear (Driver *drvthis)
{
        PrivateData *p = drvthis->private_data;

	unsigned char out[4] = { '\\', '@', ' ', '0' };

	out[2] = p->font + 32;  // font numbers must be shifted to printable chars

	write(p->fd, out, 4); // clear and select font 0

	debug(RPT_DEBUG, "jw002: cleared LCD and switched to font %d", p->font);
}


/**
 * Turn the LCD's built-in linewrapping feature on or off.
 * \param drvthis  Pointer to driver structure.
 * \param on       New state.
 */
static void
jw002_linewrap (Driver *drvthis, int on)
{
        PrivateData *p = drvthis->private_data;
	unsigned char out[4] = { '\\', 'A', 0, 0 };

	out[2] = (on) ? '3' : '0';  // wrap _and_ scroll on or off
	write(p->fd, out, 3);

	debug(RPT_DEBUG, "jw002: linewrap turned %s", (on) ? "on" : "off");
}


/**
 * Turn the LCD's built-in automatic scrolling feature on or off.
 * \param drvthis  Pointer to driver structure.
 * \param on       New state.
 */
static void
jw002_autoscroll (Driver *drvthis, int on)
{
        PrivateData *p = drvthis->private_data;
	unsigned char out[4] = { '\\', 'A', 0, 0 };

	out[2] = (on) ? '3' : '0';  // wrap _and_ scroll on or off
	write(p->fd, out, 3);

	debug(RPT_DEBUG, "jw002: autoscroll turned %s", (on) ? "on" : "off");
}


/**
 * Move cursor to position (x,y).
 * \param drvthis  Pointer to driver structure.
 * \param x        Horizontal character position (column).
 * \param y        Vertical character position (row).
 */
static void
jw002_cursor_goto(Driver *drvthis, int x, int y)
{
	PrivateData *p = drvthis->private_data;
	unsigned char out[5] = { '\\', 'B', 0, 0 };

	x--; // turn 1-based coords back into 0-based coords
	y--;
	/* set cursor position */
	if ((x >= 0) && (x < p->width))
		out[2] = (unsigned char) x + p->xoff + 0x20;  // shift values above cntrl chars
	if ((y >= 0) && (y < p->height))
		out[3] = (unsigned char) y + p->yoff + 0x20;  // shift values above cntrl chars
	write(p->fd, out, 4);
}


/**
 * Provide general information about the LCD/VFD display.
 * \param drvthis  Pointer to driver structure.
 * \return  Constant string with information.
 */
MODULE_EXPORT const char *
jw002_get_info (Driver *drvthis)
{
        PrivateData *p = drvthis->private_data;

	debug(RPT_DEBUG, "jw002: get_info");

	memset(p->info, '\0', sizeof(p->info));
	strcpy(p->info, "JW-002 Driver ");

	return p->info;
}


/**
 * Draw a vertical bar bottom-up.
 * \param drvthis  Pointer to driver structure.
 * \param x        Horizontal character position (column) of the starting point.
 * \param y        Vertical character position (row) of the starting point.
 * \param len      Number of characters that the bar is high at 100%
 * \param promille Current height level of the bar in promille.
 * \param options  Options (currently unused).
 */
MODULE_EXPORT void
jw002_vbar (Driver *drvthis, int x, int y, int len, int promille, int options)
{
#define ROMBARS

#ifndef ROMBARS
	PrivateData *p = drvthis->private_data;

	if (p->ccmode != vbar) {
		unsigned char vBar[p->cellheight];
		int i;

		if (p->ccmode != standard) {
			/* Not supported(yet) */
			report(RPT_WARNING, "%s: vbar: cannot combine two modes using user-defined characters",
					drvthis->name);
			return;
		}
		p->ccmode = vbar;

		memset(vBar, 0x00, sizeof(vBar));

		for (i = 1; i <= p->cellheight; i++) {
			// add pixel line per pixel line ...
			vBar[p->cellheight - i] = 0xFF;
			jw002_set_char(drvthis, i+CC_OFFSET, vBar);
		}
	}

	lib_vbar_static(drvthis, x, y, len, promille, options, p->cellheight, CC_OFFSET);

#else
	PrivateData *p = drvthis->private_data;

	int cellheight = p->cellheight; // quick hack to get hbars working

        int total_pixels  = ((long) 2 * len * cellheight + 1 ) * promille / 2000;
        int pos;

        for (pos = 0; pos < len; pos++ ) {

                int pixels = total_pixels - cellheight * pos;

                if ( pixels >= cellheight ) {
                        /* write a "full" block to the screen... */
                        drvthis->icon (drvthis, x, y - pos, ICON_BLOCK_FILLED);
                }
                else if ( pixels > 0 ) {
                        /* write a partial block... */
                        drvthis->chr (drvthis, x, y - pos, (cellheight - pixels) + 136);
                        break;
                }
                else {
                        ; /* write nothing (not even a space) */
                }
        }
#endif

}


/**
 * Draw a horizontal bar to the right.
 * \param drvthis  Pointer to driver structure.
 * \param x        Horizontal character position (column) of the starting point.
 * \param y        Vertical character position (row) of the starting point.
 * \param len      Number of characters that the bar is long at 100%
 * \param promille Current length level of the bar in promille.
 * \param options  Options (currently unused).
 *
 * For the JW-002, the first 6 chars of Font 0 happen to contain vertical
 * lines of 0, 1, 2, 3, 4, and 5 pixels wide.  No custom-defined chars
 * required.
 *
 */
MODULE_EXPORT void
jw002_hbar (Driver *drvthis, int x, int y, int len, int promille, int options)
{
#define ROMBARS

#ifndef ROMBARS
	PrivateData *p = drvthis->private_data;

	if (p->ccmode != hbar) {
		unsigned char hBar[p->cellheight];
		int i;

		if (p->ccmode != standard) {
			/* Not supported(yet) */
			report(RPT_WARNING, "%s: hbar: cannot combine two modes using user-defined characters",
					drvthis->name);
			return;
		}
		p->ccmode = hbar;

		memset(hBar, 0x00, sizeof(hBar));

		for (i = 1; i <= p->cellwidth; i++) {
			// fill pixel columns from left to right.
			memset(hBar, 0xFF & ~((1 << (p->cellwidth - i)) - 1), sizeof(hBar));
			jw002_set_char(drvthis, i+CC_OFFSET, hBar);
		}
	}

	lib_hbar_static(drvthis, x, y, len, promille, options, p->cellwidth, CC_OFFSET);
#else
	PrivateData *p = drvthis->private_data;

	int cellwidth = p->cellwidth; // quick hack to get hbars working

        int total_pixels  = ((long) 2 * len * cellwidth + 1 ) * promille / 2000;
        int pos;

        for (pos = 0; pos < len; pos++ ) {

                int pixels = total_pixels - cellwidth * pos;

                if ( pixels >= cellwidth ) {
                        /* write a "full" block to the screen... */
                        drvthis->icon (drvthis, x+pos, y, ICON_BLOCK_FILLED);
                }
                else if ( pixels > 0 ) {
                        /* write a partial block... */
                        drvthis->chr (drvthis, x+pos, y, pixels);
                        break;
                }
                else {
                        ; /* write nothing (not even a space) */
                }
        }
#endif
}


/**
 * Write a big number to the screen.
 * \param drvthis  Pointer to driver structure.
 * \param x        Horizontal character position (column).
 * \param num      Character to write (0 - 10 with 10 representing ':')
 */
MODULE_EXPORT void
jw002_num (Driver *drvthis, int x, int num)
{

	PrivateData *p = drvthis->private_data;
	int do_init = 0;

	if ((num < 0) || (num > 10))
		return;

	debug(RPT_DEBUG, "BG jw002_num: ccmode = %d (bignum = %d)", p->ccmode, bignum);

	if (p->ccmode != bignum) {
		if (p->ccmode != standard) {
			/* Not supported (yet) */
			report(RPT_WARNING, "%s: num: cannot combine two modes using user-defined characters",
					drvthis->name);
			return;
		}

		p->ccmode = bignum;

		do_init = 1;
	}

	debug(RPT_DEBUG, "BG  do_init = %d", do_init);

	// Lib_adv_bignum does everything needed to show the bignumbers.
	lib_adv_bignum(drvthis, x, num, CC_OFFSET, do_init);

}


/**
 * Get total number of custom characters available.
 * \param drvthis  Pointer to driver structure.
 * \return  Number of custom characters (always NUM_CCs).
 */
MODULE_EXPORT int
jw002_get_free_chars (Driver *drvthis)
{
//PrivateData *p = drvthis->private_data;

  return NUM_CCs;
}


/**
 * Define a custom character and write it to the LCD.
 * \param drvthis  Pointer to driver structure.
 * \param n        Custom character to define [0 - (NUM_CCs-1)].
 * \param dat      Array of 8(=cellheight) bytes, each representing a pixel row
 *                 starting from the top to bottom.
 *                 The bits in each byte represent the pixels where the LSB
 *                 (least significant bit) is the rightmost pixel in each pixel row.
 *
 * From http://www.pjrc.com/mp3/lcd_protocol.html
 *
 * Define Custom Character
 *   Download a custom character to RAM. The character number is sent as
 *   two byte ascii hex, followed by a font number (offset by 32), and
 *   an 8-byte bitmap. You may write to any font. User defined fonts
 *   should be placed in 8 through 31. Low numbered fonts may also be
 *   written, but this should generally only be done if the appearance
 *   of particular characters needs to be changed. See the LCD Fonts
 *   page for images of the fonts included in the display board's
 *   firmware. All downloaded font bitmaps are stored in volatile
 *   memory and are lost when the board is rebooted.
 *
 *  Transmit:
 *      0x5C 0x44 <char, 2 byte hex> <font+32> <bitmap, 8 bytes>
 *
 *      Example: Changing the appearance of capital "R" (R is ascii 0x52)
 *               in font #0:
 *      0x5C 0x44 0x35 0x32 0x20 0x3E 0x39 0x39 0x39 0x3E 0x3A 0x39 0x39
 */

//#define HEX2ASC(x) ((((x) & 0xF) + (((x) & 0xF) > 9) ? 48 : 55 ))
//#define HEX2ASC(x) ((x) & 15) + ((((x) & 15) > 9) ? 55 : 48)
#define HEX2ASC(x) ((x) + (((x) > 9) ? 55 : 48))

MODULE_EXPORT void
jw002_set_char (Driver *drvthis, int n, unsigned char *dat)
{

	PrivateData *p = drvthis->private_data;
	unsigned char out[13] = { '\\', 'D', 0,0, ' ', 0,0,0,0,0,0,0,0 };
	unsigned char mask = (1 << p->cellwidth) - 1;
	int row;

	if ((n < CC_OFFSET) || (n >= NUM_CCs+CC_OFFSET))
		return;
	if (!dat)
		return;

	out[2] = HEX2ASC(n >> 4);  /* Custom char to define. xxx */
	out[3] = HEX2ASC(n & 0x0F);  /* Custom char to define. xxx */

	for (row = 0; row <= p->cellheight; row++) {
		out[row+5] = (dat[row] & mask) | 0x20; // data portion range 0x20 - 0x3F
	}

#ifdef DEBUG_CHARS
	debug(RPT_DEBUG, "Chardef: '%.*s'", 13, out);
#endif
	write(p->fd, out, 13);

}


/**
 * Place an icon on the screen.
 * \param drvthis  Pointer to driver structure.
 * \param x        Horizontal character position (column).
 * \param y        Vertical character position (row).
 * \param icon     synbolic value representing the icon.
 * \return  Information whether the icon is handled here or needs to be handled by the server core.
 */
MODULE_EXPORT int
jw002_icon (Driver *drvthis, int x, int y, int icon)
{

//	PrivateData *p = drvthis->private_data;


	static unsigned char heart_open[] = 
		{ b__XXXXX,
		  b__X_X_X,
		  b_______,
		  b_______,
		  b_______,
		  b__X___X,
		  b__XX_XX,
		  b__XXXXX };
	static unsigned char heart_filled[] = 
		{ b__XXXXX,
		  b__X_X_X,
		  b___X_X_,
		  b___XXX_,
		  b___XXX_,
		  b__X_X_X,
		  b__XX_XX,
		  b__XXXXX };
	static unsigned char arrow_up[] = 
		{ b____X__,
		  b___XXX_,
		  b__X_X_X,
		  b____X__,
		  b____X__,
		  b____X__,
		  b____X__,
		  b_______ };
	static unsigned char arrow_down[] = 
		{ b____X__,
		  b____X__,
		  b____X__,
		  b____X__,
		  b__X_X_X,
		  b___XXX_,
		  b____X__,
		  b_______ };
	/*
	static unsigned char arrow_left[] = 
		{ b_______,
		  b____X__,
		  b___X___,
		  b__XXXXX,
		  b___X___,
		  b____X__,
		  b_______,
		  b_______ };
	static unsigned char arrow_right[] = 
		{ b_______,
		  b____X__,
		  b_____X_,
		  b__XXXXX,
		  b_____X_,
		  b____X__,
		  b_______,
		  b_______ };
	*/
	static unsigned char checkbox_off[] = 
		{ b_______,
		  b_______,
		  b__XXXXX,
		  b__X___X,
		  b__X___X,
		  b__X___X,
		  b__XXXXX,
		  b_______ };
	static unsigned char checkbox_on[] = 
		{ b____X__,
		  b____X__,
		  b__XXX_X,
		  b__X_XX_,
		  b__X_X_X,
		  b__X___X,
		  b__XXXXX,
		  b_______ };
	static unsigned char checkbox_gray[] = 
		{ b_______,
		  b_______,
		  b__XXXXX,
		  b__X_X_X,
		  b__XX_XX,
		  b__X_X_X,
		  b__XXXXX,
		  b_______ };
	/*
	static unsigned char selector_left[] = 
		{ b___X___,
		  b___XX__,
		  b___XXX_,
		  b___XXXX,
		  b___XXX_,
		  b___XX__,
		  b___X___,
		  b_______ };
	static unsigned char selector_right[] = 
		{ b_____X_,
		  b____XX_,
		  b___XXX_,
		  b__XXXX_,
		  b___XXX_,
		  b____XX_,
		  b_____X_,
		  b_______ };
	static unsigned char ellipsis[] = 
		{ b_______,
		  b_______,
		  b_______,
		  b_______,
		  b_______,
		  b_______,
		  b__X_X_X,
		  b_______ };
	static unsigned char block_filled[] = 
		{ b__XXXXX,
		  b__XXXXX,
		  b__XXXXX,
		  b__XXXXX,
		  b__XXXXX,
		  b__XXXXX,
		  b__XXXXX,
		  b__XXXXX };
	*/

	/* Yes we know, this is a VERY BAD implementation :-) */
	switch (icon) {
		case ICON_BLOCK_FILLED:
			jw002_chr(drvthis, x, y, 136);  // Font 0 fill chr
			break;
		case ICON_HEART_FILLED:
			jw002_set_char(drvthis, CC_OFFSET, heart_filled);
			jw002_chr(drvthis, x, y, CC_OFFSET);
			break;
		case ICON_HEART_OPEN:
			jw002_set_char(drvthis, CC_OFFSET+1, heart_open);
			jw002_chr(drvthis, x, y, CC_OFFSET+1);
			break;
		case ICON_ARROW_UP:
			jw002_set_char(drvthis, CC_OFFSET+2, arrow_up);
			jw002_chr(drvthis, x, y, CC_OFFSET+2);
		case ICON_ARROW_DOWN:
			jw002_set_char(drvthis, CC_OFFSET+3, arrow_down);
			jw002_chr(drvthis, x, y, CC_OFFSET+3);
			break;
		case ICON_ARROW_LEFT:
			jw002_chr(drvthis, x, y, 0x7F);
			break;
		case ICON_ARROW_RIGHT:
			jw002_chr(drvthis, x, y, 0x7E);
			break;
		case ICON_CHECKBOX_OFF:
			jw002_set_char(drvthis, CC_OFFSET+4, checkbox_off);
			jw002_chr(drvthis, x, y, CC_OFFSET+4);
			break;
		case ICON_CHECKBOX_ON:
			jw002_set_char(drvthis, CC_OFFSET+5, checkbox_on);
			jw002_chr(drvthis, x, y, CC_OFFSET+5);
			break;
		case ICON_CHECKBOX_GRAY:
			jw002_set_char(drvthis, CC_OFFSET+6, checkbox_gray);
			jw002_chr(drvthis, x, y, CC_OFFSET+6);
			break;
		default:
			return -1; /* Let the core do other icons */
	}

	return 0;
}


/**
 * Set cursor position and state.
 * \param drvthis  Pointer to driver structure.
 * \param x        Horizontal cursor position (column).
 * \param y        Vertical cursor position (row).
 * \param state    New cursor state.
 */
MODULE_EXPORT void 
jw002_cursor (Driver *drvthis, int x, int y, int state)
{

	// jw-002 doesn't support visible (hardware-driven) cursors

	/* set cursor position */
	 jw002_cursor_goto(drvthis, x, y);
}

/**
 * Initialize keypad strings
 *
 * The standard PJRC firmware for the JW-002 sends back strings at
 * keydown, keyup, and repeat.  We don't really care about keyup,
 * and to us, repeat might as well be another keydown event.  Fortunately,
 * the firmware allows us to set arbitrary strings for all keys and
 * all events.
 *
 * To simplify things, we will set the keydown and repeat strings to 'A'-'L',
 * and the keyup strings to nothing (12 spaces).
 *
 * From http://www.pjrc.com/mp3/lcd_protocol.html
 *
 * Configure Pushbutton Message String
 *
 *  Transmit:
 *      0x5C 0x48 <button> <string, 12 bytes>
 *        button = 48 to 59, sets string when pressed (down)
 *        button = 64 to 75, sets strings when released (up)
 *        button = 80 to 91, sets strings for auto-repeat
 *
 *        string = 12 byte string to send, pad with spaces to 12 bytes,
 *        (all spaces suppresses printing of the string)
 *
 *  Receive:
 *      nothing 
 *
 *
 * \param drvthis  Pointer to driver structure.
 *
 */
#define KEYDOWN_STR 48
#define KEYUP_STR   64
#define KEYRPT_STR  80

MODULE_EXPORT void
jw002_init_keys (Driver *drvthis)
{
	PrivateData *p = drvthis->private_data;
	int key;

	// The basic command structure is 0x5C 0x48 <key> <12 char return string>
        unsigned char out[15]      = { '\\', 'H', 0, ' ',' ',' ',' ',' ',' ',' ',' ',' ',' ',' ',' ' };

	// loop over all possible key values and set all three strings
	for (key = 0; key < MAX_KEY_MAP; key++) {

		// 'down' first
		out[2] = key + KEYDOWN_STR;
		out[3] = key + 'A'; // return 'A' through 'L'
		write(p->fd, out, 15);

		// 'repeat' next
		out[2] = key + KEYRPT_STR;
		out[3] = key + 'A'; // return 'A' through 'L'
		write(p->fd, out, 15);

		// 'up' last
		out[2] = key + KEYUP_STR;
		out[3] = ' ' ; // return nothing
		write(p->fd, out, 15);
	}

        debug(RPT_DEBUG, "jw002: initialized keypad return strings");
}

/**
 * Get key from the LCD.
 * \param drvthis  Pointer to driver structure.
 * \return  String representation of the key.
 *
 */
MODULE_EXPORT const char *
jw002_get_key (Driver *drvthis)
{
	PrivateData *p = drvthis->private_data;
	char key = 0;
	struct pollfd fds[1];

	/* don't query the keyboard if there are no mapped keys; see \todo above */
	if ((p->keys == 0) && (!p->keypad_test_mode))
		return NULL;

	/* poll for data or return */
	fds[0].fd = p->fd;
	fds[0].events = POLLIN;
	fds[0].revents = 0;
	poll(fds,1,0);
	if (fds[0].revents == 0)
		return NULL;

	(void) read(p->fd, &key, 1);
	report(RPT_DEBUG, "%s: get_key: key 0x%02X", drvthis->name, key);

	if (key == '\0')
		return NULL;

	if (!p->keypad_test_mode) {
		/* we assume standard key mapping here */
		if ((key >= 'A') && (key <= 'A' + MAX_KEY_MAP)) {
			return p->keymap[key-'A'];
		}
		if (key == 0x0d || key == 0x0a) {
			return NULL;	// ignore CR and LF from the jw002
		}
		else {
			report(RPT_INFO, "%s: Untreated key 0x%02X", drvthis->name, key);
			return NULL;
		}
	}
	else {
		fprintf(stdout, "jw002: Received character %c\n", key);
		fprintf(stdout, "jw002: Press another key of your device.\n");
	}
	return NULL;
}

/* EOF */
-------------- next part --------------
#ifndef JW002_H
#define JW002_H
/*
    Includes for jw002.c, the JW-002 driver.

    Copyright (C) 2008, 2009, Ethan Dicks

    This program is free software; you can redistribute it and/or modify
    it under the terms of the GNU General Public License as published by
    the Free Software Foundation; either version 2 of the License, or
    any later version.

    This program is distributed in the hope that it will be useful,
    but WITHOUT ANY WARRANTY; without even the implied warranty of
    MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
    GNU General Public License for more details.

    You should have received a copy of the GNU General Public License
    along with this program; if not, write to the Free Software
    Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301
*/

#include "lcd.h"

#define DEFAULT_DEVICE		"/dev/lcd"
#define DEFAULT_SPEED		19200
#define JW002_DEFAULT_WIDTH      24
#define JW002_DEFAULT_HEIGHT     8
#define JW002_DEFAULT_CELLWIDTH  5
#define JW002_DEFAULT_CELLHEIGHT 8

#define JW002_DEFAULT_FONT      0
#define JW002_MAX_FONT          32

#define DEFAULT_SIZE		"24x8"
#define DEFAULT_XOFFSET         0
#define DEFAULT_YOFFSET         0

#define DEFAULT_BACKLIGHT	0


MODULE_EXPORT int  jw002_init (Driver *drvthis);
MODULE_EXPORT void jw002_close (Driver *drvthis);
MODULE_EXPORT int  jw002_width (Driver *drvthis);
MODULE_EXPORT int  jw002_height (Driver *drvthis);
MODULE_EXPORT int  jw002_cellwidth (Driver *drvthis);
MODULE_EXPORT int  jw002_cellheight (Driver *drvthis);
MODULE_EXPORT void jw002_clear (Driver *drvthis);
MODULE_EXPORT void jw002_flush (Driver *drvthis);
MODULE_EXPORT void jw002_string (Driver *drvthis, int x, int y, const char string[]);
MODULE_EXPORT void jw002_chr (Driver *drvthis, int x, int y, char c);
MODULE_EXPORT const char * jw002_get_key (Driver *drvthis);
MODULE_EXPORT void jw002_init_keys (Driver *drvthis);

MODULE_EXPORT void jw002_vbar (Driver *drvthis, int x, int y, int len, int promille, int options);
MODULE_EXPORT void jw002_hbar (Driver *drvthis, int x, int y, int len, int promille, int options);
MODULE_EXPORT int  jw002_icon (Driver *drvthis, int x, int y, int icon);
MODULE_EXPORT void jw002_num (Driver *drvthis, int x, int num);
MODULE_EXPORT void jw002_cursor (Driver *drvthis, int x, int y, int state);

MODULE_EXPORT int  jw002_get_free_chars (Driver *drvthis);
MODULE_EXPORT void jw002_set_char (Driver *drvthis, int n, unsigned char *dat);

MODULE_EXPORT void jw002_output (Driver *drvthis, int state);
MODULE_EXPORT const char * jw002_get_info (Driver *drvthis);

#endif /* JW002_H */
-------------- next part --------------
A non-text attachment was scrubbed...
Name: configure_patch
Type: application/octet-stream
Size: 2391 bytes
Desc: not available
URL: <http://lists.omnipotent.net/pipermail/lcdproc/attachments/20090207/4e798d5a/attachment-0003.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: LCDd.8.in_patch
Type: application/octet-stream
Size: 382 bytes
Desc: not available
URL: <http://lists.omnipotent.net/pipermail/lcdproc/attachments/20090207/4e798d5a/attachment-0004.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: LCDd.conf_patch
Type: application/octet-stream
Size: 1448 bytes
Desc: not available
URL: <http://lists.omnipotent.net/pipermail/lcdproc/attachments/20090207/4e798d5a/attachment-0005.obj>

From bsdfan at nurfuerspam.de  Sun Feb  8 09:53:29 2009
From: bsdfan at nurfuerspam.de (Markus Dolze)
Date: Sun, 08 Feb 2009 10:53:29 +0100
Subject: [Lcdproc] usblcd driver resurrected
Message-ID: <20090208095329.35060@gmx.net>

Hello,

I added the 'usblcd' connection type of hd44780 driver to lcdproc 0.5dev. It had been part of lcdproc 0.4.5 but was never added to CURRENT and got lost.

The attached patch works as reported by an user owning such a device. It includes code and documentation.

Regards
Markus
-------------- next part --------------
A non-text attachment was scrubbed...
Name: usblcd-driver.diff
Type: application/octet-stream
Size: 12396 bytes
Desc: not available
URL: <http://lists.omnipotent.net/pipermail/lcdproc/attachments/20090208/206f3558/attachment.obj>

From ethan.dicks at gmail.com  Sun Feb  8 17:17:32 2009
From: ethan.dicks at gmail.com (Ethan Dicks)
Date: Sun, 8 Feb 2009 12:17:32 -0500
Subject: [Lcdproc] Adding support for multi-color backlight in Matrix
	Orbital LK204-7T-1U-BK-USB-TCI
Message-ID: <f4eb766f0902080917o69d0301ai2a1669a98729c7d9@mail.gmail.com>

Hi, All,

Thanks to Ray Molenkamp at Matrix Orbital, I have two more Matrix
Orbital displays to go with my M-O VFD, a GK19264 graphic display, and
a LK204-7T-1U-BK-USB-TCI 20x4 textual LCD w/integral 7-key backlit
keypad *and*, the "TCI" part of the part number, a tri-color LCD
backlight.

There is no current support in LCDproc for being able to change the
color of the backlight (just on/off and sometimes brightness), but in
less than an hour, I cobbled up support for a "BacklightColor" option
in the MtxOrb section of LCDd.conf.  As presently implemented, you
give your display a color as a 12-bit hex number (0xAABBCC) and new
code in MtxOrb.c parses that and splits it into Red, Blue and Green
components and sends them to the display with the "Set Backlight Base
Colour" command (0x82).

Working with this feature brings to mind that there are a lot of
features on newer displays that just weren't available on LCD modules
10 or more years ago.  The  LK204-7T-1U-BK-USB-TCI as one example, has
a multi-color backlight, backlit pushbuttons, and three bi-color
output LEDs, plus GPOs, plus (like many other recent Matrix Orbital
products) Dallas 1-wire support.  There really isn't much that can be
done to the present client-server protocol, but I wanted to mention
these sorts of options in a public forum for eventual discussions of
how to be able to take advantage of hardware features we've already
paid for.  I think it's great that LCDproc supports simple LCDs with a
parallel port interface all the way up to fancy and complicated USB
and network-attached displays.  It's important to have a core set of
solidly supported display features (text strings, bargraphs, big nums,
etc).  It is, however, occasionally frustrating that the neat and new
features of fancy new displays take such effort to incorporate, when
they can be incorporated at all.

For the meantime now, I'm going to turn some efforts to better
supporting various LED options on the  LK204-7T-1U-BK-USB-TCI,
probably largely via the 'output' mechanism.

-ethan

From ethan.dicks at gmail.com  Mon Feb  9 05:40:33 2009
From: ethan.dicks at gmail.com (Ethan Dicks)
Date: Mon, 9 Feb 2009 00:40:33 -0500
Subject: [Lcdproc] Overloading the 'output' token
Message-ID: <f4eb766f0902082140p249d4408tbc880c032b0559bc@mail.gmail.com>

Hi, All,

I'm still fiddling with this LK204-7T-1U, trying to get more of its
native features accessible from LCDproc.  To that end, I'm staring at
'output.  As it stands, with no modification, the LCD has 9 GPOs -
three physical GPOs of a traditional sort (10mA current sink, software
control), and six are tied into three bi-color LEDs adjacent to the
LCD.  It's all quite straightforward - GPO1 and GPO2 are tied to LED1,
GPO3 and GPO4 are tied to LED2, GPO5 and GPO6 are tied to LED3, and
the remaining three "real" GPOs are known as GPO7, GPO8, and GPO9.
The way 'output' is implemented, one just send the bitmask of which
GPOs to have on, and the driver takes care of it.  Fortunately, it's
all compatible with the present state of the Matrix Orbital driver, so
it just works as expected.

Now... what's different is that there are LEDs on this display that
are *not* under control of the GPOs - in particular, the white
backlight for the keypad, and the red, blue, and green LEDs in the
backlight.  I know of only one other display with an independent
backlight for the keypad, the picoLCD 20x2 "minibox" display.  The
driver for that supports some additional keywords in LCDd.conf to
enable individual LEDs behind specific keys.  It's trivial to add that
feature to the Matrix Orbital driver - in this case, one LED for all
buttons, but the syntax could be similar or nearly identical as what's
presently in the picoLCD driver.

The remaining bit is the 24-bit backlight LED.  I have some
experimental code here that allows the user to pick a color for the
session by listing a 24-bit hex number in LCDd.conf.  It's handy, but
it doesn't allow the user to change the color without taking LCDd
down, changing the LCDd.conf, and restarting LCDd.  Given the
limitation of the present client-server protocol, one way to extend
this functionality to the clients is to overload 'output'.

My thought is this - use upper bits of the output argument to select,
inside the Matrix Orbital driver, if the low 9 bits mean assert GPOs,
or to set a new red, new green or new blue value.  'output 0x01' would
still light up GPO1 as it does now, but if you were to (arbitrarily)
decide that output bits 16 and 17 were tags for color, 'output
0x10000' could set red to zero, while 'output 0x100ff' could set red
to full (likewise 0x20000 to 0x200ff for green and 0x30000 to 0x300ff
for blue).  If leaving room in the Matrix Orbital driver (remember,
this is driver-specific) for 16 GPOs isn't enough, one could slide the
color marker up 8 more bits (producing output numbers like 0x30000ff,
etc.) and leave room for 24 real GPOs and still not overflow a 32-bit
signed int.

It probably won't take me more than a couple of hours to code up and
test this change to MtxOrb.c, so I'm wondering if anyone has any
opinions one way or the other about this technique.  As it stands, the
documentation does warn that the value passed to 'output' is
driver-specific.  More than most, the Matrix Orbital driver has to
handle a variety of GPO configurations from LCDs to VFDs, new, old,
etc.  It seems unlikely (I know... famous last words) that anyone will
produce an LCD with more than 16 GPOs (let alone 24), but I would
never dare to say that it will never happen.

I'm minded to ask if anyone knows of LCDproc being ported to a 16-bit
architecture.  I haven't torn through the code to see specifically how
the parser defines the arg for 'output', but if it happens to just use
a machine-length int, it might be safer to use bits 14 and 13.

Comments? Suggestions?

Thanks,

-ethan

From joerg.hohwieler at pyramid.de  Mon Feb  9 10:19:12 2009
From: joerg.hohwieler at pyramid.de (=?ISO-8859-1?Q?J=F6rg_Hohwieler?=)
Date: Mon, 09 Feb 2009 11:19:12 +0100
Subject: [Lcdproc] pyramid lcd
Message-ID: <49900320.3070408@pyramid.de>

Hi,

I'm having some issues with lcdproc-client in conjunction with the
Pyramid LCD,
which is a 2x16 display.

The lcdproc-client supports several screen commands.

The only screens that work with the display are:
P
N
G
L

Is this an expected behaviour due to limitations by the display size?


The other screens won't show anything on the display when executed
whereas the 4 mentioned screens above immediately show up on the display.

I tested with current CVS version of lcdproc.


Best regards
Joerg


From junk_inbox at verizon.net  Tue Feb 10 16:40:17 2009
From: junk_inbox at verizon.net (Jeff)
Date: Tue, 10 Feb 2009 11:40:17 -0500
Subject: [Lcdproc] LCDd daemon hangs with USB Crystalfontz 634 LCD
In-Reply-To: <20090131104931.290160@gmx.net>
References: <4345451E4BEF4958BD79FC703E4B780C@jartzhome>
	<B3875DA949544633A05058507CEEA665@jartzhome>
	<alpine.LNX.1.00.0901291403060.30137@green.pepper>
	<d569babb0901301551n40054a4ei83083d7e2449aad@mail.gmail.com>
	<20090131104931.290160@gmx.net>
Message-ID: <d569babb0902100840v34c3c11eq446056045e7405b8@mail.gmail.com>

On Sat, Jan 31, 2009 at 5:49 AM, Markus Dolze <bsdfan at nurfuerspam.de> wrote:

> -------- Original-Nachricht --------
> > Datum: Fri, 30 Jan 2009 18:51:29 -0500
> > Von: Jeff <junk_inbox at verizon.net>
> > An: lcdproc <lcdproc at lists.omnipotent.net>
> > Betreff: Re: [Lcdproc] LCDd daemon hangs with USB Crystalfontz 634 LCD
>
> > On Thu, Jan 29, 2009 at 3:08 PM, Daryl F <wyatt at prairieturtle.ca> wrote:
> >
> > >  On Thu, 29 Jan 2009, Jeff Artz wrote:
> > >
> > >   Does anybody have anything to suggest?  It's now been a month since I
> > >> posted my issue, but haven't even gotten a single response...
> > >>
> > >> :-(
> > >>
> > >> Jeff
> > >>  ----- Original Message -----
> > >>  From: Jeff Artz
> > >>  To: lcdproc
> > >>  Sent: Sunday, December 28, 2008 11:07 PM
> > >>  Subject: [Lcdproc] LCDd daemon hangs with USB Crystalfontz 634 LCD
> > >>
> > >>
> > >>  Ok, I've googled and found some references to this hang, and my new
> CF
> > >> 634 display does the same, exactly as described in this thread from
> > last
> > >> year:
> > >>  http://lists.omnipotent.net/pipermail/lcdproc/2007-April/011646.html
> > >>
> > >>  I'm running Fedora Core 8, kernel "2.6.26.6-49.fc8", current CVS
> > LCDproc
> > >> v0.5.2
> > >>
> > >>  Here's what happens:
> > >>  [mythtv at mythbackend etc]$ sudo /sbin/service LCDd start
> > >>  Starting up LCDd:
> > >>  <hangs forever unless CTRL-C is pressed or a "kill -USR1" is
> > issued...>
> > >>
> > >>  ps ax of above hang scenerio:
> > >>  [root at mythbackend mythtv]# ps ax | grep LCDd
> > >>  16361 pts/1    S+     0:00 /bin/sh /sbin/service LCDd start
> > >>  16368 pts/1    S+     0:00 /bin/sh /etc/init.d/LCDd start
> > >>  16373 pts/1    S+     0:00 /bin/bash -c ulimit -S -c 0 >/dev/null
> 2>&1
> > ;
> > >> /usr/local/sbin/LCDd -c /home/mythtv/lcd/LCDd.conf
> > >>  16374 pts/1    S+     0:00 /usr/local/sbin/LCDd -c
> > >> /home/mythtv/lcd/LCDd.conf
> > >>  16375 ?        Ss     0:00 /usr/local/sbin/LCDd -c
> > >> /home/mythtv/lcd/LCDd.conf
> > >>  16381 pts/3    R+     0:00 grep LCDd
> > >>  [root at mythbackend mythtv]#
> > >>
> > >>  If I manually do a "kill -USR1 16374", "[ OK ]" is displayed and the
> > >> prompt will come back and everything works fine.
> > >>
> > >>  So, to help troubleshoot, I changed the ReportLevel to 5, and here's
> > what
> > >> I get to stdout:
> > >>  [mythtv at mythbackend etc]$ sudo /sbin/service LCDd start
> > >>  Starting up LCDd: LCDd version 0.5.2 starting
> > >>  Built on Dec 22 2008, protocol version 0.3, API version 0.5
> > >>  Using Configuration File: /home/mythtv/lcd/LCDd.conf
> > >>  Set report level to 5, output to stderr
> > >>  Server forking to background
> > >>  Listening for queries on 127.0.0.1:13666
> > >>  screenlist_init()
> > >>  driver_load(name="CFontz", filename="/home/mythtv/lcd/CFontz.so")
> > >>  CFontz: using Device /dev/lcd
> > >>  CFontz: init() done
> > >>  Key "Escape" is now reserved in exclusive mode by client [-1]
> > >>  Key "Enter" is now reserved in shared mode by client [-1]
> > >>  Key "Up" is now reserved in shared mode by client [-1]
> > >>  Key "Down" is now reserved in shared mode by client [-1]
> > >>  screenlist_process()
> > >>  screenlist_switch(s=[_server_screen])
> > >>  screenlist_switch: switched to screen [_server_screen]
> > >>  screenlist_process()
> > >>  screenlist_process()
> > >>  screenlist_process()
> > >>  screenlist_process()
> > >>  screenlist_process()
> > >>  screenlist_process()
> > >>  screenlist_process()
> > >>  screenlist_process()
> > >>  screenlist_process()
> > >>  screenlist_process()
> > >>  <etc...   And then the running 'mythlcdserver' process starts
> > displaying
> > >> screens within a few seconds>
> > >>
> > >>  (Which doesn't seem very helpful to me -  perhaps it will to the
> > >> developers)
> > >>
> > >>  So for the moment I can't setup LCDd to start at boot time, or it
> will
> > >> hang my system.  I manually start it after booting.  (Thankfully
> that's
> > not
> > >> very often, as it's my MythTV backend system)
> > >>
> > >>  How can I help troubleshoot this further?  (Suggestions of a debugger
> > >> and/or the process, not quite step-by-step, but the more explict the
> > better
> > >> - ie please don't reply with simply "just debug the process"... I
> don't
> > know
> > >> how to do that [yet]!)
> > >>
> > >>  Thanks!
> > >>
> > >>
> > >>
> > >>
> >
> ------------------------------------------------------------------------------
> > >>
> > >>
> > >>
> > >>
> > > Hi Jeff,
> > >
> > > It may be that the child is sending the USR1 signal but it is being
> > blocked
> > > from the parent because of permissions. Instead of a `ps ax` try `ps
> > -ef`
> > > and see who owns the processes.
> > >
> > > I suspect the init script is running as root and also the parent LCDd
> > > process but the child is running as a less privileged user and the
> > signal is
> > > not being delivered. The assumption hear is that the `kill -USR1 <pid>'
> > is
> > > manually being done from a root login so it gets delivered and then the
> > > parent ends and the init script completes and delivers the [ OK ] to
> the
> > > console.
> > >
> > > Post the `ps -ef'. Maybe someone else on this list can figure out what
> > > needs to be done if it is permissions at fault.
> > >
> > > -Daryl
> > >
> > >
> >
> > Thanks Daryl,
> >
> >  Here's the "ps -ef |grep LCDd" output while issuing a "/sbin/service
> > start
> > LCDd" command:
> >
> > [root at mythbackend ~]# ps -ef |grep LCDd
> > root      3667  3632  0 20:42 pts/5    00:00:00 /bin/sh /sbin/service
> LCDd
> > start
> > root      3675  3667  0 20:42 pts/5    00:00:00 /bin/sh /etc/init.d/LCDd
> > start
> > root      3680  3675  0 20:42 pts/5    00:00:00 /bin/bash -c ulimit -S -c
> > 0
> > >/dev/null 2>&1 ; /usr/local/sbin/LCDd -c /home/mythtv/lcd/LCDd.conf
> > root      3681  3680  0 20:42 pts/5    00:00:00 /usr/local/sbin/LCDd -c
> > /home/mythtv/lcd/LCDd.conf
> > nobody    3682  3681  0 20:42 ?        00:00:00 /usr/local/sbin/LCDd -c
> > /home/mythtv/lcd/LCDd.conf
> > root      3686 23166  0 20:42 pts/1    00:00:00 grep LCDd
> > [root at mythbackend ~]#
> >
> > (and you can see the parent running as root, and the daemon launced as
> > nobody)
> >
> > If I comment out the "User=" line from the conf file, it still starts as
> > 'nobody', and I get the same result.
> >
> > If, however, I change it to "User=root", it starts as root and exhibits
> > the
> > same behavior, so it doesn't appear to be a permissions issue:
> > [root at mythbackend ~]# ps -ef |grep LCDd
> > root      3800  3632  0 20:51 pts/5    00:00:00 /bin/sh /sbin/service
> LCDd
> > start
> > root      3807  3800  0 20:51 pts/5    00:00:00 /bin/sh /etc/init.d/LCDd
> > start
> > root      3812  3807  0 20:51 pts/5    00:00:00 /bin/bash -c ulimit -S -c
> > 0
> > >/dev/null 2>&1 ; /usr/local/sbin/LCDd -c /home/mythtv/lcd/LCDd.conf
> > root      3813  3812  0 20:51 pts/5    00:00:00 /usr/local/sbin/LCDd -c
> > /home/mythtv/lcd/LCDd.conf
> > root      3814  3813  0 20:51 ?        00:00:00 /usr/local/sbin/LCDd -c
> > /home/mythtv/lcd/LCDd.conf
> > root      3816 23166  0 20:51 pts/1    00:00:00 grep LCDd
> > [root at mythbackend ~]#
> >
> > PS: Same behavior with latest CVS - revision 1.29.2.4
> >
> > Thanks,
> >
> > Jeff
>
> Hi,
>
> the user privilege is changed after the signal has been sent, so this
> should not be a problem.
>
> Would you mind sending a log output of LCDd? You will have to rebuild LCDd
> and use "configure --enable-debug". Then use ReportLevel=5 and
> ReportToSyslog=yes in your LCDd.conf.
>
> You probably want to add an entry to your syslog.conf as well:
> !LCDd
> *.*     /var/log/LCDd.conf
>
> (I am not sure if this works with Linux, but it should have something
> similar.)
>
> In the end you should see something like this:
>
> <LCDd.log>
> Jan 31 11:24:38 <user.notice> kirika LCDd: LCDd version 0.5dev starting
> ...
> Jan 31 11:24:38 <user.info> kirika LCDd: Set report level to 5, output to
> syslog
> Jan 31 11:24:38 <user.info> kirika LCDd: Server forking to background
> Jan 31 11:24:38 <user.debug> kirika LCDd: daemonize()
> Jan 31 11:24:38 <user.info> kirika LCDd: parent = 1082
> Jan 31 11:24:38 <user.info> kirika LCDd: child = 1083
> Jan 31 11:24:38 <user.debug> kirika LCDd:
> install_signal_handlers(allow_reload=1)
> ...
> Jan 31 11:24:41 <user.debug> kirika LCDd: wave_to_parent(parent_pid=1082)
> Jan 31 11:24:41 <user.info> kirika LCDd: child_ok_func(signal=30)
> Jan 31 11:24:41 <user.debug> kirika LCDd: drop_privs(user="nobody")
> Jan 31 11:24:41 <user.debug> kirika LCDd: do_mainloop()
> </LCDd.log>
>
> The lines wave_to_parent() and child_ok_func() should appear. After this
> you should not see a process with the parent PID anymore!
>
> Regards
> Markus
>
Hi Markus,

  I will get this info for you in the next couple of days.  Sorry, it's been
hectic at work, and I have not had the time to sit down in front of my myth
box to do this yet.

Jeff
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omnipotent.net/pipermail/lcdproc/attachments/20090210/5df56e76/attachment.htm>

From stewartputnam at comcast.net  Wed Feb 11 05:19:38 2009
From: stewartputnam at comcast.net (stewartputnam at comcast.net)
Date: Wed, 11 Feb 2009 05:19:38 +0000 (UTC)
Subject: [Lcdproc] LCDd daemon hangs with USB Crystalfontz 634 LCD
In-Reply-To: <d569babb0902100837g20e59094rf0a6b711f675d6c0@mail.gmail.com>
Message-ID: <885484394.3903071234329578114.JavaMail.root@sz0098a.emeryville.ca.mail.comcast.net>


----- Original Message ----- 
From: "Jeff" <junk_inbox at verizon.net> 
To: stewartputnam at comcast.net 
Sent: Tuesday, February 10, 2009 8:37:16 AM GMT -08:00 US/Canada Pacific 
Subject: Re: [Lcdproc] LCDd daemon hangs with USB Crystalfontz 634 LCD 




On Sun, Feb 1, 2009 at 7:25 PM, < stewartputnam at comcast.net > wrote: 






----- Original Message ----- 
From: "Jeff Artz" < junk_inbox at verizon.net > 
To: "lcdproc" < lcdproc at lists.omnipotent.net > 
Sent: Wednesday, January 28, 2009 9:21:21 PM GMT -08:00 US/Canada Pacific 
Subject: Re: [Lcdproc] LCDd daemon hangs with USB Crystalfontz 634 LCD 


Does anybody have anything to suggest?? It's now been a month since?I posted my issue, but haven't even gotten a single response... 

:-( 

Jeff 



----- Original Message ----- 
From: Jeff Artz 
To: lcdproc 
Sent: Sunday, December 28, 2008 11:07 PM 
Subject: [Lcdproc] LCDd daemon hangs with USB Crystalfontz 634 LCD 



So, to help troubleshoot, I? changed the ReportLevel to 5, and here's what I get to stdout: 
[mythtv at mythbackend etc]$ sudo /sbin/service LCDd start 
Starting up LCDd: LCDd version 0.5.2 starting 
Built on Dec 22 2008, protocol version 0.3, API version 0.5 
Using Configuration File: /home/mythtv/lcd/LCDd.conf 
Set report level to 5, output to stderr 
Server forking to background 
Listening for queries on 127.0.0.1:13666 
screenlist_init() 
driver_load(name="CFontz", filename="/home/mythtv/lcd/CFontz.so") 
CFontz: using Device /dev/lcd 
Excuse me, this strikes me as too simple to be the answer.? It popped out to me only after downloading the latest 634*.pdf form CF... 

I've used three CrystalFontz proucts, never a 634, and debian.? All three use the /drivers/usb/serial/ftdi_sio kernel module (CONFIG_USB_SERIAL_FTDI_SIO=m).? The device nodes appear as /dev/ttyUSB{n}? This is always kernel, not distribution, dependent? Do any distributions customze that part of the kernel or create symlinks?? Does the 634 use the same usb-serial converter as the 631, 633, & 635? 

usbcore: registered new driver usbserial 
drivers/usb/serial/usb-serial.c: USB Serial Driver core 
drivers/usb/serial/usb-serial.c: USB Serial support registered for FTDI USB Serial Device 
ftdi_sio 2-3:1.0: usb_probe_interface 
ftdi_sio 2-3:1.0: usb_probe_interface - got id 
ftdi_sio 2-3:1.0: FTDI USB Serial Device converter detected 
drivers/usb/serial/ftdi_sio.c: Detected FT8U232AM 
usb 2-3: FTDI USB Serial Device converter now attached to ttyUSB0 
usbcore: registered new driver ftdi_sio 
drivers/usb/serial/ftdi_sio.c: v1.4.3:USB FTDI Serial Converters Driver 

I've not used any module that appears as /dev/lcd. 
Um, er, I speculate that some modules do ?? Some must? (or used to ?) for that to appear as a default in [driver] sections of LCDd.conf, yes?? 

If this is the cause of Jeff Artz hang: how many others give lcdproc a try but do not go as far as signing up to this list & submitting ReportLev=5 logs & resubmitting a mont later?? Should /dev/lcd be replaced in some [driver] sectiens of the default / example / distribution LCDd.conf? 





Hi Stuart, 

? I'm not sure I follow you here.? Yes, the device does show up as /dev/ttyUSB1? - I have a udev rule created to create a symlink to /dev/lcd as I also have a USB->Serial adapter for X10 control that flip-flops with the LCD on every boot.? Instead of modifying config files on every reboot, I created udev rules.? That way /dev/lcd is always a symlink to the correct /dev/ttyUSBx port for the LCD, and the same for my X10 serial adapter, which gets symlinked to /dev/x10 

[mythtv at mythbackend ~]$ ls -al /dev/lcd /dev/x10 
lrwxrwxrwx 1 root root 7 2009-02-08 02:06 /dev/lcd -> ttyUSB1 
lrwxrwxrwx 1 root root 7 2009-02-08 02:06 /dev/x10 -> ttyUSB0 
[mythtv at mythbackend ~]$??? 

Here's my relevant section of the LCDd.conf: 
## CrystalFontz driver (for CF632 & CF634) ## 
[CFontz] 

# Select the output device to use [default: /dev/lcd] 
Device=/dev/lcd 
#Device=/dev/ttyUSB1 

# Select the LCD size [default: 20x4] 
Size=20x4 
# Set the initial contrast [default: 560; legal: 0 - 1000] 
Contrast=650 
# Set the initial brightness [default: 1000; legal: 0 - 1000] 
Brightness=700 
# Set the initial off-brightness [default: 0; legal: 0 - 1000] 
# This value is used when the display is normally 
# switched off in case LCDd is inactive 
OffBrightness=0 
# Set the communication speed [default: 9600; legal: 1200, 2400, 9600, 19200 or 115200] 
Speed=19200 
# Set the firmware version (New means >= 2.0) [default: no; legal: yes, no] 
NewFirmware=yes 
# Reinitialize the LCD's BIOS [default: no; legal: yes, no] 
# normally you shouldn't need this 
Reboot=no 
# option seen in the driver itself - will it fix my LCDd startup hang?? 2009-01-29 JLA? **NOPE** 
USB=yes 

? So I'm not sure what you're implying or asking... 

? Indeed, I do still need to follow-up on Marcus' request for additional info - I have not yet had the time to do this as of yet.? I hope to be able to do that in the next couple of days.?? -- And I'm not a new LCDProc user - I've used it for the last 4 years or so with HD44780 displays.? 

Jeff 


>From a distance, not having used a 634, ?I was wondering if there was a /dev/lcd on your system.? My question / suggestion is resolved: there is a /dev/lcd.???dev/CF634 and /dev/X10 flip flopping /dev/usb[01] every boot looks like a nuisance that you have handled porperly with udev rule symlinks.? 



Seeing that you have experience with the HD44780 on lcdproc I can only rattle off a few shallow simplistic things that occour to me,? you've probably tried already:?test without the similink, using /dev/USB directly; test without any mythtv.? 



I'm writing away from my lcdproc install at the moment.? If anything else occours to me when I look at the CFontz.[ch] code I'll mention it. 

Stewart.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omnipotent.net/pipermail/lcdproc/attachments/20090211/fc480f79/attachment-0001.htm>

From root at c-works.net  Wed Feb 11 07:06:11 2009
From: root at c-works.net (Harald Latzko)
Date: Wed, 11 Feb 2009 08:06:11 +0100 (CET)
Subject: [Lcdproc] pyramid lcd
In-Reply-To: <49900320.3070408@pyramid.de>
References: <49900320.3070408@pyramid.de>
Message-ID: <1632.212.6.135.66.1234335971.squirrel@squirrel.c-works.net>

(could someone configure this mailinglist to set the "reply-to" address to
the mailing list back again or is this an unwanted feature? thx)

so, again, posted back to the list:
---------------------------------
Hello J?rg,

as a customer of Pyramid (using the Miniflex appliance), I could test out
your problems. Are you having the behaviour with the LCDproc version 0.52?
Also, do you have a sample client program (Linux binary would be perfect)
reproducing the behaviour?

Regards,
Harald


> Hi,
>
> I'm having some issues with lcdproc-client in conjunction with the
> Pyramid LCD,
> which is a 2x16 display.
>
> The lcdproc-client supports several screen commands.
>
> The only screens that work with the display are:
> P
> N
> G
> L
>
> Is this an expected behaviour due to limitations by the display size?
>
>
> The other screens won't show anything on the display when executed
> whereas the 4 mentioned screens above immediately show up on the display.
>
> I tested with current CVS version of lcdproc.
>
>
> Best regards
> Joerg
>
> _______________________________________________
> LCDproc mailing list
> LCDproc at lists.omnipotent.net
> http://lists.omnipotent.net/mailman/listinfo/lcdproc
>
>


From joerg.hohwieler at pyramid.de  Wed Feb 11 08:44:15 2009
From: joerg.hohwieler at pyramid.de (=?ISO-8859-1?Q?J=F6rg_Hohwieler?=)
Date: Wed, 11 Feb 2009 09:44:15 +0100
Subject: [Lcdproc] pyramid lcd
In-Reply-To: <1632.212.6.135.66.1234335971.squirrel@squirrel.c-works.net>
References: <49900320.3070408@pyramid.de>
	<1632.212.6.135.66.1234335971.squirrel@squirrel.c-works.net>
Message-ID: <49928FDF.90204@pyramid.de>

Hello Harald,

please download the archive from [1]. It contains lcdproc-0.5.2 (linux binary).

server: sudo ./LCDd -c LCDd.conf -d pyramid -f
client: ./lcdproc -f P

and try other screens, e.g M or T or U.


Thanks for testing.

Best regards
Joerg


[1] http://hohwie.com/lcd/lcd_test.tar.bz2


Harald Latzko wrote:
> (could someone configure this mailinglist to set the "reply-to" address to
> the mailing list back again or is this an unwanted feature? thx)
>
> so, again, posted back to the list:
> ---------------------------------
> Hello J?rg,
>
> as a customer of Pyramid (using the Miniflex appliance), I could test out
> your problems. Are you having the behaviour with the LCDproc version 0.52?
> Also, do you have a sample client program (Linux binary would be perfect)
> reproducing the behaviour?
>
> Regards,
> Harald
>
>
>   
>> Hi,
>>
>> I'm having some issues with lcdproc-client in conjunction with the
>> Pyramid LCD,
>> which is a 2x16 display.
>>
>> The lcdproc-client supports several screen commands.
>>
>> The only screens that work with the display are:
>> P
>> N
>> G
>> L
>>
>> Is this an expected behaviour due to limitations by the display size?
>>
>>
>> The other screens won't show anything on the display when executed
>> whereas the 4 mentioned screens above immediately show up on the display.
>>
>> I tested with current CVS version of lcdproc.
>>
>>
>> Best regards
>> Joerg
>>
>> _______________________________________________
>> LCDproc mailing list
>> LCDproc at lists.omnipotent.net
>> http://lists.omnipotent.net/mailman/listinfo/lcdproc
>>
>>
>>     
>
> _______________________________________________
> LCDproc mailing list
> LCDproc at lists.omnipotent.net
> http://lists.omnipotent.net/mailman/listinfo/lcdproc
>   

From ethan.dicks at gmail.com  Wed Feb 11 16:40:36 2009
From: ethan.dicks at gmail.com (Ethan Dicks)
Date: Wed, 11 Feb 2009 11:40:36 -0500
Subject: [Lcdproc] Overloading the 'output' token
In-Reply-To: <f4eb766f0902082140p249d4408tbc880c032b0559bc@mail.gmail.com>
References: <f4eb766f0902082140p249d4408tbc880c032b0559bc@mail.gmail.com>
Message-ID: <f4eb766f0902110840k158cb4c0k30da7eb65cd7611d@mail.gmail.com>

Hi, All,

OK... at this point, I think I have things hammered out in my head,
but I wanted to toss the in-line documentation on my color backlight
scheme out to the group for comment (in the hopes that it will
stimulate any)...

/**
 * Set output port(s).
 *
 * At one time, the range of Matrix Orbital products was small enough
that it was
 * possible to "know" how many GPOs a module was likely to have based
on some simple
 * characteristics (i.e., displays with keypad had 6 outputs, but simple modules
 * only had one).   Now, it is much more complex.  One of the most convoluted
 * examples is the LK204-7T-1U with the tri-color LED backlight.  In addition to
 * a white backlight for just the built-in keypad and the 256-level
red, green, and
 * blue backlight LEDs, it has three ordinary off-board GPOs (10mA
current sink),
 * _plus_ six GPOs that are tied to three on-board bi-color status
LEDs.  Using the
 * existing GPO scheme, it's possible to twiddle the 3 off-board GPOs
and set the
 * on-board LEDs to red, green or "amber" (both red and green lit).
 *
 * The keypad backlight and LCD backlight are controlled with Matrix Orbital
 * commands that are different from the GPO commands ("W" and "V"), but in the
 * present (0.5.2) LCDproc model, it seems reasonable to use the 'output'
 * keyword to control the color of the backlight as well (backlight on/off is
 * still controlled by the same commands as on other Matrix Orbital displays,
 * but the specific color is independent of that).
 *
 * Since the LK204-7T-1U already has nine formal GPOs and since 'output' passes
 * an "int" from the client through the server to the driver, one mechanism that
 * won't break the existing GPO model is to define some of the upper bits in a
 * signed 32-bit int to mean "set backlight color".  It seems unlikely that any
 * LCD will implement more than 28 GPOs, so bits 28 and 29 can be used to select
 * four different results of the output command from the client:
 *
 * 29 28 27...7..0
 *  0  0 NNNNNNNNN  - which GPO to turn on/off with "W"/"V" command
 *  0  1      RRRR  - use low 8-bits for red backlight setting
 *  1  0      GGGG  - use low 8-bits for green backlight setting
 *  1  1      BBBB  - use low 8-bits for blue backlight setting


What I have not done yet is to decide if this code needs a new token
in LCDd.conf to confirm that the user does indeed have a display that
accepts the tri-color backlight commands.  I only have two textual
Matrix Orbital displays, an ancient VKD204 that I've written about
frequently, and this new LK204-7T-1U, so my ability to test commands,
responses, and errors will be limited.  It certainly is easy enough to
add a new token "HasMulticolorBacklight" with acceptable args of
"yes/no" or whatever contextually matches the other drivers as a way
to wall off code that is specific to units with the tricolor LED
backlight, but whether it's reasonable to do that or not depends on
how much we want to burden the user with knowing about his own
display.

One approach is to just let the user set up an initial color and tweak
that color with the modified 'output' arg that I've been proposing -
if they have a tricolor backlight it'll just work.  If they don't,
then I'm thinking the display will complain that it was sent an
invalid command which it will ignore.  The problem is that may lead to
garbage characters on displays that don't have that as a valid MtxOrb
command.  I'm not proposing to enable tricolor backlight control in
LCDd.conf by default, so out of the box, all Matrix Orbital displays
would work and work fine.  Where they might get messed up is if the
user removed the comment in LCDd.conf for the initial backlight color
setting or if they ran a tricolor-aware client that happened to send
output commands with the high bits enabled.  The "safe" approach is to
require the user to enable these commands in LCDd.conf, but given that
many LCDproc users are unsophisticated, adding more and more options
into LCDd.conf can be considered a hindrance, especially for the users
who are unable to figure out what's wrong when things don't look neat
and clean.

I wish there were a way to automatically detect tricolor backlight
support, but as we've seen with GPOs and backlights, etc., there are
so many new and old Matrix Orbital displays with re-use of identifier
codes, etc., that there is no practical way to query the unit to see
exactly what features it supports.  Even if they did add that as a
feature in the future, it still wouldn't help the dozens of models
that are in the real world right now.  It's simpler with other brands
since they don't have 10+ years of LCD models with subtle changes
between models, but I still think it's worth a good effort to support
as many kinds of Matrix Orbital displays as reasonably possible.  The
cost, though, is shifting some of the burden to the end-user who will
actually be required to know something about the product he purchased
and what it can do.  It is a complex enough issue that perhaps it
warrants a Matrix Orbital "configurator" program where the user can
answer simple questions about their display which results in a series
of correct parameter settings in LCDd.conf.  Something like this was
proposed for Windows users since "editing .INI files" is alien to most
of them anymore, but even Linux has filtered down from geeks-only to
the point where some hand-holding might be in order.

For now, though, the question I'm putting on the table is if it's
better or worse to make the user set some LCDd.conf parameter like
"HasMulticolorBacklight yes/no" to enable these new commands.
Implementation is easy either way.  It's about what is a greater or
lesser burden to the end-user.

Comments?  Complaints?  Acknowledgments?

-ethan

From junk_inbox at verizon.net  Wed Feb 11 17:36:20 2009
From: junk_inbox at verizon.net (Jeff)
Date: Wed, 11 Feb 2009 12:36:20 -0500
Subject: [Lcdproc] LCDd daemon hangs with USB Crystalfontz 634 LCD
In-Reply-To: <49842446.7070007@ituner.com>
References: <4345451E4BEF4958BD79FC703E4B780C@jartzhome>
	<B3875DA949544633A05058507CEEA665@jartzhome>
	<alpine.LNX.1.00.0901291403060.30137@green.pepper>
	<d569babb0901301551n40054a4ei83083d7e2449aad@mail.gmail.com>
	<alpine.LNX.1.00.0901302245070.3818@green.pepper>
	<49842446.7070007@ituner.com>
Message-ID: <d569babb0902110936j1311bfb6p81900279830337ad@mail.gmail.com>

On Sat, Jan 31, 2009 at 5:13 AM, Nicu Pavel <npavel at ituner.com> wrote:

> Hi,
>
> I don't have a Crystalfontz LCD but I got a similar report on picoLCD 20x4
> with mythTV freezeing the LCD output. Do you have the same problem if you
> run LCDd + lcdproc client ? Either it's something wrong with mythTV LCDd
> client or another process is
> taking over LCD device or there is a problem in driver usb implementation.
> I will check on picoLCD side and post if I find something.
>
> Regards,
> Nicu Pavel


Nicu,

  My init script hangs on the startup of LCDd, which hangs the boot
process.  I disabled the kernel startup of it, and just start it manually at
the moment.  That way it doesn't hang the boot process.

  In my case, the LCDd process spawns the daemon, but then does not exit
itself, so the boot process hangs.  I can easily replicate it by starting it
manually from a command prompt.  Once LCDd is running, the myth lcdproc
server (mythlcdserver) has no problem writing screens to it.

  I owe some additional debug info to Marcus - I should be able to gather
that tonight or tomorrow night.

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

From wyatt at prairieturtle.ca  Wed Feb 11 20:45:41 2009
From: wyatt at prairieturtle.ca (Daryl F)
Date: Wed, 11 Feb 2009 14:45:41 -0600 (CST)
Subject: [Lcdproc] Overloading the 'output' token
In-Reply-To: <f4eb766f0902110840k158cb4c0k30da7eb65cd7611d@mail.gmail.com>
References: <f4eb766f0902082140p249d4408tbc880c032b0559bc@mail.gmail.com>
	<f4eb766f0902110840k158cb4c0k30da7eb65cd7611d@mail.gmail.com>
Message-ID: <alpine.LNX.2.00.0902111432440.15461@green.pepper>

On Wed, 11 Feb 2009, Ethan Dicks wrote:

> Hi, All,
>
> OK... at this point, I think I have things hammered out in my head,
> but I wanted to toss the in-line documentation on my color backlight
> scheme out to the group for comment (in the hopes that it will
> stimulate any)...
>
> /**
> * Set output port(s).
> *
> * At one time, the range of Matrix Orbital products was small enough
> that it was
> * possible to "know" how many GPOs a module was likely to have based
> on some simple
> * characteristics (i.e., displays with keypad had 6 outputs, but simple modules
> * only had one).   Now, it is much more complex.  One of the most convoluted
> * examples is the LK204-7T-1U with the tri-color LED backlight.  In addition to
> * a white backlight for just the built-in keypad and the 256-level
> red, green, and
> * blue backlight LEDs, it has three ordinary off-board GPOs (10mA
> current sink),
> * _plus_ six GPOs that are tied to three on-board bi-color status
> LEDs.  Using the
> * existing GPO scheme, it's possible to twiddle the 3 off-board GPOs
> and set the
> * on-board LEDs to red, green or "amber" (both red and green lit).
> *
> * The keypad backlight and LCD backlight are controlled with Matrix Orbital
> * commands that are different from the GPO commands ("W" and "V"), but in the
> * present (0.5.2) LCDproc model, it seems reasonable to use the 'output'
> * keyword to control the color of the backlight as well (backlight on/off is
> * still controlled by the same commands as on other Matrix Orbital displays,
> * but the specific color is independent of that).
> *
> * Since the LK204-7T-1U already has nine formal GPOs and since 'output' passes
> * an "int" from the client through the server to the driver, one mechanism that
> * won't break the existing GPO model is to define some of the upper bits in a
> * signed 32-bit int to mean "set backlight color".  It seems unlikely that any
> * LCD will implement more than 28 GPOs, so bits 28 and 29 can be used to select
> * four different results of the output command from the client:
> *
> * 29 28 27...7..0
> *  0  0 NNNNNNNNN  - which GPO to turn on/off with "W"/"V" command
> *  0  1      RRRR  - use low 8-bits for red backlight setting
> *  1  0      GGGG  - use low 8-bits for green backlight setting
> *  1  1      BBBB  - use low 8-bits for blue backlight setting
>
>
> What I have not done yet is to decide if this code needs a new token
> in LCDd.conf to confirm that the user does indeed have a display that
> accepts the tri-color backlight commands.  I only have two textual
> Matrix Orbital displays, an ancient VKD204 that I've written about
> frequently, and this new LK204-7T-1U, so my ability to test commands,
> responses, and errors will be limited.  It certainly is easy enough to
> add a new token "HasMulticolorBacklight" with acceptable args of
> "yes/no" or whatever contextually matches the other drivers as a way
> to wall off code that is specific to units with the tricolor LED
> backlight, but whether it's reasonable to do that or not depends on
> how much we want to burden the user with knowing about his own
> display.
>
> One approach is to just let the user set up an initial color and tweak
> that color with the modified 'output' arg that I've been proposing -
> if they have a tricolor backlight it'll just work.  If they don't,
> then I'm thinking the display will complain that it was sent an
> invalid command which it will ignore.  The problem is that may lead to
> garbage characters on displays that don't have that as a valid MtxOrb
> command.  I'm not proposing to enable tricolor backlight control in
> LCDd.conf by default, so out of the box, all Matrix Orbital displays
> would work and work fine.  Where they might get messed up is if the
> user removed the comment in LCDd.conf for the initial backlight color
> setting or if they ran a tricolor-aware client that happened to send
> output commands with the high bits enabled.  The "safe" approach is to
> require the user to enable these commands in LCDd.conf, but given that
> many LCDproc users are unsophisticated, adding more and more options
> into LCDd.conf can be considered a hindrance, especially for the users
> who are unable to figure out what's wrong when things don't look neat
> and clean.
>
> I wish there were a way to automatically detect tricolor backlight
> support, but as we've seen with GPOs and backlights, etc., there are
> so many new and old Matrix Orbital displays with re-use of identifier
> codes, etc., that there is no practical way to query the unit to see
> exactly what features it supports.  Even if they did add that as a
> feature in the future, it still wouldn't help the dozens of models
> that are in the real world right now.  It's simpler with other brands
> since they don't have 10+ years of LCD models with subtle changes
> between models, but I still think it's worth a good effort to support
> as many kinds of Matrix Orbital displays as reasonably possible.  The
> cost, though, is shifting some of the burden to the end-user who will
> actually be required to know something about the product he purchased
> and what it can do.  It is a complex enough issue that perhaps it
> warrants a Matrix Orbital "configurator" program where the user can
> answer simple questions about their display which results in a series
> of correct parameter settings in LCDd.conf.  Something like this was
> proposed for Windows users since "editing .INI files" is alien to most
> of them anymore, but even Linux has filtered down from geeks-only to
> the point where some hand-holding might be in order.
>
> For now, though, the question I'm putting on the table is if it's
> better or worse to make the user set some LCDd.conf parameter like
> "HasMulticolorBacklight yes/no" to enable these new commands.
> Implementation is easy either way.  It's about what is a greater or
> lesser burden to the end-user.
>
> Comments?  Complaints?  Acknowledgments?
>
> -ethan

For two reasons I'd say use "HasMulticolorBacklight yes/no" and set the 
default default to "no".

First, since it is unknown how older devices will respond. It would be 
better if they worked more often. This way, even though the newer device 
won't have colored backlight at least all devices will display correctly, 
without garbled characters or lockups. In the case of a user going from 
Windows to Linux, they've likely seen their device work correctly. If it 
had color before and now doesn't they may note that but will also see that 
it is still displaying readable information. But should a Windows user 
with an older device suddenly find it is displaying garbled characters or 
not working at all they may abandon lcdproc or Linux as "not working".

Second, because of where I think the role of lcdproc developers are in the 
bigger scheme of "new to Linux users". It is up to integrators, like 
Gentoo or Redhat, to write the hand-holding configurators that will ease 
the path, not driver developers. Some distributions are targeted to 
Windows users, like Ubuntu, others like Gentoo appeal to those who don't 
mind learning by doing (tweaking). Ubuntu might give them an nice multiple 
choice quiz interspersed with probing the device where Gentoo might give 
them a written "Howto Configure lcdproc" document.

Just my .02 of a dollar on the question. And kudos for your work on the 
drivers.

-Daryl Fonseca-Holt

From ethan.dicks at gmail.com  Wed Feb 11 21:26:48 2009
From: ethan.dicks at gmail.com (Ethan Dicks)
Date: Wed, 11 Feb 2009 16:26:48 -0500
Subject: [Lcdproc] Overloading the 'output' token
In-Reply-To: <alpine.LNX.2.00.0902111432440.15461@green.pepper>
References: <f4eb766f0902082140p249d4408tbc880c032b0559bc@mail.gmail.com>
	<f4eb766f0902110840k158cb4c0k30da7eb65cd7611d@mail.gmail.com>
	<alpine.LNX.2.00.0902111432440.15461@green.pepper>
Message-ID: <f4eb766f0902111326p3be18e84kab35bc4c672eff2c@mail.gmail.com>

Hi, Daryl,

Thanks for responding.

On Wed, Feb 11, 2009 at 3:45 PM, Daryl F <wyatt at prairieturtle.ca> wrote:
>On Wed, 11 Feb 2009, Ethan Dicks wrote:
>> For now, though, the question I'm putting on the table is if it's
>> better or worse to make the user set some LCDd.conf parameter like
>> "HasMulticolorBacklight yes/no" to enable these new commands.
>> Implementation is easy either way.  It's about what is a greater or
>> lesser burden to the end-user.
>>
>> Comments?  Complaints?  Acknowledgments?
>>
>> -ethan
>
> For two reasons I'd say use "HasMulticolorBacklight yes/no" and set the
> default default to "no".
>
> First, since it is unknown how older devices will respond. It would be
> better if they worked more often. This way, even though the newer device
> won't have colored backlight at least all devices will display correctly,
> without garbled characters or lockups.

It certainly is the safer alternative, but having seen some traffic
on the list about how LCDd.conf is "too complicated", I wanted to
throw the issue out for some examination.

I'm personally not opposed to it, but perhaps someone out there is
thinking, "Ghod!  Not more stuff in LCDd.conf you have to set".

> Second, because of where I think the role of lcdproc developers are in the
> bigger scheme of "new to Linux users". It is up to integrators, like Gentoo
> or Redhat, to write the hand-holding configurators that will ease the path,
> not driver developers.

Hmm... while it would be nice to push the issue out to the distros, are they
really going to do anything with LCDproc that doesn't come out of the box?
I can see a distro maintainer being willing to whip together some simple
init script to start LCDd automatically (whether it releases or not is another
problem that's been all over the list this month), but I'm thinking that if
LCDproc doesn't come pretty much ready to integrate into most popular
distros, it's going to be left out as too much hassle to include.

> Some distributions are targeted to Windows users,
> like Ubuntu, others like Gentoo appeal to those who don't mind learning by
> doing (tweaking). Ubuntu might give them an nice multiple choice quiz
> interspersed with probing the device where Gentoo might give them a written
> "Howto Configure lcdproc" document.

OK... while that makes sense in principle, who writes that?  Who maintains that?
The driver writers know more than anyone about what needs to go into LCDd.conf,
certainly on a driver-by-driver basis.  Is it reasonable to push a
requirement to
understand how even the 20 most popular drivers work onto someone who is
mostly interested in just gathering interesting and cool packages into a distro?
If the answer is 'yes', then OK, but it seems to me that LCDproc could enjoy a
pretty wide distro-based availability if we (the LCDproc developers) meet the
distro guys more than halfway.  Where that point is, I'm not certain,
but I think
we should be willing to go much more than halfsies.

LCDproc supports a *lot* of types of hardware; so many that it's both advantage
and a disadvantage at the same time.  Obviously, since I've worked on multiple
drivers stretching over 10 years, I don't have a problem with digging deep into
the code to fix something, but I've been a professional software
developer a long
time, and I've come to learn (sometimes the hard way ;-) that what's easy and
obvious to me is rarely easy and obvious to "users".

> Just my .02 of a dollar on the question. And kudos for your work on the
> drivers.

Thank you.  I appreciate your input, so please don't take what I've written as
criticism or refutation.  I'm just not sure we have the same expectation of
what to count on from distro maintainers.

Unless someone weighs in with a persuasive argument against adding a
line to LCDd.conf to "EnableMulticolorBacklight" (no nitpicks about Color vs
Colour, please ;-), I'm likely to have something coded up and submitted as
a patch to MtxOrb.c pretty soon.  Right now, I'm fiddling the colors with a
standalone script to bypass LCDd and go right down the pipe, and want to
get some "real support" for this.

I'm having problems finding any concrete references, but isn't there at least
one more module out there that has user-controllable backlight color?  I know
it's not available on every street corner, but I thought there were a
couple that
at least could do simple bi- or tri-color.  If I know what hardware is
out there,
it makes it easier to pick a mechanism that I don't regret later.

Thanks, and keep those cards and letters coming,

-ethan

From herdler at gmx.de  Thu Feb 12 00:22:46 2009
From: herdler at gmx.de (Stefan Herdler)
Date: Thu, 12 Feb 2009 01:22:46 +0100
Subject: [Lcdproc] Overloading the 'output' token
In-Reply-To: <f4eb766f0902082140p249d4408tbc880c032b0559bc@mail.gmail.com>
References: <f4eb766f0902082140p249d4408tbc880c032b0559bc@mail.gmail.com>
Message-ID: <49936BD6.30908@gmx.de>

Hi,

Ethan Dicks wrote:
> It probably won't take me more than a couple of hours to code up and
> test this change to MtxOrb.c, so I'm wondering if anyone has any
> opinions one way or the other about this technique.  As it stands, the
> documentation does warn that the value passed to 'output' is
> driver-specific.  More than most, the Matrix Orbital driver has to
> handle a variety of GPO configurations from LCDs to VFDs, new, old,
> etc.  It seems unlikely (I know... famous last words) that anyone will
> produce an LCD with more than 16 GPOs (let alone 24), but I would
> never dare to say that it will never happen.
>   
a few weeks ago (late December) there had been a thread about 
controlling special icons on display.

My suggestion was to create a kind of all-purpose interface to enable 
the clients sending display specific commands to the driver.

The first approaches looked promising to me, but sadly the development 
stalled, due to lack of response.


I personally don't own a display that would support that features, but 
from the side of the client author I appreciate a official and "clean" 
way to handle this "extended" features.

Regards Stefan

From ethan.dicks at gmail.com  Thu Feb 12 00:56:58 2009
From: ethan.dicks at gmail.com (Ethan Dicks)
Date: Wed, 11 Feb 2009 19:56:58 -0500
Subject: [Lcdproc] Overloading the 'output' token
In-Reply-To: <49936BD6.30908@gmx.de>
References: <f4eb766f0902082140p249d4408tbc880c032b0559bc@mail.gmail.com>
	<49936BD6.30908@gmx.de>
Message-ID: <f4eb766f0902111656j6ba6fba1y24c2201c10f69fc8@mail.gmail.com>

On Wed, Feb 11, 2009 at 7:22 PM, Stefan Herdler <herdler at gmx.de> wrote:
> Hi,
>
> Ethan Dicks wrote:
>>
>> It probably won't take me more than a couple of hours to code up and
>> test this change to MtxOrb.c... It seems unlikely (I know... famous last
>> words) that anyone will produce an LCD with more than 16 GPOs (let
>> alone 24), but I would never dare to say that it will never happen.
>>
>
> a few weeks ago (late December) there had been a thread about controlling
> special icons on display.

Yes. I recall.  It was specific to a particular display, not a Matrix
Orbital display
(relevant because 'output' is driver-specific).

> My suggestion was to create a kind of all-purpose interface to enable the
> clients sending display specific commands to the driver.
>
> The first approaches looked promising to me, but sadly the development
> stalled, due to lack of response.

Given the existing client-server protocol we have to work with, I can't envison
a solution to the icon/GPO problem that handles all existing displays, let alone
any that might come to market in the near future.

The present protocol is quite old and is unextensible.  It's also not
going to be
changed for any 0.5.x version of LCDproc, so I didn't propose any changes to
the protocol itself.

I have made a simple proposal to handle a specific case (how to pass 8-bit
color values from the client to the server) for a particular driver (MtxOrb.c).
The general case of how to handle more displayable icons on a non-generic
display than fit in a 32-bit (or is it effectively 31-bit, due to
sign?) int is, to me,
a much harder problem to solve.  There are no 24 or 28 _GPO_ displays from
Matrix Orbital, nor are there likely to be (but anything is possible), so my
proposal is somewhat easy to implement in a way that will probably not
break anything.  I'm not inventing a new transport mechanism, just a way to
interpret the values that are already being transported.   I'm fully prepared to
code up whatever I create, but since I myself do not approve patches, I
wanted some discussions so that when I get to the coding stage, I won't
find that my patches are unwelcome and the effort for naught.

> I personally don't own a display that would support that features, but from
> the side of the client author I appreciate a official and "clean" way to
> handle this "extended" features.

Once the discussion opens for a new way for clients and servers to
communicate, there will be plenty of opportunity to discuss things as
specific as DVD/VCR-like media displays that are, in effect, mostly
"icons" (as LCDproc sees them) rather than blocks of plain text, which
is where LCDproc came from 10+ years ago.

I've been using LCDproc a long time (since 0.3.something) - it is *much*
easier to add new drivers and features now than in the bad-old-days.   The
issue for me now is that the hardware guys are coming up with fantastic
stuff that we never could have imagined was available, and it is straining
the boundaries of what LCDproc was set up to do.  Once we get a chance
to start discussing the next incarnation of the product, there are lots of
real-world displays that have unsupported features that will be great fun
to unlock with LCDproc.

I do like the fact that I can write clients that are mostly display-agnostic
(by querying the geometry and perhaps altering what widgets are created
as a result).  I would love to see future versions of LCDproc enhance the
communications between server and client about what "features" the server
is prepared to support (a bazillion icons, GPOs, multi-color this and that,
Dallas 1-wire, less textual interpretation of graphic displays, etc., etc.)  For
now, though, only small steps are possible.

-ethan

P.S. - while writing this, I did just come up with what might be a less
intrusive way to assign a new color value - since we have a 32-bit int,
use the highest bit possible as the selector between "GPO  X"
and "use the low 24-bits for RGB values" (it might look like 'output
0x40RRGGBB' to keep it a positive number).  It reduces the number of
output commands required to set a color; it reduces the risk that the
user will see red change, pause, green change, pause, blue change;
and it leaves the maximum amount of space possible for GPO control.
This would be, of course, specific to the MtxOrb.c driver, leaving 'output'
behavior unaltered for all other drivers.

From ethan.dicks at gmail.com  Thu Feb 12 01:47:44 2009
From: ethan.dicks at gmail.com (Ethan Dicks)
Date: Wed, 11 Feb 2009 20:47:44 -0500
Subject: [Lcdproc] What ever happened to the "NUMGPOs" patch for MtxOrb.c?
Message-ID: <f4eb766f0902111747j634f0968h5a4641775aa2ce4a@mail.gmail.com>

Hi, All,

Pursuant to implementing my proposed changes to MtxOrb.c, I was
surprised to dig into the code to realize that it's hard-coded for one
or six GPOs.  I remember this issue coming up in the not-too-distant
past (a year or two) because of some of the newer Matrix Orbital
displays not strictly following the older pattern of how many GPOs
were available for a particular module (the old scheme is one reason
why the user specifies lkd/vkd vs lcd/vfd in LCDd.conf).

Looking at the code in CVS on SourceForge, I see my changes nearly two
years ago to repair problems with VFDs and VKDs...

Revision 1.101 - (view) (download) (annotate) - [select for diffs]
Sun May 13 12:48:41 2007 UTC (21 months ago) by marschap
Branch: MAIN
Changes since 1.100: +1 -1 lines
Diff to previous 1.100

MtxOrb driver: fix VFD/VKD support (Ethan Dicks)

... but I don't see anything after that relating to allowing/requiring
the user to specify how many GPOs their module has.

The tri-color module I have now happens to have nine GPOs, so it
doesn't fully work with the code from CVS - the three LEDs work, since
they use GPO1-GPO6, but the physical pins on the back (GPO7-GPO9) will
never toggle.

I could re-implement NUMGPOs in a matter of hours, but if it's been
done once, there's little reason to recode the wheel.

Did the submitted patch just never get posted to CVS?  Am I looking in
the wrong place
(<http://lcdproc.cvs.sourceforge.net/viewvc/lcdproc/lcdproc/server/drivers/MtxOrb.c?view=log>)?
 The code I fetched definitely supported a fixed number of GPOs and
that number is one or six.  Did I only see discussion and a proposed
patch but not a formal patch submitted?  I thought I remembered
testing it on my VKD204, but the depths of Winter at the South Pole
plays tricks on ones memory.

Hopefully it's just in the queue to be approved and applied.  Since
the LK204-7T-1U has 9 real GPOs, the true number for real hardware is
no longer either six or one, making it well past time to have a method
of supporting the GPOs that are really there.  I'd rather apply my
fixes to a NUMGPOs version of MtxOrb.c, but I'm itching to get coding,
so I won't wait forever.

I suppose I should also finish my debugging client for GPOs as well as
make some LEDs to be able to watch real GPOs go on and off.  In the
past, mostly I've just seen the commands go through without error or
glitched text on the display and figured it was all working.  Clearly
a more formal approach is needed.

-ethan

From avdongen at xs4all.nl  Thu Feb 12 08:32:20 2009
From: avdongen at xs4all.nl (Arthur van Dongen)
Date: Thu, 12 Feb 2009 09:32:20 +0100
Subject: [Lcdproc] [Fwd: Re:  Overloading the 'output' token]
Message-ID: <1234427540.4677.34.camel@TangoLinux.lan>


Hi,
-------- Forwarded Message --------
> From: Ethan Dicks <ethan.dicks at gmail.com>
> To: lcdproc at lists.omnipotent.net
> Subject: Re: [Lcdproc] Overloading the 'output' token
> Date: Wed, 11 Feb 2009 19:56:58 -0500
> 
> On Wed, Feb 11, 2009 at 7:22 PM, Stefan Herdler <herdler at gmx.de> wrote:
> > Hi,
> >
> > Ethan Dicks wrote:
> >>
> >> It probably won't take me more than a couple of hours to code up and
> >> test this change to MtxOrb.c... It seems unlikely (I know... famous last
> >> words) that anyone will produce an LCD with more than 16 GPOs (let
> >> alone 24), but I would never dare to say that it will never happen.
> >>
> >
> > a few weeks ago (late December) there had been a thread about controlling
> > special icons on display.
> 
> Yes. I recall.  It was specific to a particular display, not a Matrix
> Orbital display
> (relevant because 'output' is driver-specific).
> 
I was the one who started that thread. It touched the 'output'
functionality because the current driver had the 'icons' on the glass
available through 'output' commands. I thought I could implement better
support for these icons in the Christmas period, but did not succeed in
the time I had. 

> > My suggestion was to create a kind of all-purpose interface to enable the
> > clients sending display specific commands to the driver.
> >
> > The first approaches looked promising to me, but sadly the development
> > stalled, due to lack of response.
> 
> Given the existing client-server protocol we have to work with, I can't envison
> a solution to the icon/GPO problem that handles all existing displays, let alone
> any that might come to market in the near future.
> 
> The present protocol is quite old and is unextensible.  It's also not
> going to be
> changed for any 0.5.x version of LCDproc, so I didn't propose any changes to
> the protocol itself.
> 
> I have made a simple proposal to handle a specific case (how to pass 8-bit
> color values from the client to the server) for a particular driver (MtxOrb.c).
> The general case of how to handle more displayable icons on a non-generic
> display than fit in a 32-bit (or is it effectively 31-bit, due to
> sign?) int is, to me,
> a much harder problem to solve.  There are no 24 or 28 _GPO_ displays from
> Matrix Orbital, nor are there likely to be (but anything is possible), so my
> proposal is somewhat easy to implement in a way that will probably not
> break anything.  I'm not inventing a new transport mechanism, just a way to
> interpret the values that are already being transported.   I'm fully prepared to
> code up whatever I create, but since I myself do not approve patches, I
> wanted some discussions so that when I get to the coding stage, I won't
> find that my patches are unwelcome and the effort for naught.

I see two problems when hijacking the 'output' commands for controlling
the backlight. The first is that the value set in the 'output' command
is buffered, and only written to the driver periodically. So you cannot
use numeric commands like the 32-bit color command, and the lower bits
to control the output pins at the same time.
The other problem is that the output interface could work well if you
configure the _client_ which pin means what. But backlight/vfd
illumination is a common thing that should have a dedicated command. 
> 
> > I personally don't own a display that would support that features, but from
> > the side of the client author I appreciate a official and "clean" way to
> > handle this "extended" features.
> 
> Once the discussion opens for a new way for clients and servers to
> communicate, there will be plenty of opportunity to discuss things as
> specific as DVD/VCR-like media displays that are, in effect, mostly
> "icons" (as LCDproc sees them) rather than blocks of plain text, which
> is where LCDproc came from 10+ years ago.
> 
> I've been using LCDproc a long time (since 0.3.something) - it is *much*
> easier to add new drivers and features now than in the bad-old-days.   The
> issue for me now is that the hardware guys are coming up with fantastic
> stuff that we never could have imagined was available, and it is straining
> the boundaries of what LCDproc was set up to do.  Once we get a chance
> to start discussing the next incarnation of the product, there are lots of
> real-world displays that have unsupported features that will be great fun
> to unlock with LCDproc.
> 
> I do like the fact that I can write clients that are mostly display-agnostic
> (by querying the geometry and perhaps altering what widgets are created
> as a result).  I would love to see future versions of LCDproc enhance the
> communications between server and client about what "features" the server
> is prepared to support (a bazillion icons, GPOs, multi-color this and that,
> Dallas 1-wire, less textual interpretation of graphic displays, etc., etc.)  For
> now, though, only small steps are possible.
I agree that changes to the interface at this point should be avoided.
But I would suggest to make an exception for controlling the
backlight/illumination, because otherwise different drivers would go in
diverging directions. I've seen that happen in the icon business: one
driver uses the 'output' command, another the 'icon' command. For very
similar things...
> 
> -ethan
> 
> P.S. - while writing this, I did just come up with what might be a less
> intrusive way to assign a new color value - since we have a 32-bit int,
> use the highest bit possible as the selector between "GPO  X"
> and "use the low 24-bits for RGB values" (it might look like 'output
> 0x40RRGGBB' to keep it a positive number).  It reduces the number of
> output commands required to set a color; it reduces the risk that the
> user will see red change, pause, green change, pause, blue change;
> and it leaves the maximum amount of space possible for GPO control.
> This would be, of course, specific to the MtxOrb.c driver, leaving 'output'
> behavior unaltered for all other drivers.
> _______________________________________________
> LCDproc mailing list
> LCDproc at lists.omnipotent.net
> http://lists.omnipotent.net/mailman/listinfo/lcdproc

BR,
Arthur


From ethan.dicks at gmail.com  Thu Feb 12 15:12:44 2009
From: ethan.dicks at gmail.com (Ethan Dicks)
Date: Thu, 12 Feb 2009 10:12:44 -0500
Subject: [Lcdproc] [Fwd: Re: Overloading the 'output' token]
In-Reply-To: <1234427540.4677.34.camel@TangoLinux.lan>
References: <1234427540.4677.34.camel@TangoLinux.lan>
Message-ID: <f4eb766f0902120712l3940d15fleeb629403a9cb139@mail.gmail.com>

On Thu, Feb 12, 2009 at 3:32 AM, Arthur van Dongen <avdongen at xs4all.nl> wrote:
>> > Ethan Dicks wrote:
>> >>
>> >> It probably won't take me more than a couple of hours to code up and
>> >> test this change to MtxOrb.c...

It didn't.  I have something working now.  It's not without drawbacks,
but I can allow a client to set the backlight color directly _and_
control the onboard GPOs.

>> > a few weeks ago (late December) there had been a thread about controlling
>> > special icons on display.
>
> I was the one who started that thread. It touched the 'output'
> functionality because the current driver had the 'icons' on the glass
> available through 'output' commands. I thought I could implement better
> support for these icons in the Christmas period, but did not succeed in
> the time I had.

Right... but wasn't one of the problems that there were more than 32
icons to control?

Turns out, because the server parse code uses strtol(), the limit is
31 bits.  I tested that last night.  If you send 0xffffffff as an arg
to output, you get an overflow message in the server message logs.
The largest number you can send (without code changes) is 0x7fffffff.
There is strtoll(), and it's always possible to roll our own numeric
parser routine, but even so, in a 32-bit environment, without
extensive code changes, the limit is going to be the signed int that
gets handed around throughout the server code.

>> I have made a simple proposal to handle a specific case (how to pass 8-bit
>> color values from the client to the server) for a particular driver (MtxOrb.c).
>> The general case of how to handle more displayable icons on a non-generic
>> display than fit in a... 31-bit...int is, to me,
>> a much harder problem to solve.

> I see two problems when hijacking the 'output' commands for controlling
> the backlight. The first is that the value set in the 'output' command
> is buffered, and only written to the driver periodically.

True.  It is buffered and it does take a noticeable amount of time for
the change to be enacted.  One consequence is that the client I wrote
to twiddle GPOs has to sleep for a second or else it won't keep the
socket open long enough for the output change to be picked up by the
server.

> So you cannot
> use numeric commands like the 32-bit color command, and the lower bits
> to control the output pins at the same time.

I don't think you got the salient point of my proposal... you turn on
bit 30 and use the low 24 bits as color, _or_ you leave bit 30 off and
use the low bits (6 presently) as GPO settings.  Because of how I've
staged the bit checking in MtxOrb_output(), even though the function
gets called repeatedly with the same value since the last output
command was sent from a client, the colors and/or GPOs are stable.

It's true that you cannot issue one output command that sets the
backlight color _and_ twiddles GPOs.  There just isn't enough room in
31 bits for that on a Matrix Orbital display (especially not one that
already has nine real GPOs).  The idea I had was that changing color
would be an infrequent sort of thing.  Now that I see how long it
takes, I'm certain that it would be infrequent.

> The other problem is that the output interface could work well if you
> configure the _client_ which pin means what. But backlight/vfd
> illumination is a common thing that should have a dedicated command.

I agree.  It should have a dedicated command.  I've added one to set
an initial color from user-selected parameters in LCDd.conf.  What I
was trying to do additionally is to come up with some way to
dynamically change the color after LCDd starts.  To that end, what I
have working now does just that.  It's slow and a tiny bit cumbersome,
but it does work.

> I agree that changes to the interface at this point should be avoided.
> But I would suggest to make an exception for controlling the
> backlight/illumination, because otherwise different drivers would go in
> diverging directions. I've seen that happen in the icon business: one
> driver uses the 'output' command, another the 'icon' command. For very
> similar things...

I'd go a little farther than that - _discussions_ of changes to the
interface should be avoided, because it's just not going to happen.
Not for 0.5.anything.  What we have is what we have.  We can discuss
how to make things better for the next version of LCDproc, and at some
point, we _should_ discuss it, but it's going to be a long, long time
before anything happens.

LCDproc started as a way to abstract talking to a specific product, a
Matrix Orbital serial-interfaced 20x4 textual LCD with eight
user-definable characters and hbar, vbar and bignum support in
firmware.  It grew to encompass new geometries, new interfaces, and a
large variety of devices which are not so similar to a 20x4
HD44780-based display.  The market continues to produce fancier and
fancier displays which are still simple to talk to, but have features
that couldn't have been conceived of ten years ago, so the software
lags the market rather badly.  Rendering text has been pretty well
covered for every version of LCDproc.  The support for keypads and
small numbers of outputs and special features has worked pretty well
too.   The place it goes pear-shaped is all the unique and fancy
features of premium displays.  For the lowest common denominator, it's
all fine.  For the extra features with top-shelf hardware, though,
there's just no conceptual framework in the LCDproc model to fit them
in.

Would it be simple to add code to handle a new client-server message
to twiddle backlight colors?  Yes.  Utterly simple.  Do I have that
option?  No.  So, I have proposed an imperfect solution for the
present environment.  I am open to discussions about how it could be
better, which is why I brought it up first before coding line 1 (and
I'm glad I did because my second idea was much more workable than my
first).

Thinking on the greater scope, what level of abstraction is reasonable
for backlight color choices?  One model is that there is an initial
color, but that either alerts (flashing backlight sorts of things now)
or client requests could pick a new color.  Perhaps the mechanism
should be like heartbeat is now - on, off, or open.  Lock color
changes to the server vs allowing clients to change it.  If clients
can change it, the next choice is for only themselves or for all
clients?  I can see both being useful.  If it would be distracting to
see cycles of colors, then let one client tune the backlight control
according to the current user's current preference, and leave it alone
after that.  If it would be informative to associate red hues with
high-temp or low-diskspace situations, that could be worked in, too.
Less aggressive colors (blues, greens, purples, yellows...) could be
used to tie in with network or disk or CPU activity so that as the
screen change, you'd know at a glance what data is rendered on them
because you recognize the color first.

Given how cheaply RGB LEDs are anymore, I can't imagine that this
feature won't continue to expand across more and more displays.  I can
even envision a simple 3-bit RGB backlight for a hobby-level MCU or
parallel attachment display as a future hardware project.  There's
even the Ambient Orb (and at least one hobby-level knockoff) for which
color is the primary informational channel.  LEDs are cheap and people
like colored blinkies.  I'd love to see some discussion about how
tuned color can be worked into LCDproc in a less kludgy manner than
hijacking an existing command.  First and foremost, then, is probably
who (clients vs server) can control the backlight color and when and
under what circumstances and who gets priority over whom.  Come up
with some scenarios where LCDproc is enhanced by the use of color and
we're off to a great start.  I've already made some suggestions above.
 Anyone else, imagine for a moment that all displays have color
control for free - how do you use it?  What do you use it for?

-ethan

From rw at nelianur.org  Fri Feb 13 00:29:11 2009
From: rw at nelianur.org (Rene Wagner)
Date: Fri, 13 Feb 2009 01:29:11 +0100
Subject: [Lcdproc] Overloading the 'output' token
In-Reply-To: <f4eb766f0902111656j6ba6fba1y24c2201c10f69fc8@mail.gmail.com>
References: <f4eb766f0902082140p249d4408tbc880c032b0559bc@mail.gmail.com>
	<49936BD6.30908@gmx.de>
	<f4eb766f0902111656j6ba6fba1y24c2201c10f69fc8@mail.gmail.com>
Message-ID: <1234484951.8698.59.camel@antarctica.nelianur.org>

[Merely take the following as food for thought. I haven't seen/touched
 any LCDproc code in ages...]

On Wed, 2009-02-11 at 19:56 -0500, Ethan Dicks wrote:
> Given the existing client-server protocol we have to work with, I can't envison
> a solution to the icon/GPO problem that handles all existing displays, let alone
> any that might come to market in the near future.
> 
> The present protocol is quite old and is unextensible.  It's also not
> going to be
> changed for any 0.5.x version of LCDproc, so I didn't propose any changes to
> the protocol itself.

It's a thin line. Adding to the protocol for each and every slight
variation to the way displays have worked in the past is probably not a
good idea. Squeezing new functionality into the existing protocol on the
other hand can be problematic, too.

Personally, I'd prefer a clean protocol in the sense that it represents
what the individual commands actually do even if that requires protocol
extensions. Additional commands don't break compatibility after all.

I'm not saying this is the definite answer to your question, but I
thought I'd mention it as an option.

> I do like the fact that I can write clients that are mostly display-agnostic
> (by querying the geometry and perhaps altering what widgets are created
> as a result).  I would love to see future versions of LCDproc enhance the
> communications between server and client about what "features" the server
> is prepared to support (a bazillion icons, GPOs, multi-color this and that,
> Dallas 1-wire, less textual interpretation of graphic displays, etc., etc.)  For
> now, though, only small steps are possible.

I like the idea. Many widely used protocols have this sort of mechanism:
a baseline "always supported" protocol core and a way of negotiating
what other optional features are supported.

Maybe this is indeed more of a long term goal, but maybe it's worth
considering whether the type of functionality mentioned in this thread 
can be wrapped in a new command or two more elegantly than by means of
"output".

In any case, keep up the good work!

Regards,

Rene


From herdler at gmx.de  Fri Feb 13 01:19:24 2009
From: herdler at gmx.de (Stefan Herdler)
Date: Fri, 13 Feb 2009 02:19:24 +0100
Subject: [Lcdproc] Overloading the 'output' token
In-Reply-To: <f4eb766f0902111656j6ba6fba1y24c2201c10f69fc8@mail.gmail.com>
References: <f4eb766f0902082140p249d4408tbc880c032b0559bc@mail.gmail.com>	<49936BD6.30908@gmx.de>
	<f4eb766f0902111656j6ba6fba1y24c2201c10f69fc8@mail.gmail.com>
Message-ID: <4994CA9C.2040309@gmx.de>

Ethan Dicks wrote:
> On Wed, Feb 11, 2009 at 7:22 PM, Stefan Herdler <herdler at gmx.de> wrote:
>   
>> Hi,
>>
>> Ethan Dicks wrote:
>>     
>>> It probably won't take me more than a couple of hours to code up and
>>> test this change to MtxOrb.c... It seems unlikely (I know... famous last
>>> words) that anyone will produce an LCD with more than 16 GPOs (let
>>> alone 24), but I would never dare to say that it will never happen.
>>>
>>>       
>> a few weeks ago (late December) there had been a thread about controlling
>> special icons on display.
>>     
>
> Yes. I recall.  It was specific to a particular display, not a Matrix
> Orbital display
> (relevant because 'output' is driver-specific).
>
>   
Yes, it was just meant as hint that others are having similar problems 
sending display-specific commands to the display.
>> My suggestion was to create a kind of all-purpose interface to enable the
>> clients sending display specific commands to the driver.
>>
>> The first approaches looked promising to me, but sadly the development
>> stalled, due to lack of response.
>>     
>
> Given the existing client-server protocol we have to work with, I can't envison
> a solution to the icon/GPO problem that handles all existing displays, let alone
> any that might come to market in the near future.
>   
My plan was to add a function the client can use to send numeric values 
directly to the driver.
The names and possible ranges of the variables would be defined in the 
driver.
The client should also be able to query the possible variable names and 
ranges.

Any function of a display i could imagine so far would be controllable e.g.:
Icon, functions: on off blinking -> 1, 0, -1
Bargraph, percent, percent blinking -> 0 ... 100 , -1 ... -100
Brightness , percent -> 0 ... 100
GPIOx , boolean -> 0 ,1
....

This is a practically future proof concept I think.
> The present protocol is quite old and is unextensible.  It's also not
> going to be
> changed for any 0.5.x version of LCDproc, so I didn't propose any changes to
> the protocol itself.
>
>   
> I have made a simple proposal to handle a specific case (how to pass 8-bit
> color values from the client to the server) for a particular driver (MtxOrb.c).
> The general case of how to handle more displayable icons on a non-generic
> display than fit in a 32-bit (or is it effectively 31-bit, due to
> sign?) int is, to me,
> a much harder problem to solve.  There are no 24 or 28 _GPO_ displays from
> Matrix Orbital, nor are there likely to be (but anything is possible), so my
> proposal is somewhat easy to implement in a way that will probably not
> break anything.  I'm not inventing a new transport mechanism, just a way to
> interpret the values that are already being transported.   I'm fully prepared to
> code up whatever I create, but since I myself do not approve patches, I
> wanted some discussions so that when I get to the coding stage, I won't
> find that my patches are unwelcome and the effort for naught.
>
>   
At the other hand you (and everyone with the intension to send commands 
to a driver) are wasting much time trying to squeeze the data somehow 
through the 'output' function.
>> I personally don't own a display that would support that features, but from
>> the side of the client author I appreciate a official and "clean" way to
>> handle this "extended" features.
>>     
>
> Once the discussion opens for a new way for clients and servers to
> communicate, there will be plenty of opportunity to discuss things as
> specific as DVD/VCR-like media displays that are, in effect, mostly
> "icons" (as LCDproc sees them) rather than blocks of plain text, which
> is where LCDproc came from 10+ years ago.
>
> I've been using LCDproc a long time (since 0.3.something) - it is *much*
> easier to add new drivers and features now than in the bad-old-days.   The
> issue for me now is that the hardware guys are coming up with fantastic
> stuff that we never could have imagined was available, and it is straining
> the boundaries of what LCDproc was set up to do.  Once we get a chance
> to start discussing the next incarnation of the product, there are lots of
> real-world displays that have unsupported features that will be great fun
> to unlock with LCDproc.
>
> I do like the fact that I can write clients that are mostly display-agnostic
> (by querying the geometry and perhaps altering what widgets are created
> as a result).  I would love to see future versions of LCDproc enhance the
> communications between server and client about what "features" the server
> is prepared to support (a bazillion icons, GPOs, multi-color this and that,
> Dallas 1-wire, less textual interpretation of graphic displays, etc., etc.)  For
> now, though, only small steps are possible.
>   
I agree, it takes time to add support for new display-features to the 
server.

But we are talking about very special features supported by only a few 
displays. I don't think it is possible to control all this features 
(e.g. different Icons) of the different displays by the servercore. In 
such a case it would it would be useful to have the possibility to 
control this features directly by a client.

Well, with the 'output' function it is already possible but it is 
defiantly not user friendly.

...just my 2 cents, regards

Stefan
> -ethan
>
> P.S. - while writing this, I did just come up with what might be a less
> intrusive way to assign a new color value - since we have a 32-bit int,
> use the highest bit possible as the selector between "GPO  X"
> and "use the low 24-bits for RGB values" (it might look like 'output
> 0x40RRGGBB' to keep it a positive number).  It reduces the number of
> output commands required to set a color; it reduces the risk that the
> user will see red change, pause, green change, pause, blue change;
> and it leaves the maximum amount of space possible for GPO control.
> This would be, of course, specific to the MtxOrb.c driver, leaving 'output'
> behavior unaltered for all other drivers.
> _______________________________________________
> LCDproc mailing list
> LCDproc at lists.omnipotent.net
> http://lists.omnipotent.net/mailman/listinfo/lcdproc
>
>   


From ethan.dicks at gmail.com  Fri Feb 13 06:37:11 2009
From: ethan.dicks at gmail.com (Ethan Dicks)
Date: Fri, 13 Feb 2009 01:37:11 -0500
Subject: [Lcdproc] Cheap version of the AmbientOrb anyone?
Message-ID: <f4eb766f0902122237l1c2f36fapa23d00cbd82b4c45@mail.gmail.com>

All,

USB-interface multicolor cube, $17 at many places...

<http://www.usbgeek.com/prod_detail.php?prod_id=0922>

I haven't been able to see where anyone has hacked it much yet (just
one forum where someone used the green signal to trigger some sort of
USB dancing owl), but it appears to be a single Sharp GM5WA06270A
tri-color SMT "chip" LED, and a blob-encapsulated USB controller and
LED driver.  Digging on Digikey and Mouser, that model of Sharp LED
runs $6 in single-unit quantities but drops a bit by the tens or
hundreds.  If nobody wants to figure out how to talk to a real USB
Webmail Notifier (I'm guessing there are no Linux drivers for it), it
wouldn't really be all that hard or all that expensive to merely
emulate the behavior with something like an ATmega8, as seen in Till
Harbaum's lcd2usb (which I know for certain already works fine with
LCDproc since I have one).

...or here's a DIY color LED e-mail signal/indicator using a little
more hardware than I was envisioning...

<http://hackaday.com/2008/09/28/email-notification-via-an-rgb-led/>

However it's done, it seems to me that a device like this could be
thought of like an LK204-7T-1U without the LCD.  The problem to be
solved is the same - what's the most logical way to have either LCDd
or a client program twiddle colors and under what circumstances.

I knew there'd be plenty of this sort of device someday.  I didn't
realize that there are already so many out there.

So no new questions from me, just a couple of datapoints to show how
common this sort of thing is getting to suggest why this will need a
real solution someday.

-ethan

From joerg.hohwieler at pyramid.de  Fri Feb 13 14:21:57 2009
From: joerg.hohwieler at pyramid.de (=?ISO-8859-1?Q?J=F6rg_Hohwieler?=)
Date: Fri, 13 Feb 2009 15:21:57 +0100
Subject: [Lcdproc] pyramid lcd
In-Reply-To: <49900320.3070408@pyramid.de>
References: <49900320.3070408@pyramid.de>
Message-ID: <49958205.600@pyramid.de>

Anyone out there who can tell me why some screens don't work?


Best regards
Joerg


J?rg Hohwieler wrote:
> Hi,
>
> I'm having some issues with lcdproc-client in conjunction with the
> Pyramid LCD,
> which is a 2x16 display.
>
> The lcdproc-client supports several screen commands.
>
> The only screens that work with the display are:
> P
> N
> G
> L
>
> Is this an expected behaviour due to limitations by the display size?
>
>
> The other screens won't show anything on the display when executed
> whereas the 4 mentioned screens above immediately show up on the display.
>
> I tested with current CVS version of lcdproc.
>
>
> Best regards
> Joerg
>
>   

From rmolenkamp at matrixorbital.ca  Fri Feb 13 16:19:04 2009
From: rmolenkamp at matrixorbital.ca (Ray Molenkamp)
Date: Fri, 13 Feb 2009 09:19:04 -0700
Subject: [Lcdproc] Cheap version of the AmbientOrb anyone?
In-Reply-To: <f4eb766f0902122237l1c2f36fapa23d00cbd82b4c45@mail.gmail.com>
References: <f4eb766f0902122237l1c2f36fapa23d00cbd82b4c45@mail.gmail.com>
Message-ID: <49959D78.7070702@matrixorbital.ca>

Ethan,

Googled a bit for their software, by the looks of it its a simple
USB HID device so shouldn't require any special driver,
I doubt you'll have much trouble getting this running with linux.

--Ray


Ethan Dicks wrote:
> All,
>
> USB-interface multicolor cube, $17 at many places...
>
> <http://www.usbgeek.com/prod_detail.php?prod_id=0922>
>
> I haven't been able to see where anyone has hacked it much yet (just
> one forum where someone used the green signal to trigger some sort of
> USB dancing owl), but it appears to be a single Sharp GM5WA06270A
> tri-color SMT "chip" LED, and a blob-encapsulated USB controller and
> LED driver.  Digging on Digikey and Mouser, that model of Sharp LED
> runs $6 in single-unit quantities but drops a bit by the tens or
> hundreds.  If nobody wants to figure out how to talk to a real USB
> Webmail Notifier (I'm guessing there are no Linux drivers for it), it
> wouldn't really be all that hard or all that expensive to merely
> emulate the behavior with something like an ATmega8, as seen in Till
> Harbaum's lcd2usb (which I know for certain already works fine with
> LCDproc since I have one).
>
> ...or here's a DIY color LED e-mail signal/indicator using a little
> more hardware than I was envisioning...
>
> <http://hackaday.com/2008/09/28/email-notification-via-an-rgb-led/>
>
> However it's done, it seems to me that a device like this could be
> thought of like an LK204-7T-1U without the LCD.  The problem to be
> solved is the same - what's the most logical way to have either LCDd
> or a client program twiddle colors and under what circumstances.
>
> I knew there'd be plenty of this sort of device someday.  I didn't
> realize that there are already so many out there.
>
> So no new questions from me, just a couple of datapoints to show how
> common this sort of thing is getting to suggest why this will need a
> real solution someday.
>
> -ethan
> _______________________________________________
> LCDproc mailing list
> LCDproc at lists.omnipotent.net
> http://lists.omnipotent.net/mailman/listinfo/lcdproc
>   

From root at c-works.net  Fri Feb 13 17:16:15 2009
From: root at c-works.net (Harald Latzko)
Date: Fri, 13 Feb 2009 18:16:15 +0100
Subject: [Lcdproc] pyramid lcd
In-Reply-To: <49958205.600@pyramid.de>
References: <49900320.3070408@pyramid.de> <49958205.600@pyramid.de>
Message-ID: <380F31B7-9E7F-4DDE-AA53-141A6C904F16@c-works.net>

hi!

seems to work for me as expected! i could send you pictures about how  
it looks like on my display. i'm using the official 0.5.2 release, not  
the actual cvs build (if that makes any difference).


Am 13.02.2009 um 15:21 schrieb J?rg Hohwieler:

> Anyone out there who can tell me why some screens don't work?
>
>
> Best regards
> Joerg
>
>
> J?rg Hohwieler wrote:
>> Hi,
>>
>> I'm having some issues with lcdproc-client in conjunction with the
>> Pyramid LCD,
>> which is a 2x16 display.
>>
>> The lcdproc-client supports several screen commands.
>>
>> The only screens that work with the display are:
>> P
>> N
>> G
>> L
>>
>> Is this an expected behaviour due to limitations by the display size?
>>
>>
>> The other screens won't show anything on the display when executed
>> whereas the 4 mentioned screens above immediately show up on the  
>> display.
>>
>> I tested with current CVS version of lcdproc.
>>
>>
>> Best regards
>> Joerg
>>
>>
> _______________________________________________
> LCDproc mailing list
> LCDproc at lists.omnipotent.net
> http://lists.omnipotent.net/mailman/listinfo/lcdproc
>


From bsdfan at nurfuerspam.de  Mon Feb 16 07:33:20 2009
From: bsdfan at nurfuerspam.de (Markus Dolze)
Date: Mon, 16 Feb 2009 08:33:20 +0100
Subject: [Lcdproc] Overloading the 'output' token
In-Reply-To: <f4eb766f0902110840k158cb4c0k30da7eb65cd7611d@mail.gmail.com>
References: <f4eb766f0902082140p249d4408tbc880c032b0559bc@mail.gmail.com>
	<f4eb766f0902110840k158cb4c0k30da7eb65cd7611d@mail.gmail.com>
Message-ID: <499916C0.5050302@nurfuerspam.de>

Ethan Dicks wrote:
> Hi, All,
>
>  *
>  * Since the LK204-7T-1U already has nine formal GPOs and since 'output' passes
>  * an "int" from the client through the server to the driver, one mechanism that
>  * won't break the existing GPO model is to define some of the upper bits in a
>  * signed 32-bit int to mean "set backlight color".  It seems unlikely that any
>  * LCD will implement more than 28 GPOs, so bits 28 and 29 can be used to select
>  * four different results of the output command from the client:
>  *
> ...
>
> ... It is a complex enough issue that perhaps it
> warrants a Matrix Orbital "configurator" program where the user can
> answer simple questions about their display which results in a series
> of correct parameter settings in LCDd.conf.  Something like this was
> proposed for Windows users since "editing .INI files" is alien to most
> of them anymore, but even Linux has filtered down from geeks-only to
> the point where some hand-holding might be in order.
>
> For now, though, the question I'm putting on the table is if it's
> better or worse to make the user set some LCDd.conf parameter like
> "HasMulticolorBacklight yes/no" to enable these new commands.
> Implementation is easy either way.  It's about what is a greater or
> lesser burden to the end-user.
>
> Comments?  Complaints?  Acknowledgments?
>   
Hi,

there has been written a lot of text about his and I would like add even 
more to get my thoughts written down.

I think of LCDproc as a software than can be useful to home users as 
well as system integrators who want to add displays to there systems or 
appliances. So we offer a wide range of displays support starting at 
simple text-only output, keypad and LED support, up to fancy case 
modding displays featuring colors, fan control, ...

The ouput port was probably intended to drive a LED bargraph attached to 
the parallel port. As this, the output() function works with hardware 
that is not part of the display. The same is true for output() 
controlling GPIO pins of a display. If one uses output() the client does 
need to know what happens if it talks to the driver using it (as the 
hardware attached to the output port is out of scope for the driver).

One might think to reuse the output function to pass arbitrary command 
to the display. However, there are some drawbacks: First the number of 
bytes is limited and second it is only sent to the drivery every 1/8 
second during an screen update cycle. But in a more general 
implementation the client could be programmed to use the full range of 
display commands. In this case LCDproc would perhaps not be necessary at 
all. If we want to control display features, I like to have a defined 
interface.

The big question I have is: Shall the backlight be client controllable?

If yes, we should take a more general approach by adding a new command 
to the client language and design it in a way it may be used by all 
drivers. That is, it shall support monochrome brightness as well as 
different colors.

But the implications of having the backlight client controllable are not 
easy to deal with:

    * Shall it behave like the current backlight on/off state?
    * If yes, shall it be controllable per screen, per client and
      server-wide?
    * Does it need to be restricted like backlight on/off/open by the
      server?

If the backlight does not need to be client controllable, adding a 
option to LCDd.conf is not bad. Additionally I would love to see a 
server menu to control the colors like it is possible with the 
brightness and contrast.

As for the discussion about the number of options: Yes, LCDd.conf does 
have a lot of options, but that's not bad IMHO. On the other hand, I do 
not want to shadow the myriad of options and functions lcdhype or 
lcdsmartie have to LCDproc (regarding Windows users migrating to Linux 
discussion).

But as a first step, it would be nice if the config file is adapted by 
configure to the drivers built. (That is, only include sections for 
those drivers actually installed).

These are my thoughts,
Markus

From malte at maltepoeggel.de  Fri Feb 20 14:41:55 2009
From: malte at maltepoeggel.de (=?iso-8859-1?Q?Malte_P=F6ggel?=)
Date: Fri, 20 Feb 2009 15:41:55 +0100
Subject: [Lcdproc] Changes to get EA-DOGM163 + four keys working with
	hd44780-lcd2usb driver
Message-ID: <BBC090545EA14A1CB4E61EF56FAA5219@subnote1400>

Hi,

i am currently developing a front panel LCD which is using a EA-DOGM163.
This display has a Sitronix ST7036 Controller. Every next line in "3 line"
mode starts 0x10 higher, if i enable the "extended mode" it would fix it a
bit, but to 0x20... I have added a new parameter "LINEADDRESS" to change the
default 0x20 value in extended mode:

The new parameter in struct driver_private_data (hd44780-low.h):
+ int line_address;        // line address in extended mode

Reading the configuration on hd44780.c:

//// READ THE CONFIG FILE
[...]
+ p->line_address          = drvthis->config_get_int(drvthis->name,
"lineaddress", 0, 0);

And in the HD44780_position function:
+ int lineaddress;

if (p->ext_mode) {
+  // Linear addressing, each line normally starts 0x20 higher.
+                if(p->line_address) lineaddress = p->line_address; else
lineaddress=0x20;
+  DDaddr = x + relY * lineaddress;
 } else {
[...]


Another confusing thing is that the keys aren't converted to scancodes in
the hd44780-lcd2usb.c.
I found out that this is for those who have only the 2 keys of the original
design, to have a virtual third key by pressing both buttons.
In my case i added two keys to two additional ports - and now the value has
to be converted to a scancode.
Maybe it would be nice to add a parameter there, too - for those who would
use the 2 ("3") keys and for those who use a custom layout / AVR firmware
and more buttons.

Malte

Ps: Could somebody fix the link of my homepage, mentioned in the LCDproc
users guide (serialVFD Driver)? The old URL isn't working anymore - should
be changed to http://www.maltepoeggel.de/index.php?site=vfd 


From joris at robijn.net  Fri Feb 20 15:19:17 2009
From: joris at robijn.net (joris at robijn.net)
Date: Fri, 20 Feb 2009 16:19:17 +0100 (CET)
Subject: [Lcdproc] Changes to get EA-DOGM163 + four keys working with
 hd44780-lcd2usb driver
In-Reply-To: <BBC090545EA14A1CB4E61EF56FAA5219@subnote1400>
Message-ID: <20090220151917.B9E631C9DB6@wizard.robijn.net>

Hi,

Why don't you set the default in the config file function to 0x20 ?
Then you don't need to check if the private data structure is set or
not....

p->line_address          = drvthis->config_get_int(drvthis->name,
"lineaddress", 0, 0);  <- should have 0x20 here as default

Joris


From bsdfan at nurfuerspam.de  Fri Feb 20 17:54:16 2009
From: bsdfan at nurfuerspam.de (Markus Dolze)
Date: Fri, 20 Feb 2009 18:54:16 +0100
Subject: [Lcdproc] Changes to get EA-DOGM163 + four keys working
	with	hd44780-lcd2usb driver
In-Reply-To: <BBC090545EA14A1CB4E61EF56FAA5219@subnote1400>
References: <BBC090545EA14A1CB4E61EF56FAA5219@subnote1400>
Message-ID: <20090220175416.120800@gmx.net>

-------- Original-Nachricht --------
> Datum: Fri, 20 Feb 2009 15:41:55 +0100
> Von: "Malte P?ggel" <malte at maltepoeggel.de>
> An: lcdproc at lists.omnipotent.net
> Betreff: [Lcdproc] Changes to get EA-DOGM163 + four keys working with	hd44780-lcd2usb driver

> Hi,
> 
> i am currently developing a front panel LCD which is using a EA-DOGM163.
> This display has a Sitronix ST7036 Controller. Every next line in "3 line"
> mode starts 0x10 higher, if i enable the "extended mode" it would fix it a
> bit, but to 0x20... I have added a new parameter "LINEADDRESS" to change
> the
> default 0x20 value in extended mode:
> 
> The new parameter in struct driver_private_data (hd44780-low.h):
> + int line_address;        // line address in extended mode
> 
> Reading the configuration on hd44780.c:
> 
> //// READ THE CONFIG FILE
> [...]
> + p->line_address          = drvthis->config_get_int(drvthis->name,
> "lineaddress", 0, 0);
> 
> And in the HD44780_position function:
> + int lineaddress;
> 
> if (p->ext_mode) {
> +  // Linear addressing, each line normally starts 0x20 higher.
> +                if(p->line_address) lineaddress = p->line_address; else
> lineaddress=0x20;
> +  DDaddr = x + relY * lineaddress;
>  } else {
> [...]
> 
> 

Voting for Joris' comment here.

> Another confusing thing is that the keys aren't converted to scancodes in
> the hd44780-lcd2usb.c.
> I found out that this is for those who have only the 2 keys of the
> original
> design, to have a virtual third key by pressing both buttons.
> In my case i added two keys to two additional ports - and now the value
> has
> to be converted to a scancode.
> Maybe it would be nice to add a parameter there, too - for those who would
> use the 2 ("3") keys and for those who use a custom layout / AVR firmware
> and more buttons.
> 

I don't think this is really necessary. The value the lcd2usb driver returns is directly used as a scancode: 1, 2 or 3 according to the keys pressed. The hd44780.c maps this to DirectKeys.

The value (1-2-3) is directly read from the lcd2usb response message and passed without modifications to hd44780.c

As you use a custom firmware you can take care of this yourself. You have to decide what to happen if the user presses two or more keys at the same time.

If your firmware just returns a bitmap of the pressed keys (like the original one) the driver would have to decide on how to handle simultaneous key presses. But if your firmware returns a 'scancode' instead of a pressed key bitmap - that is one numeric value for each key - the driver will work without modification.

I don't like to add a modification to a driver to support a custom firmware where this is not really necessary.

> Malte
> 
> Ps: Could somebody fix the link of my homepage, mentioned in the LCDproc
> users guide (serialVFD Driver)? The old URL isn't working anymore - should
> be changed to http://www.maltepoeggel.de/index.php?site=vfd 
> 

I can take care of this.

Regards
Markus

From ethan.dicks at gmail.com  Fri Feb 20 20:37:29 2009
From: ethan.dicks at gmail.com (Ethan Dicks)
Date: Fri, 20 Feb 2009 15:37:29 -0500
Subject: [Lcdproc] Changes to get EA-DOGM163 + four keys working with
	hd44780-lcd2usb driver
In-Reply-To: <BBC090545EA14A1CB4E61EF56FAA5219@subnote1400>
References: <BBC090545EA14A1CB4E61EF56FAA5219@subnote1400>
Message-ID: <f4eb766f0902201237g797de0ddg113584365a5b89db@mail.gmail.com>

On Fri, Feb 20, 2009 at 9:41 AM, Malte P?ggel <malte at maltepoeggel.de> wrote:
> Hi,
>
> i am currently developing a front panel LCD which is using a EA-DOGM163.
> This display has a Sitronix ST7036 Controller....
> Another confusing thing is that the keys aren't converted to scancodes in
> the hd44780-lcd2usb.c.
> I found out that this is for those who have only the 2 keys of the original
> design, to have a virtual third key by pressing both buttons.
> In my case i added two keys to two additional ports - and now the value has
> to be converted to a scancode.
> Maybe it would be nice to add a parameter there, too - for those who would
> use the 2 ("3") keys and for those who use a custom layout / AVR firmware
> and more buttons.

I have a lcd2usb that I use with a couple of difference 4x40 displays.
 I also have rigged up a pair of diodes for a third switch so that I
have three unique buttons to press and get three different "codes" to
the driver.  I didn't have to modify the lcd2usb at all (besides
running wires for external switches off the lcd2usb board).

I would prefer not to see scancode modifications since that will break
the existing hardware.

-ethan

From moridin1138 at gmail.com  Sat Feb 21 00:07:32 2009
From: moridin1138 at gmail.com (brian jackson)
Date: Fri, 20 Feb 2009 19:07:32 -0500
Subject: [Lcdproc] lcdproc on OSX presents random block characters (all on)
Message-ID: <5ba1b2c60902201607v2c70c67fyd8afa7409fa3bade@mail.gmail.com>

This is my first post after much searching and tinkering. I hope
someone can help!

I have an LCD2041 rev 1.3 that I have used flawlessly on Windows for a
long time. Unfortunately I have not been able to get it to work on OSX
with LCDproc . Initially it was because I was using /dev/tty.serial1
as the device, but now with it using /dev/cu.serial1 instead it
works... sort of.

I get random block characters or heartbeat characters when it's
running. They show up in random places, and generally make it
unusable. lcdproc issue perhaps?
When using 'screen /dev/cu.serial1 19200' everything shows up fine, as
in I can type as usual, clear the screen, etc.

Here's a Youtube video of the screen output:
http://www.youtube.com/watch?v=33QbuKkItcY

Any thoughts/ideas?

Thanks,

-brian

From ethan.dicks at gmail.com  Sat Feb 21 08:58:31 2009
From: ethan.dicks at gmail.com (Ethan Dicks)
Date: Sat, 21 Feb 2009 03:58:31 -0500
Subject: [Lcdproc] lcdproc on OSX presents random block characters (all
	on)
In-Reply-To: <5ba1b2c60902201607v2c70c67fyd8afa7409fa3bade@mail.gmail.com>
References: <5ba1b2c60902201607v2c70c67fyd8afa7409fa3bade@mail.gmail.com>
Message-ID: <f4eb766f0902210058t2136345u74824464b437895e@mail.gmail.com>

On Fri, Feb 20, 2009 at 7:07 PM, brian jackson <moridin1138 at gmail.com> wrote:
> This is my first post after much searching and tinkering. I hope
> someone can help!
>
> I have an LCD2041 rev 1.3 that I have used flawlessly on Windows for a
> long time. Unfortunately I have not been able to get it to work on OSX
> with LCDproc . Initially it was because I was using /dev/tty.serial1
> as the device, but now with it using /dev/cu.serial1 instead it
> works... sort of.
>
> I get random block characters or heartbeat characters when it's
> running. They show up in random places, and generally make it
> unusable. lcdproc issue perhaps?
> When using 'screen /dev/cu.serial1 19200' everything shows up fine, as
> in I can type as usual, clear the screen, etc.

What version of LCDproc are you running?  If you are running 0.5.2,
there is a well known and long-fixed bug with MtxOrb displays.  You
will need a somewhat recent build from source (anything less than a
year old will probably do).

From moridin1138 at gmail.com  Sat Feb 21 19:19:50 2009
From: moridin1138 at gmail.com (brian jackson)
Date: Sat, 21 Feb 2009 14:19:50 -0500
Subject: [Lcdproc] lcdproc on OSX presents random block characters (all
	on)
In-Reply-To: <f4eb766f0902210058t2136345u74824464b437895e@mail.gmail.com>
References: <5ba1b2c60902201607v2c70c67fyd8afa7409fa3bade@mail.gmail.com>
	<f4eb766f0902210058t2136345u74824464b437895e@mail.gmail.com>
Message-ID: <5ba1b2c60902211119j40486b4cx33b1b61c9d7119a0@mail.gmail.com>

I am using the latest tarball from http://lcdproc.sourceforge.net/nightly/

I installed it again just to be sure, and the same thing is happening
as in the original video I posted; random all on characters.

./LCDd -f
LCDd version 0.5dev starting
Using Configuration File: /usr/local/etc/LCDd.conf
LCDd 0.5dev, LCDproc Protocol 0.3

brian$ /usr/local/bin/lcdproc -v
LCDproc 0.5dev


On Sat, Feb 21, 2009 at 3:58 AM, Ethan Dicks <ethan.dicks at gmail.com> wrote:
> On Fri, Feb 20, 2009 at 7:07 PM, brian jackson <moridin1138 at gmail.com> wrote:
>> This is my first post after much searching and tinkering. I hope
>> someone can help!
>>
>> I have an LCD2041 rev 1.3 that I have used flawlessly on Windows for a
>> long time. Unfortunately I have not been able to get it to work on OSX
>> with LCDproc . Initially it was because I was using /dev/tty.serial1
>> as the device, but now with it using /dev/cu.serial1 instead it
>> works... sort of.
>>
>> I get random block characters or heartbeat characters when it's
>> running. They show up in random places, and generally make it
>> unusable. lcdproc issue perhaps?
>> When using 'screen /dev/cu.serial1 19200' everything shows up fine, as
>> in I can type as usual, clear the screen, etc.
>
> What version of LCDproc are you running?  If you are running 0.5.2,
> there is a well known and long-fixed bug with MtxOrb displays.  You
> will need a somewhat recent build from source (anything less than a
> year old will probably do).
>

From bsdfan at nurfuerspam.de  Sat Feb 21 19:42:17 2009
From: bsdfan at nurfuerspam.de (Markus Dolze)
Date: Sat, 21 Feb 2009 20:42:17 +0100
Subject: [Lcdproc] lcdproc on OSX presents random block characters
	(all	on)
In-Reply-To: <5ba1b2c60902211119j40486b4cx33b1b61c9d7119a0@mail.gmail.com>
References: <5ba1b2c60902201607v2c70c67fyd8afa7409fa3bade@mail.gmail.com>
	<f4eb766f0902210058t2136345u74824464b437895e@mail.gmail.com>
	<5ba1b2c60902211119j40486b4cx33b1b61c9d7119a0@mail.gmail.com>
Message-ID: <20090221194217.289250@gmx.net>

-------- Original-Nachricht --------
> Datum: Sat, 21 Feb 2009 14:19:50 -0500
> Von: brian jackson <moridin1138 at gmail.com>
> An: Ethan Dicks <ethan.dicks at gmail.com>, lcdproc at lists.omnipotent.net
> Betreff: Re: [Lcdproc] lcdproc on OSX presents random block characters (all	on)

> I am using the latest tarball from http://lcdproc.sourceforge.net/nightly/
> 
> I installed it again just to be sure, and the same thing is happening
> as in the original video I posted; random all on characters.
> 
> ./LCDd -f
> LCDd version 0.5dev starting
> Using Configuration File: /usr/local/etc/LCDd.conf
> LCDd 0.5dev, LCDproc Protocol 0.3
> 
> brian$ /usr/local/bin/lcdproc -v
> LCDproc 0.5dev
> 
> 
> On Sat, Feb 21, 2009 at 3:58 AM, Ethan Dicks <ethan.dicks at gmail.com>
> wrote:
> > On Fri, Feb 20, 2009 at 7:07 PM, brian jackson <moridin1138 at gmail.com>
> wrote:
> >> This is my first post after much searching and tinkering. I hope
> >> someone can help!
> >>
> >> I have an LCD2041 rev 1.3 that I have used flawlessly on Windows for a
> >> long time. Unfortunately I have not been able to get it to work on OSX
> >> with LCDproc . Initially it was because I was using /dev/tty.serial1
> >> as the device, but now with it using /dev/cu.serial1 instead it
> >> works... sort of.
> >>
> >> I get random block characters or heartbeat characters when it's
> >> running. They show up in random places, and generally make it
> >> unusable. lcdproc issue perhaps?
> >> When using 'screen /dev/cu.serial1 19200' everything shows up fine, as
> >> in I can type as usual, clear the screen, etc.
> >
> > What version of LCDproc are you running?  If you are running 0.5.2,
> > there is a well known and long-fixed bug with MtxOrb displays.  You
> > will need a somewhat recent build from source (anything less than a
> > year old will probably do).
> >

Hi,

I am not sure if the nightly tarballs work again (they have been broken since September), but there have been no changes to the MtxOrb driver anyway.

Depending on your firmware version it may not support the adjustable backlight like my LCD2025. You may try the attached patch to see if your display is affected (this patch actually disables the adjustable backlight and restores previous behaviour).

@Ethan: As you already mentioned this feature is not detectable by software and that you have an idea how to solve this. Did you made any advance?

Regards,
Markus
-------------- next part --------------
A non-text attachment was scrubbed...
Name: mtxorb-backlight.diff
Type: application/octet-stream
Size: 733 bytes
Desc: not available
URL: <http://lists.omnipotent.net/pipermail/lcdproc/attachments/20090221/cc8e167e/attachment-0001.obj>

From bsdfan at nurfuerspam.de  Sat Feb 21 20:16:26 2009
From: bsdfan at nurfuerspam.de (Markus Dolze)
Date: Sat, 21 Feb 2009 21:16:26 +0100
Subject: [Lcdproc] Changes to get EA-DOGM163 + four keys working
	with	hd44780-lcd2usb driver
In-Reply-To: <BBC090545EA14A1CB4E61EF56FAA5219@subnote1400>
References: <BBC090545EA14A1CB4E61EF56FAA5219@subnote1400>
Message-ID: <20090221201626.289250@gmx.net>

-------- Original-Nachricht --------
> Datum: Fri, 20 Feb 2009 15:41:55 +0100
> Von: "Malte P?ggel" <malte at maltepoeggel.de>
> An: lcdproc at lists.omnipotent.net
> Betreff: [Lcdproc] Changes to get EA-DOGM163 + four keys working with	hd44780-lcd2usb driver

> Hi,
> 
> i am currently developing a front panel LCD which is using a EA-DOGM163.
> This display has a Sitronix ST7036 Controller. Every next line in "3 line"
> mode starts 0x10 higher, if i enable the "extended mode" it would fix it a
> bit, but to 0x20... I have added a new parameter "LINEADDRESS" to change
> the
> default 0x20 value in extended mode:
> 

Hi,

I had a quick look at the controller's datasheet today. I have already seen those DOG modules in german stores. The controller is interesting because of his 3-line mode. In 1-line mode DDRAM is addressed linear (like in lcdproc's ext_mode). In 2-line mode the address of the second line starting at 0x40 (like in lcdproc's hd44780 standard mode).

Did you had a look at the character table? I have not checked if it matches an existing one, but as it supports umlauts as well as japanese characters.

Regards,
Markus

From electrofreak66 at yahoo.com  Sun Feb 22 09:58:14 2009
From: electrofreak66 at yahoo.com (B. N.)
Date: Sun, 22 Feb 2009 01:58:14 -0800 (PST)
Subject: [Lcdproc] does lcdproc support pic16c54c?
Message-ID: <187217.3569.qm@web52108.mail.re2.yahoo.com>

I have a board I pulled out of a Imerge SoundServer M1000. The LCD has a label that says its a "Densitron V" and google yeilds no results related to the one I have. There is a board that it is attached to it that has a PIC16C54C chip, I know lcdproc is supposed to support PIC16CC54 (without the C). The board that has the PIC16C54C connects to power and to the serial port. After running LCDd, nothing happens. After running lcdproc, a few seconds later the backlight turns on but that is it. There are no characters or anything being displayed. Any way to get lcdproc working with this? I am using the lcdserializer driver. Also, the board that has the LCD mounted to it also has 14 buttons on it too, if that makes a difference. Am I using the wrong driver?

Thanks,
Brad



      

From multiroom at sympatico.ca  Mon Feb 23 13:07:17 2009
From: multiroom at sympatico.ca (David Scott)
Date: Mon, 23 Feb 2009 08:07:17 -0500
Subject: [Lcdproc] Zalman HD135 and CVS Current LCDproc mplay connection
Message-ID: <DJEGLLNGDMGIFNAOLMELGEBJDNAA.multiroom@sympatico.ca>


 Hello All,

 Well I wanted to make a comment regarding, I installed the CVS current
version with drivers=44780 which I assume is using the lis2.c model for my
Zalman HD-135's case mplay VFD, I then proceeded to edit my LCDd.conf to
include

 driver path = /usr/local/lib/lcdproc/
 driver hd44780
 connection type = mplay
 device = ttyUSB0
 bit rate = 38400 (also tried zero)
 size = 20x2

 start LCDd and it would load up and work fine for about 40-60 minutes then
I receive garbled text etc or it would restart lcdproc and just load up the
server screen and stay there. I am running xbmc as the front end to
mythbuntu 8.10 backend. I then proceeded to swap this around and added a
launcher for XBMC to the mythtv frontend and autostarted mythtv this way now
the display would only give me a single dash on the top row to the very left
of the screen - no clock, no date, no myth menu information. I could also
not use livetv or watch any recorded shows as my remote would stop
responding and the screen would become completely garble to the point that
it was not readable AT ALL. As soon as I went back to the lcdproc src
directory and issued sudo make uninstall and rebooted all was fine again.

 I then proceeded to remove that version of lcdproc and try the 0.5.2
version as well as the stable nightly all using the lis2 connections type
with all the same results as above. I then hunted for some answers and I
found the patch for the driver created in 2007 that was never included in
the stable or unstable versions of LCDd or the CVS versions. I proceeded to
get the patch, dwnld 0.5.2 configured again with driver=44780 patched
with -p0 < mplay-final.patch. reconfigured my LCDd.conf file with the fan
controller portion now and rebooted the system and VOILA all is now PERFECT,
with mythtv and xbmc. The display works properly and the clock, date,
mythmenu, recorded show details etc are all working, and I can watch live
and recorded tv perfectly.

 If I read the posts all correctly the mplay connection type is based off
the lis2.c file WELL the lis2 device uses a different baud rate and I think
this is the root of all evil with this issue and it is now coming to light
as more guys are starting to use this case with XBMC for instance and
starting to note the same problem at least the garbled text. I have been
running the patched version of 0.5.2 now with the proper driver for two days
and it is working perfectly always awake and always displaying the proper
info as it should and the fans are working 100% all the time and the y/n fan
switch in the LCDd.conf file works as well if no fans are used. I really
think this patch should be installed permanently in the src for anyone using
the HD135 case with the mplay connection.


Regards,

 Dave
 Ottawa, Canada



From ethan.dicks at gmail.com  Mon Feb 23 15:50:05 2009
From: ethan.dicks at gmail.com (Ethan Dicks)
Date: Mon, 23 Feb 2009 09:50:05 -0600
Subject: [Lcdproc] does lcdproc support pic16c54c?
In-Reply-To: <187217.3569.qm@web52108.mail.re2.yahoo.com>
References: <187217.3569.qm@web52108.mail.re2.yahoo.com>
Message-ID: <f4eb766f0902230750hfdd0612i29b28142df483b89@mail.gmail.com>

On Sun, Feb 22, 2009 at 3:58 AM, B. N. <electrofreak66 at yahoo.com> wrote:
> I have a board I pulled out of a Imerge SoundServer M1000. The LCD has a label that says its a "Densitron V"
> and google yeilds no results related to the one I have.

I recognize the brand name 'Densitron', but not the model.

> There is a board that it is attached to it that has a PIC16C54C chip, I know lcdproc is supposed to
> support PIC16CC54 (without the C).

Where do you get that?  LCDproc supports various displays which may or
may not contain PIC microcontrollers which may or may not be a
PIC16C54.  It's all about whatever program is running on that
PICC16C54.

> The board that has the PIC16C54C connects to power and to the serial port. After running
>LCDd, nothing happens. After running lcdproc, a few seconds later the backlight turns on
> but that is it. There are no characters or anything being displayed.

OK.  There are a couple of possibilities - one is that you are sending
commands to the display that the display doesn't understand.  Another
one (that I've run into myself) is that the base LCD module is an
"extended temp" module and needs a negative bias voltage - if this is
a complete unit and you are powering it as it was in its original
location, this is less likely, but if you just gave the display +5V
and it happens to need -5V too, this could be it.  Another possibility
is that the contrast setting is off and the LCD isn't showing its
characters visibly.  I have no idea if your board has a potentiometer
or software-controlled contrast, so you'll need to figure that out.

> Any way to get lcdproc working with this? I am using the lcdserializer driver. Also, the board
> that has the LCD mounted to it also has 14 buttons on it too, if that makes a difference.

It may make a difference in identifying what device you have.

> Am I using the wrong driver?

It's likely.

>From what you've said about your module, I'm having to make guesses
about what you have.  If you could take a few *in focus* pictures and
put them up somewhere where we could have a look (don't attach them to
a message for the list), that might help.  If there's any way to find
more info about the SoundServer M1000, that might help, too.  There
are tools that could be used to sniff the serial traffic between your
LCD display and the SoundServer M1000, but unless happen to have, say,
an HP 4951A serial line analyzer on hand, you'd probably have to build
one from a two-serial-port PC running a sniffer app.  It's not a task
for novices, but I wanted to mention such things exist if it's really
important to figure out how a particular module works.

There are things you can do short of hooking in a serial analyzer.
You can try to send strings to the display *without* LCDproc.  I work
with Linux and UNIX, so I use 'echo' for simple stuff, or write shell
or Perl scripts for more interesting stuff, just sending to the serial
port with the display on it.  You didn't describe your environment,
but if it's Windows, perhaps someone else can make a suggestion.  Most
serializers have a simple device-level protocol - printable ASCII
characters are just printed at the present location, and "control
characters" (below 0x20) are used for various control and positioning
functions.  Since you aren't getting any characters, it might be a bit
tricky, but if you have a potentiometer, you could send some chars,
then twiddle the knob (mark the start position first) to see if the
chars suddenly appear.  If you have a software-controllable contrast
control, you'll need to know the module's command set first, so you
are back to looking for docs or the software for the SoundServer M1000
itself (if it's Open Source).


-ethan

From multiroom at sympatico.ca  Mon Feb 23 16:04:57 2009
From: multiroom at sympatico.ca (David Scott)
Date: Mon, 23 Feb 2009 11:04:57 -0500
Subject: [Lcdproc] Antec Fusion Black ffdc LCD device
Message-ID: <DJEGLLNGDMGIFNAOLMELCEBKDNAA.multiroom@sympatico.ca>


 Hey all,

 I have a couple questions about the LCD's backlight in this chassis.
LCDproc-0.5.2 works perfectly with the latest patches only for the
backlight. Now I notice in the LCDd.conf file the driver section for
[imonlcd] list exit=2 which is I assume why the Backlight shuts off when
shutting down temporarily (this does not happen in suspend) So I guess the
way I see this is lcdproc is removing power to the LCD while shutting down
and controlling it but as soon as lcdproc is closed Antec takes over and
resumes sending power to the lcd's backlight. Then there is the option under
the driver section to set the Backlight to 0 or 1 (on or Off) but this
completely turns off the backlight which is really not a good choice. I have
not played with any variation of the master backlight setting and the
drivers setting and that may help in some way as well, I currently have the
master set to open for XBMC to dim it.

 So is there some way that the exit=2 could hold the lcd until lcdproc send
the wakeup 8 command to the lcd on reboot, I am not sure how this would
happen outside of lcdproc running but someone more qualified then I may be
able to answer the question.

 Thanks,

 Dave


From bsdfan at nurfuerspam.de  Mon Feb 23 16:14:49 2009
From: bsdfan at nurfuerspam.de (Markus Dolze)
Date: Mon, 23 Feb 2009 17:14:49 +0100
Subject: [Lcdproc] Zalman HD135 and CVS Current LCDproc mplay connection
In-Reply-To: <DJEGLLNGDMGIFNAOLMELGEBJDNAA.multiroom@sympatico.ca>
References: <DJEGLLNGDMGIFNAOLMELGEBJDNAA.multiroom@sympatico.ca>
Message-ID: <20090223161449.213670@gmx.net>


-------- Original-Nachricht --------
> Datum: Mon, 23 Feb 2009 08:07:17 -0500
> Von: "David Scott" <multiroom at sympatico.ca>
> An: lcdproc at lists.omnipotent.net
> Betreff: [Lcdproc] Zalman HD135 and CVS Current LCDproc mplay connection

> 
>  Hello All,
...
> 
>  I then proceeded to remove that version of lcdproc and try the 0.5.2
> version as well as the stable nightly all using the lis2 connections type
> with all the same results as above. I then hunted for some answers and I
> found the patch for the driver created in 2007 that was never included in
> the stable or unstable versions of LCDd or the CVS versions. I proceeded
> to
> get the patch, dwnld 0.5.2 configured again with driver=44780 patched
> with -p0 < mplay-final.patch. reconfigured my LCDd.conf file with the fan
> controller portion now and rebooted the system and VOILA all is now
> PERFECT,
> with mythtv and xbmc. The display works properly and the clock, date,
> mythmenu, recorded show details etc are all working, and I can watch live
> and recorded tv perfectly.
> 

Hi,

do you mean this http://lists.omnipotent.net/pipermail/lcdproc/2007-October/011966.html patch? I wasn't able to find any other.

The patch got never commited in the form it was sent in, because the fan controlling part was split of.

AFAIK the mplay part was incorporated into the lis2 driver. So the lis2 driver actually knows about the lis2 and the mplay device and their differences (e.g. the serial speed). If the original patch does work for the mplay device but the current driver not, we need to have a look at the lis2 driver.

Regards,
Markus

From bsdfan at nurfuerspam.de  Mon Feb 23 16:26:11 2009
From: bsdfan at nurfuerspam.de (Markus Dolze)
Date: Mon, 23 Feb 2009 17:26:11 +0100
Subject: [Lcdproc] Antec Fusion Black ffdc LCD device
In-Reply-To: <DJEGLLNGDMGIFNAOLMELCEBKDNAA.multiroom@sympatico.ca>
References: <DJEGLLNGDMGIFNAOLMELCEBKDNAA.multiroom@sympatico.ca>
Message-ID: <20090223162611.31300@gmx.net>

-------- Original-Nachricht --------
> Datum: Mon, 23 Feb 2009 11:04:57 -0500
> Von: "David Scott" <multiroom at sympatico.ca>
> An: lcdproc at lists.omnipotent.net
> Betreff: [Lcdproc] Antec Fusion Black ffdc LCD device

> 
>  Hey all,
> 
>  I have a couple questions about the LCD's backlight in this chassis.
> LCDproc-0.5.2 works perfectly with the latest patches only for the
> backlight. Now I notice in the LCDd.conf file the driver section for
> [imonlcd] list exit=2 which is I assume why the Backlight shuts off when
> shutting down temporarily (this does not happen in suspend) So I guess the
> way I see this is lcdproc is removing power to the LCD while shutting down
> and controlling it but as soon as lcdproc is closed Antec takes over and
> resumes sending power to the lcd's backlight. Then there is the option
> under
> the driver section to set the Backlight to 0 or 1 (on or Off) but this
> completely turns off the backlight which is really not a good choice. I
> have
> not played with any variation of the master backlight setting and the
> drivers setting and that may help in some way as well, I currently have
> the
> master set to open for XBMC to dim it.
> 
>  So is there some way that the exit=2 could hold the lcd until lcdproc
> send
> the wakeup 8 command to the lcd on reboot, I am not sure how this would
> happen outside of lcdproc running but someone more qualified then I may be
> able to answer the question.
> 
>  Thanks,
> 
>  Dave
> 

Hi,

what patches are you using LCDproc 0.5.2 with? Where did you get them from? There is no [imonlcd] section in LCDd.conf and there is no 'exit=2'.

Regards,
Markus

From jarod at wilsonet.com  Mon Feb 23 16:38:39 2009
From: jarod at wilsonet.com (Jarod Wilson)
Date: Mon, 23 Feb 2009 11:38:39 -0500
Subject: [Lcdproc] Antec Fusion Black ffdc LCD device
In-Reply-To: <20090223162611.31300@gmx.net>
References: <DJEGLLNGDMGIFNAOLMELCEBKDNAA.multiroom@sympatico.ca>
	<20090223162611.31300@gmx.net>
Message-ID: <200902231138.40522.jarod@wilsonet.com>

On Monday 23 February 2009 11:26:11 Markus Dolze wrote:
> -------- Original-Nachricht --------
> > Datum: Mon, 23 Feb 2009 11:04:57 -0500
> > Von: "David Scott" <multiroom at sympatico.ca>
> > An: lcdproc at lists.omnipotent.net
> > Betreff: [Lcdproc] Antec Fusion Black ffdc LCD device
> 
> > 
> >  Hey all,
> > 
> >  I have a couple questions about the LCD's backlight in this chassis.
> > LCDproc-0.5.2 works perfectly with the latest patches only for the
> > backlight. Now I notice in the LCDd.conf file the driver section for
> > [imonlcd] list exit=2 which is I assume why the Backlight shuts off when
[...]
> what patches are you using LCDproc 0.5.2 with? Where did you get them from? There is no [imonlcd] section in LCDd.conf and there is no 'exit=2'.

Was going to say as much myself... imonlcd is the new device added by the
patches originated from codeka.com, which Fedora (and possibly others)
currently carries. Its on my personal TODO list to help get the code
fully documented so that it can be merged into lcdproc-proper, but I've
been a wee bit lacking on spare time lately...

-- 
Jarod Wilson
jarod at wilsonet.com

From multiroom at sympatico.ca  Mon Feb 23 16:42:06 2009
From: multiroom at sympatico.ca (David Scott)
Date: Mon, 23 Feb 2009 11:42:06 -0500
Subject: [Lcdproc] Zalman HD135 and CVS Current LCDproc mplay connection
In-Reply-To: <20090223161449.213670@gmx.net>
Message-ID: <DJEGLLNGDMGIFNAOLMELGEBLDNAA.multiroom@sympatico.ca>

Hello Markus,

 Yes! that is exactly what I am talking about, I first compiled using the
CVS-current version as that is the only version that setting connection type
to mplay will work with. and as I stated it would work ok for a little while
then I could no loner view live tv or recorded shows with myth as my remote
would stop responding in either of those two scenario's. So heading into the
src directory and running sudo make uninstall and then rebooting all was
back to normal without LCDd running.

 So I googled and found the patch you are referring to and could not find
the actual .patch file so I contacted the author and got a copy of it. Then
I proceeded to download the current 0.5.2 lcdproc version and applied the
mplay-final.patch as supplied by the author WITH the fan controller changes
to the LCDd.conf, then configured LCDd.conf for the mplay device. rebooted
and everything is working perfectly. Mythbuntu works perfectly all lines are
displayed properly with myth's lcdserver, the clock, date and time are
perfect and I can watch livetv and recorded shows with LCDd running.

 Regards,

 Dave

-----Original Message-----
From: Markus Dolze [mailto:bsdfan at nurfuerspam.de]
Sent: Monday, February 23, 2009 11:15 AM
To: David Scott; lcdproc at lists.omnipotent.net
Subject: Re: [Lcdproc] Zalman HD135 and CVS Current LCDproc mplay
connection



-------- Original-Nachricht --------
> Datum: Mon, 23 Feb 2009 08:07:17 -0500
> Von: "David Scott" <multiroom at sympatico.ca>
> An: lcdproc at lists.omnipotent.net
> Betreff: [Lcdproc] Zalman HD135 and CVS Current LCDproc mplay connection

>
>  Hello All,
...
>
>  I then proceeded to remove that version of lcdproc and try the 0.5.2
> version as well as the stable nightly all using the lis2 connections type
> with all the same results as above. I then hunted for some answers and I
> found the patch for the driver created in 2007 that was never included in
> the stable or unstable versions of LCDd or the CVS versions. I proceeded
> to
> get the patch, dwnld 0.5.2 configured again with driver=44780 patched
> with -p0 < mplay-final.patch. reconfigured my LCDd.conf file with the fan
> controller portion now and rebooted the system and VOILA all is now
> PERFECT,
> with mythtv and xbmc. The display works properly and the clock, date,
> mythmenu, recorded show details etc are all working, and I can watch live
> and recorded tv perfectly.
>

Hi,

do you mean this
http://lists.omnipotent.net/pipermail/lcdproc/2007-October/011966.html
patch? I wasn't able to find any other.

The patch got never commited in the form it was sent in, because the fan
controlling part was split of.

AFAIK the mplay part was incorporated into the lis2 driver. So the lis2
driver actually knows about the lis2 and the mplay device and their
differences (e.g. the serial speed). If the original patch does work for the
mplay device but the current driver not, we need to have a look at the lis2
driver.

Regards,
Markus


From ethan.dicks at gmail.com  Mon Feb 23 16:50:19 2009
From: ethan.dicks at gmail.com (Ethan Dicks)
Date: Mon, 23 Feb 2009 10:50:19 -0600
Subject: [Lcdproc] lcdproc on OSX presents random block characters (all
	on)
In-Reply-To: <20090221194217.289250@gmx.net>
References: <5ba1b2c60902201607v2c70c67fyd8afa7409fa3bade@mail.gmail.com>
	<f4eb766f0902210058t2136345u74824464b437895e@mail.gmail.com>
	<5ba1b2c60902211119j40486b4cx33b1b61c9d7119a0@mail.gmail.com>
	<20090221194217.289250@gmx.net>
Message-ID: <f4eb766f0902230850p7b9cf991tdd9b6f4551279399@mail.gmail.com>

On Sat, Feb 21, 2009 at 1:42 PM, Markus Dolze <bsdfan at nurfuerspam.de> wrote:
> Depending on your firmware version it may not support the adjustable backlight like my LCD2025. You may try the attached patch to see if your display is affected (this patch actually disables the adjustable backlight and restores previous behaviour).
>
> @Ethan: As you already mentioned this feature is not detectable by software and that you have an idea how to solve this. Did you made any advance?

Hmm... I'm trying to think of what I was thinking of when these
discussions came around last time...

I do have a recollection about an idea to streamline LCDd.conf setup
(essentially fragmenting the current distributed LCDd.conf into a
driver-specific section, then an entry in the Makefile to compile (in
the sense of heap together) a header and footer with the
config-specified driver sections, so that at least, there's only the
needed parts in LCDd.conf.

I don't remember off the top of my head any mods to MtxOrb.c relating
to config options relating to the presence or absence of adjustable
backlight commands.  Markus, could you perhaps give me some context
and help me remember the feature you are thinking of?

There is a MtxOrb.c patch I'm still trying to find where it went...
the one that implemented NUMGPOs.  It wasn't mine, but I seem to
remember testing it about a year ago and it worked fine with my VKD204
(6 GPOs).  Now that I have a nine GPO MtxOrb display, I'd really like
to see the NUMGPOs patch rolled out and I'd rather not have to whip it
up from scratch since it's already been written and tested.  I don't
have the same development environment I did a year ago, so I don't
have that patched version to refer to, unfortunately.

I'm thinking that MtxOrb.c is in need of a bit of collective work.
Perhaps those of us who have Matrix Orbital displays could mention on
the list what we have so we can see what firmware and feature sets are
capable of being tested?  I'm happy to make proposals and code up
changes, but I only have two textual Matrix Orbital displays to check
for results.  With a list of who has what, testing might go more
smoothly.

-ethan

From multiroom at sympatico.ca  Mon Feb 23 16:50:38 2009
From: multiroom at sympatico.ca (David Scott)
Date: Mon, 23 Feb 2009 11:50:38 -0500
Subject: [Lcdproc] Antec Fusion Black ffdc LCD device
In-Reply-To: <200902231138.40522.jarod@wilsonet.com>
Message-ID: <DJEGLLNGDMGIFNAOLMELAEBMDNAA.multiroom@sympatico.ca>

Hey Jarod,

 You beat me to the punch. Markus I hope that answers your questions on the
patch. I am not sure if my other comments as to what and how the device is
being controlled.

 Jarod,

 On another note, I want to thank you for yours and the links I found from
your how to's on setting up my lirc_dev lirc_imon and lirc_mceusb2 devices
all to work together. It was a nightmare to do until I found your site. I
now have my mce remote (hand held) working off the imon IR/LCD and the M$
USB dongle transmitting to my Express VU rcvr working perfectly. I did not
have to edit /etc/init.d/lirc at all and I did not have to setup and udev
rules for the two devices. This is where most of the misinformation in al
the posts I found, most posts would explain how to setup the udev rules and
aliases but none would properly describe how to prepare the lirc script.
Using rc.local and /etc/modprobe.d/aliases worked 100%.so thanks so much.

 rgds,

 Dave

-----Original Message-----
From: Jarod Wilson [mailto:jarod at wilsonet.com]
Sent: Monday, February 23, 2009 11:39 AM
To: lcdproc at lists.omnipotent.net
Cc: Markus Dolze; David Scott
Subject: Re: [Lcdproc] Antec Fusion Black ffdc LCD device


On Monday 23 February 2009 11:26:11 Markus Dolze wrote:
> -------- Original-Nachricht --------
> > Datum: Mon, 23 Feb 2009 11:04:57 -0500
> > Von: "David Scott" <multiroom at sympatico.ca>
> > An: lcdproc at lists.omnipotent.net
> > Betreff: [Lcdproc] Antec Fusion Black ffdc LCD device
>
> >
> >  Hey all,
> >
> >  I have a couple questions about the LCD's backlight in this chassis.
> > LCDproc-0.5.2 works perfectly with the latest patches only for the
> > backlight. Now I notice in the LCDd.conf file the driver section for
> > [imonlcd] list exit=2 which is I assume why the Backlight shuts off when
[...]
> what patches are you using LCDproc 0.5.2 with? Where did you get them
from? There is no [imonlcd] section in LCDd.conf and there is no 'exit=2'.

Was going to say as much myself... imonlcd is the new device added by the
patches originated from codeka.com, which Fedora (and possibly others)
currently carries. Its on my personal TODO list to help get the code
fully documented so that it can be merged into lcdproc-proper, but I've
been a wee bit lacking on spare time lately...

--
Jarod Wilson
jarod at wilsonet.com


From ethan.dicks at gmail.com  Mon Feb 23 17:05:44 2009
From: ethan.dicks at gmail.com (Ethan Dicks)
Date: Mon, 23 Feb 2009 11:05:44 -0600
Subject: [Lcdproc] Matrix Orbital display registry
Message-ID: <f4eb766f0902230905s6d9dea9s973255995ae0df4b@mail.gmail.com>

Hi, All,

As mentioned in my previous message, I think it would be a good idea
for those of us on the list with Matrix Orbital displays to post what
we have so we can coordinate testing.

I have the following displays...

VKD204 20x4 VFD w/5x5 keypad, 3 GPOs, serial interface (but also has
optional TTL and I2C).  It's an older device, about 10 years old at
this point but has been incredibly reliable.  The only problem I've
had is that it's so old that the glue for the rubber mounting pads on
the VFD glass gave way a while back, but a drop of superglue fixed
that (and I later found the *exact* VFD on eBay for $20, so I have a
spare).  There is no online manual for this module, but fortunately I
still have the original printed manual.

LK204-7T-1U-BK-USB-TCI 20x4 LCD w/built-in keypad, 9 GPOs (6 for
onboard LEDs, 3 external), Dallas 1-Wire bus, multi-color backlight,
USB interface (but also available in serial, I2C and TTL).  Its core
functions work fine with the present CVS head, but it has
vendor-supplied features that LCDproc doesn't take advantage of (yet).

GLK19264 LCD w/built-in keypad, USB interface, but graphical, not
textual, so outside the scope of MtxOrb.c development/testing.

So if you also have a Matrix Orbital display, tell us about it.   I
don't mind taking the initiative of coordinating notification of new
versions of MtxOrb.c to test, but I'd like to know what scope the
testing will entail.

-ethan

From bsdfan at nurfuerspam.de  Mon Feb 23 17:32:49 2009
From: bsdfan at nurfuerspam.de (Markus Dolze)
Date: Mon, 23 Feb 2009 18:32:49 +0100
Subject: [Lcdproc] configfile.c breaks on Mac OS X due to nested function
Message-ID: <20090223173249.31310@gmx.net>

Erik Hansen reported this as a SF tracker event:

--- quote begin ---

Nested functions have been disabled by Mac OS X Developer tools -- gcc
4.0.1. As a result, compilation of configfile.c fails due to the following
code:

int config_read_string(const char *sectionname, const char *str)
/* All the config parameters are placed in the given section in memory.*/
{
int pos = 0;
section *s;

/* We use a nested fuction to transfer the characters from buffer
to parser*/
char get_next_char() {
return str[pos++];
}

if ((s = find_section(sectionname)) == NULL)
s = add_section(sectionname);

return process_config(&s, get_next_char, "command line", NULL);
}

--- quote end ---

Any suggestions how to deal with this? Does it work for other MacOS X users?

Regards,
Markus

From moridin1138 at gmail.com  Mon Feb 23 21:52:41 2009
From: moridin1138 at gmail.com (brian jackson)
Date: Mon, 23 Feb 2009 16:52:41 -0500
Subject: [Lcdproc] lcdproc on OSX presents random block characters (all
	on)
In-Reply-To: <5ba1b2c60902231233j1470215dn8f0e1b92d951d9f8@mail.gmail.com>
References: <5ba1b2c60902201607v2c70c67fyd8afa7409fa3bade@mail.gmail.com>
	<f4eb766f0902210058t2136345u74824464b437895e@mail.gmail.com>
	<5ba1b2c60902211119j40486b4cx33b1b61c9d7119a0@mail.gmail.com>
	<20090221194217.289250@gmx.net>
	<5ba1b2c60902211656l4430d490w1b4466b35205b276@mail.gmail.com>
	<20090222064814.202310@gmx.net>
	<5ba1b2c60902220639v2abd26cfkcb271c4039384f45@mail.gmail.com>
	<20090223071123.160040@gmx.net>
	<5ba1b2c60902231233j1470215dn8f0e1b92d951d9f8@mail.gmail.com>
Message-ID: <5ba1b2c60902231352m457433f6tdbe04f1ffadf797e@mail.gmail.com>

Success!!

It looks like the problem was actually with 'make'.  When I compiled
lcdproc, despite getting no errors with the powerpc version, it was
screwing things up just enough that lcdproc would run but with the
issues described above.

After manually downloading gnumake, compiling it, and using it to
compile lcdproc... everything works fine!

Strange too, as gnumake that came with the iPhone dev kit is the only
one installed previously....

Well, problem solved.  Thanks for the help everyone!

-brian

On Mon, Feb 23, 2009 at 3:33 PM, brian jackson <moridin1138 at gmail.com> wrote:
> Unfortunately it's the same:
>
> ============
> brian$ make
> gcc -fPIC -Wall -arch x86_64 -O3 -Wno-unused-function -bundle
> -flat_namespace -undefined suppress  -o MtxOrb.so  MtxOrb.o libLCD.a
> libbignum.a -ldl
> brian$
> brian$ ./LCDd -c ../LCDd.conf
> Could not open driver module /Users/brian/lcdproc3/server/drivers/Mtx:
> dlopen(/Users/brian/lcdproc3/server/drivers/MtxOrb.so, 2): no suitable
> image found.  Did find:
>        /Users/brian/lcdproc3/server/drivers/MtxOrb.so: mach-o, but
> wrong architecture
> Driver [MtxOrb] binding failed
> Could not load driver MtxOrb
> There is no output driver
> Critical error while initializing, abort.
> brian$
>
> =========
>
> The make -V CFLAGS does not like the -V,  however upon doing a -v I noticed:
> "This program built for powerpc-apple-darwin9.0"
> That's not right, it shouldnt be powerpc!
>
> gcc reports that it's for i686... Strange.
>
> -brian
>
>
>
> On Mon, Feb 23, 2009 at 2:11 AM, Markus Dolze <bsdfan at nurfuerspam.de> wrote:
>> Hi,
>>
>> I found that Apple has a lot of documentation about that, but as I can't test anything someone else will have to step in.
>>
>> It may also be a good idea to use the system's default CFLAGS and LDFLAGS. Would you please mail me the output of:
>> make -V CFLAGS
>> make -V LDFLAGS
>> (should work from any directory)
>>
>> Regards,
>> Markus
>>
>> -------- Original-Nachricht --------
>>> Datum: Sun, 22 Feb 2009 09:39:40 -0500
>>> Von: brian jackson <moridin1138 at gmail.com>
>>> An: Markus Dolze <bsdfan at nurfuerspam.de>
>>> Betreff: Re: [Lcdproc] lcdproc on OSX presents random block characters (all   on)
>>
>>> Nope, everything would appear to be in order.
>>>
>>> ------
>>> brian$ make
>>> gcc -fPIC -Wall  -O3 -Wno-unused-function -bundle -flat_namespace
>>> -undefined suppress  -o MtxOrb.so  MtxOrb.o libLCD.a libbignum.a -ldl
>>> brian$
>>> ------
>>>
>>> Strange. :(
>>>
>>> -brian
>>>
>>>
>>> On Sun, Feb 22, 2009 at 1:48 AM, Markus Dolze <bsdfan at nurfuerspam.de>
>>> wrote:
>>> >
>>> > -------- Original-Nachricht --------
>>> >> Datum: Sat, 21 Feb 2009 19:56:41 -0500
>>> >> Von: brian jackson <moridin1138 at gmail.com>
>>> >> An: Markus Dolze <bsdfan at nurfuerspam.de>
>>> >> Betreff: Re: [Lcdproc] lcdproc on OSX presents random block characters
>>> (all   on)
>>> >
>>> >> Thanks, but is this from an Intel Mac?
>>> >>
>>> >> I get the following:
>>> >>
>>> >> -----
>>> >>
>>> >> Listening for queries on 127.0.0.1:13666
>>> >> Could not open driver module /usr/local/lib/lcdproc/MtxOrb.so:
>>> >> dlopen(/usr/local/lib/lcdproc/MtxOrb.so, 2): no suitable image found.
>>> >> Did find:
>>> >>         /usr/local/lib/lcdproc/MtxOrb.so: mach-o, but wrong
>>> architecture
>>> >> Driver [MtxOrb] binding failed
>>> >> Could not load driver MtxOrb
>>> >> There is no output driver
>>> >> Critical error while initializing, abort.
>>> >> brian$
>>> >>
>>> >> -----
>>> >>
>>> >
>>> > Hi,
>>> >
>>> > the patch was from x86 Freebsd, but I can't see any platform specific
>>> code. Have any errors occured during 'make'?
>>> >
>>> > Regards,
>>> > Markus
>>> >
>>
>

From moridin1138 at gmail.com  Mon Feb 23 21:57:26 2009
From: moridin1138 at gmail.com (brian jackson)
Date: Mon, 23 Feb 2009 16:57:26 -0500
Subject: [Lcdproc] Matrix Orbital display registry
In-Reply-To: <f4eb766f0902230905s6d9dea9s973255995ae0df4b@mail.gmail.com>
References: <f4eb766f0902230905s6d9dea9s973255995ae0df4b@mail.gmail.com>
Message-ID: <5ba1b2c60902231357l129cfc29u75be39c8d867673d@mail.gmail.com>

I have the following:

LCD2041 20x4 LCD serial interface.  Works with Prolific Serial-USB as
well.  No extra features.
core functions work with CVS.

LK202-25-GW-V 20x2 serial interface.  Also works with Prolific
Serial-USB.  No extra features.
core functions work with CVS.

-brian

On Mon, Feb 23, 2009 at 12:05 PM, Ethan Dicks <ethan.dicks at gmail.com> wrote:
> Hi, All,
>
> As mentioned in my previous message, I think it would be a good idea
> for those of us on the list with Matrix Orbital displays to post what
> we have so we can coordinate testing.
>
> I have the following displays...
>
> VKD204 20x4 VFD w/5x5 keypad, 3 GPOs, serial interface (but also has
> optional TTL and I2C).  It's an older device, about 10 years old at
> this point but has been incredibly reliable.  The only problem I've
> had is that it's so old that the glue for the rubber mounting pads on
> the VFD glass gave way a while back, but a drop of superglue fixed
> that (and I later found the *exact* VFD on eBay for $20, so I have a
> spare).  There is no online manual for this module, but fortunately I
> still have the original printed manual.
>
> LK204-7T-1U-BK-USB-TCI 20x4 LCD w/built-in keypad, 9 GPOs (6 for
> onboard LEDs, 3 external), Dallas 1-Wire bus, multi-color backlight,
> USB interface (but also available in serial, I2C and TTL).  Its core
> functions work fine with the present CVS head, but it has
> vendor-supplied features that LCDproc doesn't take advantage of (yet).
>
> GLK19264 LCD w/built-in keypad, USB interface, but graphical, not
> textual, so outside the scope of MtxOrb.c development/testing.
>
> So if you also have a Matrix Orbital display, tell us about it.   I
> don't mind taking the initiative of coordinating notification of new
> versions of MtxOrb.c to test, but I'd like to know what scope the
> testing will entail.
>
> -ethan
> _______________________________________________
> LCDproc mailing list
> LCDproc at lists.omnipotent.net
> http://lists.omnipotent.net/mailman/listinfo/lcdproc
>

From sascha.zielinski at gmx.de  Tue Feb 24 02:36:07 2009
From: sascha.zielinski at gmx.de (Sascha)
Date: Tue, 24 Feb 2009 03:36:07 +0100
Subject: [Lcdproc] HD44780 40x4 with Backlight and winamp wiring
In-Reply-To: <49960372.9080003@nurfuerspam.de>
References: <9185341920196262063@unknownmsgid>
	<200902061027.56222.sascha.zielinski@gmx.de>
	<49960372.9080003@nurfuerspam.de>
Message-ID: <200902240336.07806.sascha.zielinski@gmx.de>

Am Samstag 14 Februar 2009 00:34:10 schrieben Sie:
> Hello,
>
> today I bought some BC327 and built the hd44780 parallel port backlight
> switching circuit.
>
> I put together a patch (attached) that includes some of my previous
> changes with some modifications for a 40x4 setup.
>
> Besides the DATA lines, I used the wiring:
>
> LCD      => Parallel Port
>
> EN1 (9)  => STRB (1)
> RW  (10) => GND  (18)
> RS  (11) => INIT (16)
> EN2 (15) => SEL  (17)
> A   (17) => BL switch circuit => LF (14)
> K   (18) => GND
>
> The BL switching circuit lights up the display not too bright. The BL
> draws current of 260 mA.
>
> To see the result: http://mdolze.gmxhome.de/files/lcdproc.avi.
>
> Regards
> Markus

Yeah! :D It took a long time but my Backlight lights up. I had to make a new 
cable. 

Thank you for all you help. I will now play around with the settings.

And thanks one more for your help :)

Regards
Sascha Zielinski

From sascha.zielinski at gmx.de  Tue Feb 24 03:26:35 2009
From: sascha.zielinski at gmx.de (Sascha)
Date: Tue, 24 Feb 2009 04:26:35 +0100
Subject: [Lcdproc] HD44780 40x4 with Backlight and winamp wiring
In-Reply-To: <49960372.9080003@nurfuerspam.de>
References: <9185341920196262063@unknownmsgid>
	<200902061027.56222.sascha.zielinski@gmx.de>
	<49960372.9080003@nurfuerspam.de>
Message-ID: <200902240426.36134.sascha.zielinski@gmx.de>

I want to use the Load screen from lcdproc too, but lcdproc always quit, if I 
start lcdproc in the konsole with:
$ lcdproc L -f

I also tried:
$ lcdproc 'L' -f

I  am always getting this massage from LCDd:

Connect from host 127.0.0.1:33967 on socket 6                                                            
sock_read_from_client: got message from client 6: "hello                                                 
"                                                                                                        
screenlist_process()                                                                                     
screenlist_process()                                                                                     
screenlist_process()                                                                                     
screenlist_process()                                                                                     
sock_read_from_client: got message from client 6: "client_set -name {LCDproc 
servereis}                  
screen_add C                                                                                             
screen_set C -name {CPU Use: servereis}                                                                  
widget_add C title title                                                                                 
widget_set C title {CPU LOAD}                                                                            
widget_add C one string                                                                                  
widget_add C two string                                                                                  
widget_add C three string                                                                                
widget_set C one 1 2 {Usr                 Nice                }                                          
widget_set C two 1 3 {Sys                 Idle                }                                          
widget_set C three 1 4 {0%                                  100%}                                        
widget_add C usr string                                                                                  
widget_add C nice string                                                                                 
widget_add C idle string                                                                                 
widget_add C sys string                                                                                  
widget_add C bar hbar                                                                                    
widget_set C bar 3 4 0                                                                                   
"                                                                                                        
error: huh? Too much data received... quiet down!                                                        

Client on socket 6 disconnected

Regards
Sascha Zielinski

From epooch at cox.net  Tue Feb 24 03:38:21 2009
From: epooch at cox.net (Eric Pooch)
Date: Mon, 23 Feb 2009 19:38:21 -0800
Subject: [Lcdproc] configfile.c breaks on Mac OS X due to nested function
In-Reply-To: <20090223173249.31310@gmx.net>
References: <20090223173249.31310@gmx.net>
Message-ID: <E9A4BE24-980F-41F2-B08B-7D1812F11999@cox.net>

I am pretty sure this has been a non-issue for almost a year.  I am  
pretty sure  the nested functions were removed a while ago.

--Eric

On Feb 23, 2009, at 9:32 AM, Markus Dolze wrote:

> Erik Hansen reported this as a SF tracker event:
>
> --- quote begin ---
>
> Nested functions have been disabled by Mac OS X Developer tools -- gcc
> 4.0.1. As a result, compilation of configfile.c fails due to the  
> following
> code:
>
> int config_read_string(const char *sectionname, const char *str)
> /* All the config parameters are placed in the given section in  
> memory.*/
> {
> int pos = 0;
> section *s;
>
> /* We use a nested fuction to transfer the characters from buffer
> to parser*/
> char get_next_char() {
> return str[pos++];
> }
>
> if ((s = find_section(sectionname)) == NULL)
> s = add_section(sectionname);
>
> return process_config(&s, get_next_char, "command line", NULL);
> }
>
> --- quote end ---
>
> Any suggestions how to deal with this? Does it work for other MacOS  
> X users?
>
> Regards,
> Markus
> _______________________________________________
> LCDproc mailing list
> LCDproc at lists.omnipotent.net
> http://lists.omnipotent.net/mailman/listinfo/lcdproc


From bsdfan at nurfuerspam.de  Tue Feb 24 08:05:46 2009
From: bsdfan at nurfuerspam.de (Markus Dolze)
Date: Tue, 24 Feb 2009 09:05:46 +0100
Subject: [Lcdproc] HD44780 40x4 with Backlight and winamp wiring
In-Reply-To: <200902240426.36134.sascha.zielinski@gmx.de>
References: <9185341920196262063@unknownmsgid>
	<200902061027.56222.sascha.zielinski@gmx.de>
	<49960372.9080003@nurfuerspam.de>
	<200902240426.36134.sascha.zielinski@gmx.de>
Message-ID: <20090224080546.149970@gmx.net>


-------- Original-Nachricht --------
> Datum: Tue, 24 Feb 2009 04:26:35 +0100
> Von: Sascha <sascha.zielinski at gmx.de>
> An: lcdproc at lists.omnipotent.net
> Betreff: Re: [Lcdproc] HD44780 40x4 with Backlight and winamp wiring

> I want to use the Load screen from lcdproc too, but lcdproc always quit,
> if I 
> start lcdproc in the konsole with:
> $ lcdproc L -f
> 
> I also tried:
> $ lcdproc 'L' -f
> 
> I  am always getting this massage from LCDd:
> 
> Connect from host 127.0.0.1:33967 on socket 6                             
>                               
> sock_read_from_client: got message from client 6: "hello                  
>                               
> "                                                                         
>                               
> screenlist_process()                                                      
>                               
> screenlist_process()                                                      
>                               
> screenlist_process()                                                      
>                               
> screenlist_process()                                                      
>                               
> sock_read_from_client: got message from client 6: "client_set -name
> {LCDproc 
> servereis}                  
> screen_add C                                                              
>                               
> screen_set C -name {CPU Use: servereis}                                   
>                               
> widget_add C title title                                                  
>                               
> widget_set C title {CPU LOAD}                                             
>                               
> widget_add C one string                                                   
>                               
> widget_add C two string                                                   
>                               
> widget_add C three string                                                 
>                               
> widget_set C one 1 2 {Usr                 Nice                }           
>                               
> widget_set C two 1 3 {Sys                 Idle                }           
>                               
> widget_set C three 1 4 {0%                                  100%}         
>                               
> widget_add C usr string                                                   
>                               
> widget_add C nice string                                                  
>                               
> widget_add C idle string                                                  
>                               
> widget_add C sys string                                                   
>                               
> widget_add C bar hbar                                                     
>                               
> widget_set C bar 3 4 0                                                    
>                               
> "                                                                         
>                               
> error: huh? Too much data received... quiet down!                         
>                               
> 
> Client on socket 6 disconnected
> 

Hi,

I had the same problem some time ago. With large displays like a 40x4 the client sends too much data for the server's receive buffer if using the load screen. I think I fixed it already for my setup, but I am currently away from my development machine.

Regards
Markus

From bsdfan at nurfuerspam.de  Tue Feb 24 08:18:27 2009
From: bsdfan at nurfuerspam.de (Markus Dolze)
Date: Tue, 24 Feb 2009 09:18:27 +0100
Subject: [Lcdproc] configfile.c breaks on Mac OS X due to nested function
In-Reply-To: <E9A4BE24-980F-41F2-B08B-7D1812F11999@cox.net>
References: <20090223173249.31310@gmx.net>
	<E9A4BE24-980F-41F2-B08B-7D1812F11999@cox.net>
Message-ID: <20090224081827.179590@gmx.net>

Hi,

OK, I checked the source and the mentioned function is still there but wrapped with #ifdef since version 0.5.2. The user doesn't state which version he is using and he is not reachable by mail.

Regards,
Markus

-------- Original-Nachricht --------
> Datum: Mon, 23 Feb 2009 19:38:21 -0800
> Von: Eric Pooch <epooch at cox.net>
> An: Markus Dolze <bsdfan at nurfuerspam.de>
> CC: LCDproc Mailing List <lcdproc at lists.omnipotent.net>
> Betreff: Re: [Lcdproc] configfile.c breaks on Mac OS X due to nested function

> I am pretty sure this has been a non-issue for almost a year.  I am  
> pretty sure  the nested functions were removed a while ago.
> 
> --Eric
> 
> On Feb 23, 2009, at 9:32 AM, Markus Dolze wrote:
> 
> > Erik Hansen reported this as a SF tracker event:
> >
> > --- quote begin ---
> >
> > Nested functions have been disabled by Mac OS X Developer tools -- gcc
> > 4.0.1. As a result, compilation of configfile.c fails due to the  
> > following
> > code:
> >
> > int config_read_string(const char *sectionname, const char *str)
> > /* All the config parameters are placed in the given section in  
> > memory.*/
> > {
> > int pos = 0;
> > section *s;
> >
> > /* We use a nested fuction to transfer the characters from buffer
> > to parser*/
> > char get_next_char() {
> > return str[pos++];
> > }
> >
> > if ((s = find_section(sectionname)) == NULL)
> > s = add_section(sectionname);
> >
> > return process_config(&s, get_next_char, "command line", NULL);
> > }
> >
> > --- quote end ---
> >
> > Any suggestions how to deal with this? Does it work for other MacOS  
> > X users?
> >

From malte at maltepoeggel.de  Tue Feb 24 12:11:07 2009
From: malte at maltepoeggel.de (=?iso-8859-1?Q?Malte_P=F6ggel?=)
Date: Tue, 24 Feb 2009 13:11:07 +0100
Subject: [Lcdproc] Changes to get EA-DOGM163 + four keys working with
	hd44780-lcd2usb driver
In-Reply-To: <20090221201626.289250@gmx.net>
References: <BBC090545EA14A1CB4E61EF56FAA5219@subnote1400>
	<20090221201626.289250@gmx.net>
Message-ID: <D8B559509C6B4526B97C4F675184332A@Schleppi4000>

----- Original Message ----- 
From: "Markus Dolze" <bsdfan at nurfuerspam.de>
To: ""Malte P?ggel"" <malte at maltepoeggel.de>; <lcdproc at lists.omnipotent.net>
Sent: Saturday, February 21, 2009 9:16 PM
Subject: Re: [Lcdproc] Changes to get EA-DOGM163 + four keys working 
withhd44780-lcd2usb driver

Hi,

> I had a quick look at the controller's datasheet today. I have already 
> seen those DOG modules in german stores. The controller is interesting 
> because of his 3-line mode.
> In 1-line mode DDRAM is addressed linear (like in lcdproc's ext_mode). In 
> 2-line mode the address of the second line starting at 0x40 (like in 
> lcdproc's hd44780 standard mode).

we tried different EA-DOG displays here, two and three line. The two line 
display seems to work perfectly without setting the ext_mode. The three line 
lcd needs the modified ext_mode.
Some of the prototypes: http://www.maltepoeggel.de/cache/sp-lcd2.jpg

Is there any way to get a hexadecimal value from the config? Currently the 
"config_get_int" function is used and i added a "LineAddress=16" to the 
config.

> Did you had a look at the character table? I have not checked if it 
> matches an existing one, but as it supports umlauts as well as japanese 
> characters.

To check out that, i have added a screen / widget with umlauts using telnet 
at fedora linux. I dont know why but the string on the display seems to be 
encoded, as there are two characters shown on each umlaut i entered. 
(??????)
Here's a pic: http://www.maltepoeggel.de/cache/umlaut.jpg

For compatibility i modified the key routine in the lcd2usb firmware so that 
it returns a scancode to the usb buffer as Joris and Marcus voted for.

I'll publish the atmel sourcecode, layout files, schematics on my webpage 
this week.

Malte 


From bsdfan at nurfuerspam.de  Tue Feb 24 19:39:47 2009
From: bsdfan at nurfuerspam.de (Markus Dolze)
Date: Tue, 24 Feb 2009 20:39:47 +0100
Subject: [Lcdproc] Changes to get EA-DOGM163 + four keys working with
 hd44780-lcd2usb driver
In-Reply-To: <D8B559509C6B4526B97C4F675184332A@Schleppi4000>
References: <BBC090545EA14A1CB4E61EF56FAA5219@subnote1400>
	<20090221201626.289250@gmx.net>
	<D8B559509C6B4526B97C4F675184332A@Schleppi4000>
Message-ID: <20090224193947.216800@gmx.net>

-------- Original-Nachricht --------
> Datum: Tue, 24 Feb 2009 13:11:07 +0100
> Von: "Malte P?ggel" <malte at maltepoeggel.de>
> An: "Markus Dolze" <bsdfan at nurfuerspam.de>, lcdproc at lists.omnipotent.net
> Betreff: Re: [Lcdproc] Changes to get EA-DOGM163 + four keys working with hd44780-lcd2usb driver

> ----- Original Message ----- 
> From: "Markus Dolze" <bsdfan at nurfuerspam.de>
> To: ""Malte P?ggel"" <malte at maltepoeggel.de>;
> <lcdproc at lists.omnipotent.net>
> Sent: Saturday, February 21, 2009 9:16 PM
> Subject: Re: [Lcdproc] Changes to get EA-DOGM163 + four keys working 
> withhd44780-lcd2usb driver
> 
> Hi,
> 
> > I had a quick look at the controller's datasheet today. I have already 
> > seen those DOG modules in german stores. The controller is interesting 
> > because of his 3-line mode.
> > In 1-line mode DDRAM is addressed linear (like in lcdproc's ext_mode).
> In 
> > 2-line mode the address of the second line starting at 0x40 (like in 
> > lcdproc's hd44780 standard mode).
> 
> we tried different EA-DOG displays here, two and three line. The two line 
> display seems to work perfectly without setting the ext_mode. The three
> line 
> lcd needs the modified ext_mode.
> Some of the prototypes: http://www.maltepoeggel.de/cache/sp-lcd2.jpg

This device looks cool.

> 
> Is there any way to get a hexadecimal value from the config? Currently the
> "config_get_int" function is used and i added a "LineAddress=16" to the 
> config.

config_get_int() uses strtol() internally. So any numbers supported by strtol() will work, so "0x10" will work.

> 
> > Did you had a look at the character table? I have not checked if it 
> > matches an existing one, but as it supports umlauts as well as japanese 
> > characters.
> 
> To check out that, i have added a screen / widget with umlauts using
> telnet 
> at fedora linux. I dont know why but the string on the display seems to be
> encoded, as there are two characters shown on each umlaut i entered. 
> (??????)
> Here's a pic: http://www.maltepoeggel.de/cache/umlaut.jpg

This may be because of the telnet or system charset. To check the available characters you may configure lcdproc with --enable-testmenus. In the server menu you then have the option to test how your display displays the available "extended" characters (ascii 160 - 255).

Regards
Markus

From ethan.dicks at gmail.com  Tue Feb 24 20:55:08 2009
From: ethan.dicks at gmail.com (Ethan Dicks)
Date: Tue, 24 Feb 2009 15:55:08 -0500
Subject: [Lcdproc] Changes to get EA-DOGM163 + four keys working with
	hd44780-lcd2usb driver
In-Reply-To: <20090224193947.216800@gmx.net>
References: <BBC090545EA14A1CB4E61EF56FAA5219@subnote1400>
	<20090221201626.289250@gmx.net>
	<D8B559509C6B4526B97C4F675184332A@Schleppi4000>
	<20090224193947.216800@gmx.net>
Message-ID: <f4eb766f0902241255r5ab3bb14pfc181412752ee8cf@mail.gmail.com>

On Tue, Feb 24, 2009 at 2:39 PM, Markus Dolze <bsdfan at nurfuerspam.de> wrote:
>> Some of the prototypes: http://www.maltepoeggel.de/cache/sp-lcd2.jpg
>
> This device looks cool.

Indeed.   Very cool.  It looks like the lines are offset from each
other by a pixel or so, or is that just the camera angle?  How do you
pick different colors, from the factory, or do you have access to the
backlight LEDs to install your own?

If those are prototypes, I'd be interested in securing a 3-line
display later.  I write line-number support into all of my clients,
but have never seen a 3-line display before.  That could be fun to
play with for a METAR client or my xmms client.  Obviously one can
pretend a 4x20 is 3x16, but it's good to see in the natural
proportions.

I look forward to hearing that this module is out of prototype.  It
would make a good desk-side display in the right case.

-ethan

From bsdfan at nurfuerspam.de  Tue Feb 24 22:01:57 2009
From: bsdfan at nurfuerspam.de (Markus Dolze)
Date: Tue, 24 Feb 2009 23:01:57 +0100
Subject: [Lcdproc] Big bug in server/main.c
In-Reply-To: <CE091CB077F4A74A9CBA33A4E4A8A3BF123D5607@USEA-EXCH4.na.uis.unisys.com>
References: <CE091CB077F4A74A9CBA33A4E4A8A3BF123D5607@USEA-EXCH4.na.uis.unisys.com>
Message-ID: <49A46E55.8020205@nurfuerspam.de>

Vallevand, Mark K wrote:
>
> While testing with my embedded Linux and also on SUSE 11 Linux, I 
> found that if time goes backwards, LCDd will stall until time catches 
> up.  Try it.  Set the time back 2 minutes.  For 2 minutes LCDd does 
> nothing.  Here?s the fix.
>
>  
>
> server/main.c
>
> 813c813
>
> <                        if ((t_diff + 1) > (LONG_MAX / 1e6)) {
>
> ---
>
> >                        if ( ((t_diff + 1) > (LONG_MAX / 1e6)) || 
> (t_diff<0) ) {
>
> If someone has the time, this really should be rewritten to use 
> something not based on the time and date of Linux.  But, this fix 
> suffices and we are now using it.
>
> Regards.
> Mark K Vallevand
>
Commited, thanks
Markus

From bsdfan at nurfuerspam.de  Tue Feb 24 22:12:22 2009
From: bsdfan at nurfuerspam.de (Markus Dolze)
Date: Tue, 24 Feb 2009 23:12:22 +0100
Subject: [Lcdproc] Please test: hd44780 backlight update
In-Reply-To: <497C51CD.1080801@nurfuerspam.de>
References: <497C51CD.1080801@nurfuerspam.de>
Message-ID: <49A470C6.9070709@nurfuerspam.de>

Markus Dolze wrote:
> Hello,
>
> After analyzing Sascha's problem with 40x4 winamp-wired display I had 
> a closer look how the backlight is used.
>
> I found that:
>
> 1. In render.c the backlight state is determined.
> 2. drivers.c passed the BL state to all drivers, if supported
> 3. The hd44780 passed the BL to the connection type, if supported
> 4. The conntection type sets the hardware accordingly.
>
> Besides a possible problem in 3. because the hardware is asked to set 
> the backlight off if the user specified no backlight being available 
> in the config file, the whole chain is executed with every screen 
> rendering.
>
> Looking at how other drivers handle this I found some implement an 
> "incremental" backlight change (only update hardware if the the state 
> has really changed) while others do not.
>
> I decided to implement this "incremental update" for the hd44780 
> driver as well. Patch attached.
>
> As this applies to all connection types, I ask developers and users 
> with hd44780 type displays and backlight to test the impact of this 
> change. I already tested with lcd2usb and winamp (but without 
> switchable backlight) and found no problems so far.
>
> Please also test what happens if "Backlight=off" is set in LCDd.conf.
>
> Regards
> Markus

Commited this patch to CVS.

Regards
Markus

From bsdfan at nurfuerspam.de  Tue Feb 24 22:20:47 2009
From: bsdfan at nurfuerspam.de (Markus Dolze)
Date: Tue, 24 Feb 2009 23:20:47 +0100
Subject: [Lcdproc] lcdproc on OSX presents random block characters (all
 on)
In-Reply-To: <5ba1b2c60902231352m457433f6tdbe04f1ffadf797e@mail.gmail.com>
References: <5ba1b2c60902201607v2c70c67fyd8afa7409fa3bade@mail.gmail.com>	
	<f4eb766f0902210058t2136345u74824464b437895e@mail.gmail.com>	
	<5ba1b2c60902211119j40486b4cx33b1b61c9d7119a0@mail.gmail.com>	
	<20090221194217.289250@gmx.net>	
	<5ba1b2c60902211656l4430d490w1b4466b35205b276@mail.gmail.com>	
	<20090222064814.202310@gmx.net>	
	<5ba1b2c60902220639v2abd26cfkcb271c4039384f45@mail.gmail.com>	
	<20090223071123.160040@gmx.net>	
	<5ba1b2c60902231233j1470215dn8f0e1b92d951d9f8@mail.gmail.com>
	<5ba1b2c60902231352m457433f6tdbe04f1ffadf797e@mail.gmail.com>
Message-ID: <49A472BF.2020505@nurfuerspam.de>

Hello Brian,

does it now work with or without the backlight patch I sent to you?

Markus

brian jackson wrote:
> Success!!
> 
> It looks like the problem was actually with 'make'.  When I compiled
> lcdproc, despite getting no errors with the powerpc version, it was
> screwing things up just enough that lcdproc would run but with the
> issues described above.
> 
> After manually downloading gnumake, compiling it, and using it to
> compile lcdproc... everything works fine!
> 
> Strange too, as gnumake that came with the iPhone dev kit is the only
> one installed previously....
> 
> Well, problem solved.  Thanks for the help everyone!
> 
> -brian


From Mark.Vallevand at UNISYS.com  Tue Feb 24 22:22:42 2009
From: Mark.Vallevand at UNISYS.com (Vallevand, Mark K)
Date: Tue, 24 Feb 2009 16:22:42 -0600
Subject: [Lcdproc] Big bug in server/main.c
In-Reply-To: <49A46E55.8020205@nurfuerspam.de>
References: <CE091CB077F4A74A9CBA33A4E4A8A3BF123D5607@USEA-EXCH4.na.uis.unisys.com>
	<49A46E55.8020205@nurfuerspam.de>
Message-ID: <CE091CB077F4A74A9CBA33A4E4A8A3BF128F83CA@USEA-EXCH4.na.uis.unisys.com>

Thank you!

Regards.
Mark K Vallevand

"I got free checking at Bear Stearns!"

THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY
MATERIAL and is thus for use only by the intended recipient. If you
received this in error, please contact the sender and delete the e-mail
and its attachments from all computers.


-----Original Message-----
From: Markus Dolze [mailto:bsdfan at nurfuerspam.de] 
Sent: Tuesday, February 24, 2009 4:02 PM
To: Vallevand, Mark K
Cc: lcdproc at lists.omnipotent.net
Subject: Re: [Lcdproc] Big bug in server/main.c

Vallevand, Mark K wrote:
>
> While testing with my embedded Linux and also on SUSE 11 Linux, I 
> found that if time goes backwards, LCDd will stall until time catches 
> up.  Try it.  Set the time back 2 minutes.  For 2 minutes LCDd does 
> nothing.  Here's the fix.
>
>  
>
> server/main.c
>
> 813c813
>
> <                        if ((t_diff + 1) > (LONG_MAX / 1e6)) {
>
> ---
>
> >                        if ( ((t_diff + 1) > (LONG_MAX / 1e6)) || 
> (t_diff<0) ) {
>
> If someone has the time, this really should be rewritten to use 
> something not based on the time and date of Linux.  But, this fix 
> suffices and we are now using it.
>
> Regards.
> Mark K Vallevand
>
Commited, thanks
Markus

From bsdfan at nurfuerspam.de  Tue Feb 24 22:36:07 2009
From: bsdfan at nurfuerspam.de (Markus Dolze)
Date: Tue, 24 Feb 2009 23:36:07 +0100
Subject: [Lcdproc] Matrix Orbital display registry
In-Reply-To: <f4eb766f0902230905s6d9dea9s973255995ae0df4b@mail.gmail.com>
References: <f4eb766f0902230905s6d9dea9s973255995ae0df4b@mail.gmail.com>
Message-ID: <49A47657.8050508@nurfuerspam.de>

Ethan Dicks wrote:
> Hi, All,
>
> As mentioned in my previous message, I think it would be a good idea
> for those of us on the list with Matrix Orbital displays to post what
> we have so we can coordinate testing.
>
>
>   
I have a LK202-25, PCB Rev. 1.12 (PIC based), unknown old firmware (does 
not respond to "6" or "7" commands).

This device suffers from the non-adjustable backlight / random block 
characters problem. Works fne otherwise.

Markus

From bsdfan at nurfuerspam.de  Tue Feb 24 22:43:57 2009
From: bsdfan at nurfuerspam.de (Markus Dolze)
Date: Tue, 24 Feb 2009 23:43:57 +0100
Subject: [Lcdproc] HD44780 40x4 with Backlight and winamp wiring
In-Reply-To: <200902240336.07806.sascha.zielinski@gmx.de>
References: <9185341920196262063@unknownmsgid>	<200902061027.56222.sascha.zielinski@gmx.de>	<49960372.9080003@nurfuerspam.de>
	<200902240336.07806.sascha.zielinski@gmx.de>
Message-ID: <49A4782D.30609@nurfuerspam.de>

Sascha wrote:
> Am Samstag 14 Februar 2009 00:34:10 schrieben Sie:
>   
>> Hello,
>>
>> today I bought some BC327 and built the hd44780 parallel port backlight
>> switching circuit.
>>
>> I put together a patch (attached) that includes some of my previous
>> changes with some modifications for a 40x4 setup.
>>
>> Besides the DATA lines, I used the wiring:
>>
>> LCD      => Parallel Port
>>
>> EN1 (9)  => STRB (1)
>> RW  (10) => GND  (18)
>> RS  (11) => INIT (16)
>> EN2 (15) => SEL  (17)
>> A   (17) => BL switch circuit => LF (14)
>> K   (18) => GND
>>
>> The BL switching circuit lights up the display not too bright. The BL
>> draws current of 260 mA.
>>
>> To see the result: http://mdolze.gmxhome.de/files/lcdproc.avi.
>>
>> Regards
>> Markus
>>     
>
> Yeah! :D It took a long time but my Backlight lights up. I had to make a new 
> cable. 
>
> Thank you for all you help. I will now play around with the settings.
>
> And thanks one more for your help :)
>
>
>   
Attached is the patch mentioned above. The important modification is 
that the EN2 line is set if two displays are attached (as given by the 
'vSpan' option). This now works independent of the availability of the 
backlight.

Any comments?

Markus
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patch-hd44780-winamp.diff
URL: <http://lists.omnipotent.net/pipermail/lcdproc/attachments/20090224/67dd7c7f/attachment.txt>

From bsdfan at nurfuerspam.de  Tue Feb 24 23:04:13 2009
From: bsdfan at nurfuerspam.de (Markus Dolze)
Date: Wed, 25 Feb 2009 00:04:13 +0100
Subject: [Lcdproc] imonlcd server driver with icon support
Message-ID: <49A47CED.7060101@nurfuerspam.de>

Hi,

I would like to point your attention to 
http://sourceforge.net/tracker/index.php?func=detail&aid=2620055&group_id=119&atid=300119

This is the imonlcd driver from codeka.com. It contains a working 
solution for accessing icons beside the display by using the output() 
function.

The driver is commented well (including doxygen) but misses 
documentation. I have not checked anything else yet and would like to 
hear your comments.

Regards
Markus

From ethan.dicks at gmail.com  Tue Feb 24 23:04:48 2009
From: ethan.dicks at gmail.com (Ethan Dicks)
Date: Tue, 24 Feb 2009 18:04:48 -0500
Subject: [Lcdproc] Matrix Orbital display registry
In-Reply-To: <49A47657.8050508@nurfuerspam.de>
References: <f4eb766f0902230905s6d9dea9s973255995ae0df4b@mail.gmail.com>
	<49A47657.8050508@nurfuerspam.de>
Message-ID: <f4eb766f0902241504k16588e6u27fd905fe7ea1da4@mail.gmail.com>

On Tue, Feb 24, 2009 at 5:36 PM, Markus Dolze <bsdfan at nurfuerspam.de> wrote:
> I have a LK202-25, PCB Rev. 1.12 (PIC based), unknown old firmware (does not
> respond to "6" or "7" commands).

>From talking to the M-O guys, if it has a PIC it's definitely an older
one (my VKD204
has a PIC).  They've moved on to AVRs for more recent stuff.

> This device suffers from the non-adjustable backlight / random block
> characters problem. Works fne otherwise.

This one will be a good one to keep an eye on for testing.

Thanks, Markus,

-ethan

From vincent at cunniffe.net  Wed Feb 25 00:43:13 2009
From: vincent at cunniffe.net (Vincent Cunniffe)
Date: Wed, 25 Feb 2009 00:43:13 +0000
Subject: [Lcdproc] PicoLCD 20x4
Message-ID: <49A49421.7020809@cunniffe.net>

Hi,

I've been working at getting the PicoLCD 20x4 device (lsusb shows it as 
a 04d8:c001) working using under CentOS 5.0

It's for eventual deployment on a different machine, but I want to get 
it working in dev first. I've got all of the basic support working, it's 
detected correctly and can be seen by LCDd. I can run lcdproc and the 
various info screens cycle through correctly on the device.

Driver was downloaded from :

http://resources.mini-box.com/online/picolcd/4x20/lcdproc-picolcd20x4-0.5.2-cvs.tgz

However, there are a couple of problems :

1. The rightmost column won't display (looks to be a known problem from
    the email thread on 2009/02/02 here)... any idea when the patched
    version will be out? Worst case I can integrate it myself.
2. Keypresses don't seem to get detected at all. They show up on the
    device itself ('Hold', 'Rotate', etc.) when I press OK, but nothing
    happens on the backend when I press any of the keys. This is with
    lcdexec running with its example .conf file, and connecting to the
    server.
3. I get a warning of :

       Interface 0 already claimed by 'usbhid' detaching.

    every time I start LCDd... is this anything to do with the keypress
    problem?

Any assistance or leads gratefully received,

Regards,

Vin

From vincent at cunniffe.net  Wed Feb 25 00:46:52 2009
From: vincent at cunniffe.net (Vincent Cunniffe)
Date: Wed, 25 Feb 2009 00:46:52 +0000
Subject: [Lcdproc] PicoLCD 20x4
In-Reply-To: <49A49421.7020809@cunniffe.net>
References: <49A49421.7020809@cunniffe.net>
Message-ID: <49A494FC.2010209@cunniffe.net>

Vincent Cunniffe wrote:
> Hi,
> 
> I've been working at getting the PicoLCD 20x4 device (lsusb shows it as 
> a 04d8:c001) working using under CentOS 5.0

<snip>

Just to confirm, I tested the device on a Windows box using the test 
software from PicoLCD, and all of the keypresses show up correctly, so 
there's no hardware problem.

Regards,

Vin

From code at edoceo.com  Wed Feb 25 02:24:46 2009
From: code at edoceo.com (edoceo)
Date: Tue, 24 Feb 2009 18:24:46 -0800
Subject: [Lcdproc] PicoLCD 20x4
In-Reply-To: <49A494FC.2010209@cunniffe.net>
References: <49A49421.7020809@cunniffe.net> <49A494FC.2010209@cunniffe.net>
Message-ID: <6bf66f090902241824w3447f809n90988f9e88b00d0@mail.gmail.com>

All,
  I'm having this exact same issue on Gentoo using the latest CVS from
lcdproc (grabbed yesterday).  I also tested on Win and saw the screen
and buttons were fully OK.  I'm still unable to find where in the
lcdproc code-base I need to dig (hey, I've only spent 45m so far) but
if anyone has pointers I'll hack some code and maybe Vincent and I can
do some testing on it.

  Would also like to add that the "dead" column issue even affects the
text produced when I'm pushing buttons so things lik "Prev" and "Next"
show up as "Pre" or "Nex" (and Hold and Rotate look like "Hol" and
"Rotat")  The are positioned correctly - just the 20th column doesn't
"draw" anything.

Thanks!

On Tue, Feb 24, 2009 at 4:46 PM, Vincent Cunniffe <vincent at cunniffe.net> wrote:
>> Hi,
>> I've been working at getting the PicoLCD 20x4 device (lsusb shows it as a
>> 04d8:c001) working using under CentOS 5.0

David Busby
Edoceo, Inc.
http://edoceo.com/

From sascha.zielinski at gmx.de  Wed Feb 25 02:34:20 2009
From: sascha.zielinski at gmx.de (Sascha)
Date: Wed, 25 Feb 2009 03:34:20 +0100
Subject: [Lcdproc] LCDproc Digest, Vol 7, Issue 12
In-Reply-To: <mailman.1112.1235514038.30287.lcdproc@lists.omnipotent.net>
References: <mailman.1112.1235514038.30287.lcdproc@lists.omnipotent.net>
Message-ID: <200902250334.20644.sascha.zielinski@gmx.de>

> Markus Dolze wrote:
> > Hello,
> >
> > After analyzing Sascha's problem with 40x4 winamp-wired display I had
> > a closer look how the backlight is used.
> >
> > I found that:
> >
> > 1. In render.c the backlight state is determined.
> > 2. drivers.c passed the BL state to all drivers, if supported
> > 3. The hd44780 passed the BL to the connection type, if supported
> > 4. The conntection type sets the hardware accordingly.
> >
> > Besides a possible problem in 3. because the hardware is asked to set
> > the backlight off if the user specified no backlight being available
> > in the config file, the whole chain is executed with every screen
> > rendering.
> >
> > Looking at how other drivers handle this I found some implement an
> > "incremental" backlight change (only update hardware if the the state
> > has really changed) while others do not.
> >
> > I decided to implement this "incremental update" for the hd44780
> > driver as well. Patch attached.
> >
> > As this applies to all connection types, I ask developers and users
> > with hd44780 type displays and backlight to test the impact of this
> > change. I already tested with lcd2usb and winamp (but without
> > switchable backlight) and found no problems so far.
> >
> > Please also test what happens if "Backlight=off" is set in LCDd.conf.
> >
> > Regards
> > Markus
>
> Commited this patch to CVS.
>
> Regards
> Markus

I checked out a fresh CVS and everything compiled fine. I set the backlight 
setting on and off in the config file and the programm behaved like it should.
I will do some more tests, if lcdproc starts with the load plugin.

Is it possible to switch off the backlight with a commandline option or over a 
script wich connects to telnet? Would be great if I could turn the backlight 
off between some time  (00:00 - 6:00 am).

I don't know if its the right place. Someone knows whether the perl lcdproc 
extension is still in active development? It seems that IO::lcdproc is missing 
some features like scoller, frame, backlight, ....

Regards Sascha

From andy at siliconlandmark.com  Wed Feb 25 03:41:09 2009
From: andy at siliconlandmark.com (Andre Guibert de Bruet)
Date: Tue, 24 Feb 2009 22:41:09 -0500
Subject: [Lcdproc] PicoLCD 20x4
In-Reply-To: <6bf66f090902241824w3447f809n90988f9e88b00d0@mail.gmail.com>
References: <49A49421.7020809@cunniffe.net> <49A494FC.2010209@cunniffe.net>
	<6bf66f090902241824w3447f809n90988f9e88b00d0@mail.gmail.com>
Message-ID: <B0474C8B-D352-4341-AA23-E36FC5697F29@siliconlandmark.com>

On Feb 24, 2009, at 9:24 PM, edoceo wrote:

>  I'm having this exact same issue on Gentoo using the latest CVS from
> lcdproc (grabbed yesterday).  I also tested on Win and saw the screen
> and buttons were fully OK.  I'm still unable to find where in the
> lcdproc code-base I need to dig (hey, I've only spent 45m so far) but
> if anyone has pointers I'll hack some code and maybe Vincent and I can
> do some testing on it.
>
>  Would also like to add that the "dead" column issue even affects the
> text produced when I'm pushing buttons so things lik "Prev" and "Next"
> show up as "Pre" or "Nex" (and Hold and Rotate look like "Hol" and
> "Rotat")  The are positioned correctly - just the 20th column doesn't
> "draw" anything.


See the patches from early February, which address this very issue.

Cheers,
Andy

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



From code at edoceo.com  Wed Feb 25 07:55:30 2009
From: code at edoceo.com (edoceo)
Date: Tue, 24 Feb 2009 23:55:30 -0800
Subject: [Lcdproc] PicoLCD 20x4
In-Reply-To: <6bf66f090902242050y32a6adbfm43791682f93db0b5@mail.gmail.com>
References: <49A49421.7020809@cunniffe.net> <49A494FC.2010209@cunniffe.net>
	<6bf66f090902241824w3447f809n90988f9e88b00d0@mail.gmail.com>
	<B0474C8B-D352-4341-AA23-E36FC5697F29@siliconlandmark.com>
	<6bf66f090902242050y32a6adbfm43791682f93db0b5@mail.gmail.com>
Message-ID: <6bf66f090902242355x572d6e61j68f32ea7b0c4d5ab@mail.gmail.com>

Oops. With a deft amateur move I sent this from the wrong account and
it bounced.  I hope the list admins won't hold it against me.  Here it
is from the right address.  My apologies

On Tue, Feb 24, 2009 at 8:50 PM, edoceo <null at edoceo.com> wrote:
> Andre,
> ?Yes! Thank you - found it in a message dated 2008-11-32
>
> ?http://article.gmane.org/gmane.comp.sysutils.lcdproc/12364/match=picolcd
>
> ?So then I rebuilt like so for debugging:
> ? ./configure --enable-debug and ran the server in -r5
>
> ?In server/drivers/picolcd.c the function picoLCD_string() starts at line 431
> ?Like Andre's email above stated there are some 'x-- and y-- statements
> ?In the CVS from yesterday they are on line 452 and I simply moved
> them to line 444 to fix the issue.
>
> Here's my work in patch form:
> ?https://carbon.edoceo.com/picolcd.patch
>
> Thanks all!
>
> /David Busby/
> Edoceo, Inc.
> http://edoceo.com/
>

From malte at maltepoeggel.de  Wed Feb 25 14:50:07 2009
From: malte at maltepoeggel.de (=?iso-8859-1?Q?Malte_P=F6ggel?=)
Date: Wed, 25 Feb 2009 15:50:07 +0100
Subject: [Lcdproc] Changes to get EA-DOGM163 + four keys working with
	hd44780-lcd2usb driver
References: <BBC090545EA14A1CB4E61EF56FAA5219@subnote1400>
	<20090221201626.289250@gmx.net>
	<D8B559509C6B4526B97C4F675184332A@Schleppi4000>
	<20090224193947.216800@gmx.net>
Message-ID: <640A2DDB416645A58B0EC4D12737744D@subnote1400>

Hi,

> config_get_int() uses strtol() internally. So any numbers supported by 
> strtol() will work, so "0x10" will work.

very good, here are the changed sources :-)

> Indeed.   Very cool.  It looks like the lines are offset from each
> other by a pixel or so, or is that just the camera angle?  How do you
> pick different colors, from the factory, or do you have access to the
> backlight LEDs to install your own?

There is a little offset, that wont look very good for the bar graphics... 
But its okay..
The different display types and the different backlights are sold 
seperately, so every user can combine his favourite lcd glass + bl. There is 
also a RGB backlight available!
You may find some more information on the product page: 
http://www.lcd-module.com/produkte/dog.html

> If those are prototypes, I'd be interested in securing a 3-line
> display later.  I write line-number support into all of my clients,
> but have never seen a 3-line display before.  That could be fun to
> play with for a METAR client or my xmms client.  Obviously one can
> pretend a 4x20 is 3x16, but it's good to see in the natural
> proportions.

The size of the PCB is very small - about 10 x 3,5 cm. I think it would fit 
perfectly into a 5 1/4 zoll slot.

> I look forward to hearing that this module is out of prototype.  It
> would make a good desk-side display in the right case.

If you are interested in building a display, you could download the layout 
files, etc on my homepage later.
I dont know if there would ever be kits available, but its no problem for me 
to make some small amounts of single sided PCBs at home.

Malte

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: hd44780.c
URL: <http://lists.omnipotent.net/pipermail/lcdproc/attachments/20090225/8a3a4658/attachment-0002.txt>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: hd44780-low.h
URL: <http://lists.omnipotent.net/pipermail/lcdproc/attachments/20090225/8a3a4658/attachment-0003.txt>

From ethan.dicks at gmail.com  Wed Feb 25 16:00:35 2009
From: ethan.dicks at gmail.com (Ethan Dicks)
Date: Wed, 25 Feb 2009 11:00:35 -0500
Subject: [Lcdproc] Changes to get EA-DOGM163 + four keys working with
	hd44780-lcd2usb driver
In-Reply-To: <640A2DDB416645A58B0EC4D12737744D@subnote1400>
References: <BBC090545EA14A1CB4E61EF56FAA5219@subnote1400>
	<20090221201626.289250@gmx.net>
	<D8B559509C6B4526B97C4F675184332A@Schleppi4000>
	<20090224193947.216800@gmx.net>
	<640A2DDB416645A58B0EC4D12737744D@subnote1400>
Message-ID: <f4eb766f0902250800x3668a120s15fa2108f6d0a50f@mail.gmail.com>

On Wed, Feb 25, 2009 at 9:50 AM, Malte P?ggel <malte at maltepoeggel.de> wrote:
>> Indeed. ? Very cool. ?It looks like the lines are offset from each
>> other by a pixel or so, or is that just the camera angle?
>
> There is a little offset, that wont look very good for the bar graphics...
> But its okay..

That's fine with me.  I personally don't use bar graphs much, but I do
make a point to support them in the drivers I write.

Some of the modules I work with have larger spaces between the
character cells than others.  Sometimes the bargraphs don't look very
good on those.

> The different display types and the different backlights are sold
> seperately, so every user can combine his favourite lcd glass + bl. There is
> also a RGB backlight available!
> You may find some more information on the product page:
> http://www.lcd-module.com/produkte/dog.html

Very interesting.  I remember these guys from their DIP series.  I
never got one since they were in Germany (exchange rate, overseas
shipping costs, etc.), but they looked really good.

I did spot a great page of datasheets on their website, full of PDFs
for controller chips that LCDproc supports...

<http://www.lcd-module.com/datasheets.html>

It reminds me that one of my long-term projects is to put together an
oscillator and LPT interface cable for an AX6120 display I've had for
years.  It's so small (122x32 pixels) that when I got it, I thought it
was a 2x16 character display.  It was really cheap because the seller
had no docs and no idea how to drive it.  I keep meaning to pick up
more when I see that seller at Hamventions, but I've missed the last
two places they sold at.  I think it's pretty much functionally
identical to one of their DIP displays, just with a different pinout
(across the top rather than down both sides).

> The size of the PCB is very small - about 10 x 3,5 cm. I think it would fit
> perfectly into a 5 1/4 zoll slot.

That's always nice.  I like my Matrix Orbital VKD204, but it's so tall
that it takes a double-bay.  The newer M-O displays are shorter and
wider and fit a 5.25" slot perfectly.

>> I look forward to hearing that this module is out of prototype. ?It
>> would make a good desk-side display in the right case.
>
> If you are interested in building a display, you could download the layout
> files, etc on my homepage later.
> I dont know if there would ever be kits available, but its no problem for me
> to make some small amounts of single sided PCBs at home.

If I understand what you are doing (I can't exactly tell from the
pictures you posted), you are using an ATMEGA-8 with Till Harbaum's
code on that single-sided PCB, right?  I wouldn't mind a pre-fabbed
board, but if you are making them at home, I can certainly whip
something up myself (I do a lot with pre-perfed 0.1" protoboard and
30ga wire).  I've got all the gear to burn AVRs, etc.

So the next question would be where to pick up a 3-line DOG display in
the States.

I did a little digging around and couldn't find info on the LED
backlights.  I am, of course, curious about the RGB backlight since
it's clearly easy to pick which backlight you want to use.  Malte, do
you have any specific docs on the backlight modules?

-ethan

From joehenley at kc.rr.com  Wed Feb 25 17:13:10 2009
From: joehenley at kc.rr.com (Joe Henley)
Date: Wed, 25 Feb 2009 11:13:10 -0600
Subject: [Lcdproc] newbie question
Message-ID: <49A57C26.4060808@kc.rr.com>

Hi,

I'm a newbie here, so please forgive any un-intended "politically 
incorrect" items.  Also, I'm not a C programmer, so I'm pretty much 
dependent upon what I can find at sites like this.

Is lcdproc still under development?  The last version is from 2007.  I 
see lots and lots of patches; and I see comments about folks not getting 
things to run when patches overlap.  I see alot of notes about getting 
patches incorporated, but it seems none do.  I've looked repeatedly at 
the sourceforge site for updates to the code, but patches I see here 
don't seem to show up there.

I bought a picolcd to use with MythTV and have given up on getting 
support from mini-box.  I hoped to get some here, so I've lurked abit to 
see what's happening.  But I must be missing something, because I see 
alot of folks submitting patches, raising questions and suggesting 
fixes, but nothing seems to be done to the code.

What am I missing?  Is there some other place to look (other than here 
and the sourceforge site)?

Thanks for any help/suggestions/guidance/etc.

Joe Henley

PS:  Yes, I know I have not indicated my picolcd problems.  But they are 
  all previously listed here by others, and are still open as far as I 
can tell.


From bsdfan at nurfuerspam.de  Wed Feb 25 18:37:14 2009
From: bsdfan at nurfuerspam.de (Markus Dolze)
Date: Wed, 25 Feb 2009 19:37:14 +0100
Subject: [Lcdproc] newbie question
In-Reply-To: <49A57C26.4060808@kc.rr.com>
References: <49A57C26.4060808@kc.rr.com>
Message-ID: <49A58FDA.5060307@nurfuerspam.de>

Joe Henley wrote:
> Hi,
>
> I'm a newbie here, so please forgive any un-intended "politically 
> incorrect" items.  Also, I'm not a C programmer, so I'm pretty much 
> dependent upon what I can find at sites like this.
>
> Is lcdproc still under development?  The last version is from 2007.  I 
> see lots and lots of patches; and I see comments about folks not 
> getting things to run when patches overlap.  I see alot of notes about 
> getting patches incorporated, but it seems none do.  I've looked 
> repeatedly at the sourceforge site for updates to the code, but 
> patches I see here don't seem to show up there.
Yes, there is ongoing development. Unlike other projects we use this 
mailing list to submit patches for review. Someone with write access 
commits the patches once they have received feedback.

The changelog since 0.5.2 has grown large. Usually you receive the 
latest code directly from CVS or by using a 'nightly current build' from 
http://lcdproc.sourceforge.net/nightly/.

Currently our most important maintainer is away, so changes pile up, but 
I commited a few fixes recently.
>
> I bought a picolcd to use with MythTV and have given up on getting 
> support from mini-box.  I hoped to get some here, so I've lurked abit 
> to see what's happening.  But I must be missing something, because I 
> see alot of folks submitting patches, raising questions and suggesting 
> fixes, but nothing seems to be done to the code.
>
> What am I missing?  Is there some other place to look (other than here 
> and the sourceforge site)?
As LCDproc is open source anyone can take it and ship modified versions. 
Some Linux distributions may contain additional patches.
>
> Thanks for any help/suggestions/guidance/etc.
>
> Joe Henley
>
> PS:  Yes, I know I have not indicated my picolcd problems.  But they 
> are  all previously listed here by others, and are still open as far 
> as I can tell.
>
If you do need help, as on this list. There are people familiar with 
these devices here.

Regards,
Markus

From TELarson at west.com  Wed Feb 25 18:41:00 2009
From: TELarson at west.com (Larson, Timothy E.)
Date: Wed, 25 Feb 2009 12:41:00 -0600
Subject: [Lcdproc] newbie question
In-Reply-To: <49A58FDA.5060307@nurfuerspam.de>
References: <49A57C26.4060808@kc.rr.com> <49A58FDA.5060307@nurfuerspam.de>
Message-ID: <226316B3E1F749498E28ACA66321D5BA02BB9F30@oma00cexmbx03.corp.westworlds.com>

Markus wrote:
> The changelog since 0.5.2 has grown large. Usually you receive the
> latest code directly from CVS or by using a 'nightly current build' from
> http://lcdproc.sourceforge.net/nightly/.

Cutting a release would be useful, though.  Getting development snapshots
into NetBSD's pkgsrc is not usually done.  Having a version that is
considered release quality would help.


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

?????????????? Eschew obfuscation! 

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

From bsdfan at nurfuerspam.de  Wed Feb 25 19:01:51 2009
From: bsdfan at nurfuerspam.de (Markus Dolze)
Date: Wed, 25 Feb 2009 20:01:51 +0100
Subject: [Lcdproc] newbie question
In-Reply-To: <226316B3E1F749498E28ACA66321D5BA02BB9F30@oma00cexmbx03.corp.westworlds.com>
References: <49A57C26.4060808@kc.rr.com> <49A58FDA.5060307@nurfuerspam.de>
	<226316B3E1F749498E28ACA66321D5BA02BB9F30@oma00cexmbx03.corp.westworlds.com>
Message-ID: <49A5959F.7080608@nurfuerspam.de>

Larson, Timothy E. wrote:
> Markus wrote:
>   
>> The changelog since 0.5.2 has grown large. Usually you receive the
>> latest code directly from CVS or by using a 'nightly current build' from
>> http://lcdproc.sourceforge.net/nightly/.
>>     
>
> Cutting a release would be useful, though.  Getting development snapshots
> into NetBSD's pkgsrc is not usually done.  Having a version that is
> considered release quality would help.
>
>   
The same goes for FreeBSD. And it is the reason why I currently don't 
commit new drivers, but fixes only.

We still have problems with the MtxOrb and Crystalfontz drivers I would 
like to see resolved before making a release.

Regards
Markus

From ethan.dicks at gmail.com  Wed Feb 25 19:06:21 2009
From: ethan.dicks at gmail.com (Ethan Dicks)
Date: Wed, 25 Feb 2009 14:06:21 -0500
Subject: [Lcdproc] newbie question
In-Reply-To: <49A5959F.7080608@nurfuerspam.de>
References: <49A57C26.4060808@kc.rr.com> <49A58FDA.5060307@nurfuerspam.de>
	<226316B3E1F749498E28ACA66321D5BA02BB9F30@oma00cexmbx03.corp.westworlds.com>
	<49A5959F.7080608@nurfuerspam.de>
Message-ID: <f4eb766f0902251106i497a08a7k2567627d0d6001bf@mail.gmail.com>

On Wed, Feb 25, 2009 at 2:01 PM, Markus Dolze <bsdfan at nurfuerspam.de> wrote:
> Larson, Timothy E. wrote:
>> Markus wrote:
>>> The changelog since 0.5.2 has grown large. Usually you receive the
>>> latest code directly from CVS or by using a 'nightly current build' from
>>> http://lcdproc.sourceforge.net/nightly/.
>>
>> Cutting a release would be useful, though. ?Getting development snapshots
>> into NetBSD's pkgsrc is not usually done. ?Having a version that is
>> considered release quality would help.
>
> The same goes for FreeBSD. And it is the reason why I currently don't commit
> new drivers, but fixes only.

I'm all in favor of fixes, but I'd like to see the project get caught
up to the point of new drivers (since I just wrote one).

> We still have problems with the MtxOrb and Crystalfontz drivers I would like
> to see resolved before making a release.

Very much agreed.  The MtxOrb.c that ships with 0.5.2 is really
broken.  I've lost count of the number of folks I've helped in the
past two years.

-ethan

From bsdfan at nurfuerspam.de  Wed Feb 25 21:38:01 2009
From: bsdfan at nurfuerspam.de (Markus Dolze)
Date: Wed, 25 Feb 2009 22:38:01 +0100
Subject: [Lcdproc] [PATCH] PicoLCD off-by-one causes last char to get
 chopped off in picoLCD_string()
In-Reply-To: <498A90D4.8050805@nurfuerspam.de>
References: <75BFC17F-FBBB-4BA0-B610-D6FD12751992@siliconlandmark.com>
	<498A90D4.8050805@nurfuerspam.de>
Message-ID: <49A5BA39.6010802@nurfuerspam.de>

Markus Dolze wrote:
> Andre Guibert de Bruet wrote:
>> Hi,
>>
>> I found the cause of the bug that causes the last character to get 
>> chopped off on the PicoLCD devices. It turns out it was an off-by-one 
>> error in picoLCD_string() in the section that enforces line length on 
>> the desired output.
>>
>> Please review and commit the attached patch.
> Thank you for spotting this. Although I cannot test your patch, I 
> tested picoLCD_string() separately and created a slightly different 
> patch.
Commited this.


From bsdfan at nurfuerspam.de  Wed Feb 25 21:44:41 2009
From: bsdfan at nurfuerspam.de (Markus Dolze)
Date: Wed, 25 Feb 2009 22:44:41 +0100
Subject: [Lcdproc] PicoLCD 20x4
In-Reply-To: <6bf66f090902242355x572d6e61j68f32ea7b0c4d5ab@mail.gmail.com>
References: <49A49421.7020809@cunniffe.net>
	<49A494FC.2010209@cunniffe.net>	<6bf66f090902241824w3447f809n90988f9e88b00d0@mail.gmail.com>	<B0474C8B-D352-4341-AA23-E36FC5697F29@siliconlandmark.com>	<6bf66f090902242050y32a6adbfm43791682f93db0b5@mail.gmail.com>
	<6bf66f090902242355x572d6e61j68f32ea7b0c4d5ab@mail.gmail.com>
Message-ID: <49A5BBC9.9010006@nurfuerspam.de>

edoceo wrote:
> On Tue, Feb 24, 2009 at 8:50 PM, edoceo <null at edoceo.com> wrote:
>   
>> Andre,
>>  Yes! Thank you - found it in a message dated 2008-11-32
>>
>>  http://article.gmane.org/gmane.comp.sysutils.lcdproc/12364/match=picolcd
>>
>>  So then I rebuilt like so for debugging:
>>   ./configure --enable-debug and ran the server in -r5
>>
>>  In server/drivers/picolcd.c the function picoLCD_string() starts at line 431
>>  Like Andre's email above stated there are some 'x-- and y-- statements
>>  In the CVS from yesterday they are on line 452 and I simply moved
>> them to line 444 to fix the issue.
>>
>> Here's my work in patch form:
>>  https://carbon.edoceo.com/picolcd.patch
>>
>> Thanks all!
>>
>> /David Busby/
>> Edoceo, Inc.
>> http://edoceo.com/
>>     
>

As Andre pointed out, that patch has already been proposed. It is fixed 
in CVS now.

Markus

From vincent at cunniffe.net  Wed Feb 25 22:21:21 2009
From: vincent at cunniffe.net (Vincent Cunniffe)
Date: Wed, 25 Feb 2009 22:21:21 +0000
Subject: [Lcdproc] PicoLCD 20x4
In-Reply-To: <49A5BBC9.9010006@nurfuerspam.de>
References: <49A49421.7020809@cunniffe.net>	<49A494FC.2010209@cunniffe.net>	<6bf66f090902241824w3447f809n90988f9e88b00d0@mail.gmail.com>	<B0474C8B-D352-4341-AA23-E36FC5697F29@siliconlandmark.com>	<6bf66f090902242050y32a6adbfm43791682f93db0b5@mail.gmail.com>	<6bf66f090902242355x572d6e61j68f32ea7b0c4d5ab@mail.gmail.com>
	<49A5BBC9.9010006@nurfuerspam.de>
Message-ID: <49A5C461.6060407@cunniffe.net>

Markus Dolze wrote:
> edoceo wrote:
>> On Tue, Feb 24, 2009 at 8:50 PM, edoceo <null at edoceo.com> wrote:
>>  
>>> Andre,
>>>  Yes! Thank you - found it in a message dated 2008-11-32
>>>
>>>  http://article.gmane.org/gmane.comp.sysutils.lcdproc/12364/match=picolcd 
>>>
>>>
>>>  So then I rebuilt like so for debugging:
>>>   ./configure --enable-debug and ran the server in -r5
>>>
>>>  In server/drivers/picolcd.c the function picoLCD_string() starts at 
>>> line 431
>>>  Like Andre's email above stated there are some 'x-- and y-- statements
>>>  In the CVS from yesterday they are on line 452 and I simply moved
>>> them to line 444 to fix the issue.
>>>
>>> Here's my work in patch form:
>>>  https://carbon.edoceo.com/picolcd.patch
>>>
>>> Thanks all!
>>>
>>> /David Busby/
>>> Edoceo, Inc.
>>> http://edoceo.com/
> 
> As Andre pointed out, that patch has already been proposed. It is fixed 
> in CVS now.

I can confirm that it solved the missing 20th column in my case.

I've also got the PicoLCD working fully on CentOS 5.0, and am preparing 
a writeup with a step by step as to how to do so.

Vin

From sascha.zielinski at gmx.de  Wed Feb 25 23:04:11 2009
From: sascha.zielinski at gmx.de (Sascha)
Date: Thu, 26 Feb 2009 00:04:11 +0100
Subject: [Lcdproc] HD44780 40x4 with Backlight and winamp wiring
In-Reply-To: <49A5ADA4.1080808@nurfuerspam.de>
References: <9185341920196262063@unknownmsgid>
	<200902240426.36134.sascha.zielinski@gmx.de>
	<49A5ADA4.1080808@nurfuerspam.de>
Message-ID: <200902260004.12149.sascha.zielinski@gmx.de>

Am Mittwoch 25 Februar 2009 21:44:20 schrieben Sie:
> Would you please send me a copy of your "lcdproc.conf" file
> (configuration file for lcdproc client)? I suspect something else.

And here it is :)

-------------- next part --------------
# LCDproc client configuration file

## general options ##
[lcdproc]
# address of the LCDd server to connect to
Server=localhost

# Port of the server to connect to
Port=13666

# set reporting level
#ReportLevel=2

# report to to syslog ?
ReportToSyslog=false

# run in foreground [default: false; legal: true, false]
Foreground=false

# PidFile location when running as daemon [default: /var/run/lcdproc.pid]
#PidFile=/var/run/lcdproc.pid

# slow down initial announcement of modes (in 1/100s)
#delay=2

# display name for the main menu [default: LCDproc HOST]
#DisplayName=lcdproc


## screen specific configuration options ##

[CPU]
# Show screen
Active=True
OnTime=1
OffTime=2
ShowInvisible=true


[Iface]
# Show screen
Active=True

# Show stats for Interface0
Interface0=eth0
# Interface alias name to display [default: <interface name>]
Alias0=LAN

# Show stats for Interface1
#Interface1=eth1
#Alias1=WAN

# Show stats for Interface2
#Interface2=eth2
#Alias2=MGMT

# for more than 3 interfaces change MAX_INTERFACES in iface.h and rebuild

# Units to display [default: byte; legal: byte, bit, packet]
unit=byte

# add screen with transferred traffic
transfer=TRUE


[Memory]
# Show screen
Active=True


[Load]
# Show screen
Active=false
# Min Load Avg at which the backlight will be turned off [default: 0.05]
LowLoad=0.05
# Max Load Avg at which the backlight will start blinking [default: 1.3]
HighLoad=1.3


[TimeDate]
# Show screen
Active=True
# time format [default: %H:%M:%S; legal: see strftime(3)]
TimeFormat="%H:%M:%S"
# date format [default: %x; legal: see strftime(3)]
DateFormat="%x"


[About]
# Show screen
Active=false


[SMP-CPU]
# Show screen
Active=true


[OldTime]
# Show screen
Active=false
# time format [default: %H:%M:%S; legal: see strftime(3)]
TimeFormat="%H:%M:%S"
# date format [default: %x; legal: see strftime(3)]
DateFormat="%x"


[BigClock]
# Show screen
Active=true


[Uptime]
# Show screen
Active=false


[Battery]
# Show screen
Active=false


[CPUGraph]
# Show screen
Active=true


[ProcSize]
# Show screen
Active=true


[Disk]
# Show screen
Active=true


[MiniClock]
# Show screen
Active=False
# time format [default: %H:%M; legal: see strftime(3)]
TimeFormat="%H:%M"


# EOF

From code at edoceo.com  Thu Feb 26 00:08:58 2009
From: code at edoceo.com (edoceo)
Date: Wed, 25 Feb 2009 16:08:58 -0800
Subject: [Lcdproc] PicoLCD 20x4
In-Reply-To: <49A5C461.6060407@cunniffe.net>
References: <49A49421.7020809@cunniffe.net> <49A494FC.2010209@cunniffe.net>
	<6bf66f090902241824w3447f809n90988f9e88b00d0@mail.gmail.com>
	<B0474C8B-D352-4341-AA23-E36FC5697F29@siliconlandmark.com>
	<6bf66f090902242050y32a6adbfm43791682f93db0b5@mail.gmail.com>
	<6bf66f090902242355x572d6e61j68f32ea7b0c4d5ab@mail.gmail.com>
	<49A5BBC9.9010006@nurfuerspam.de> <49A5C461.6060407@cunniffe.net>
Message-ID: <6bf66f090902251608sf50a8edqc9f42e0cff769d34@mail.gmail.com>

>>
>> As Andre pointed out, that patch has already been proposed. It is fixed in
>> CVS now.
>
> I can confirm that it solved the missing 20th column in my case.
>

I just fetched from CSV two minutes ago, Rebuilding and testing shows
all 20 columns working as expected.
Fix confirmed for me as well.  Thank you!

Can we expect a 0.5.3 soon?  I'll gladly work with the Gentoo team to
get what ever next stable release of lcdproc into their portage tree.

Thanks again!

/djb

From bsdfan at nurfuerspam.de  Thu Feb 26 07:05:58 2009
From: bsdfan at nurfuerspam.de (Markus Dolze)
Date: Thu, 26 Feb 2009 08:05:58 +0100
Subject: [Lcdproc] MtxOrb hbars missing bottom row of pixels
In-Reply-To: <251aaf6c0812290737j48f9087cw2bc26c46b7d8138@mail.gmail.com>
References: <251aaf6c0812290737j48f9087cw2bc26c46b7d8138@mail.gmail.com>
Message-ID: <49A63F56.8060300@nurfuerspam.de>

Benjamin Roberts wrote:
> I noticed this weekend that my Matrix Orbital LK202-USB display was
> only displaying seven vertical pixels of the last hbar cell in each
> bar, missing the bottom row. The cells to the left of the last one are
> fine because they are completely filled block characters, which makes
> the problem easy to notice on any hbar which consists of at least one
> completely filled cell and a partially filled final cell.
>
> The problematic code is in MtxOrb_hbar (this is also the code in CVS
> as of today):
>
>   
>> for (i = 1; i <= p->cellwidth; i++) {
>>          // fill pixel columns from left to right.
>>          memset(hBar, 0xFF & ~((1 << (p->cellwidth - i)) - 1), sizeof(hBar)-1);
>>          MtxOrb_set_char(drvthis, i, hBar);
>> }
>>     
>
> I changed the last argument of the memset line from "sizeof(hBar)-1"
> to "sizeof(hBar)" and it solved the problem. However, due to a charset
> incompatibility I have modified my copy of lcdproc to use a custom
> icon for ICON_BLOCK_FILLED (an 8x5 of 1's, as defined by the normally
> commented out block_filled[] array in MtxOrb_icon) so it's possible my
> icon does not represent the character that's on normal LCD character
> sets. Do other people see this problem or is it just my BLOCK_FILLED
> character?
>
> Ben
>
>   
Commited to CVS.

Markus

From moridin1138 at gmail.com  Thu Feb 26 13:49:55 2009
From: moridin1138 at gmail.com (brian jackson)
Date: Thu, 26 Feb 2009 08:49:55 -0500
Subject: [Lcdproc] lcdproc on OSX presents random block characters (all
	on)
In-Reply-To: <49A472BF.2020505@nurfuerspam.de>
References: <5ba1b2c60902201607v2c70c67fyd8afa7409fa3bade@mail.gmail.com>
	<5ba1b2c60902211119j40486b4cx33b1b61c9d7119a0@mail.gmail.com>
	<20090221194217.289250@gmx.net>
	<5ba1b2c60902211656l4430d490w1b4466b35205b276@mail.gmail.com>
	<20090222064814.202310@gmx.net>
	<5ba1b2c60902220639v2abd26cfkcb271c4039384f45@mail.gmail.com>
	<20090223071123.160040@gmx.net>
	<5ba1b2c60902231233j1470215dn8f0e1b92d951d9f8@mail.gmail.com>
	<5ba1b2c60902231352m457433f6tdbe04f1ffadf797e@mail.gmail.com>
	<49A472BF.2020505@nurfuerspam.de>
Message-ID: <5ba1b2c60902260549r7e3d01b1v1905327774eef8a6@mail.gmail.com>

I can confirm that the mtxorb-backlight.diff patch was definitely
necessary in order to avoid the original symptoms.
I tried compiling with the proper make and without the patch and still
get the block characters.

-brian

On Tue, Feb 24, 2009 at 5:20 PM, Markus Dolze <bsdfan at nurfuerspam.de> wrote:
> Hello Brian,
>
> does it now work with or without the backlight patch I sent to you?
>
> Markus
>
> brian jackson wrote:
>>
>> Success!!
>>
>> It looks like the problem was actually with 'make'. ?When I compiled
>> lcdproc, despite getting no errors with the powerpc version, it was
>> screwing things up just enough that lcdproc would run but with the
>> issues described above.
>>
>> After manually downloading gnumake, compiling it, and using it to
>> compile lcdproc... everything works fine!
>>
>> Strange too, as gnumake that came with the iPhone dev kit is the only
>> one installed previously....
>>
>> Well, problem solved. ?Thanks for the help everyone!
>>
>> -brian
>
>

From malte at maltepoeggel.de  Thu Feb 26 14:15:13 2009
From: malte at maltepoeggel.de (=?iso-8859-1?Q?Malte_P=F6ggel?=)
Date: Thu, 26 Feb 2009 15:15:13 +0100
Subject: [Lcdproc] Changes to get EA-DOGM163 + four keys working
	withhd44780-lcd2usb driver
References: <BBC090545EA14A1CB4E61EF56FAA5219@subnote1400><20090221201626.289250@gmx.net><D8B559509C6B4526B97C4F675184332A@Schleppi4000><20090224193947.216800@gmx.net><640A2DDB416645A58B0EC4D12737744D@subnote1400>
	<f4eb766f0902250800x3668a120s15fa2108f6d0a50f@mail.gmail.com>
Message-ID: <2B7A08BBA8BC484FA8831E5428471578@subnote1400>

----- Original Message ----- 
From: "Ethan Dicks" <ethan.dicks at gmail.com>
To: <lcdproc at lists.omnipotent.net>
Sent: Wednesday, February 25, 2009 5:00 PM
Subject: Re: [Lcdproc] Changes to get EA-DOGM163 + four keys working 
withhd44780-lcd2usb driver


> Very interesting.  I remember these guys from their DIP series.  I
> never got one since they were in Germany (exchange rate, overseas
> shipping costs, etc.), but they looked really good.
[..]
> So the next question would be where to pick up a 3-line DOG display in
> the States.

I think there should also be a distributor for you, take a look at the 
contact page:
http://www.lcd-module.com/contact.html


> If I understand what you are doing (I can't exactly tell from the
> pictures you posted), you are using an ATMEGA-8 with Till Harbaum's
> code on that single-sided PCB, right?  I wouldn't mind a pre-fabbed
> board, but if you are making them at home, I can certainly whip
> something up myself (I do a lot with pre-perfed 0.1" protoboard and
> 30ga wire).  I've got all the gear to burn AVRs, etc.

I changed the mega8 to a mega48 because i wanted to run everything at 3.3 
Volts, and the firmware was changed, too.
The init is a little bit different to the hd44780, and the EA-DOG has a 
digital contrast setting.
You could take a look at my schematics: 
http://www.maltepoeggel.de/data/sp-lcd/schematic.pdf
I'll upload the atmel sourcecode and a more detailed description within this 
week.


> I did a little digging around and couldn't find info on the LED
> backlights.  I am, of course, curious about the RGB backlight since
> it's clearly easy to pick which backlight you want to use.  Malte, do
> you have any specific docs on the backlight modules?
http://www.lcd-module.com/eng/pdf/doma/dog-me.pdf (Page 6 and Page 8)
If you aren't shure which backlight would look nice you could also use the 
DOGM simulator found at the product page.
I don't have more information, but it looks like there are four leds into 
the backlight panel. I could also send you high resolution pictures.

Malte


From ethan.dicks at gmail.com  Thu Feb 26 18:39:30 2009
From: ethan.dicks at gmail.com (Ethan Dicks)
Date: Thu, 26 Feb 2009 13:39:30 -0500
Subject: [Lcdproc] Changes to get EA-DOGM163 + four keys working
	withhd44780-lcd2usb driver
In-Reply-To: <2B7A08BBA8BC484FA8831E5428471578@subnote1400>
References: <BBC090545EA14A1CB4E61EF56FAA5219@subnote1400>
	<20090221201626.289250@gmx.net>
	<D8B559509C6B4526B97C4F675184332A@Schleppi4000>
	<20090224193947.216800@gmx.net>
	<640A2DDB416645A58B0EC4D12737744D@subnote1400>
	<f4eb766f0902250800x3668a120s15fa2108f6d0a50f@mail.gmail.com>
	<2B7A08BBA8BC484FA8831E5428471578@subnote1400>
Message-ID: <f4eb766f0902261039p21810db9q209400d28565b40d@mail.gmail.com>

On Thu, Feb 26, 2009 at 9:15 AM, Malte P?ggel <malte at maltepoeggel.de> wrote:
> I changed the mega8 to a mega48 because i wanted to run everything at 3.3
> Volts, and the firmware was changed, too.

Ah.  So not _really_ a lcd2usb, but a descendant of it.

> The init is a little bit different to the hd44780, and the EA-DOG has a
> digital contrast setting.

OK.   Between keypad differences and the digital contrast, perhaps
it's a good idea to differentiate between your interface and the
original lcd2usb at the LCDd/LCDd.conf level?  I have one of the older
units and I'd rather it not break because a newer nearly-compatible
interface comes out.

> You could take a look at my schematics:
> http://www.maltepoeggel.de/data/sp-lcd/schematic.pdf
> I'll upload the atmel sourcecode and a more detailed description within this
> week.

Cool.  What's there looks pretty simple.

>> I did a little digging around and couldn't find info on the LED
>> backlights...
> http://www.lcd-module.com/eng/pdf/doma/dog-me.pdf (Page 6 and Page 8)

Thanks.

> If you aren't shure which backlight would look nice you could also use the
> DOGM simulator found at the product page.

I am pretty much 100% UNIX these days (Linux, Solaris, MacOS), so a
simulator for Windows is uninteresting to me.

> I don't have more information, but it looks like there are four leds into
> the backlight panel. I could also send you high resolution pictures.

Sure.  Feel free to send me a couple of pictures off-list.

Thanks,

-ethan

From bsdfan at nurfuerspam.de  Thu Feb 26 18:49:19 2009
From: bsdfan at nurfuerspam.de (Markus Dolze)
Date: Thu, 26 Feb 2009 19:49:19 +0100
Subject: [Lcdproc] Changes to get EA-DOGM163 + four keys
 working	withhd44780-lcd2usb driver
In-Reply-To: <f4eb766f0902261039p21810db9q209400d28565b40d@mail.gmail.com>
References: <BBC090545EA14A1CB4E61EF56FAA5219@subnote1400>	<20090221201626.289250@gmx.net>	<D8B559509C6B4526B97C4F675184332A@Schleppi4000>	<20090224193947.216800@gmx.net>	<640A2DDB416645A58B0EC4D12737744D@subnote1400>	<f4eb766f0902250800x3668a120s15fa2108f6d0a50f@mail.gmail.com>	<2B7A08BBA8BC484FA8831E5428471578@subnote1400>
	<f4eb766f0902261039p21810db9q209400d28565b40d@mail.gmail.com>
Message-ID: <49A6E42F.4070805@nurfuerspam.de>

Ethan Dicks wrote:
> On Thu, Feb 26, 2009 at 9:15 AM, Malte P?ggel <malte at maltepoeggel.de> wrote:
>   
>> I changed the mega8 to a mega48 because i wanted to run everything at 3.3
>> Volts, and the firmware was changed, too.
>>     
>
> Ah.  So not _really_ a lcd2usb, but a descendant of it.
>   

Mr. Harbaum recently anounced "Complete and assembled LCD2USB compatible 
devices are available from http://www.lcdmodkit.com 
<http://www.lcdmodkit.com/lcd.html>." See his page for more info.

>   
>> The init is a little bit different to the hd44780, and the EA-DOG has a
>> digital contrast setting.
>>     
>
> OK.   Between keypad differences and the digital contrast, perhaps
> it's a good idea to differentiate between your interface and the
> original lcd2usb at the LCDd/LCDd.conf level?  I have one of the older
> units and I'd rather it not break because a newer nearly-compatible
> interface comes out.
>
>   

I just want to mention that the original lcd2usb has software adjustable 
contrast as well. I have no problem with the difference as long as the 
protocol implemented in hd44780-lcd2usb does not need to be changed and 
the firmware can cope with the hd44780 initialization sequence sent to it.

Regards
Markus


From ethan.dicks at gmail.com  Thu Feb 26 19:13:07 2009
From: ethan.dicks at gmail.com (Ethan Dicks)
Date: Thu, 26 Feb 2009 14:13:07 -0500
Subject: [Lcdproc] Changes to get EA-DOGM163 + four keys working
	withhd44780-lcd2usb driver
In-Reply-To: <49A6E42F.4070805@nurfuerspam.de>
References: <BBC090545EA14A1CB4E61EF56FAA5219@subnote1400>
	<20090221201626.289250@gmx.net>
	<D8B559509C6B4526B97C4F675184332A@Schleppi4000>
	<20090224193947.216800@gmx.net>
	<640A2DDB416645A58B0EC4D12737744D@subnote1400>
	<f4eb766f0902250800x3668a120s15fa2108f6d0a50f@mail.gmail.com>
	<2B7A08BBA8BC484FA8831E5428471578@subnote1400>
	<f4eb766f0902261039p21810db9q209400d28565b40d@mail.gmail.com>
	<49A6E42F.4070805@nurfuerspam.de>
Message-ID: <f4eb766f0902261113k3e7cb874s4b9a4929d2bff206@mail.gmail.com>

On Thu, Feb 26, 2009 at 1:49 PM, Markus Dolze <bsdfan at nurfuerspam.de> wrote:
> Mr. Harbaum....

Dr. Harbaum, I believe.

> ... recently anounced "Complete and assembled LCD2USB compatible
> devices are available from http://www.lcdmodkit.com
> <http://www.lcdmodkit.com/lcd.html>." See his page for more info.

Very nice.  Quite affordable (though I just got a bare module since I
already had a pair of 40x4s and didn't mind soldering up my own
stuff).

> I just want to mention that the original lcd2usb has software adjustable
> contrast as well. I have no problem with the difference as long as the
> protocol implemented in hd44780-lcd2usb does not need to be changed and the
> firmware can cope with the hd44780 initialization sequence sent to it.

Now that you mention it, yes.  I do recall software adjustable contrast.

My concern is just not breaking the original board with the DIP
designs because of a change to the firmware from what Till Harbaum
released.

-ethan

From joehenley at kc.rr.com  Thu Feb 26 20:02:16 2009
From: joehenley at kc.rr.com (Joe Henley)
Date: Thu, 26 Feb 2009 14:02:16 -0600
Subject: [Lcdproc] newbie question
In-Reply-To: <49A58FDA.5060307@nurfuerspam.de>
References: <49A57C26.4060808@kc.rr.com> <49A58FDA.5060307@nurfuerspam.de>
Message-ID: <49A6F548.7090902@kc.rr.com>

Hi Markus,

Thanks very much for your reply.

Markus Dolze wrote:
> Joe Henley wrote:
>> Hi,
>>
>> I'm a newbie here, so please forgive any un-intended "politically 
>> incorrect" items.  Also, I'm not a C programmer, so I'm pretty much 
>> dependent upon what I can find at sites like this.
>>
>> Is lcdproc still under development?  The last version is from 2007.  I 
>> see lots and lots of patches; and I see comments about folks not 
>> getting things to run when patches overlap.  I see alot of notes about 
>> getting patches incorporated, but it seems none do.  I've looked 
>> repeatedly at the sourceforge site for updates to the code, but 
>> patches I see here don't seem to show up there.
> Yes, there is ongoing development. Unlike other projects we use this 
> mailing list to submit patches for review. Someone with write access 
> commits the patches once they have received feedback.

Ah, OK.  As I confessed earlier, I'm a newbie .... does "commit" mean to 
incorporate it into the nightly updates?

> The changelog since 0.5.2 has grown large. Usually you receive the 
> latest code directly from CVS or by using a 'nightly current build' from 
> http://lcdproc.sourceforge.net/nightly/.

Is that OK now?  I saw a message in the archives that the nightlies 
weren't always current.  Since I don't yet know enough about this to be 
able to tell when it is, or when it isn't current, I just decided to 
avoid them.  Probably the wrong thing to do, huh? ....

> Currently our most important maintainer is away, so changes pile up, but 
> I commited a few fixes recently.
>>
>> I bought a picolcd to use with MythTV and have given up on getting 
>> support from mini-box.  I hoped to get some here, so I've lurked abit 
>> to see what's happening.  But I must be missing something, because I 
>> see alot of folks submitting patches, raising questions and suggesting 
>> fixes, but nothing seems to be done to the code.
>>
>> What am I missing?  Is there some other place to look (other than here 
>> and the sourceforge site)?
> As LCDproc is open source anyone can take it and ship modified versions. 
> Some Linux distributions may contain additional patches.

Yes, that's part of the problem I'm having with mini-box.  They have a 
version on their site which they reference as 0.5.2, but which is NOT 
the same as what you have here.  It's abit confusing, and very 
frustrating, for someone just getting started (like me).

>> Thanks for any help/suggestions/guidance/etc.
>>
>> Joe Henley
>>
>> PS:  Yes, I know I have not indicated my picolcd problems.  But they 
>> are  all previously listed here by others, and are still open as far 
>> as I can tell.
>>
> If you do need help, as on this list. There are people familiar with 
> these devices here.

Thanks for the offer.  I looked back thru the last 4 or 5 months of 
posts in the archives and picked out the problems/patches others had 
identified which also looked like ones I'm having.  These include:
10/1/08  pavel      "add support"
11/2/08  marschall  "picolcd build problems"
11/6/08  ekholm     "LCDproc & PicoLCD"
1/13/09  dicks      "19 to 20 character"
2/2/09   de Bruet   "off by one"
2/25/09  de Bruet   various

Again, it's a newbie picking these out, so I might be wrong on some.

So if these were fixed (I assume that means "committed") then I should 
be able to move forward on getting my picolcd 4x20 to work.

> Regards,
> Markus

Oh, while I may be a newbie, I can probably help by doing any testing 
you'd like.  I'd be happy to do that.  As indicated before, I have a 
picolcd 4x20 from mini-box.  Right now it's connected to a miniMyth 
front end running version 0.21.0-53 (kernel is 2.6.25).

Thanks again for all your help.  It is very much appreciated.

Joe Henley

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

>> If you aren't shure which backlight would look nice you could also use 
>> the
>> DOGM simulator found at the product page.
>
>I am pretty much 100% UNIX these days (Linux, Solaris, MacOS), so a
>simulator for Windows is uninteresting to me.

Runs fine at fedora core 10, gnome with the wine emulator :-P


> My concern is just not breaking the original board with the DIP
> designs because of a change to the firmware from what Till Harbaum
> released.

The ports for the keys are also changed. Driver is completely compatible if 
you use the 2x16 DOG.
3x16 -> enable extended mode and set lineaddress = 0x10.


I got my blue/white ea-dog yesterday :o)

Added everything to my website, i'll also translate it to english later. 
Sourcecode and layouts could be downloaded on the second page there.
http://www.maltepoeggel.de/index.php?site=sp-lcd


Also had a look at the charactersets; nothing available that fits the used 
controller. So we have to create a new one...

Malte





From sascha.zielinski at gmx.de  Fri Feb 27 17:23:12 2009
From: sascha.zielinski at gmx.de (Sascha)
Date: Fri, 27 Feb 2009 18:23:12 +0100
Subject: [Lcdproc] HD44780 40x4 with Backlight and winamp wiring
In-Reply-To: <49A7946C.7040609@nurfuerspam.de>
References: <9185341920196262063@unknownmsgid>
	<200902270212.48056.sascha.zielinski@gmx.de>
	<49A7946C.7040609@nurfuerspam.de>
Message-ID: <200902271823.13624.sascha.zielinski@gmx.de>

Am Freitag 27 Februar 2009 08:21:16 schrieben Sie:
> Sascha wrote:
> > Connect from host 127.0.0.1:36381 on socket 5
> > screenlist_switch: switched to screen [_server_screen]
> > sock_read_from_client: received 8020 bytes
> > error: huh? Too much data received... quiet down
> >
> > Regards Sascha
>
> OK, the server's receive buffer is too small to hold all the data sent
> by the client. But I am wondering why your clients sends 8K whereas my
> client send only about 6K with the same config file.
>
> The attached patch increases the receive buffer. Please patch and try
> again with reportlevel 5.
>
> I am interested in the commands the client actually send to compare them
> to the one my client sends.
>
> Markus

If attached the log with your patch.

Regards Sascha
-------------- next part --------------
A non-text attachment was scrubbed...
Name: LCDd-r5-increased_sock.log.bz2
Type: application/x-bzip
Size: 6674 bytes
Desc: not available
URL: <http://lists.omnipotent.net/pipermail/lcdproc/attachments/20090227/6ece0d3c/attachment-0001.bin>

From bsdfan at nurfuerspam.de  Fri Feb 27 19:41:04 2009
From: bsdfan at nurfuerspam.de (Markus Dolze)
Date: Fri, 27 Feb 2009 20:41:04 +0100
Subject: [Lcdproc] HD44780 40x4 with Backlight and winamp wiring
In-Reply-To: <200902271823.13624.sascha.zielinski@gmx.de>
References: <9185341920196262063@unknownmsgid>	<200902270212.48056.sascha.zielinski@gmx.de>	<49A7946C.7040609@nurfuerspam.de>
	<200902271823.13624.sascha.zielinski@gmx.de>
Message-ID: <49A841D0.3040803@nurfuerspam.de>

Sascha wrote:
> Am Freitag 27 Februar 2009 08:21:16 schrieben Sie:
>   
>> Sascha wrote:
>>     
>>> Connect from host 127.0.0.1:36381 on socket 5
>>> screenlist_switch: switched to screen [_server_screen]
>>> sock_read_from_client: received 8020 bytes
>>> error: huh? Too much data received... quiet down
>>>
>>> Regards Sascha
>>>       
>> OK, the server's receive buffer is too small to hold all the data sent
>> by the client. But I am wondering why your clients sends 8K whereas my
>> client send only about 6K with the same config file.
>>
>> The attached patch increases the receive buffer. Please patch and try
>> again with reportlevel 5.
>>
>> I am interested in the commands the client actually send to compare them
>> to the one my client sends.
>>
>> Markus
>>     
>
> If attached the log with your patch.
>
> Regards Sascha
>   

OK, I think I now know what is going wrong.

The first thing is that the lcdproc client _adds_ screens you specify on 
the command line to those activated in the config file. This is not a bug.

The second thing is that the CPUGraph screen is enabled in the config file.

Thus, if you start "lcdproc L" it uses both screen (cpugraph and load) 
which use vertical bars. On a 40x4 display this creates an initial 
message from lcdproc to LCDd which is large enough to trigger LCDd 
closing the connection. Therefore it seems the 'L' screen is causing the 
problem, but actually its not the screen itself, but all together.

Solutions:
1. Keep my patch. I will discuss this on the mailing list seperately.
2. Disable the CPUGraph screen if you don't need it.


BTW: Your 4 core CPU looks cool. However, if you notice the behaviour 
reported here: 
https://sourceforge.net/tracker2/?func=detail&aid=2580087&group_id=119&atid=100119 
please report.


Regards,
Markus


From bsdfan at nurfuerspam.de  Sat Feb 28 08:17:51 2009
From: bsdfan at nurfuerspam.de (Markus Dolze)
Date: Sat, 28 Feb 2009 09:17:51 +0100
Subject: [Lcdproc] Increasing the server's receive buffer
Message-ID: <49A8F32F.10800@nurfuerspam.de>

Hi,

if LCDd is used with large displays (40x4) it may happen that the 
server's receive buffer is too small and the client gets disconnected. 
The disconnect is triggered if the client sends 7K. This is likely to 
occur during initial creation of screens by the client if the client 
sets up several screens.

Our lcdproc client is sometimes struck by this if you use a 40x4 display 
and the 'L' screen in addition to the default lcdproc.conf. I wrote 
"sometimes" because it depends on how fast LCDd reads out the buffer. I 
was not able to reproduce this with the curses driver (server reads 
about 4K), but it happened everytime I use the hd44780-lcd2usb (server 
reads about 8K).

Updates of a single screen are < 1K most times.

I suggest on of these options:
1. Increase the server's receive buffer to 16K
2. Slow down the client's initial screen setup.

Any objections against 1?

Regards
Markus

From aeriksson2 at fastmail.fm  Sat Feb 28 09:10:28 2009
From: aeriksson2 at fastmail.fm (aeriksson2 at fastmail.fm)
Date: Sat, 28 Feb 2009 10:10:28 +0100
Subject: [Lcdproc] Increasing the server's receive buffer
In-Reply-To: <49A8F32F.10800@nurfuerspam.de>
References: <49A8F32F.10800@nurfuerspam.de>
Message-ID: <20090228091028.C44792C407A@tippex.mynet.homeunix.org>


bsdfan at nurfuerspam.de said:
> if LCDd is used with large displays (40x4) it may happen that the  server's
> receive buffer is too small and the client gets disconnected.  The disconnect
> is triggered if the client sends 7K. This is likely to  occur during initial
> creation of screens by the client if the client  sets up several screens.

This sounds like a client error to me. You can't just write to the socket and 
expect all bytes to be sucessfully written. Queueing _will_ happen. Have you 
tried over a 2400 bps modem link?

> Our lcdproc client is sometimes struck by this if you use a 40x4 display  and
> the 'L' screen in addition to the default lcdproc.conf. I wrote  "sometimes"
> because it depends on how fast LCDd reads out the buffer. I  was not able to
> reproduce this with the curses driver (server reads  about 4K), but it
> happened everytime I use the hd44780-lcd2usb (server  reads about 8K).

> Updates of a single screen are < 1K most times.

> I suggest on of these options: 1. Increase the server's receive buffer to 16K
> 2. Slow down the client's initial screen setup.

> Any objections against 1? 

Yes. It would waste memory on a potentially memory-short device. 
Fix the client instead.

/Anders


From sascha.zielinski at gmx.de  Sat Feb 28 18:14:21 2009
From: sascha.zielinski at gmx.de (Sascha)
Date: Sat, 28 Feb 2009 19:14:21 +0100
Subject: [Lcdproc] HD44780 40x4 with Backlight and winamp wiring
Message-ID: <200902281914.21583.sascha.zielinski@gmx.de>

Am Freitag 27 Februar 2009 20:41:04 schrieben Sie:

> OK, I think I now know what is going wrong.
>
> The first thing is that the lcdproc client _adds_ screens you specify on
> the command line to those activated in the config file. This is not a bug.
>
> The second thing is that the CPUGraph screen is enabled in the config file.
>
> Thus, if you start "lcdproc L" it uses both screen (cpugraph and load)
> which use vertical bars. On a 40x4 display this creates an initial
> message from lcdproc to LCDd which is large enough to trigger LCDd
> closing the connection. Therefore it seems the 'L' screen is causing the
> problem, but actually its not the screen itself, but all together.
>
> Solutions:
> 1. Keep my patch. I will discuss this on the mailing list seperately.
> 2. Disable the CPUGraph screen if you don't need it.
>
>
> BTW: Your 4 core CPU looks cool. However, if you notice the behaviour
> reported here:
> https://sourceforge.net/tracker2/?func=detail&aid=2580087&group_id=119&atid
>=100119 please report.
>
>
> Regards,
> Markus

Hi
I loaded 4 instances of burnMMX and watched the SMP CPU Screen but I didn't 
noticed any strange things. While switching between the screens I noticed 
something strange in the CPU Graph screen. I uploaded 2 videos which show my 
two screens.
http://uploading.com/files/USJU7LBP/CPU-Graph_vs_SMP-CPU.rar.html


Is there a feature wish list where I can write down some things?
lcdproc looks good, but it is not optimized for 4x40 lcd's, I think.
It would be nice if the CPU MHz for each core is shown in the SMP-CPU Graph.


Regards,
Sascha





From leon at tim-online.nl  Sat Feb 28 22:48:04 2009
From: leon at tim-online.nl (Leon Bogaert)
Date: Sat, 28 Feb 2009 23:48:04 +0100
Subject: [Lcdproc] imonlcd / icons question
Message-ID: <0A02838AFAB4AA41A421A9D09800FE66B2DD4C5F5B@server-tim.tim-online.nl>

Hi all,

I'm trying to write a simple script to control the icons of my imon lcd screen.
Browsing throught the code of that driver I saw that every icon has it's own code.

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

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

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

Could anybody help me with this?

Thanks in advance!

Leon

From andy at siliconlandmark.com  Sat Feb 28 23:56:22 2009
From: andy at siliconlandmark.com (Andre Guibert de Bruet)
Date: Sat, 28 Feb 2009 18:56:22 -0500
Subject: [Lcdproc] Increasing the server's receive buffer
In-Reply-To: <20090228091028.C44792C407A@tippex.mynet.homeunix.org>
References: <49A8F32F.10800@nurfuerspam.de>
	<20090228091028.C44792C407A@tippex.mynet.homeunix.org>
Message-ID: <0CCDE7FF-6F93-4F7D-A568-505EDF06DF7B@siliconlandmark.com>

On Feb 28, 2009, at 4:10 AM, aeriksson2 at fastmail.fm wrote:

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

There appears to be a client bug, an aggressively low receive buffer  
size and an LCDd bug involved here. From the way that I read  
sock_read_from_client(), Markus' client should be getting the "Too  
much data received... quiet down!" message. The magical 7KB value  
comes from sock.c line 414:

else if (nbytes > (MAXMSG - (MAXMSG / 8))) {	/* Very noisy client... */
       something > (8192 - (8192 / 8)) /* which becomes: something >  
7168 */

It is important to note that our call to recv() is made with MAXMSG,  
so the buffer may legitimately be filled with 7169 through 8192 bytes  
worth of data. In my opinion, the entire else if() check on line 414  
is bogus and should be removed, and its "quiet down!" message along  
with it.

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

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

As more data gets communicated between the clients and server, this  
may become desirable.

>> 2. Slow down the client's initial screen setup.

This band-aid does nothing to address the root of the problem.

>> Any objections against 1?
>
> Yes. It would waste memory on a potentially memory-short device.

I really question whether anyone has lcdproc rolled out on a machine  
where an 8KB of RAM increase is a "make-it-or-break-it" proposition.

> Fix the client instead.

The apparent disconnecting because of unknown input is something that  
needs to be fixed, indeed.

Cheers,
Andy

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