From bsdfan at nurfuerspam.de  Sat Nov  1 01:00:48 2008
From: bsdfan at nurfuerspam.de (Markus Dolze)
Date: Sat, 01 Nov 2008 08:00:48 +0100
Subject: [Lcdproc] [PATCH] Remove devfs from list of reported
 filesystems on	FreeBSD
In-Reply-To: <CD39870E-ABE9-4145-90E3-F46A883BFAE8@siliconlandmark.com>
References: <CD39870E-ABE9-4145-90E3-F46A883BFAE8@siliconlandmark.com>
Message-ID: <490BFEA0.3090004@nurfuerspam.de>

Hello,

you patch makes sound and compiles fine. Committed to CVS.

Regards,
Markus

Andre Guibert de Bruet wrote:
> Hello,
>
> I have attached a patch which removes the listing of devfs-type 
> filesystems from machine_get_fs() calls on FreeBSD. Devfs is a special 
> filesystem that is reported as 1k in size, used at 100% and is 
> presently cluttering the disk display.
>
> Could this get committed upon review? :)
>
> 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 */
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> LCDproc mailing list
> LCDproc at lists.omnipotent.net
> http://lists.omnipotent.net/mailman/listinfo/lcdproc
>   

From bsdfan at nurfuerspam.de  Sat Nov  1 01:13:33 2008
From: bsdfan at nurfuerspam.de (Markus Dolze)
Date: Sat, 01 Nov 2008 08:13:33 +0100
Subject: [Lcdproc] Smoke tests upload changed
Message-ID: <490C019D.3040003@nurfuerspam.de>

Hi,

those of you who run the smoke test compile script will need to update 
the part which uploads the results to Sourceforge.

Over a month ago, they changed the way to login via ssh to the web 
server (interactive login is no longer possible).

To upload the smoke test results now use :

scp -C ${COMPILEREPORT}* <your sf 
name>,lcdproc at web.sourceforge.net:htdocs/smoketests/st-compile-report/

Regards,
Markus

From twentysixdb at yahoo.com  Mon Nov  3 19:54:07 2008
From: twentysixdb at yahoo.com (Craig Fisher)
Date: Mon, 3 Nov 2008 17:54:07 -0800 (PST)
Subject: [Lcdproc] HD44780 backlight control
Message-ID: <687048.44176.qm@web65705.mail.ac4.yahoo.com>

Hi All!

I am new to Linux and LCDProc. I have a HD44780 LCD up and running in the "4-bit" config. The problem I have concerns how to control the backlight. I have not found any refs in the docs or list archives.

I have tested my circuit using telnet as described in the developer docs and the control appears to be implemented as negative logic, i.e.

screen_set #id -backlight on



clears LPT pin 7.



screen_set #id -backlight off



sets LPT pin 7.



My backlight works in this setting; however, where is the software control? Server? Driver?
Thanks,
Craig





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

From loosen at xs4all.nl  Tue Nov  4 10:20:16 2008
From: loosen at xs4all.nl (Bob van Loosen)
Date: Tue, 04 Nov 2008 17:20:16 +0100
Subject: [Lcdproc] fcntl for lcd serializer
Message-ID: <49107640.50206@xs4all.nl>

Hi,

I've got an hd44780 connected to a PIC18F4550 which is connected to usb, 
it emulates a cdc device, which is sort of like a serial port, it uses 
the lcd serializer protocol.
I got it to work with my own software, but not with a standard lcdproc.

I noticed two problems:

Lcdproc initializes the display to 8 bit mode by default, I'm using 4 
bit mode but since the standard lcd serializer initializes the display 
anyway lcdproc shouldn't have to do any initialization.

Lcdproc doesn't set the serial port to blocking mode, for some reason 
the cdc device defaults to non-blocking mode and because it's not very 
fast and doesn't have a very large buffer it didn't work.
Adding fcntl(p->fd, F_SETFL, 0); in hd_init_serial sets the port to 
blocking mode.

Lcdproc is a great piece of software, keep up the good work.

Regards,

Bob van Loosen.



From twentysixdb at yahoo.com  Tue Nov  4 17:23:36 2008
From: twentysixdb at yahoo.com (Craig Fisher)
Date: Tue, 4 Nov 2008 15:23:36 -0800 (PST)
Subject: [Lcdproc] HD44870 backlight control
Message-ID: <725246.77111.qm@web65712.mail.ac4.yahoo.com>

Ok, got my hardware working correctly now. Incorrectly substituted an NPN
for the backlight circuit. :)

I am still unsure how to control the backlight state. Server? Client?
Thanks for your help with what is most likely another simple oversight.
Craig




      

From trivex at gmail.com  Wed Nov  5 17:17:25 2008
From: trivex at gmail.com (Larry Gadea)
Date: Wed, 5 Nov 2008 18:17:25 -0500
Subject: [Lcdproc] LCDProc + PicoLCD
Message-ID: <5bab428f0811051517q5f3a2a08w48b9bd64680d0e39@mail.gmail.com>

Hello.
I have a 20x4 PicoLCD. I've been trying to get it to work on ubuntu 32 bit
and am not having much luck.

I have built it using --enable-drivers=picolcd. I noticed that i needed
libusb so downloaded that from sourceforge and built it using: "./configure
&& make && make install". I then reran the lcdproc ./configure with
--enable-drivers=picolcd and the picolcd.so built properly.

When I try to run "./LCDd", i get the following:

----
LCDd version CVS-current-20080924 starting
Using Configuration File: /usr/local/etc/LCDd.conf
Listening for queries on 127.0.0.1:13666
picolcd: no device found
Driver [picolcd] init failed, return code < 0
Could not load driver picolcd
There is no output driver
Critical error while initializing, abort.
----

I'm sure the device is plugged into the USB port. Do i need to do anything
else when installing libusb? I'm not entirely sure what's wrong.

Thank you!

-- Larry.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omnipotent.net/pipermail/lcdproc/attachments/20081105/08975a3a/attachment.htm>

From npavel at ituner.com  Wed Nov  5 18:18:15 2008
From: npavel at ituner.com (Nicu Pavel)
Date: Thu, 06 Nov 2008 02:18:15 +0200
Subject: [Lcdproc] {Disarmed}  LCDProc + PicoLCD
In-Reply-To: <5bab428f0811051517q5f3a2a08w48b9bd64680d0e39@mail.gmail.com>
References: <5bab428f0811051517q5f3a2a08w48b9bd64680d0e39@mail.gmail.com>
Message-ID: <491237C7.3040603@ituner.com>

Hi Larry,

The version that you have doesn't have the picoLCD20x4 driver. You will 
need to get the code from the CVS since picolcd 20x4 driver has been
added on 2008-10 and the latest nightly tarball is from 2008-09.

Nicu Pavel.
> Hello.
>
> I have a 20x4 PicoLCD. I've been trying to get it to work on ubuntu 32 
> bit and am not having much luck.
>
> I have built it using --enable-drivers=picolcd. I noticed that i 
> needed libusb so downloaded that from sourceforge and built it using: 
> "./configure && make && make install". I then reran the lcdproc 
> ./configure with --enable-drivers=picolcd and the picolcd.so built 
> properly.
>
> When I try to run "./LCDd", i get the following:
>
> ----
> LCDd version CVS-current-20080924 starting
> Using Configuration File: /usr/local/etc/LCDd.conf
> Listening for queries on *MailScanner warning: numerical links are 
> often malicious:* 127.0.0.1:13666 <http://127.0.0.1:13666>
> picolcd: no device found
> Driver [picolcd] init failed, return code < 0
> Could not load driver picolcd
> There is no output driver
> Critical error while initializing, abort.
> ----
>
> I'm sure the device is plugged into the USB port. Do i need to do 
> anything else when installing libusb? I'm not entirely sure what's wrong.
>
> Thank you!
>
> -- Larry.
> -- 
> This message has been scanned for viruses and
> dangerous content by *MailScanner* <http://www.mailscanner.info/>, and is
> believed to be clean.
> ------------------------------------------------------------------------
>
> _______________________________________________
> LCDproc mailing list
> LCDproc at lists.omnipotent.net
> http://lists.omnipotent.net/mailman/listinfo/lcdproc
>   


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.


From speedy_2k2 at hotmail.com  Thu Nov  6 07:10:34 2008
From: speedy_2k2 at hotmail.com (Speedy2k)
Date: Thu, 6 Nov 2008 08:10:34 -0500
Subject: [Lcdproc] LCDd on screen Display
Message-ID: <BAY106-DS23D8551D8F27336D20193E51E0@phx.gbl>

Hi everybody, is it possible to start LCDd on a machine without any LCD device and just print the content on the host screen, because i'm building right now a production box, and i will need to program from out of my lab and the computer i have don'T have any LCD and i would like to be able to see my change in me laptop screen.

Thanx a lot!

Martin.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omnipotent.net/pipermail/lcdproc/attachments/20081106/3dc41be2/attachment.htm>

From tfangio at fractech.net  Thu Nov  6 08:30:36 2008
From: tfangio at fractech.net (Topher Fangio)
Date: Thu, 6 Nov 2008 08:30:36 -0600
Subject: [Lcdproc] LCDd on screen Display
In-Reply-To: <BAY106-DS23D8551D8F27336D20193E51E0@phx.gbl>
References: <BAY106-DS23D8551D8F27336D20193E51E0@phx.gbl>
Message-ID: <42B18A8261FAE0428A17F9A6A539339E11879C8CD2@EXCHCLST01.FRACTECH.LOCAL>

Martin:

I have done this a few times and know that it is possible. I am not sure what operating system you use but I know that at one point
I successfully used LCDEmu from http://www.esden.net/lcdemu to do what you are needing. I do believe I had some difficulty using
this under OS X, but I found something similar. Basically, just search for "LCD Emulation" on Google if you are having trouble and I am
sure you will find what you are looking for.

I think there is a special setting in the LCDd.conf file that tells it to use a driver that is compatible with the on-screen display, but perhaps
someone else with a little more experience can guide you in the right direction in this area.

Topher Fangio

From: lcdproc-bounces at lists.omnipotent.net [mailto:lcdproc-bounces at lists.omnipotent.net] On Behalf Of Speedy2k
Sent: Thursday, November 06, 2008 7:11 AM
To: lcdproc at lists.omnipotent.net
Subject: [Lcdproc] LCDd on screen Display

Hi everybody, is it possible to start LCDd on a machine without any LCD device and just print the content on the host screen, because i'm building right now a production box, and i will need to program from out of my lab and the computer i have don'T have any LCD and i would like to be able to see my change in me laptop screen.

Thanx a lot!

Martin.

No virus found in this incoming message.
Checked by AVG - http://www.avg.com
Version: 8.0.175 / Virus Database: 270.8.6/1766 - Release Date: 11/5/2008 7:17 AM

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

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

If you have received this email message in error, please immediately notify the sender by return email and permanently delete from your system, the original and any copies of this email and any attachments hereto and any printout hereof. Unauthorized interception of this email is a violation of federal criminal law.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omnipotent.net/pipermail/lcdproc/attachments/20081106/980ab1e9/attachment-0001.htm>

From jan.ekholm at smultron.net  Thu Nov  6 09:34:41 2008
From: jan.ekholm at smultron.net (Jan Ekholm)
Date: Thu, 6 Nov 2008 17:34:41 +0200
Subject: [Lcdproc] {Disarmed}  LCDProc + PicoLCD
In-Reply-To: <491237C7.3040603@ituner.com>
References: <5bab428f0811051517q5f3a2a08w48b9bd64680d0e39@mail.gmail.com>
	<491237C7.3040603@ituner.com>
Message-ID: <200811061734.41818.jan.ekholm@smultron.net>


I got the source package from:

	http://www.mini-box.com/PicoLCD-4X20-Sideshow

which is a packaged CVS version. Worked ok for me.

On Thursday 06 November 2008 02:18:15 Nicu Pavel wrote:
> Hi Larry,
>
> The version that you have doesn't have the picoLCD20x4 driver. You will
> need to get the code from the CVS since picolcd 20x4 driver has been
> added on 2008-10 and the latest nightly tarball is from 2008-09.
>
> Nicu Pavel.
>
> > Hello.
> >
> > I have a 20x4 PicoLCD. I've been trying to get it to work on ubuntu 32
> > bit and am not having much luck.
> >
> > I have built it using --enable-drivers=picolcd. I noticed that i
> > needed libusb so downloaded that from sourceforge and built it using:
> > "./configure && make && make install". I then reran the lcdproc
> > ./configure with --enable-drivers=picolcd and the picolcd.so built
> > properly.
> >
> > When I try to run "./LCDd", i get the following:
> >
> > ----
> > LCDd version CVS-current-20080924 starting
> > Using Configuration File: /usr/local/etc/LCDd.conf
> > Listening for queries on *MailScanner warning: numerical links are
> > often malicious:* 127.0.0.1:13666 <http://127.0.0.1:13666>
> > picolcd: no device found
> > Driver [picolcd] init failed, return code < 0
> > Could not load driver picolcd
> > There is no output driver
> > Critical error while initializing, abort.
> > ----
> >
> > I'm sure the device is plugged into the USB port. Do i need to do
> > anything else when installing libusb? I'm not entirely sure what's wrong.
> >
> > Thank you!
> >
> > -- Larry.
> > --
> > This message has been scanned for viruses and
> > dangerous content by *MailScanner* <http://www.mailscanner.info/>, and is
> > believed to be clean.
> > ------------------------------------------------------------------------
> >
> > _______________________________________________
> > LCDproc mailing list
> > LCDproc at lists.omnipotent.net
> > http://lists.omnipotent.net/mailman/listinfo/lcdproc

-- 

              Many an ancient lord's last words had been:
         "You can't kill me because I've got magic aaargh...."
                                      -- Terry Pratchett, Interesting Times


From trivex at gmail.com  Thu Nov  6 14:35:45 2008
From: trivex at gmail.com (Larry Gadea)
Date: Thu, 6 Nov 2008 15:35:45 -0500
Subject: [Lcdproc] {Disarmed} LCDProc + PicoLCD
In-Reply-To: <200811061734.41818.jan.ekholm@smultron.net>
References: <5bab428f0811051517q5f3a2a08w48b9bd64680d0e39@mail.gmail.com>
	<491237C7.3040603@ituner.com>
	<200811061734.41818.jan.ekholm@smultron.net>
Message-ID: <5bab428f0811061235k3297782fy130e0412fdd193a9@mail.gmail.com>

Thanks everyone, this did it!
Please consider making an official release with this built in. :)

-- Larry.

On Thu, Nov 6, 2008 at 10:34 AM, Jan Ekholm <jan.ekholm at smultron.net> wrote:

>
> I got the source package from:
>
>        http://www.mini-box.com/PicoLCD-4X20-Sideshow
>
> which is a packaged CVS version. Worked ok for me.
>
> On Thursday 06 November 2008 02:18:15 Nicu Pavel wrote:
> > Hi Larry,
> >
> > The version that you have doesn't have the picoLCD20x4 driver. You will
> > need to get the code from the CVS since picolcd 20x4 driver has been
> > added on 2008-10 and the latest nightly tarball is from 2008-09.
> >
> > Nicu Pavel.
> >
> > > Hello.
> > >
> > > I have a 20x4 PicoLCD. I've been trying to get it to work on ubuntu 32
> > > bit and am not having much luck.
> > >
> > > I have built it using --enable-drivers=picolcd. I noticed that i
> > > needed libusb so downloaded that from sourceforge and built it using:
> > > "./configure && make && make install". I then reran the lcdproc
> > > ./configure with --enable-drivers=picolcd and the picolcd.so built
> > > properly.
> > >
> > > When I try to run "./LCDd", i get the following:
> > >
> > > ----
> > > LCDd version CVS-current-20080924 starting
> > > Using Configuration File: /usr/local/etc/LCDd.conf
> > > Listening for queries on *MailScanner warning: numerical links are
> > > often malicious:* 127.0.0.1:13666 <http://127.0.0.1:13666>
> > > picolcd: no device found
> > > Driver [picolcd] init failed, return code < 0
> > > Could not load driver picolcd
> > > There is no output driver
> > > Critical error while initializing, abort.
> > > ----
> > >
> > > I'm sure the device is plugged into the USB port. Do i need to do
> > > anything else when installing libusb? I'm not entirely sure what's
> wrong.
> > >
> > > Thank you!
> > >
> > > -- Larry.
> > > --
> > > This message has been scanned for viruses and
> > > dangerous content by *MailScanner* <http://www.mailscanner.info/>, and
> is
> > > believed to be clean.
> > >
> ------------------------------------------------------------------------
> > >
> > > _______________________________________________
> > > LCDproc mailing list
> > > LCDproc at lists.omnipotent.net
> > > http://lists.omnipotent.net/mailman/listinfo/lcdproc
>
> --
>
>              Many an ancient lord's last words had been:
>         "You can't kill me because I've got magic aaargh...."
>                                      -- Terry Pratchett, Interesting Times
>
> _______________________________________________
> LCDproc mailing list
> LCDproc at lists.omnipotent.net
> http://lists.omnipotent.net/mailman/listinfo/lcdproc
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omnipotent.net/pipermail/lcdproc/attachments/20081106/ccf17c77/attachment.htm>

From loosen at xs4all.nl  Sat Nov  8 20:35:44 2008
From: loosen at xs4all.nl (Bob van Loosen)
Date: Sun, 09 Nov 2008 03:35:44 +0100
Subject: [Lcdproc] LCDd on screen Display
In-Reply-To: <BAY106-DS23D8551D8F27336D20193E51E0@phx.gbl>
References: <BAY106-DS23D8551D8F27336D20193E51E0@phx.gbl>
Message-ID: <49164C80.7050101@xs4all.nl>

You should try the curses driver.

Bob.

Speedy2k wrote:
> Hi everybody, is it possible to start LCDd on a machine without any 
> LCD device and just print the content on the host screen, because i'm 
> building right now a production box, and i will need to program from 
> out of my lab and the computer i have don'T have any LCD and i would 
> like to be able to see my change in me laptop screen.
>  
> Thanx a lot!
>  
> Martin.
> ------------------------------------------------------------------------
>
> _______________________________________________
> LCDproc mailing list
> LCDproc at lists.omnipotent.net
> http://lists.omnipotent.net/mailman/listinfo/lcdproc
>   

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

From peterhollas at hotmail.com  Mon Nov 10 07:45:03 2008
From: peterhollas at hotmail.com (Peter Hollas)
Date: Mon, 10 Nov 2008 13:45:03 +0000
Subject: [Lcdproc] picolcd build problems
Message-ID: <BAY123-W433F16719746BD826A3CCBAC1A0@phx.gbl>


Hi,

I'm trying to compile the latest cvs version of lcdproc for picolcd 20x2 on Mythbuntu 8.10 and have run into some problems. I had it working flawlessly before on Ubuntu 8.04 but this time I get an error when LCDd tries to load the picolcd driver.

root at myth:~/lcdproc# ./configure --enable-libusb --enable-drivers=picolcd

...

configure: checking how to get filesystem space usage...
checking for statvfs... yes
checking module extension... .so
checking for dlopen in -ldl... yes
checking for shl_load in -ldld... no
checking if libusb support has been enabled... yes
configure: WARNING: pkg-config not (fully) installed; drivers requiring libusb may not be built
checking if libftdi support has been enabled... yes
configure: WARNING: pkg-config not (fully) installed; drivers requiring libftdi may not be built
checking if ethlcd support has been enabled... yes
checking for doxygen... no
configure: checking which drivers to compile...
---------------------------------------
LCDd will be compiled with the drivers:
    -  picolcd
---------------------------------------
configure: creating ./config.status
config.status: creating Makefile
config.status: creating shared/Makefile
config.status: creating server/Makefile
config.status: creating server/commands/Makefile
config.status: creating server/drivers/Makefile
config.status: creating clients/Makefile
config.status: creating clients/lcdproc/Makefile
config.status: creating clients/lcdexec/Makefile
config.status: creating clients/lcdvc/Makefile
config.status: creating clients/examples/Makefile
config.status: creating clients/metar/Makefile
config.status: creating docs/Makefile
config.status: creating docs/Doxyfile
config.status: creating docs/lcdproc-dev/Makefile
config.status: creating docs/lcdproc-user/Makefile
config.status: creating docs/lcdproc-user/drivers/Makefile
config.status: creating scripts/Makefile
config.status: creating scripts/init-LCDd.LSB
config.status: creating scripts/init-lcdproc.LSB
config.status: creating scripts/init-lcdexec.LSB
config.status: creating scripts/init-lcdvc.LSB
config.status: creating scripts/init-LCDd.debian
config.status: creating scripts/init-lcdproc.debian
config.status: creating scripts/init-lcdexec.debian
config.status: creating scripts/init-lcdvc.debian
config.status: creating scripts/init-LCDd.rpm
config.status: creating scripts/init-lcdproc.rpm
config.status: creating config.h
config.status: config.h is unchanged
config.status: executing depfiles commands
root at myth:~/lcdproc# 

after doing a 'make' and 'make install', everything builds without errors, but when I try to start LCDd I get the following in syslog.

Nov 10 12:59:39 myth LCDd: Could not open driver module /usr/lib/lcdproc/picolcd.so: /usr/lib/lcdproc/picolcd.so: undefined symbol: usb_release_interface
Nov 10 12:59:39 myth LCDd: Driver [picolcd] binding failed
Nov 10 12:59:39 myth LCDd: Could not load driver picolcd
Nov 10 12:59:39 myth LCDd: There is no output driver
Nov 10 12:59:39 myth LCDd: Critical error while initializing, abort.

I'm assuming it's a libusb problem, but as far as I am aware I have the correct packages.

Any ideas would be appreciated, thanks!

Peter.


_________________________________________________________________
Win ?1000 John Lewis shopping sprees with BigSnapSearch.com
http://clk.atdmt.com/UKM/go/117442309/direct/01/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omnipotent.net/pipermail/lcdproc/attachments/20081110/2b222fc6/attachment.htm>

From andy at siliconlandmark.com  Mon Nov 10 09:06:10 2008
From: andy at siliconlandmark.com (Andre Guibert de Bruet)
Date: Mon, 10 Nov 2008 10:06:10 -0500
Subject: [Lcdproc] picolcd build problems
In-Reply-To: <BAY123-W433F16719746BD826A3CCBAC1A0@phx.gbl>
References: <BAY123-W433F16719746BD826A3CCBAC1A0@phx.gbl>
Message-ID: <3D8A8737-BAF1-4AEF-921B-4CECEF0F865D@siliconlandmark.com>

On Nov 10, 2008, at 8:45 AM, Peter Hollas wrote:

> I'm trying to compile the latest cvs version of lcdproc for picolcd  
> 20x2 on Mythbuntu 8.10 and have run into some problems. I had it  
> working flawlessly before on Ubuntu 8.04 but this time I get an  
> error when LCDd tries to load the picolcd driver.
>
> root at myth:~/lcdproc# ./configure --enable-libusb --enable- 
> drivers=picolcd
> ...
> checking if libusb support has been enabled... yes
> configure: WARNING: pkg-config not (fully) installed; drivers  
> requiring libusb may not be built
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
This is likely to be the cause of your problems.

> after doing a 'make' and 'make install', everything builds without  
> errors, but when I try to start LCDd I get the following in syslog.
>
> Nov 10 12:59:39 myth LCDd: Could not open driver module /usr/lib/ 
> lcdproc/picolcd.so: /usr/lib/lcdproc/picolcd.so: undefined symbol:  
> usb_release_interface
> Nov 10 12:59:39 myth LCDd: Driver [picolcd] binding failed
> Nov 10 12:59:39 myth LCDd: Could not load driver picolcd
> Nov 10 12:59:39 myth LCDd: There is no output driver
> Nov 10 12:59:39 myth LCDd: Critical error while initializing, abort.
>
> I'm assuming it's a libusb problem, but as far as I am aware I have  
> the correct packages.

This problem is likely to be caused by the change in CVS with regards  
to pkg-config. Make sure that pkg-config installed correctly prior to  
running configure or hack the Makefile and adjust the linker parameters.

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 jarod at wilsonet.com  Mon Nov 10 11:14:24 2008
From: jarod at wilsonet.com (Jarod Wilson)
Date: Mon, 10 Nov 2008 12:14:24 -0500
Subject: [Lcdproc] iMon LCD device support
Message-ID: <1226337264.7789.14.camel@xavier.wilsonet.com>

Hi folks,

I'm new to the list, only just last week got an LCD device to play with.
What I got was the Antec Veris Multimedia Station Premiere[1], which is
a rebadged SoundGraph iMon UltraBay (with a different usb device ID).
I've done the necessary work to get it working rather nicely with lirc's
lirc_imon driver (changes committed to lirc cvs this past weekend), and
with a patched up lcdproc, its working quite nicely with MythTV.

Anyhow, the patch is what leads me here. I see Dean Harding posted a
patch a while back for support of the original iMon LCD, and there's now
a v3 of that patch. On top of that, there's a patch to that patch for
the newer iMon LCD, which is also required for mine. Ron Frazier has
most of the details covered[2], so I won't rehash them here.

A quick search of the archives suggested the only things really needed
to get the patch merged was some documentation, but Dean had some
additional work he wanted to do... I guess my question is primarily for
Dean: what really *has* to be done for this to be ready to be merged?
Personally, I'd advocate merging it ASAP, rather than waiting until its
perfect, so that it gets out to a wider audience of testers -- not
everyone is comfortable patching and building from source, but many such
people can provide useful feedback.

Note that I maintain Fedora's lirc bits and co-maintain its lcdproc
package, and thus intend to patch in full support for this device for
Fedora users, but would really like to see it all upstreamed ASAP.


[1] http://www.newegg.com/Product/Product.aspx?Item=N82E16811999193
[2]
http://mythtvblog.blogspot.com/2008/04/getting-imon-0038-lcd-working-with-lirc.html




-- 
Jarod Wilson
jarod at wilsonet.com


From pthomas8589 at gmail.com  Mon Nov 10 15:54:31 2008
From: pthomas8589 at gmail.com (Paul Thomas)
Date: Mon, 10 Nov 2008 14:54:31 -0700
Subject: [Lcdproc] picolcd driver
In-Reply-To: <48F5E47B.10807@stuffofmine.com>
References: <c785bba30810140908k5df92c03iae5a4b683933936c@mail.gmail.com>
	<211149.84232.qm@web30205.mail.mud.yahoo.com>
	<c785bba30810141350o2a7d83a6vf8269f8e79b85e67@mail.gmail.com>
	<200810150913.15269.peter@adpm.de> <48F5E47B.10807@stuffofmine.com>
Message-ID: <c785bba30811101354m70496950gbb99086939d6b5c6@mail.gmail.com>

OK, the config.log file says "configure:13022: WARNING: The picolcd
driver needs the libusb library.", but the libusb library is
installed.

I've now tried this on both a 32-bit & 64-bit machine with the same results.

Please help

thanks,
Paul

On Wed, Oct 15, 2008 at 5:39 AM, Bob Wiegand <bob_ml at stuffofmine.com> wrote:
> Peter Marschall wrote:
>>
>> Hi Paul,
>>
>> On Tuesday, 14. October 2008, Paul Thomas wrote:
>>>
>>> I tried that with both the CSV and lcdproc-picolcd20x4-0.5.2-cvs.tgz
>>> version. I still don't get a picolcd.so file.
>>
>> Bogdan is right, picolcd is not among the drivers that are built by
>> default.
>>
>> Besides, the picolcd driver requires libusb.
>>
>> Perhaps you haven't installed it (or it's developemnt files).
>> In addition to that, LCDproc requires pkg-config installed.
>>
>> Please report if this helps.
>>
>> Regards
>> Peter
>
> A missing dependency is the most likely problem.
>
> Check the "config.log" file and search for "picolcd". There may be an
> error message telling you what's missing.
>
> --
> Regards,
> Bob
>
>
> _______________________________________________
> LCDproc mailing list
> LCDproc at lists.omnipotent.net
> http://lists.omnipotent.net/mailman/listinfo/lcdproc
>

From pthomas8589 at gmail.com  Mon Nov 10 15:54:31 2008
From: pthomas8589 at gmail.com (Paul Thomas)
Date: Mon, 10 Nov 2008 14:54:31 -0700
Subject: [Lcdproc] picolcd driver
In-Reply-To: <48F5E47B.10807@stuffofmine.com>
References: <c785bba30810140908k5df92c03iae5a4b683933936c@mail.gmail.com>
	<211149.84232.qm@web30205.mail.mud.yahoo.com>
	<c785bba30810141350o2a7d83a6vf8269f8e79b85e67@mail.gmail.com>
	<200810150913.15269.peter@adpm.de> <48F5E47B.10807@stuffofmine.com>
Message-ID: <c785bba30811101354m70496950gbb99086939d6b5c6@mail.gmail.com>

OK, the config.log file says "configure:13022: WARNING: The picolcd
driver needs the libusb library.", but the libusb library is
installed.

I've now tried this on both a 32-bit & 64-bit machine with the same results.

Please help

thanks,
Paul

On Wed, Oct 15, 2008 at 5:39 AM, Bob Wiegand <bob_ml at stuffofmine.com> wrote:
> Peter Marschall wrote:
>>
>> Hi Paul,
>>
>> On Tuesday, 14. October 2008, Paul Thomas wrote:
>>>
>>> I tried that with both the CSV and lcdproc-picolcd20x4-0.5.2-cvs.tgz
>>> version. I still don't get a picolcd.so file.
>>
>> Bogdan is right, picolcd is not among the drivers that are built by
>> default.
>>
>> Besides, the picolcd driver requires libusb.
>>
>> Perhaps you haven't installed it (or it's developemnt files).
>> In addition to that, LCDproc requires pkg-config installed.
>>
>> Please report if this helps.
>>
>> Regards
>> Peter
>
> A missing dependency is the most likely problem.
>
> Check the "config.log" file and search for "picolcd". There may be an
> error message telling you what's missing.
>
> --
> Regards,
> Bob
>
>
> _______________________________________________
> LCDproc mailing list
> LCDproc at lists.omnipotent.net
> http://lists.omnipotent.net/mailman/listinfo/lcdproc
>

From pthomas8589 at gmail.com  Mon Nov 10 15:54:31 2008
From: pthomas8589 at gmail.com (Paul Thomas)
Date: Mon, 10 Nov 2008 14:54:31 -0700
Subject: [Lcdproc] picolcd driver
In-Reply-To: <48F5E47B.10807@stuffofmine.com>
References: <c785bba30810140908k5df92c03iae5a4b683933936c@mail.gmail.com>
	<211149.84232.qm@web30205.mail.mud.yahoo.com>
	<c785bba30810141350o2a7d83a6vf8269f8e79b85e67@mail.gmail.com>
	<200810150913.15269.peter@adpm.de> <48F5E47B.10807@stuffofmine.com>
Message-ID: <c785bba30811101354m70496950gbb99086939d6b5c6@mail.gmail.com>

OK, the config.log file says "configure:13022: WARNING: The picolcd
driver needs the libusb library.", but the libusb library is
installed.

I've now tried this on both a 32-bit & 64-bit machine with the same results.

Please help

thanks,
Paul

On Wed, Oct 15, 2008 at 5:39 AM, Bob Wiegand <bob_ml at stuffofmine.com> wrote:
> Peter Marschall wrote:
>>
>> Hi Paul,
>>
>> On Tuesday, 14. October 2008, Paul Thomas wrote:
>>>
>>> I tried that with both the CSV and lcdproc-picolcd20x4-0.5.2-cvs.tgz
>>> version. I still don't get a picolcd.so file.
>>
>> Bogdan is right, picolcd is not among the drivers that are built by
>> default.
>>
>> Besides, the picolcd driver requires libusb.
>>
>> Perhaps you haven't installed it (or it's developemnt files).
>> In addition to that, LCDproc requires pkg-config installed.
>>
>> Please report if this helps.
>>
>> Regards
>> Peter
>
> A missing dependency is the most likely problem.
>
> Check the "config.log" file and search for "picolcd". There may be an
> error message telling you what's missing.
>
> --
> Regards,
> Bob
>
>
> _______________________________________________
> LCDproc mailing list
> LCDproc at lists.omnipotent.net
> http://lists.omnipotent.net/mailman/listinfo/lcdproc
>

From pthomas8589 at gmail.com  Mon Nov 10 15:54:31 2008
From: pthomas8589 at gmail.com (Paul Thomas)
Date: Mon, 10 Nov 2008 14:54:31 -0700
Subject: [Lcdproc] picolcd driver
In-Reply-To: <48F5E47B.10807@stuffofmine.com>
References: <c785bba30810140908k5df92c03iae5a4b683933936c@mail.gmail.com>
	<211149.84232.qm@web30205.mail.mud.yahoo.com>
	<c785bba30810141350o2a7d83a6vf8269f8e79b85e67@mail.gmail.com>
	<200810150913.15269.peter@adpm.de> <48F5E47B.10807@stuffofmine.com>
Message-ID: <c785bba30811101354m70496950gbb99086939d6b5c6@mail.gmail.com>

OK, the config.log file says "configure:13022: WARNING: The picolcd
driver needs the libusb library.", but the libusb library is
installed.

I've now tried this on both a 32-bit & 64-bit machine with the same results.

Please help

thanks,
Paul

On Wed, Oct 15, 2008 at 5:39 AM, Bob Wiegand <bob_ml at stuffofmine.com> wrote:
> Peter Marschall wrote:
>>
>> Hi Paul,
>>
>> On Tuesday, 14. October 2008, Paul Thomas wrote:
>>>
>>> I tried that with both the CSV and lcdproc-picolcd20x4-0.5.2-cvs.tgz
>>> version. I still don't get a picolcd.so file.
>>
>> Bogdan is right, picolcd is not among the drivers that are built by
>> default.
>>
>> Besides, the picolcd driver requires libusb.
>>
>> Perhaps you haven't installed it (or it's developemnt files).
>> In addition to that, LCDproc requires pkg-config installed.
>>
>> Please report if this helps.
>>
>> Regards
>> Peter
>
> A missing dependency is the most likely problem.
>
> Check the "config.log" file and search for "picolcd". There may be an
> error message telling you what's missing.
>
> --
> Regards,
> Bob
>
>
> _______________________________________________
> LCDproc mailing list
> LCDproc at lists.omnipotent.net
> http://lists.omnipotent.net/mailman/listinfo/lcdproc
>

From pthomas8589 at gmail.com  Mon Nov 10 15:54:31 2008
From: pthomas8589 at gmail.com (Paul Thomas)
Date: Mon, 10 Nov 2008 14:54:31 -0700
Subject: [Lcdproc] picolcd driver
In-Reply-To: <48F5E47B.10807@stuffofmine.com>
References: <c785bba30810140908k5df92c03iae5a4b683933936c@mail.gmail.com>
	<211149.84232.qm@web30205.mail.mud.yahoo.com>
	<c785bba30810141350o2a7d83a6vf8269f8e79b85e67@mail.gmail.com>
	<200810150913.15269.peter@adpm.de> <48F5E47B.10807@stuffofmine.com>
Message-ID: <c785bba30811101354m70496950gbb99086939d6b5c6@mail.gmail.com>

OK, the config.log file says "configure:13022: WARNING: The picolcd
driver needs the libusb library.", but the libusb library is
installed.

I've now tried this on both a 32-bit & 64-bit machine with the same results.

Please help

thanks,
Paul

On Wed, Oct 15, 2008 at 5:39 AM, Bob Wiegand <bob_ml at stuffofmine.com> wrote:
> Peter Marschall wrote:
>>
>> Hi Paul,
>>
>> On Tuesday, 14. October 2008, Paul Thomas wrote:
>>>
>>> I tried that with both the CSV and lcdproc-picolcd20x4-0.5.2-cvs.tgz
>>> version. I still don't get a picolcd.so file.
>>
>> Bogdan is right, picolcd is not among the drivers that are built by
>> default.
>>
>> Besides, the picolcd driver requires libusb.
>>
>> Perhaps you haven't installed it (or it's developemnt files).
>> In addition to that, LCDproc requires pkg-config installed.
>>
>> Please report if this helps.
>>
>> Regards
>> Peter
>
> A missing dependency is the most likely problem.
>
> Check the "config.log" file and search for "picolcd". There may be an
> error message telling you what's missing.
>
> --
> Regards,
> Bob
>
>
> _______________________________________________
> LCDproc mailing list
> LCDproc at lists.omnipotent.net
> http://lists.omnipotent.net/mailman/listinfo/lcdproc
>

From jarod at wilsonet.com  Mon Nov 10 16:04:18 2008
From: jarod at wilsonet.com (Jarod Wilson)
Date: Mon, 10 Nov 2008 17:04:18 -0500
Subject: [Lcdproc] picolcd driver
In-Reply-To: <c785bba30811101354m70496950gbb99086939d6b5c6@mail.gmail.com>
References: <c785bba30810140908k5df92c03iae5a4b683933936c@mail.gmail.com>
	<211149.84232.qm@web30205.mail.mud.yahoo.com>
	<c785bba30810141350o2a7d83a6vf8269f8e79b85e67@mail.gmail.com>
	<200810150913.15269.peter@adpm.de> <48F5E47B.10807@stuffofmine.com>
	<c785bba30811101354m70496950gbb99086939d6b5c6@mail.gmail.com>
Message-ID: <1226354659.7789.30.camel@xavier.wilsonet.com>

On Mon, 2008-11-10 at 14:54 -0700, Paul Thomas wrote:
> OK, the config.log file says "configure:13022: WARNING: The picolcd
> driver needs the libusb library.", but the libusb library is
> installed.
> 
> I've now tried this on both a 32-bit & 64-bit machine with the same results.
> 
> Please help

Simply having libusb probably isn't enough, you also need libusb-devel
or libusb-dev or whatever it is that provides the actual header files
for libusb.



> On Wed, Oct 15, 2008 at 5:39 AM, Bob Wiegand <bob_ml at stuffofmine.com> wrote:
> > Peter Marschall wrote:
> >>
> >> Hi Paul,
> >>
> >> On Tuesday, 14. October 2008, Paul Thomas wrote:
> >>>
> >>> I tried that with both the CSV and lcdproc-picolcd20x4-0.5.2-cvs.tgz
> >>> version. I still don't get a picolcd.so file.
> >>
> >> Bogdan is right, picolcd is not among the drivers that are built by
> >> default.
> >>
> >> Besides, the picolcd driver requires libusb.
> >>
> >> Perhaps you haven't installed it (or it's developemnt files).
> >> In addition to that, LCDproc requires pkg-config installed.
> >>
> >> Please report if this helps.
> >>
> >> Regards
> >> Peter
> >
> > A missing dependency is the most likely problem.
> >
> > Check the "config.log" file and search for "picolcd". There may be an
> > error message telling you what's missing.


-- 
Jarod Wilson
jarod at wilsonet.com


From pthomas8589 at gmail.com  Mon Nov 10 15:54:31 2008
From: pthomas8589 at gmail.com (Paul Thomas)
Date: Mon, 10 Nov 2008 14:54:31 -0700
Subject: [Lcdproc] picolcd driver
In-Reply-To: <48F5E47B.10807@stuffofmine.com>
References: <c785bba30810140908k5df92c03iae5a4b683933936c@mail.gmail.com>
	<211149.84232.qm@web30205.mail.mud.yahoo.com>
	<c785bba30810141350o2a7d83a6vf8269f8e79b85e67@mail.gmail.com>
	<200810150913.15269.peter@adpm.de> <48F5E47B.10807@stuffofmine.com>
Message-ID: <c785bba30811101354m70496950gbb99086939d6b5c6@mail.gmail.com>

OK, the config.log file says "configure:13022: WARNING: The picolcd
driver needs the libusb library.", but the libusb library is
installed.

I've now tried this on both a 32-bit & 64-bit machine with the same results.

Please help

thanks,
Paul

On Wed, Oct 15, 2008 at 5:39 AM, Bob Wiegand <bob_ml at stuffofmine.com> wrote:
> Peter Marschall wrote:
>>
>> Hi Paul,
>>
>> On Tuesday, 14. October 2008, Paul Thomas wrote:
>>>
>>> I tried that with both the CSV and lcdproc-picolcd20x4-0.5.2-cvs.tgz
>>> version. I still don't get a picolcd.so file.
>>
>> Bogdan is right, picolcd is not among the drivers that are built by
>> default.
>>
>> Besides, the picolcd driver requires libusb.
>>
>> Perhaps you haven't installed it (or it's developemnt files).
>> In addition to that, LCDproc requires pkg-config installed.
>>
>> Please report if this helps.
>>
>> Regards
>> Peter
>
> A missing dependency is the most likely problem.
>
> Check the "config.log" file and search for "picolcd". There may be an
> error message telling you what's missing.
>
> --
> Regards,
> Bob
>
>
> _______________________________________________
> LCDproc mailing list
> LCDproc at lists.omnipotent.net
> http://lists.omnipotent.net/mailman/listinfo/lcdproc
>

From epooch at cox.net  Mon Nov 10 23:15:30 2008
From: epooch at cox.net (epooch at cox.net)
Date: Mon, 10 Nov 2008 21:15:30 -0800
Subject: [Lcdproc] picolcd driver
In-Reply-To: <1226354659.7789.30.camel@xavier.wilsonet.com>
Message-ID: <20081111001530.I702H.205206.imail@fed1rmwml28>

Make sure you have pkg-config installed and the PKG_CONFIG set to the path of pkg-config if it is not installed in your search paths.

---- Jarod Wilson <jarod at wilsonet.com> wrote: 
> On Mon, 2008-11-10 at 14:54 -0700, Paul Thomas wrote:
> > OK, the config.log file says "configure:13022: WARNING: The picolcd
> > driver needs the libusb library.", but the libusb library is
> > installed.
> > 
> > I've now tried this on both a 32-bit & 64-bit machine with the same results.
> > 
> > Please help
> 
> Simply having libusb probably isn't enough, you also need libusb-devel
> or libusb-dev or whatever it is that provides the actual header files
> for libusb.
> 
> 
> 
> > On Wed, Oct 15, 2008 at 5:39 AM, Bob Wiegand <bob_ml at stuffofmine.com> wrote:
> > > Peter Marschall wrote:
> > >>
> > >> Hi Paul,
> > >>
> > >> On Tuesday, 14. October 2008, Paul Thomas wrote:
> > >>>
> > >>> I tried that with both the CSV and lcdproc-picolcd20x4-0.5.2-cvs.tgz
> > >>> version. I still don't get a picolcd.so file.
> > >>
> > >> Bogdan is right, picolcd is not among the drivers that are built by
> > >> default.
> > >>
> > >> Besides, the picolcd driver requires libusb.
> > >>
> > >> Perhaps you haven't installed it (or it's developemnt files).
> > >> In addition to that, LCDproc requires pkg-config installed.
> > >>
> > >> Please report if this helps.
> > >>
> > >> Regards
> > >> Peter
> > >
> > > A missing dependency is the most likely problem.
> > >
> > > Check the "config.log" file and search for "picolcd". There may be an
> > > error message telling you what's missing.
> 
> 
> -- 
> Jarod Wilson
> jarod at wilsonet.com
> 
> _______________________________________________
> LCDproc mailing list
> LCDproc at lists.omnipotent.net
> http://lists.omnipotent.net/mailman/listinfo/lcdproc


From peterhollas at hotmail.com  Tue Nov 11 12:21:43 2008
From: peterhollas at hotmail.com (Peter Hollas)
Date: Tue, 11 Nov 2008 18:21:43 +0000
Subject: [Lcdproc] picolcd build problems
In-Reply-To: <3D8A8737-BAF1-4AEF-921B-4CECEF0F865D@siliconlandmark.com>
References: <BAY123-W433F16719746BD826A3CCBAC1A0@phx.gbl>
	<3D8A8737-BAF1-4AEF-921B-4CECEF0F865D@siliconlandmark.com>
Message-ID: <BAY123-W5324E0AD2916CA367D7CBDAC150@phx.gbl>


Hi,

I have downloaded the latest cvs source and tried again. 



I am no longer seeing pkg-config problems when I do the ./configure and everything compiles and installs without obvious errors. 

Everything works fine for the display side of things with the picolcd driver.

Unfortunately I can't seem to get lirc to receive anything on UDP using irw. I "think" that the picolcd is not sending out UDP but I have no idea how to test that it. Doing a "nc -p 8765 -u -l" when lircd is disabled also shows nothing and I have set the UDP options up for the picolcd driver in LCDd.conf as well as lirc.

Any ideas would be welcome!

Thanks, Peter.


> CC: lcdproc at lists.omnipotent.net
> From: andy at siliconlandmark.com
> To: peterhollas at hotmail.com
> Subject: Re: [Lcdproc] picolcd build problems
> Date: Mon, 10 Nov 2008 10:06:10 -0500
> 
> On Nov 10, 2008, at 8:45 AM, Peter Hollas wrote:
> 
> > I'm trying to compile the latest cvs version of lcdproc for picolcd  
> > 20x2 on Mythbuntu 8.10 and have run into some problems. I had it  
> > working flawlessly before on Ubuntu 8.04 but this time I get an  
> > error when LCDd tries to load the picolcd driver.
> >
> > root at myth:~/lcdproc# ./configure --enable-libusb --enable- 
> > drivers=picolcd
> > ...
> > checking if libusb support has been enabled... yes
> > configure: WARNING: pkg-config not (fully) installed; drivers  
> > requiring libusb may not be built
>              ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> This is likely to be the cause of your problems.
> 
> > after doing a 'make' and 'make install', everything builds without  
> > errors, but when I try to start LCDd I get the following in syslog.
> >
> > Nov 10 12:59:39 myth LCDd: Could not open driver module /usr/lib/ 
> > lcdproc/picolcd.so: /usr/lib/lcdproc/picolcd.so: undefined symbol:  
> > usb_release_interface
> > Nov 10 12:59:39 myth LCDd: Driver [picolcd] binding failed
> > Nov 10 12:59:39 myth LCDd: Could not load driver picolcd
> > Nov 10 12:59:39 myth LCDd: There is no output driver
> > Nov 10 12:59:39 myth LCDd: Critical error while initializing, abort.
> >
> > I'm assuming it's a libusb problem, but as far as I am aware I have  
> > the correct packages.
> 
> This problem is likely to be caused by the change in CVS with regards  
> to pkg-config. Make sure that pkg-config installed correctly prior to  
> running configure or hack the Makefile and adjust the linker parameters.
> 
> 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 */

_________________________________________________________________
BigSnapSearch.com - 24 prizes a day, every day - Search Now!
http://clk.atdmt.com/UKM/go/117442309/direct/01/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omnipotent.net/pipermail/lcdproc/attachments/20081111/a680d0b6/attachment.htm>

From peterhollas at hotmail.com  Wed Nov 12 06:22:04 2008
From: peterhollas at hotmail.com (Peter Hollas)
Date: Wed, 12 Nov 2008 12:22:04 +0000
Subject: [Lcdproc] picolcd build problems
In-Reply-To: <BAY123-W5324E0AD2916CA367D7CBDAC150@phx.gbl>
References: <BAY123-W433F16719746BD826A3CCBAC1A0@phx.gbl>
	<3D8A8737-BAF1-4AEF-921B-4CECEF0F865D@siliconlandmark.com> 
	<BAY123-W5324E0AD2916CA367D7CBDAC150@phx.gbl>
Message-ID: <BAY123-W176B48FE7D417FEE09FD5EAC140@phx.gbl>



Hi,

After a bit of debugging, it appears that there the picolcd driver looks for LircHost= as a configuration parameter. However, in the /etc/LCDd.conf it is defined as LircAddress= and so Lirc UDP never gets switched on with the standard cvs config.

Please could someone submit a correction to cvs.

Thanks, Peter.
From: peterhollas at hotmail.com
To: lcdproc at lists.omnipotent.net
Date: Tue, 11 Nov 2008 18:21:43 +0000
Subject: Re: [Lcdproc] picolcd build problems








Hi,

I have downloaded the latest cvs source and tried again. 



I am no longer seeing pkg-config problems when I do the ./configure and everything compiles and installs without obvious errors. 

Everything works fine for the display side of things with the picolcd driver.

Unfortunately I can't seem to get lirc to receive anything on UDP using irw. I "think" that the picolcd is not sending out UDP but I have no idea how to test that it. Doing a "nc -p 8765 -u -l" when lircd is disabled also shows nothing and I have set the UDP options up for the picolcd driver in LCDd.conf as well as lirc.

Any ideas would be welcome!

Thanks, Peter.


> CC: lcdproc at lists.omnipotent.net
> From: andy at siliconlandmark.com
> To: peterhollas at hotmail.com
> Subject: Re: [Lcdproc] picolcd build problems
> Date: Mon, 10 Nov 2008 10:06:10 -0500
> 
> On Nov 10, 2008, at 8:45 AM, Peter Hollas wrote:
> 
> > I'm trying to compile the latest cvs version of lcdproc for picolcd  
> > 20x2 on Mythbuntu 8.10 and have run into some problems. I had it  
> > working flawlessly before on Ubuntu 8.04 but this time I get an  
> > error when LCDd tries to load the picolcd driver.
> >
> > root at myth:~/lcdproc# ./configure --enable-libusb --enable- 
> > drivers=picolcd
> > ...
> > checking if libusb support has been enabled... yes
> > configure: WARNING: pkg-config not (fully) installed; drivers  
> > requiring libusb may not be built
>              ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> This is likely to be the cause of your problems.
> 
> > after doing a 'make' and 'make install', everything builds without  
> > errors, but when I try to start LCDd I get the following in syslog.
> >
> > Nov 10 12:59:39 myth LCDd: Could not open driver module /usr/lib/ 
> > lcdproc/picolcd.so: /usr/lib/lcdproc/picolcd.so: undefined symbol:  
> > usb_release_interface
> > Nov 10 12:59:39 myth LCDd: Driver [picolcd] binding failed
> > Nov 10 12:59:39 myth LCDd: Could not load driver picolcd
> > Nov 10 12:59:39 myth LCDd: There is no output driver
> > Nov 10 12:59:39 myth LCDd: Critical error while initializing, abort.
> >
> > I'm assuming it's a libusb problem, but as far as I am aware I have  
> > the correct packages.
> 
> This problem is likely to be caused by the change in CVS with regards  
> to pkg-config. Make sure that pkg-config installed correctly prior to  
> running configure or hack the Makefile and adjust the linker parameters.
> 
> 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 */

Click here for FREE customisable desktop wallpapers. Get them Now!
_________________________________________________________________
Win ?1000 John Lewis shopping sprees with BigSnapSearch.com
http://clk.atdmt.com/UKM/go/117442309/direct/01/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omnipotent.net/pipermail/lcdproc/attachments/20081112/74c54d94/attachment.htm>

From avionicsdv at aim.com  Thu Nov 13 04:55:14 2008
From: avionicsdv at aim.com (David W Studeman)
Date: Thu, 13 Nov 2008 02:55:14 -0800
Subject: [Lcdproc] iMon LCD device support
In-Reply-To: <1226337264.7789.14.camel@xavier.wilsonet.com>
References: <1226337264.7789.14.camel@xavier.wilsonet.com>
Message-ID: <gfh12j$l6f$1@ger.gmane.org>

Jarod Wilson wrote:
> Hi folks,
>
> I'm new to the list, only just last week got an LCD device to play with.
> What I got was the Antec Veris Multimedia Station Premiere[1], which is
> a rebadged SoundGraph iMon UltraBay (with a different usb device ID).
> I've done the necessary work to get it working rather nicely with lirc's
> lirc_imon driver (changes committed to lirc cvs this past weekend), and
> with a patched up lcdproc, its working quite nicely with MythTV.
>
> Anyhow, the patch is what leads me here. I see Dean Harding posted a
> patch a while back for support of the original iMon LCD, and there's now
> a v3 of that patch. On top of that, there's a patch to that patch for
> the newer iMon LCD, which is also required for mine. Ron Frazier has
> most of the details covered[2], so I won't rehash them here.
>
> A quick search of the archives suggested the only things really needed
> to get the patch merged was some documentation, but Dean had some
> additional work he wanted to do... I guess my question is primarily for
> Dean: what really *has* to be done for this to be ready to be merged?
> Personally, I'd advocate merging it ASAP, rather than waiting until its
> perfect, so that it gets out to a wider audience of testers -- not
> everyone is comfortable patching and building from source, but many such
> people can provide useful feedback.
>
> Note that I maintain Fedora's lirc bits and co-maintain its lcdproc
> package, and thus intend to patch in full support for this device for
> Fedora users, but would really like to see it all upstreamed ASAP.
>
>
> [1] http://www.newegg.com/Product/Product.aspx?Item=N82E16811999193
> [2]
> http://mythtvblog.blogspot.com/2008/04/getting-imon-0038-lcd-working-with-lirc.html
>
>
>
>
I thought your name was familiar, I use MythDora myself and in 2007 
offered up an imon patched lirc driver set to Dennis in the MD4 days.
Most of what you see in these articles is related to getting Lirc 
patched and running the remote. The Lcd or VFD portion of it should have 
nothing at all to do with kernel drivers or lirc for that matter. In 
fact, while mixing on and off topic here anyway, I hated the imon remote 
so much I changed to a new rf remote and just left lcdproc to drive the 
display which is likely hd44780 compatible anyway like 99% of the 
character displays out there and set up lirc for the new remote. Once 
you get the mousepad working, you'll scream obscenities at it sometimes 
because it's overly sensitive but you do need four axis control on a 
remote to enjoy MythTV without using the keyboard. If I knew then what I 
know now about displays and remotes, I would have not bought an 
expensive Imon setup to only have a 16x2 display and a remote I 
abandoned anyway. A 20x4 VFD or LCD will fit in the same window.

-- 
Dave Studeman
http://www.raqcop.com


From hansfong at zonnet.nl  Thu Nov 13 16:01:17 2008
From: hansfong at zonnet.nl (hansfong at zonnet.nl)
Date: Thu, 13 Nov 2008 23:01:17 +0100
Subject: [Lcdproc] Clients for dummies!
Message-ID: <20081113230117.53av9c3nd7cckk8k@webmail.versatel.nl>

Hello,

I got a picoLCD 4x20, which works fine with LCDproc and the example 
perl scripts which came with it. My aim is to understand the workings 
of this type of hardware, but I'm no programmer by any means apart from 
some bash/php experience.

I looked at the perl scripts, but they are a bit hard to comprehend and 
alter to my own needs. So my questions:
- Is there a beginners guide for writing clients for LCDproc? - Or 
maybe a template on which I can build my own client or study the 
workings of the code? - Can a client be written as a simple shell 
script, or php script called from the command line?

Right now my preferred next step is to just get some own text displayed 
on the screen, e.g. open a text file and send the contents to the 
display and then move on to more complex things. Any help is very much 
appreciated. Cheers,

Hans

From andy.grover at gmail.com  Thu Nov 13 17:27:53 2008
From: andy.grover at gmail.com (Andrew Grover)
Date: Thu, 13 Nov 2008 15:27:53 -0800
Subject: [Lcdproc] Clients for dummies!
In-Reply-To: <20081113230117.53av9c3nd7cckk8k@webmail.versatel.nl>
References: <20081113230117.53av9c3nd7cckk8k@webmail.versatel.nl>
Message-ID: <c0a09e5c0811131527h61e40a1fm3ffd02639a8f7632@mail.gmail.com>

On Thu, Nov 13, 2008 at 2:01 PM,  <hansfong at zonnet.nl> wrote:
> I got a picoLCD 4x20, which works fine with LCDproc and the example perl
> scripts which came with it. My aim is to understand the workings of this
> type of hardware, but I'm no programmer by any means apart from some
> bash/php experience.
>
> I looked at the perl scripts, but they are a bit hard to comprehend and
> alter to my own needs. So my questions:
> - Is there a beginners guide for writing clients for LCDproc? - Or maybe a
> template on which I can build my own client or study the workings of the
> code? - Can a client be written as a simple shell script, or php script
> called from the command line?

Look at the LCDd manpage. The client protocol is human-readable, so
you can use whatever language you want to telnet to localhost port
13666 and send commands.

You might also want to check out the source of some other languages'
wrapper libraries, if you don't like Perl:
Ruby: http://sourceforge.net/projects/lcdproc-ruby/
Ruby: http://sourceforge.net/projects/ruby-lcd/

These both include clients written to demonstrate the use of the library.

I'm also working on a Python lib, see here:
http://github.com/agrover/pylcd/tree/master
(it's not really ready for primetime, but take a look if you want.)

> Right now my preferred next step is to just get some own text displayed on
> the screen, e.g. open a text file and send the contents to the display and
> then move on to more complex things. Any help is very much appreciated.

telnet localhost 13666
hello
screen_add myscreen
widget_add myscreen mywidget string
widget_set myscreen 1 1 {hello world!}

Regards -- Andy

From epooch at cox.net  Thu Nov 13 19:11:34 2008
From: epooch at cox.net (epooch at cox.net)
Date: Thu, 13 Nov 2008 17:11:34 -0800
Subject: [Lcdproc] Clients for dummies!
In-Reply-To: <c0a09e5c0811131527h61e40a1fm3ffd02639a8f7632@mail.gmail.com>
Message-ID: <20081113201134.NSK1Y.167089.imail@fed1rmwml33>

You can use an expect script to control a telnet session to make a very simple client using the title and message as arguments :
----
#!/usr/bin/expect -f
# Sample telnet to LCDproc automation
## call with /path/to/script "Title" "Message"

spawn telnet localhost 13666 

expect "Connected" {
send "hello\n"
expect "connect"

expect -re "lcd wid (.*) hgt (.*) cellwid"
set screen_wid $expect_out(1,string)
set screen_hgt $expect_out(2,string)
	
send "screen_add myscreen\n"

send "widget_add myscreen title1 title\n"
send "widget_set myscreen title1 {[lindex $argv 0]}\n"

send "widget_add myscreen scroller2 scroller\n"
send "widget_set myscreen scroller2 1 2 $screen_wid 1 m 3 {[lindex $argv 1]}\n"
}
exit

---
I haven't really tested that, but it should work.

---- Andrew Grover <andy.grover at gmail.com> wrote: 
> On Thu, Nov 13, 2008 at 2:01 PM,  <hansfong at zonnet.nl> wrote:
> > I got a picoLCD 4x20, which works fine with LCDproc and the example perl
> > scripts which came with it. My aim is to understand the workings of this
> > type of hardware, but I'm no programmer by any means apart from some
> > bash/php experience.
> >
> > I looked at the perl scripts, but they are a bit hard to comprehend and
> > alter to my own needs. So my questions:
> > - Is there a beginners guide for writing clients for LCDproc? - Or maybe a
> > template on which I can build my own client or study the workings of the
> > code? - Can a client be written as a simple shell script, or php script
> > called from the command line?
> 
> Look at the LCDd manpage. The client protocol is human-readable, so
> you can use whatever language you want to telnet to localhost port
> 13666 and send commands.
> 
> You might also want to check out the source of some other languages'
> wrapper libraries, if you don't like Perl:
> Ruby: http://sourceforge.net/projects/lcdproc-ruby/
> Ruby: http://sourceforge.net/projects/ruby-lcd/
> 
> These both include clients written to demonstrate the use of the library.
> 
> I'm also working on a Python lib, see here:
> http://github.com/agrover/pylcd/tree/master
> (it's not really ready for primetime, but take a look if you want.)
> 
> > Right now my preferred next step is to just get some own text displayed on
> > the screen, e.g. open a text file and send the contents to the display and
> > then move on to more complex things. Any help is very much appreciated.
> 
> telnet localhost 13666
> hello
> screen_add myscreen
> widget_add myscreen mywidget string
> widget_set myscreen 1 1 {hello world!}
> 
> Regards -- Andy
> _______________________________________________
> LCDproc mailing list
> LCDproc at lists.omnipotent.net
> http://lists.omnipotent.net/mailman/listinfo/lcdproc


From epooch at cox.net  Thu Nov 13 22:40:03 2008
From: epooch at cox.net (Eric Pooch)
Date: Thu, 13 Nov 2008 20:40:03 -0800
Subject: [Lcdproc] Clients for dummies!
In-Reply-To: <20081113201134.NSK1Y.167089.imail@fed1rmwml33>
References: <20081113201134.NSK1Y.167089.imail@fed1rmwml33>
Message-ID: <4555B55B-5AC3-417E-991F-87A4320BC6E1@cox.net>

oops: stick a
sleep 30
or a
interact
  in at the end before exit to keep the connection open for a bit
On Nov 13, 2008, at 5:11 PM, <epooch at cox.net> <epooch at cox.net> wrote:

> #!/usr/bin/expect -f
> # Sample telnet to LCDproc automation
> ## call with /path/to/script "Title" "Message"
>
> spawn telnet localhost 13666
>
> expect "Connected" {
> send "hello\n"
> expect "connect"
>
> expect -re "lcd wid (.*) hgt (.*) cellwid"
> set screen_wid $expect_out(1,string)
> set screen_hgt $expect_out(2,string)
> 	
> send "screen_add myscreen\n"
>
> send "widget_add myscreen title1 title\n"
> send "widget_set myscreen title1 {[lindex $argv 0]}\n"
>
> send "widget_add myscreen scroller2 scroller\n"
> send "widget_set myscreen scroller2 1 2 $screen_wid 1 m 3 {[lindex  
> $argv 1]}\n"
interact
> }
> exit

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

From hansfong at zonnet.nl  Fri Nov 14 03:21:34 2008
From: hansfong at zonnet.nl (hansfong at zonnet.nl)
Date: Fri, 14 Nov 2008 10:21:34 +0100
Subject: [Lcdproc] Clients for dummies!
In-Reply-To: <c0a09e5c0811131527h61e40a1fm3ffd02639a8f7632@mail.gmail.com>
References: <20081113230117.53av9c3nd7cckk8k@webmail.versatel.nl>
	<c0a09e5c0811131527h61e40a1fm3ffd02639a8f7632@mail.gmail.com>
Message-ID: <20081114102134.ne63f4vi7go4wgks@webmail.versatel.nl>

Citeren Andrew Grover <andy.grover at gmail.com>:

> Look at the LCDd manpage. The client protocol is human-readable, so
> you can use whatever language you want to telnet to localhost port
> 13666 and send commands.

Isn't that a bit archaic? I haven't been using telnet for ages and I 
thought the use of telnet was depreciated.

> telnet localhost 13666
> hello
> screen_add myscreen
> widget_add myscreen mywidget string
> widget_set myscreen 1 1 {hello world!}

Success! This works, except the last line needs to read like this....
> widget_set myscreen mywidget 1 1 {hello world!}

This looks to me like building a GUI. I think I did some of this ages 
ago (like 8 years) with Perl/Tk, but I gave up then.

Thank you,

Hans

From ethan.dicks at gmail.com  Fri Nov 14 04:00:56 2008
From: ethan.dicks at gmail.com (Ethan Dicks)
Date: Fri, 14 Nov 2008 23:00:56 +1300
Subject: [Lcdproc] Clients for dummies!
In-Reply-To: <20081114102134.ne63f4vi7go4wgks@webmail.versatel.nl>
References: <20081113230117.53av9c3nd7cckk8k@webmail.versatel.nl>
	<c0a09e5c0811131527h61e40a1fm3ffd02639a8f7632@mail.gmail.com>
	<20081114102134.ne63f4vi7go4wgks@webmail.versatel.nl>
Message-ID: <f4eb766f0811140200x366d6688o32dc4996d0aca7e9@mail.gmail.com>

On Fri, Nov 14, 2008 at 10:21 PM,  <hansfong at zonnet.nl> wrote:
> Citeren Andrew Grover <andy.grover at gmail.com>:
>
>> Look at the LCDd manpage. The client protocol is human-readable, so
>> you can use whatever language you want to telnet to localhost port
>> 13666 and send commands.
>
> Isn't that a bit archaic? I haven't been using telnet for ages and I thought
> the use of telnet was depreciated.

It is deprecated for interactive use since it sends unencrypted
passwords over the wire.  In this case, passwords aren't the issue -
it's just being used as a conduit to pass command strings to a server.
 Presumably 'netcat' could do the job, too, but telnet is still on
most machines.

>> telnet localhost 13666
>> hello
>> screen_add myscreen
>> widget_add myscreen mywidget string
>> widget_set myscreen 1 1 {hello world!}
>
> Success! This works, except the last line needs to read like this....
>>
>> widget_set myscreen mywidget 1 1 {hello world!}

Yep.

> This looks to me like building a GUI. I think I did some of this ages ago
> (like 8 years) with Perl/Tk, but I gave up then.

In one sense, it's like some GUI schemes - create screens, create
widgets, set widgets...

Personally, I use Perl for my LCDproc scripts, but I think as an
example, an expect script is easier to follow.

-ethan

From hansfong at zonnet.nl  Fri Nov 14 04:32:36 2008
From: hansfong at zonnet.nl (hansfong at zonnet.nl)
Date: Fri, 14 Nov 2008 11:32:36 +0100
Subject: [Lcdproc] Clients for dummies!
In-Reply-To: <f4eb766f0811140200x366d6688o32dc4996d0aca7e9@mail.gmail.com>
References: <20081113230117.53av9c3nd7cckk8k@webmail.versatel.nl>
	<c0a09e5c0811131527h61e40a1fm3ffd02639a8f7632@mail.gmail.com>
	<20081114102134.ne63f4vi7go4wgks@webmail.versatel.nl>
	<f4eb766f0811140200x366d6688o32dc4996d0aca7e9@mail.gmail.com>
Message-ID: <20081114113236.rqoh61laha0wogwc@webmail.versatel.nl>

I guess Perl being the Swiss Army Knife of scripting languages will do 
the quickest job. But right now I try to limit myself (php and 
bash-scripting) in order not to get too confused.

Expect looks like the right tool for me right now. Will do some study 
on this. --Hans

> Personally, I use Perl for my LCDproc scripts, but I think as an
> example, an expect script is easier to follow.
>
> -ethan
>



From speedy_2k2 at hotmail.com  Sat Nov 15 09:44:41 2008
From: speedy_2k2 at hotmail.com (Speedy2k)
Date: Sat, 15 Nov 2008 10:44:41 -0500
Subject: [Lcdproc] Uptime Perl script?
Message-ID: <BAY106-DS4FF24947E501C9A87F05CE5110@phx.gbl>

What you guy's use to make a uptime script in perl, i'm using CentOS5 i would like to have like this:

D: "days" H: "hours" M: "minutes" S: "seconds"
Exemple.
D:10 H:05 M:15 S:10

And i have another question, i have a shell script that get my external IP, 
it look like that:

#!/bin/bash
curl -s http://www.whatismyip.com/automation/n09230945.asp

I don't know if i can incorporate it in my perl script without asking for an external script. if yes it would be really cool.

And i got a script to take my internal IP to:

#!/bin/bash
IP=`/sbin/ifconfig $1|gawk '/inet addr/{print $2}'|gawk -F: '{ORS="";print $2}'`
echo -n $IP


I would like to know if i can make those 2 scripts incorporated into my perl script so i will not need to call external files, and is there a way to ask for and IP refresh at about 2 hours interval, but make the uptime in real time? I'm really new to Perl scripting, but i love to make thing by myself, so if someone can give me a hand on this one it would be really appreciated thanx!


Here is my perl script so far i use it as a deamon.



#!/usr/bin/perl -w
use strict;
use POSIX qw( setsid );

my $debug = 1;
my $logfile = q(.testlog);

# Season to taste
my @fh_unused = (\*STDIN, \*STDOUT);

open \*STDERR, ">> $ENV{'HOME'}/$logfile";
select((select(\*STDERR), $| = 1)[0]);

{
# Daemon Rule 1) Fork and exit the parent.
    my $ppid = $$;
    my $pid = fork and exit 0;
    ! defined $pid and die "No Fork: ", $!;
    while (kill 0, $ppid) {
        select undef, undef, undef, .001;
    };
}

# Daemon Rule 2) become session leader, pg leader, no term
my $session_id = POSIX::setsid();

# Daemon Rule 3) cd to /
chdir '/' or die "Could not cd to rootfs", $!;

# Daemon Rule 4) set file creation mask to 0
my $oldmask = umask 00;

# Daemon Rule 5) Close unneeded file handles
close $_ or die $! for @fh_unused;
################################################################
sleep 20;
use IO::Socket;
use Fcntl;
use strict;
#
my $remote = IO::Socket::INET->new(
    Proto     => "tcp",
    PeerAddr  => "localhost",
    PeerPort  => 13666)|| die "Cannot connect to LCDd\n";
$remote->autoflush(1);
sleep 1; # give the server time to notice us...
print $remote "hello\n";
# we must read the response even if we ignore it:
my $lcdresponse = <$remote>;
# Turn off blocking mode...
fcntl($remote, F_SETFL, O_NONBLOCK);
# Set up some screen widgets...
print $remote "client_set name lcdtime\n";
#Screen_1
print $remote "screen_add scr1\n";
print $remote "widget_add scr1 str1 title\n";
print $remote "widget_add scr1 str2 string\n";
print $remote "widget_add scr1 str3 string\n";
print $remote "widget_add scr1 str4 string\n";
#Screen_2
#print $remote "screen_add scr2\n";
#print $remote "widget_add scr2 str1 title\n";
#print $remote "widget_add scr2 str2 string\n";
#print $remote "widget_add scr2 str3 string\n";
#print $remote "widget_add scr2 str4 string\n";

my $date;
my @ltime = localtime;
my $ystart = sprintf("%04d", 1900+$ltime[5]);
my $mstart = sprintf("%02d", $ltime[4]+1);
my $jstart = sprintf("%02d", $ltime[3]); 
my $hstart = sprintf("%02d", $ltime[2]);
my $minstart = sprintf("%02d", $ltime[1]);
my $yup;
my $mup;
my $jup;
my $hup;
my $minup;
my $minnow;
my $extip = `/usr/local/sbin/getextip.sh`;
my $intip = `/usr/local/sbin/getip.sh eth0`;
my $vpnip = `/usr/local/sbin/getip.sh ham0`;
while(1)
{
    $lcdresponse = <$remote>;
    #$date = scalar localtime; # this is 24 char long. The following is bettter:
    @ltime = localtime;
    #return a date in yyyy-mm-dd hh:mm format
    $date = sprintf("%04d-%02d-%02d %02d:%02d",
          1900+$ltime[5],$ltime[4]+1,$ltime[3],$ltime[2],$ltime[1],$ltime[0]);
####Seter les variable du timer.
    $yup = sprintf("%04d", 1900+$ltime[5]) - $ystart;
    $mup = sprintf("%02d", $ltime[4]+1) - $mstart;
    $jup = sprintf("%02d", $ltime[3]) - $jstart; 
    $hup = sprintf("%02d", $ltime[2]) - $hstart;
    $minup = sprintf("%02d", $ltime[1]) - $minstart;
    $minnow = sprintf("%02d", $ltime[1]);
####Uptime
    
####Screen 1 Widgets
    print $remote "widget_set scr1 str1 \"FullIP PBX\"\n";
    print $remote "widget_set scr1 str2 1 2 \"$date\"\n";
    print $remote "widget_set scr1 str4 1 4 \"A:$yup M:$mup J:$jup H:$hup M:$minup\"\n";
####Screen 2 Widgets
#    print $remote "widget_set scr2 str1 \"Info. Reseau.\"\n";
#    print $remote "widget_set scr2 str2 1 2 \"LAN: $intip\"\n";
#    print $remote "widget_set scr2 str3 1 3 \"WAN: $extip\"\n";
#    print $remote "widget_set scr2 str4 1 4 \"VPN: $vpnip\"\n";
####Screen Printing
    print "@ltime\n";  
    print "$date\n";  
    print "VPN:$vpnip\n";
    print "Local:$intip\n";
    print "WAN:$extip\n";
    print "A:$yup M:$mup J:$jup H:$hup M:$minup\n";
    print "minstart: $minstart\n";
    print "minnow:   $minnow\n";

    sleep 10;
}



exit 0;










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

From allsorts at howhill.com  Sat Nov 15 16:06:32 2008
From: allsorts at howhill.com (Dave Liquorice)
Date: Sat, 15 Nov 2008 22:06:32 +0000 (GMT)
Subject: [Lcdproc] Uptime Perl script?
In-Reply-To: <BAY106-DS4FF24947E501C9A87F05CE5110@phx.gbl>
Message-ID: <mailman.1.1226786833.17297.lcdproc@lists.omnipotent.net>

On Sat, 15 Nov 2008 10:44:41 -0500, Speedy2k wrote:

> What you guy's use to make a uptime script in perl, i'm using CentOS5 

http://www.centos.org/docs/5/html/5.1/Deployment_Guide/s2-proc-uptime.html




From g.r.vansickle at worldnet.att.net  Sat Nov 15 17:55:22 2008
From: g.r.vansickle at worldnet.att.net (Gary R. Van Sickle)
Date: Sat, 15 Nov 2008 17:55:22 -0600
Subject: [Lcdproc] LCDd, inetd,
	and Archeology (was: RE:  Clients for dummies!)
In-Reply-To: <20081114102134.ne63f4vi7go4wgks@webmail.versatel.nl>
References: <20081113230117.53av9c3nd7cckk8k@webmail.versatel.nl><c0a09e5c0811131527h61e40a1fm3ffd02639a8f7632@mail.gmail.com>
	<20081114102134.ne63f4vi7go4wgks@webmail.versatel.nl>
Message-ID: <B7042EFB8C804B0CBB245B258340E998@DFW5RB41>

> From: hansfong
>
> Citeren Andrew Grover :
> 
> > Look at the LCDd manpage. The client protocol is human-readable, so 
> > you can use whatever language you want to telnet to localhost port
> > 13666 and send commands.
> 
> Isn't that a bit archaic? I haven't been using telnet for 
> ages and I thought the use of telnet was depreciated.
> 

That was my thought when I first found that out when writing my own client.
Now, archaicness in-and-of-itself isn't necessarily a problem (or none of us
would be using *nix!), but what is a problem is LCDd's run-time dependency
on inetd.  Is there a reason why LCDproc doesn't use unix domain sockets or
named pipes or something else a little more local?

There are two primary use cases for LCDproc:

1.  As a secondary display for some local system state information (or
equivalently, some non-local state that has been obtained through other
means and made local):
	- Audaproc
	- hddtemp-lcd
	- amulestats
	- lcd-stuff
	- lcdvc
	- log4j
	- Zinf
	- lcd-nut
	- lcdwho
	- Tim Niemueller's SETI at home stats client
	- RC5 Stats Client
	- imonlcd

2.  As a primary display for "headless" and embedded systems:
	- IRMP3
	- VDR
	- netLCDclient
	- MP3SB (FWICT anyway)
	- My application (a carputer)

I don't really consider the situation where LCDd is connected to by some
outside agent over the network as a real use case.  Just because one can do
a thing doesn't mean it makes much sense, and in this case the ability to do
this is more of a side-effect of the implementation that anything else.  If
this is intended to be a real use case, sending the info over the internet
in-the-clear via telnet is probably not the best choice of IPC here either.

In the situations described in #1 above, it is probably largely immaterial
how LCDproc client-server communications happen, whether it be telnet,
sockets, named pipes, smoke signals, or whatever, since the systems in
question will often have a full-on networking stack running anyway.  Still,
why introduce a dependency when you don't have to?

In the #2 cases it does become a significant issue.  In the dedicated
MP3/PVR/many-other-embedded-application role, time-to-boot is a primary
concern, and the system may not even have any network connectivity.
Requiring inetd to be installed and having to wait for it load and figure
out there's no CAT-5 for it to look at, just so I can talk to my 20x4 LCD,
is clearly wasteful.

In order to be all things to all people, It Would Be Nice(tm) if LCDproc had
an architecture more like this:

LCDd <-some_local_IPC_protocol-> telnet_interface_client_d
<-current_LCDproc_client_language->
current_LCDproc_clients_which_use_the_telnet_interface
     <-some_local_IPC_protocol->
new_LCDproc_client_with_no_need_for_telnet_1
     <-some_local_IPC_protocol->
new_LCDproc_client_with_no_need_for_telnet_2

-- 
Gary R. Van Sickle



From w_smith at compusmiths.com  Sun Nov 16 07:33:55 2008
From: w_smith at compusmiths.com (William P.N. Smith)
Date: Sun, 16 Nov 2008 08:33:55 -0500
Subject: [Lcdproc] Uptime Perl script?
In-Reply-To: <BAY106-DS4FF24947E501C9A87F05CE5110@phx.gbl>
References: <BAY106-DS4FF24947E501C9A87F05CE5110@phx.gbl>
Message-ID: <49202143.80103@compusmiths.com>

I've just done some stuff similar to this...

Speedy2k wrote:
> What you guy's use to make a uptime script in perl, i'm using CentOS5 i 
> would like to have like this:
>  
> D: "days" H: "hours" M: "minutes" S: "seconds"
> Exemple.
> D:10 H:05 M:15 S:10

#!/usr/bin/perl -w
use strict;

my $CommandString = "uptime";
my $result = `$CommandString`;
printf ("%s\n",$result);

[The string manipulation to get the desired format is left as an
exercise for the student.  8*]

> And i have another question, i have a shell script that get my external IP,
> it look like that:
>  
> /#!/bin/bash/
> /curl -s //http://www.whatismyip.com/automation/n09230945.asp/

require "SimpleGet.pl";
my $GetString = "http://www.whatismyip.com/automation/n09230945.asp";
my $response = get("$GetString");
printf("%s\n\n",$response);

Note that you don't want the trailing slash on ...asp/

You can find SimpleGet.pl on Google

You can also use LWP, but that's overkill for this application.

If you hit them too often (more than about every 5 minutes?) you'll get 
no response or 'service unavailable'

> And i got a script to take my internal IP to:
>  
> /#!/bin/bash
> IP=`/sbin/ifconfig $1|gawk '/inet addr/{print $2}'|gawk -F: 
> '{ORS="";print $2}'`
> echo -n $IP/

Something like the first code fragment again, so:

$CommandString="/sbin/ifconfig $1|gawk '/inet addr/{print $2}'|gawk -F: 
  '{ORS="";print $2}'";
$result = `$CommandString`;
printf ("%s\n",$result);

EXCEPT that doesn't compile, because of the double quotes, and you need 
to escape them, but I'm not certain how...

Enjoy!


From meduzapat at gmail.com  Sun Nov 16 13:18:19 2008
From: meduzapat at gmail.com (MeduZa)
Date: Sun, 16 Nov 2008 14:18:19 -0500
Subject: [Lcdproc] My LCD client project
Message-ID: <492071FB.1030103@netscape.net>

Hello, my name is Patricio and I'm new in this community, but I use 
LCDproc for at last 2 years, I have a 40x4 LCD and I started working in 
my own LCDd client in C++.
This client will show system statics, and any information that the user 
need to show, will support plugins to add more features.
Right now I have the alpha state working for the demon part of the 
project and it works really nice, but is too alpha.
Demon right now connects to LCDd, Loads screens and widgets (in a very 
testing but working way), prints the information on screen, keeps track 
of refresh, and manages refresh of information, keeps track when we are 
on screen or not and a few things more.
The program has two parts, a demon and a GUI, the GUI (project starts 
but doesn't do any useful work yet) will allow the user to create their 
screens and widgets with no problem, and in a easy way without the need 
to learn the LCDd language.

The alpha demon can show any system information right now from the 
system plugins:
This is the nearly finished first plugin with the system information:
Time and Date in all posible ways, including big numbers Status: 100% 
Completed
cpu usage (total and all posible CPUs) Status: 100% Completed
cpu information (for Any CPU: Model, Vendor, Speed, Current Speed) 
Status: 20% Complete
memory usage (total free used and %) Status: 100% Completed
swap usage (like memory) Status: 100% Completed
kernel information (name, vercion, arquitecture) Status: 100% Completed
OS info (name, vercion) Status: 100% Completed
System Stats (uptime, load 1 5 15, load %, Hostname, process: total, 
running, sleeping, stoped, zombie) Status: 95% Completed
Users Info (users conected, total users, current user) Status: 100% 
Completed
Hard Drive (Name, Vendor Label, Temperature) Status: 5% Complete
Partitions Information (Mount, Size, Free, Used, %) Status: not started yet
Network Stats (Interface, Error, Recv erros, Recv Total, Recv Max, Recv 
%,Recv kb/s, Send errors, Send Total, Send Max. Send %, Send kb/s) 
Status: not started yet
Calendar (some calendar ideas I have on paper) Status: not started yet

Also I'm working on this plugins:
Audacious
LM-Sensors Status: 5% Complete
Weather

But there are a lot of ideas in paper.
**

From w_smith at compusmiths.com  Sun Nov 16 19:17:01 2008
From: w_smith at compusmiths.com (William P.N. Smith)
Date: Sun, 16 Nov 2008 20:17:01 -0500
Subject: [Lcdproc] My LCD client project
In-Reply-To: <492071FB.1030103@netscape.net>
References: <492071FB.1030103@netscape.net>
Message-ID: <4920C60D.4030007@compusmiths.com>

MeduZa wrote:
[lots of great progress on a 4x40 LCD driver]

> Also I'm working on this plugins:
> Audacious
> LM-Sensors Status: 5% Complete
> Weather

I'm (going to be) displaying weather data from my own weather station on 
my PicoLCD once I get a little further along and the drivers gell...

Is there a "standard" weather format that I should follow, or that other 
weather sources use, so I can be closer to a standard (and re-use my 
code for other weather sources), or should I just write what I want to 
the display?


From meduzapat at gmail.com  Sun Nov 16 19:51:19 2008
From: meduzapat at gmail.com (Patricio Rossi)
Date: Sun, 16 Nov 2008 20:51:19 -0500
Subject: [Lcdproc] My LCD client project
In-Reply-To: <4920C60D.4030007@compusmiths.com>
References: <492071FB.1030103@netscape.net> <4920C60D.4030007@compusmiths.com>
Message-ID: <4920CE17.8010304@gmail.com>

Hello William, I don't started yet the weather's plugin, but the idea is 
to access some information sources (best ones), and set the preferences 
on a configuration file or something like that, really I don't know how 
to access that information yet
Right now I'm working to fix minor bugs, finish necessary things like 
basic plugins to leave the demon in working and usefull conditions but 
in the future we can work together to finish the weather stuff ;)

I uploaded 1 testing vercion to the proyect page
https://sourceforge.net/project/showfiles.php?group_id=242109&package_id=294735

proyect page:
https://sourceforge.net/projects/lcdspicer/

William P.N. Smith wrote:
> MeduZa wrote:
> [lots of great progress on a 4x40 LCD driver]
>
>> Also I'm working on this plugins:
>> Audacious
>> LM-Sensors Status: 5% Complete
>> Weather
>
> I'm (going to be) displaying weather data from my own weather station 
> on my PicoLCD once I get a little further along and the drivers gell...
>
> Is there a "standard" weather format that I should follow, or that 
> other weather sources use, so I can be closer to a standard (and 
> re-use my code for other weather sources), or should I just write what 
> I want to the display?
>
>

From andy.grover at gmail.com  Mon Nov 17 00:03:35 2008
From: andy.grover at gmail.com (Andrew Grover)
Date: Sun, 16 Nov 2008 22:03:35 -0800
Subject: [Lcdproc] LCDd, inetd,
	and Archeology (was: RE: Clients for dummies!)
In-Reply-To: <B7042EFB8C804B0CBB245B258340E998@DFW5RB41>
References: <20081113230117.53av9c3nd7cckk8k@webmail.versatel.nl>
	<c0a09e5c0811131527h61e40a1fm3ffd02639a8f7632@mail.gmail.com>
	<20081114102134.ne63f4vi7go4wgks@webmail.versatel.nl>
	<B7042EFB8C804B0CBB245B258340E998@DFW5RB41>
Message-ID: <c0a09e5c0811162203y3a56b5a3v13a2ca8096bc416e@mail.gmail.com>

On Sat, Nov 15, 2008 at 3:55 PM, Gary R. Van Sickle
<g.r.vansickle at worldnet.att.net> wrote:
>> Isn't that a bit archaic? I haven't been using telnet for
>> ages and I thought the use of telnet was depreciated.
>>
>
> That was my thought when I first found that out when writing my own client.
> Now, archaicness in-and-of-itself isn't necessarily a problem (or none of us
> would be using *nix!), but what is a problem is LCDd's run-time dependency
> on inetd.  Is there a reason why LCDproc doesn't use unix domain sockets or
> named pipes or something else a little more local?

Just because you can use telnet to access lcdproc shouldn't mean that
telnet's archaicness should rub off on lcdproc. It's just a text-based
tcp stream, like http, smtp, or whatever. You could tunnel it over ssh
if you want but I'm sure it was simply why *not* use AF_INET instead
of AF_UNIX? Doesn't hurt, and you get remote clients "for free".

(^^^Complete speculation -- lcdproc has been around for a long time
and I'm a newb, FWIW.)

BTW I don't see a dependency on inetd. If you intend to always have
the lcdproc server running then you can remove inetd and start LCDd
directly.

> In order to be all things to all people, It Would Be Nice(tm) if LCDproc had
> an architecture more like this:
>
> LCDd <-some_local_IPC_protocol-> telnet_interface_client_d
> <-current_LCDproc_client_language->
> current_LCDproc_clients_which_use_the_telnet_interface
>     <-some_local_IPC_protocol->
> new_LCDproc_client_with_no_need_for_telnet_1
>     <-some_local_IPC_protocol->
> new_LCDproc_client_with_no_need_for_telnet_2

It would be trivial to enhance lcdproc to optionally use AF_UNIX. But
then clients would also have to know to try to use it.

However, I do agree that most usage is local. Some areas for
improvement I've been thinking about are some way to make it really
easy to get periodically-updated info on the LCD, maybe using a pull
model. It seems like there are a bunch of clients written in C, Ruby,
Python, etc, so you end up with a bunch of client processes running --
for some types of screens it might make more sense to run a client
periodically for updates instead of requiring it to always be running.
But that would require a different client interface, just like your
proposal.

Regards -- Andy

From joris at robijn.net  Mon Nov 17 02:58:55 2008
From: joris at robijn.net (joris at robijn.net)
Date: Mon, 17 Nov 2008 09:58:55 +0100 (CET)
Subject: [Lcdproc] My LCD client project
In-Reply-To: <4920C60D.4030007@compusmiths.com>
Message-ID: <20081117085856.30D7B1C9DB6@wizard.robijn.net>

> Is there a "standard" weather format that I should follow, or that other 
> weather sources use, so I can be closer to a standard (and re-use my 

Hi,

There is standard called METAR you you might want to follow. There is a
lcdproc metar client avaialable somewhere, that you could use to read
your own wheather station's data...

Joris


From allsorts at howhill.com  Mon Nov 17 03:20:58 2008
From: allsorts at howhill.com (Dave Liquorice)
Date: Mon, 17 Nov 2008 09:20:58 +0000 (GMT)
Subject: [Lcdproc] My LCD client project
In-Reply-To: <20081117085856.30D7B1C9DB6@wizard.robijn.net>
Message-ID: <mailman.2.1226913700.17297.lcdproc@lists.omnipotent.net>

On Mon, 17 Nov 2008 09:58:55 +0100 (CET), joris at robijn.net wrote:

> There is standard called METAR you you might want to follow. There is a
> lcdproc metar client avaialable somewhere, 

METAR is the standard for the dissmenation of weather information around the 
globe via the 'net or RTTY etc but I don't know of any weather stations(*) 
that output a METAR data stream.

(*) From the likes of Davis, Oregon Scientific and others. They tend to use 
their own protocols for the station > computer interface. Some of these are 
available on the net with 3rd party software available, others are closed. I 
think the Davis kit falls into the closed category, there is some 3rd party 
software for Davis kit but the authors sign NDAs to get the protocol.



From meduzapat at gmail.com  Mon Nov 17 03:30:03 2008
From: meduzapat at gmail.com (Patricio Rossi)
Date: Mon, 17 Nov 2008 04:30:03 -0500
Subject: [Lcdproc] My LCD client project
In-Reply-To: <49213789.0917400a.14dc.75a2SMTPIN_ADDED@mx.google.com>
References: <49213789.0917400a.14dc.75a2SMTPIN_ADDED@mx.google.com>
Message-ID: <4921399B.7020403@gmail.com>

People normally parce the information from web pages or RSS, I'll use 
that way maybe!!

Dave Liquorice wrote:
> On Mon, 17 Nov 2008 09:58:55 +0100 (CET), joris at robijn.net wrote:
>
>    
>> There is standard called METAR you you might want to follow. There is a
>> lcdproc metar client avaialable somewhere,
>>      
>
> METAR is the standard for the dissmenation of weather information around the
> globe via the 'net or RTTY etc but I don't know of any weather stations(*)
> that output a METAR data stream.
>
> (*) From the likes of Davis, Oregon Scientific and others. They tend to use
> their own protocols for the station>  computer interface. Some of these are
> available on the net with 3rd party software available, others are closed. I
> think the Davis kit falls into the closed category, there is some 3rd party
> software for Davis kit but the authors sign NDAs to get the protocol.
>
>
> _______________________________________________
> LCDproc mailing list
> LCDproc at lists.omnipotent.net
> http://lists.omnipotent.net/mailman/listinfo/lcdproc
>
>    

From ethan.dicks at gmail.com  Mon Nov 17 03:36:44 2008
From: ethan.dicks at gmail.com (Ethan Dicks)
Date: Mon, 17 Nov 2008 22:36:44 +1300
Subject: [Lcdproc] My LCD client project
In-Reply-To: <20081117085856.30D7B1C9DB6@wizard.robijn.net>
References: <4920C60D.4030007@compusmiths.com>
	<20081117085856.30D7B1C9DB6@wizard.robijn.net>
Message-ID: <f4eb766f0811170136w27866feeje22bbb0cec50270@mail.gmail.com>

On Mon, Nov 17, 2008 at 9:58 PM,  <joris at robijn.net> wrote:
>> Is there a "standard" weather format that I should follow, or that other
>> weather sources use, so I can be closer to a standard (and re-use my
>
> Hi,
>
> There is standard called METAR you you might want to follow. There is a
> lcdproc metar client avaialable somewhere, that you could use to read
> your own wheather station's data...

I've worked on Geo::METAR.  The latest version should handle non-US
temps/distances/etc., but the years-old version handles US sites
pretty well.

Metars are a method of transmitting observations - it's a highly-coded
method (thus the use of Geo::METAR) of describing temps, winds,
precipitation, and "special" comments.  There's already a client for
grabbing Metars for established stations, and I've tweaked on it quite
a bit to handle non-US locations, but still have a bit of work to make
it sharable.

If you want to create an output stream that others can read (manually
or with something like Geo::METAR), Metars are a known format for
publishing formatted weather data.  If you are just trying to format
your own local data for LCDproc, it's probably overkill.

-ethan

From allsorts at howhill.com  Mon Nov 17 09:26:26 2008
From: allsorts at howhill.com (Dave Liquorice)
Date: Mon, 17 Nov 2008 15:26:26 +0000 (GMT)
Subject: [Lcdproc] My LCD client project
In-Reply-To: <4921399B.7020403@gmail.com>
Message-ID: <mailman.3.1226935627.17297.lcdproc@lists.omnipotent.net>

On Mon, 17 Nov 2008 04:30:03 -0500, Patricio Rossi wrote:

> People normally parce the information from web pages or RSS, I'll use 
> that way maybe!!

That is one way and there are sites that will send back just the METAR of 
the station you ask for. IIRC the existing client (that was in the LCDProc 
package) does just that. That doesn't help with getting your own, 
propritary, weather station data displayed.



From hansfong at zonnet.nl  Mon Nov 17 15:18:18 2008
From: hansfong at zonnet.nl (hansfong at zonnet.nl)
Date: Mon, 17 Nov 2008 22:18:18 +0100
Subject: [Lcdproc] modifying tail.pl
Message-ID: <20081117221818.npfxay857zwkc88g@webmail.versatel.nl>

Quick question:

I am studying different client solutions after my previous post 
(Clients for dummies). I started out with the tail.pl client which came 
with lcdproc to see if I should revive my ancient Perl knowledge. What 
I can't figure out is....

the first line displays the filename and scrolls to and fro, the other 
three display the last three lines from the file. How to disable the 
first line and show the last four lines of the file?

Cheers,

Hans

From rw at nelianur.org  Tue Nov 18 18:44:49 2008
From: rw at nelianur.org (Rene Wagner)
Date: Wed, 19 Nov 2008 01:44:49 +0100
Subject: [Lcdproc] SourceForge.net Admin Privileges
Message-ID: <1227055489.4078.20.camel@antarctica.nelianur.org>

Hi all,

on Peter Marschall's request I've granted him administrative privileges
for the SourceForge.net LCDproc project. It took me longer than it should
have, so I'd like to apologize for any inconveniences the delay may have
caused.

Keep up the good work!

Cheers,

Rene


From jarod at wilsonet.com  Tue Nov 18 22:50:01 2008
From: jarod at wilsonet.com (Jarod Wilson)
Date: Tue, 18 Nov 2008 23:50:01 -0500
Subject: [Lcdproc] iMon LCD device support
In-Reply-To: <gfh12j$l6f$1@ger.gmane.org>
References: <1226337264.7789.14.camel@xavier.wilsonet.com>
	<gfh12j$l6f$1@ger.gmane.org>
Message-ID: <1227070201.3307.6.camel@icarus.wilsonet.com>

On Thu, 2008-11-13 at 02:55 -0800, David W Studeman wrote:
> Jarod Wilson wrote:
> > Hi folks,
> >
> > I'm new to the list, only just last week got an LCD device to play with.
> > What I got was the Antec Veris Multimedia Station Premiere[1], which is
> > a rebadged SoundGraph iMon UltraBay (with a different usb device ID).
[...]
> I thought your name was familiar, I use MythDora myself and in 2007 
> offered up an imon patched lirc driver set to Dennis in the MD4 days.
> Most of what you see in these articles is related to getting Lirc 
> patched and running the remote. The Lcd or VFD portion of it should have 
> nothing at all to do with kernel drivers or lirc for that matter.

The lirc driver sets up the /dev/lcdX device. Can also be done via a
stand-alone display-only driver, as I understand it.

> In 
> fact, while mixing on and off topic here anyway, I hated the imon remote 
> so much I changed to a new rf remote and just left lcdproc to drive the 
> display which is likely hd44780 compatible anyway like 99% of the 
> character displays out there and set up lirc for the new remote. Once 
> you get the mousepad working, you'll scream obscenities at it sometimes 
> because it's overly sensitive but you do need four axis control on a 
> remote to enjoy MythTV without using the keyboard. If I knew then what I 
> know now about displays and remotes, I would have not bought an 
> expensive Imon setup to only have a 16x2 display and a remote I 
> abandoned anyway. A 20x4 VFD or LCD will fit in the same window.

I only bought the thing to help get it and others like it working w/lirc
and lcdproc w/o any patching, its only in a test box. :)

But yes, the remote is far from optimal, I have several I like better.

--jarod



From avionicsdv at aim.com  Wed Nov 19 04:59:33 2008
From: avionicsdv at aim.com (David W Studeman)
Date: Wed, 19 Nov 2008 02:59:33 -0800
Subject: [Lcdproc] iMon LCD device support
In-Reply-To: <1227070201.3307.6.camel@icarus.wilsonet.com>
References: <1226337264.7789.14.camel@xavier.wilsonet.com>	<gfh12j$l6f$1@ger.gmane.org>
	<1227070201.3307.6.camel@icarus.wilsonet.com>
Message-ID: <gg0rin$2m1$1@ger.gmane.org>

Jarod Wilson wrote:
> On Thu, 2008-11-13 at 02:55 -0800, David W Studeman wrote:
>> Jarod Wilson wrote:
>>> Hi folks,
>>>
>>> I'm new to the list, only just last week got an LCD device to play with.
>>> What I got was the Antec Veris Multimedia Station Premiere[1], which is
>>> a rebadged SoundGraph iMon UltraBay (with a different usb device ID).
> [...]
>> I thought your name was familiar, I use MythDora myself and in 2007
>> offered up an imon patched lirc driver set to Dennis in the MD4 days.
>> Most of what you see in these articles is related to getting Lirc
>> patched and running the remote. The Lcd or VFD portion of it should have
>> nothing at all to do with kernel drivers or lirc for that matter.
>
> The lirc driver sets up the /dev/lcdX device. Can also be done via a
> stand-alone display-only driver, as I understand it.

  Ok, now I remember that. Basically most who use one of these solutions 
will use both the remote and lcd/vfd functions of it anyway. Makes sense 
now.

>
>> In
>> fact, while mixing on and off topic here anyway, I hated the imon remote
>> so much I changed to a new rf remote and just left lcdproc to drive the
>> display which is likely hd44780 compatible anyway like 99% of the
>> character displays out there and set up lirc for the new remote. Once
>> you get the mousepad working, you'll scream obscenities at it sometimes
>> because it's overly sensitive but you do need four axis control on a
>> remote to enjoy MythTV without using the keyboard. If I knew then what I
>> know now about displays and remotes, I would have not bought an
>> expensive Imon setup to only have a 16x2 display and a remote I
>> abandoned anyway. A 20x4 VFD or LCD will fit in the same window.
>
> I only bought the thing to help get it and others like it working w/lirc
> and lcdproc w/o any patching, its only in a test box. :)
>
> But yes, the remote is far from optimal, I have several I like better.
>
> --jarod

  Great idea. I can see no reason why the changes should not be upstream 
if it benefits nearly everyone who uses the source anyway. Even at that, 
having to add the tools necessary for compiling on one's daily MythTV 
box just to be able to patch and recompile is not really ideal either.

  Btw, I haven't read your book yet but of course when I was new to 
Myth, much of my self help googling turned up your book and where to buy 
as well as your website which is very detailed, especially in the 
remotes.

-- 
Dave Studeman
http://www.raqcop.com


From hansfong at zonnet.nl  Wed Nov 19 16:16:44 2008
From: hansfong at zonnet.nl (hansfong at zonnet.nl)
Date: Wed, 19 Nov 2008 23:16:44 +0100
Subject: [Lcdproc] How to remove the title bar?
Message-ID: <20081119231644.frnu00rnvy0wks4w@webmail.versatel.nl>

I noticed that all the clients that come with lcdproc have a title bar 
enabled, which reduces the available space by one line. I'd like to use 
all four lines of my picoLCD. How is the title bar disabled and where? 
I've been working on tail.pl for 3 nights now and can't find out how. 
Please help.

Cheers,

Hans

p.s. I did disable the title widgets and added an fourth widget to 
display text.


#From tail.pl
# Set up some screen widgets...
print $remote "client_set name {$progname}\n";
$lcdresponse = <$remote>;
print $remote "screen_add tail\n";
$lcdresponse = <$remote>;
print $remote "screen_set tail name {Tail $filename}\n";
$lcdresponse = <$remote>;
#print $remote "widget_add tail title title\n";
#$lcdresponse = <$remote>;
#print $remote "widget_set tail title {Tail: $filename}\n";
#$lcdresponse = <$remote>;
print $remote "widget_add tail 1 string\n";
$lcdresponse = <$remote>;
print $remote "widget_add tail 2 string\n";
$lcdresponse = <$remote>;
print $remote "widget_add tail 3 string\n";
$lcdresponse = <$remote>;
print $remote "widget_add tail 4 string\n";
$lcdresponse = <$remote>;

My feeling is that there is something to be done in the following 
section of tail.pl

	    # Now, display that text...
	    for (my $i = 0; $i < $lines; $i++) {
		my $j = $i + 1;
		my $k = $i + 2;

		# Avoid blank lines
		my $line = ($#lines < $i) ? " " : $lines[$i];
		$line = " "  if ($line =~ /^\s*$/o);

		print $remote "widget_set tail $j 1 $k {$line}\n";
		my $lcdresponse = <$remote>;
	    }

Any suggestions?

From jahathaway at gmail.com  Thu Nov 20 21:33:33 2008
From: jahathaway at gmail.com (Jeffrey Hathaway)
Date: Thu, 20 Nov 2008 22:33:33 -0500
Subject: [Lcdproc] mtc_16209x
Message-ID: <70febb430811201933q1490a8c1jc3be2a3162ea8f88@mail.gmail.com>

Where can i get this driver?  I have a gigabyte server and according to very
old mailing list archives, this is the driver i want however i do not have a
.so For it.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omnipotent.net/pipermail/lcdproc/attachments/20081120/45cffcdb/attachment.htm>

From peter at adpm.de  Sat Nov 22 09:42:42 2008
From: peter at adpm.de (Peter Marschall)
Date: Sat, 22 Nov 2008 16:42:42 +0100
Subject: [Lcdproc] mtc_16209x
In-Reply-To: <70febb430811201933q1490a8c1jc3be2a3162ea8f88@mail.gmail.com>
References: <70febb430811201933q1490a8c1jc3be2a3162ea8f88@mail.gmail.com>
Message-ID: <200811221642.42778.peter@adpm.de>

Hi,

On Friday, 21. November 2008, Jeffrey Hathaway wrote:
> Where can i get this driver?  I have a gigabyte server and according to
> very old mailing list archives, this is the driver i want however i do not
> have a .so For it.

Not all drivers are incuded in a default build.

You may need to build LCDproc yourself if the version you use now is from a 
distribution.

When you built LCDproc yourself, the command line 
	./configure --help
gives you information on how to add additional drivers and further compile 
time options.

Adding 
	--enable-drivers=mtc_s16209x 
to the ./configure command line should do the trick.

Regards
PEter

-- 
Peter Marschall
peter at adpm.de

From peter at adpm.de  Sat Nov 22 10:04:23 2008
From: peter at adpm.de (Peter Marschall)
Date: Sat, 22 Nov 2008 17:04:23 +0100
Subject: [Lcdproc] How to remove the title bar?
In-Reply-To: <20081119231644.frnu00rnvy0wks4w@webmail.versatel.nl>
References: <20081119231644.frnu00rnvy0wks4w@webmail.versatel.nl>
Message-ID: <200811221704.23907.peter@adpm.de>

Hi,

On Wednesday, 19. November 2008, hansfong at zonnet.nl wrote:
> I noticed that all the clients that come with lcdproc have a title bar
> enabled, which reduces the available space by one line. I'd like to use
> all four lines of my picoLCD. How is the title bar disabled and where?
> I've been working on tail.pl for 3 nights now and can't find out how.
> Please help.

The title bar n the default LCDproc clients can only be removed by
changing the clients' code.

In short, you need to
- remove the "title" widgets
- add appropriate widgets for the first line or
  move the other widgets up one line and 
  add appropriate widgets for the now fee last line
- adapt the logic that fills the widgets appropriately 

The excerpts in your mail contain only parts of tail.pl's code.
(BTW, copying the whole code is not ideal, sending universal diffs is
usuall better as it explicitly highlights what you changed)

But the excerpts show that you did the first two of the steps I outlined 
above, but the final step is missing.

Did you also change these variables at lines 53 & 54 ?

  my $top = 3;    # How far from the end of the file should we start?
  my $lines = 3;  # How many lines to display?

Then it should suffice to change line 196 appropriately, to get
the widgets in the right vertical position.

Regards
Peter

-- 
Peter Marschall
peter at adpm.de

From peter at adpm.de  Sat Nov 22 10:12:27 2008
From: peter at adpm.de (Peter Marschall)
Date: Sat, 22 Nov 2008 17:12:27 +0100
Subject: [Lcdproc] Uptime Perl script?
In-Reply-To: <BAY106-DS4FF24947E501C9A87F05CE5110@phx.gbl>
References: <BAY106-DS4FF24947E501C9A87F05CE5110@phx.gbl>
Message-ID: <200811221712.27820.peter@adpm.de>

Hi,

On Saturday, 15. November 2008, Speedy2k wrote:
> What you guy's use to make a uptime script 

What about lcdproc's TimeDate or Uptime screen ?

Regards
Peter
-- 
Peter Marschall
peter at adpm.de

From peter at adpm.de  Sat Nov 22 10:37:47 2008
From: peter at adpm.de (Peter Marschall)
Date: Sat, 22 Nov 2008 17:37:47 +0100
Subject: [Lcdproc] My LCD client project
In-Reply-To: <f4eb766f0811170136w27866feeje22bbb0cec50270@mail.gmail.com>
References: <4920C60D.4030007@compusmiths.com>
	<20081117085856.30D7B1C9DB6@wizard.robijn.net>
	<f4eb766f0811170136w27866feeje22bbb0cec50270@mail.gmail.com>
Message-ID: <200811221737.48244.peter@adpm.de>

Hi,

On Monday, 17. November 2008, Ethan Dicks wrote:
> On Mon, Nov 17, 2008 at 9:58 PM,  <joris at robijn.net> wrote:
> >> Is there a "standard" weather format that I should follow, or that other
> >> weather sources use, so I can be closer to a standard (and re-use my
> >
> > Hi,
> >
> > There is standard called METAR you you might want to follow. There is a
> > lcdproc metar client avaialable somewhere, that you could use to read
> > your own wheather station's data...
>
> I've worked on Geo::METAR.  The latest version should handle non-US
> temps/distances/etc., but the years-old version handles US sites
> pretty well.
>
> Metars are a method of transmitting observations - it's a highly-coded
> method (thus the use of Geo::METAR) of describing temps, winds,
> precipitation, and "special" comments.  There's already a client for
> grabbing Metars for established stations, and I've tweaked on it quite
> a bit to handle non-US locations, but still have a bit of work to make
> it sharable.
>
> If you want to create an output stream that others can read (manually
> or with something like Geo::METAR), Metars are a known format for
> publishing formatted weather data.  If you are just trying to format
> your own local data for LCDproc, it's probably overkill.

LCDproc already contains a client called lcdmetar.pl
that uses Geo::METAR.

Regards
Peter


-- 
Peter Marschall
peter at adpm.de

From peter at adpm.de  Sat Nov 22 11:00:52 2008
From: peter at adpm.de (Peter Marschall)
Date: Sat, 22 Nov 2008 18:00:52 +0100
Subject: [Lcdproc] LCDd, inetd,
	and Archeology (was: RE:  Clients for dummies!)
In-Reply-To: <B7042EFB8C804B0CBB245B258340E998@DFW5RB41>
References: <20081113230117.53av9c3nd7cckk8k@webmail.versatel.nl>
	<20081114102134.ne63f4vi7go4wgks@webmail.versatel.nl>
	<B7042EFB8C804B0CBB245B258340E998@DFW5RB41>
Message-ID: <200811221800.52363.peter@adpm.de>

Hi,

On Sunday, 16. November 2008, Gary R. Van Sickle wrote:
> That was my thought when I first found that out when writing my own client.
> Now, archaicness in-and-of-itself isn't necessarily a problem (or none of
> us would be using *nix!), but what is a problem is LCDd's run-time
> dependency on inetd.  Is there a reason why LCDproc doesn't use unix domain
> sockets or named pipes or something else a little more local?

Please don't disseminate false information.

	LCDproc does not depend on inetd.

How do you come to this observation.

> There are two primary use cases for LCDproc:
>
> 1.  As a secondary display for some local system state information (or
> equivalently, some non-local state that has been obtained through other
> means and made local):
> [ ...]
>
> 2.  As a primary display for "headless" and embedded systems:
> [ ...]
>
> I don't really consider the situation where LCDd is connected to by some
> outside agent over the network as a real use case.  Just because one can do
> a thing doesn't mean it makes much sense, and in this case the ability to
> do this is more of a side-effect of the implementation that anything else. 
> If this is intended to be a real use case, sending the info over the
> internet in-the-clear via telnet is probably not the best choice of IPC
> here either.

This is your personal opinion.
For me, the client-server architecture or LCDproc was the main reason to
use it and to develop for it.

What about having one display but multiple systems ?
E.g. a NSLU2 and another headless machine, both being on a trusted 
environment.

> [...]
>
> In order to be all things to all people, It Would Be Nice(tm) if LCDproc
> had an architecture more like this:
>
> LCDd <-some_local_IPC_protocol-> telnet_interface_client_d
> <-current_LCDproc_client_language->
> current_LCDproc_clients_which_use_the_telnet_interface
>      <-some_local_IPC_protocol->
> new_LCDproc_client_with_no_need_for_telnet_1
>      <-some_local_IPC_protocol->
> new_LCDproc_client_with_no_need_for_telnet_2

Sorry, this is too terse for me to understand.

I am aware that the current protocol has a lot of disadvantages:
- cleartext, not encrypted
  Yes, I want the network protocol ;-)
- no authentication
  This should be in a network protocol.
- widget commands could get some updates 
  Here are some of the things that I consider unfortunate:
  - the position of a widget should be determined when 
    defining it, so that when using it you do not need to
    tell where to position it
  - all widgets should have a size, that limits the output
  - bar widgets should give their length in percent / per mille
    instead of pixel columns
- ...

Unfortunately it is not possible to change it without breaking
compatibility with older clients.
That's why this will not happen within the 0.5.x series of
LCDproc.

Regards
Peter

-- 
Peter Marschall
peter at adpm.de

From peter at adpm.de  Sat Nov 22 11:11:36 2008
From: peter at adpm.de (Peter Marschall)
Date: Sat, 22 Nov 2008 18:11:36 +0100
Subject: [Lcdproc] picolcd build problems
In-Reply-To: <BAY123-W176B48FE7D417FEE09FD5EAC140@phx.gbl>
References: <BAY123-W433F16719746BD826A3CCBAC1A0@phx.gbl>
	<BAY123-W5324E0AD2916CA367D7CBDAC150@phx.gbl>
	<BAY123-W176B48FE7D417FEE09FD5EAC140@phx.gbl>
Message-ID: <200811221811.37053.peter@adpm.de>

On Wednesday, 12. November 2008, Peter Hollas wrote:
> Hi,
>
> After a bit of debugging, it appears that there the picolcd driver looks
> for LircHost= as a configuration parameter. However, in the /etc/LCDd.conf
> it is defined as LircAddress= and so Lirc UDP never gets switched on with
> the standard cvs config.
>
> Please could someone submit a correction to cvs.

Done.

Thanks for reporting the issue
Peter

-- 
Peter Marschall
peter at adpm.de

From peter at adpm.de  Sat Nov 22 11:15:43 2008
From: peter at adpm.de (Peter Marschall)
Date: Sat, 22 Nov 2008 18:15:43 +0100
Subject: [Lcdproc] LCDd on screen Display
In-Reply-To: <BAY106-DS23D8551D8F27336D20193E51E0@phx.gbl>
References: <BAY106-DS23D8551D8F27336D20193E51E0@phx.gbl>
Message-ID: <200811221815.43493.peter@adpm.de>

Hi,

On Thursday, 6. November 2008, Speedy2k wrote:
> Hi everybody, is it possible to start LCDd on a machine without any LCD
> device and just print the content on the host screen, because i'm building
> right now a production box, and i will need to program from out of my lab
> and the computer i have don'T have any LCD and i would like to be able to
> see my change in me laptop screen.

One of these drivers my fulfil your needs:
- text
- curses
- svga		
- xosd

Regards
Peter

-- 
Peter Marschall
peter at adpm.de

From hansfong at zonnet.nl  Sat Nov 22 12:14:55 2008
From: hansfong at zonnet.nl (hansfong at zonnet.nl)
Date: Sat, 22 Nov 2008 19:14:55 +0100
Subject: [Lcdproc] How to remove the title bar?
In-Reply-To: <200811221704.23907.peter@adpm.de>
References: <20081119231644.frnu00rnvy0wks4w@webmail.versatel.nl>
	<200811221704.23907.peter@adpm.de>
Message-ID: <20081122191455.p6fl2jb28wo0cosw@webmail.versatel.nl>

Hello Peter,

Thanks for taking the time to respond. I really appreciate it.

> Did you also change these variables at lines 53 & 54 ?

Yes, I changed them both to 4.

> Then it should suffice to change line 196 appropriately, to get
> the widgets in the right vertical position.

And this is where I don't understand the code in tail.pl. I can grasp 
how $i, $j and $k are used when setting up the widget. But then.....in 
the following loop:

	    # Now, display that text...
	    for (my $i = 0; $i < $lines; $i++) {
		my $j = $i + 1;
		my $k = $i + 2;

$i is 0, then gets compared to $lines and increased by 1. Then the 
initial value of $j is 2 and $k is 3. I guess this should be 1 and 2 
respectively to display four lines, but I can't figure out how to do 
this. I tried to change $i to -1, but that didn't work. Any ideas? 
Cheers,

Hans

From herdler at gmx.de  Sat Nov 22 14:52:15 2008
From: herdler at gmx.de (Stefan Herdler)
Date: Sat, 22 Nov 2008 21:52:15 +0100
Subject: [Lcdproc] SerialVFD update for BA63/BA66 VFD
Message-ID: <492870FF.6080204@gmx.de>

Hi,

I just want to point on a patch I sent to the list some time ago.
The Patch adds support of the BA63/BA66 VFD from Simens / Wincor-Nixdorf.

Link to the original Message:
http://lists.omnipotent.net/pipermail/lcdproc/2008-July/012253.html

Meanwhile I got some positive feedback, so I assume the driver works 
like it should do ;-) .

Regards
Stefan

From hansfong at zonnet.nl  Sat Nov 22 16:44:43 2008
From: hansfong at zonnet.nl (hansfong at zonnet.nl)
Date: Sat, 22 Nov 2008 23:44:43 +0100
Subject: [Lcdproc] How to remove the title bar?
In-Reply-To: <20081122191455.p6fl2jb28wo0cosw@webmail.versatel.nl>
References: <20081119231644.frnu00rnvy0wks4w@webmail.versatel.nl>
	<200811221704.23907.peter@adpm.de>
	<20081122191455.p6fl2jb28wo0cosw@webmail.versatel.nl>
Message-ID: <20081122234443.6id7ycnuo400o0oc@webmail.versatel.nl>

Hello,

Finally after hours of trying.....

>> Did you also change these variables at lines 53 & 54 ?
>
> Yes, I changed them both to 4.

But then I found out that this doesn't have any effect at all. Later 
the same variables are declared again, e.g. $top in line 119 and $lines 
in line 118 of the original tail.pl.

I declared the variables again just after line 188 and then it worked.

>> Then it should suffice to change line 196 appropriately, to get
>> the widgets in the right vertical position.

The trick was to change line 196:
my $k = $i + 1;  #this was changed from +2 to +1 in order to display on 
the first line of display.

Thanks for the hint.

I've got a nice modified script now which exactly suit my needs. My 
picoLCD 4x20 is up and running!!! Thanks everyone.

Hans

From hansfong at zonnet.nl  Sat Nov 22 16:54:18 2008
From: hansfong at zonnet.nl (hansfong at zonnet.nl)
Date: Sat, 22 Nov 2008 23:54:18 +0100
Subject: [Lcdproc] picoLCD 4x20 only 19 chars
Message-ID: <20081122235418.7xm7icotogwg4gwg@webmail.versatel.nl>

Not so fast....

I can only get 19 character displayed on my mini-box picoLCD 4x20. The 
last character on the first line shows three vertical lines (|||), on 
the other lines the last character is blank. This is already the case 
when I start the deamon, so it seems not a client problem. I'm using 
lcdproc which I downloaded from the mini-box website, which is version 
0.5.2. Any ideas?

Cheers,

Hans

From ethan.dicks at gmail.com  Sat Nov 22 18:33:14 2008
From: ethan.dicks at gmail.com (Ethan Dicks)
Date: Sun, 23 Nov 2008 13:33:14 +1300
Subject: [Lcdproc] picoLCD 4x20 only 19 chars
In-Reply-To: <20081122235418.7xm7icotogwg4gwg@webmail.versatel.nl>
References: <20081122235418.7xm7icotogwg4gwg@webmail.versatel.nl>
Message-ID: <f4eb766f0811221633qf364476i865b75b78227c34a@mail.gmail.com>

On Sun, Nov 23, 2008 at 11:54 AM,  <hansfong at zonnet.nl> wrote:
> Not so fast....
>
> I can only get 19 character displayed on my mini-box picoLCD 4x20. The last
> character on the first line shows three vertical lines (|||), on the other
> lines the last character is blank. This is already the case when I start the
> deamon, so it seems not a client problem. I'm using lcdproc which I
> downloaded from the mini-box website, which is version 0.5.2. Any ideas?

I can't check specifically since I'm traveling and don't have my
picoLCD with me, but I did fix and submit a bug with the driver for
the 2x20 months ago that very specifically fixed writing to the full
width.  I checked the CVS repository and I can't seem to find it.

In picoLCD_string(), I moved the line "x--; y--;" further up in the
routine, between the boundary checking and the string-length check,
IIRC.

If you compile with debugging on and start the server with debugging
turned up, you will probably see "%s: string overlength (>%d). Start:
%d Length: %d (%s)" errors when trying to display 20-char-long
strings.

I have a client I use for testing - it's really simple - open one
string widget for each line on the display, then fill each character
position with "X" and wait 30 seconds before quitting.  It helps me
find bugs like this, or with writing to the lower-right character
position (especially when writing new drivers and having to get
line-scrolling parameters correct).

I should tidy that client up and submit it - it's really not complex,
but it is very, very handy when debugging boundary conditions.

In any case, check your source for how picoLCD_string() goes - it's
probable that my last-char fix isn't in the codebase you are working
from.

-ethan

From peter at adpm.de  Sun Nov 23 06:47:18 2008
From: peter at adpm.de (Peter Marschall)
Date: Sun, 23 Nov 2008 13:47:18 +0100
Subject: [Lcdproc] mtc_16209x
In-Reply-To: <70febb430811220843n58ed8d9eyb0dda8b3d4c8408e@mail.gmail.com>
References: <70febb430811201933q1490a8c1jc3be2a3162ea8f88@mail.gmail.com>
	<200811221642.42778.peter@adpm.de>
	<70febb430811220843n58ed8d9eyb0dda8b3d4c8408e@mail.gmail.com>
Message-ID: <200811231347.18922.peter@adpm.de>

Hi,

please keep your replies on the list.
It is valuable information that may help others.

On Saturday, 22. November 2008, you wrote:
> I did do this and the display for my LCD on the gigabyte server still does
> nto work.  Any idea's?

Plese givbe more information on your system:
- HW
- OS
- configure output

Without some basic information, I fear nobody can give you more information

Regards
PEter
-- 
Peter Marschall
peter at adpm.de

From peter at adpm.de  Sun Nov 23 07:11:07 2008
From: peter at adpm.de (Peter Marschall)
Date: Sun, 23 Nov 2008 14:11:07 +0100
Subject: [Lcdproc] SerialVFD update for BA63/BA66 VFD
In-Reply-To: <492870FF.6080204@gmx.de>
References: <492870FF.6080204@gmx.de>
Message-ID: <200811231411.07888.peter@adpm.de>

Hi Stefan,

On Saturday, 22. November 2008, Stefan Herdler wrote:
> I just want to point on a patch I sent to the list some time ago.
> The Patch adds support of the BA63/BA66 VFD from Simens / Wincor-Nixdorf.
>
> Link to the original Message:
> http://lists.omnipotent.net/pipermail/lcdproc/2008-July/012253.html
>
> Meanwhile I got some positive feedback, so I assume the driver works
> like it should do ;-) .

sorry this flew below my radar back then.

Thanks for supporting LCDproc despite my lazyness/ignorance ;-)
Peter

-- 
Peter Marschall
peter at adpm.de

From andy at siliconlandmark.com  Sun Nov 23 09:06:48 2008
From: andy at siliconlandmark.com (Andre Guibert de Bruet)
Date: Sun, 23 Nov 2008 10:06:48 -0500
Subject: [Lcdproc] picoLCD 4x20 only 19 chars
In-Reply-To: <f4eb766f0811221633qf364476i865b75b78227c34a@mail.gmail.com>
References: <20081122235418.7xm7icotogwg4gwg@webmail.versatel.nl>
	<f4eb766f0811221633qf364476i865b75b78227c34a@mail.gmail.com>
Message-ID: <BE8BA262-D85C-49C9-81BD-D7DF00C62CAB@siliconlandmark.com>

On Nov 22, 2008, at 7:33 PM, Ethan Dicks wrote:

> On Sun, Nov 23, 2008 at 11:54 AM,  <hansfong at zonnet.nl> wrote:
>>
>> I can only get 19 character displayed on my mini-box picoLCD 4x20.  
>> The last
>> character on the first line shows three vertical lines (|||), on  
>> the other
>> lines the last character is blank. This is already the case when I  
>> start the
>> deamon, so it seems not a client problem. I'm using lcdproc which I
>> downloaded from the mini-box website, which is version 0.5.2. Any  
>> ideas?
>
> I can't check specifically since I'm traveling and don't have my
> picoLCD with me, but I did fix and submit a bug with the driver for
> the 2x20 months ago that very specifically fixed writing to the full
> width.  I checked the CVS repository and I can't seem to find it.
>
> In picoLCD_string(), I moved the line "x--; y--;" further up in the
> routine, between the boundary checking and the string-length check,
> IIRC.
>
> If you compile with debugging on and start the server with debugging
> turned up, you will probably see "%s: string overlength (>%d). Start:
> %d Length: %d (%s)" errors when trying to display 20-char-long
> strings.
>
> I have a client I use for testing - it's really simple - open one
> string widget for each line on the display, then fill each character
> position with "X" and wait 30 seconds before quitting.  It helps me
> find bugs like this, or with writing to the lower-right character
> position (especially when writing new drivers and having to get
> line-scrolling parameters correct).
>
> I should tidy that client up and submit it - it's really not complex,
> but it is very, very handy when debugging boundary conditions.
>
> In any case, check your source for how picoLCD_string() goes - it's
> probable that my last-char fix isn't in the codebase you are working
> from.


I can confirm the problem WRT the last character on each line. In  
fact, I was getting ready to report the issue myself.

Ethan - As far as your possible fix, I have not had the chance to give  
it a spin. I will report back when I do.

Hans - Does setting Heartbeat=off make those three vertical lines turn  
into a solid rectangle?

Cheers,

/*  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 peter at adpm.de  Sun Nov 23 12:09:57 2008
From: peter at adpm.de (Peter Marschall)
Date: Sun, 23 Nov 2008 19:09:57 +0100
Subject: [Lcdproc] How to remove the title bar?
In-Reply-To: <20081122234443.6id7ycnuo400o0oc@webmail.versatel.nl>
References: <20081119231644.frnu00rnvy0wks4w@webmail.versatel.nl>
	<20081122191455.p6fl2jb28wo0cosw@webmail.versatel.nl>
	<20081122234443.6id7ycnuo400o0oc@webmail.versatel.nl>
Message-ID: <200811231909.58424.peter@adpm.de>

Hi,

On Saturday, 22. November 2008, hansfong at zonnet.nl wrote:
> The trick was to change line 196:
> my $k = $i + 1;  #this was changed from +2 to +1 in order to display on
> the first line of display.
>
> Thanks for the hint.
>
> I've got a nice modified script now which exactly suit my needs. My
> picoLCD 4x20 is up and running!!! Thanks everyone.

After your mail I had a closer look at tail.pl which led to a few changes
which I committed this afternoon:
- reverse the up/down scrolling logic to match scrolling used 
  in viewers and editors
- make sure we have enough text widgets even on larger displays
- expand tabs to the correct number of spaces instead of showing 
  some strange character (depending on the display)
- added a few comments.

Hans,
if you make your patch run-time configurable (= a command line 
option) I think it can help the LCDproc distribution as well.

Regards
Peter

-- 
Peter Marschall
peter at adpm.de

From ethan.dicks at gmail.com  Sun Nov 23 15:15:51 2008
From: ethan.dicks at gmail.com (Ethan Dicks)
Date: Mon, 24 Nov 2008 10:15:51 +1300
Subject: [Lcdproc] My LCD client project
In-Reply-To: <f4eb766f0811231313p7d6bc5a9j3f9cf4a8cfaeadd5@mail.gmail.com>
References: <4920C60D.4030007@compusmiths.com>
	<20081117085856.30D7B1C9DB6@wizard.robijn.net>
	<f4eb766f0811170136w27866feeje22bbb0cec50270@mail.gmail.com>
	<200811221737.48244.peter@adpm.de>
	<f4eb766f0811231313p7d6bc5a9j3f9cf4a8cfaeadd5@mail.gmail.com>
Message-ID: <f4eb766f0811231315j5060bf6pe2680e181f3e2c4b@mail.gmail.com>

On Sun, Nov 23, 2008 at 5:37 AM, Peter Marschall <peter at adpm.de> wrote:
> On Monday, 17. November 2008, Ethan Dicks wrote:
>> On Mon, Nov 17, 2008 at 9:58 PM,  <joris at robijn.net> wrote:
>> > There is standard called METAR you you might want to follow. There is a
>> > lcdproc metar client avaialable somewhere, that you could use to read
>> > your own wheather station's data...
>>
>> I've worked on Geo::METAR.  The latest version should handle non-US
>> temps/distances/etc., but the years-old version handles US sites
>> pretty well.
>
> LCDproc already contains a client called lcdmetar.pl
> that uses Geo::METAR.

Yes there is, and it's a good start.  Because I spend lots of time
outside of the US, I've extended the current client, and worked with
two maintainers (present and original author) on the newest version of
the underlying Geo::METAR library.  On my personal to-do list is to
check my client changes against the current version of Geo::METAR on
CPAN before doing a little internal documentation clean-up, then I can
publish my updates to lcdmetar.pl.  I've been keeping an eye out for
the next version of LCDproc as a "deadline".

Back to the original poster, if you stick to US measurements (no
visibility in meters, for example), the older version of Geo::METAR
and the present version of lcdmetar.pl in the LCDproc clients
directory can give you an idea if Metar format will encompass what you
want to do - as I've said, it's not an ideal format for storing raw
weather data, but for sharing it with pilots or Met personnel, it's a
compact verbal format for summarizing your current observations.
Depending on what you are trying to do, you may find that it's easiest
to collect your raw data into "comma-separated value" (CSV) files that
can be easily read by Perl or most spreadsheet apps, then write a
simple CSV->Metar script in your favorite language (Perl, Python,
 Ruby...) to kick out one Metar per line of raw data.  This generated
Metar can be fed to lcdmeter.pl if your end-goal is to display your
weather observations on LCDproc.

Metars are fairly complex - real stations define all sorts of terms
(blowing snow, drifting snow, haze, dust storm, virga...) that an
amateur station is unlikely to use.  The good news is that Geo::METAR
knows well over 90% of the tokens in common usage, and all the tokens
you are likely to generate.

-ethan

From kokolist at gmail.com  Mon Nov 24 07:47:45 2008
From: kokolist at gmail.com (=?UTF-8?B?zpTOuc6xzrvOtc66z4TOriDOks6xzrvPg86szrzOv8+F?=)
Date: Mon, 24 Nov 2008 15:47:45 +0200
Subject: [Lcdproc] Non-Latin characters in LCDd.conf
Message-ID: <47da1bd90811240547r5373fb20ma9e624bd851a35e3@mail.gmail.com>

Hello,


I am trying to make my lcdproc work with some greek characters on an imon
lcd . For anyone unfamiliar with it, this LCD is not working with text, but
drawing on a grid of 6x8 per character. For more information please see
http://codeka.com/blogs/index.php/2007/09/26/imon_lcd_patch_v0_3?blog=5
Quote from the patch:

+/*
+ * The iMON LCD doesn't have a "text mode" -- everthing is pixel-based. So
we need to define
+ * our own font, basically. This structure holds the definition of that
font. The characters
+ * we define here are 6x8 pixels in size, each byte in the 'pixels' array
represents one column
+ * of pixels. The most significant bit is the top row, the least
significant bit is the bottom
+ * row.
+ */

Trying to produce my own greek fonts this way i took the simple example of
capital O
+        { 'O', { 0x0, 0x7C, 0x82, 0x82, 0x82, 0x7C } },
and produced
+        { '?', { 0x0, 0x7C, 0x92, 0x92, 0x92, 0x7C } },

Various tests have shown me that what I have done there, works. But  there
seems to be a big but: I can not include any greek letters in my LCDd.conf.
I have cross checked this by changing the code in pre-compile time to:

+        { 'O', { 0x0, 0x7C, 0x92, 0x92, 0x92, 0x7C } },
+        { '?', { 0x0, 0x7C, 0x92, 0x92, 0x92, 0x7C } },

so that both these characters are drawn like the letter ?.

and added a simple goodbye message in my LCDd.conf (my simple failsafe way
of testing this) that contained OOOO and ????. This resulted in only the
OOOO being printed (as ???? of course).
I was thinking that maybe the deamon expects its conf file to be in plain
english, so i wrote a small perl script that did quite the same (just in
case I was missing something)

All these tests of course only confirmed what most of you already know (and
my google searches had told me -but I was still hoping) : there is no way to
send non-latin characters to LCDproc and get them out alive, right?

Is there anything I am missing?

I am not a code expert but if someone feels like giving me a hint, maybe I
could take it one step further.


My problem is - just in case I didn't make myself clear (it happens when I
overthink)- that even though I have the ability to draw the desired
characters, they  get lost in translation :) How do I efficiently feed
LCDproc/myscreen with my non-static greek text ( I mean, it's not a static
menu that I can once and for all transcode) withouth using  a "wrapper"  for
any app that will be sending greek chars.

Any help will be greatly appreciated.

Also, though I should mention the note on the patch mentioned above:

The 'ch' member is an int so theoretically, you could
+         * specify UTF-32 code points as the ch. But then you'd have to
translate the UTF-8
+         * (or whatever) input to imonlcd_string to UTF-32, which doesn't
sound like much fun...

This "theoretically" part doesn't sound very promising,does it



Thank you very much in advance,


Dialecti
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omnipotent.net/pipermail/lcdproc/attachments/20081124/e9ae5f6f/attachment-0001.htm>

From aeriksson2 at fastmail.fm  Tue Nov 25 23:20:12 2008
From: aeriksson2 at fastmail.fm (aeriksson2 at fastmail.fm)
Date: Wed, 26 Nov 2008 06:20:12 +0100
Subject: [Lcdproc] Non-Latin characters in LCDd.conf
In-Reply-To: <47da1bd90811240547r5373fb20ma9e624bd851a35e3@mail.gmail.com>
References: <47da1bd90811240547r5373fb20ma9e624bd851a35e3@mail.gmail.com>
Message-ID: <20081126052013.022B633C01E@tippex.mynet.homeunix.org>


kokolist at gmail.com said:
> Is there anything I am missing?
> I am not a code expert but if someone feels like giving me a hint, maybe I
> could take it one step further. 

IIRC, the protocol LCDd exposes is ascii based and there is no provision for 
indicating charset used from a client. I'd assume that the daemon interpreses 
whatever you send (UTF8 I guess) as plain ascii, and asks the driver to render 
ascii glyphs.

Coming from Sweden, I'd like to have a solution for this too. It would be cool 
to be able to load fonts to the LCD just like you can for the regular console!

/Anders 




From ethan.dicks at gmail.com  Wed Nov 26 20:32:11 2008
From: ethan.dicks at gmail.com (Ethan Dicks)
Date: Thu, 27 Nov 2008 15:32:11 +1300
Subject: [Lcdproc] Non-Latin characters in LCDd.conf
In-Reply-To: <20081126052013.022B633C01E@tippex.mynet.homeunix.org>
References: <47da1bd90811240547r5373fb20ma9e624bd851a35e3@mail.gmail.com>
	<20081126052013.022B633C01E@tippex.mynet.homeunix.org>
Message-ID: <f4eb766f0811261832v7ee6321fo1890e9b477e40b3f@mail.gmail.com>

On Wed, Nov 26, 2008 at 6:20 PM,  <aeriksson2 at fastmail.fm> wrote:
>
> kokolist at gmail.com said:
>> Is there anything I am missing?
>> I am not a code expert but if someone feels like giving me a hint, maybe I
>> could take it one step further.
>
> IIRC, the protocol LCDd exposes is ascii based and there is no provision for
> indicating charset used from a client. I'd assume that the daemon interpreses
> whatever you send (UTF8 I guess) as plain ascii, and asks the driver to render
> ascii glyphs.
>
> Coming from Sweden, I'd like to have a solution for this too. It would be cool
> to be able to load fonts to the LCD just like you can for the regular console!

The overall problem with that is that LCDproc is firmly rooted in its
roots as an HD44780-based abstraction tool, and those sorts of
displays tend to have a small number (1-8) of user-definable
characters, with the rest of the characters and glyphs in onboard ROM.

I know the original poster is using a display which is effectively
bit-mapped, and I have a few displays that can do that (jw002, and
several true graphical LCDs), but most of what I have is stuck with
whatever the ROM character set is.  The jw002 is kinda nice in that it
presents itself to the server as a textual display, but internally
it's a graphical chip with an LCD layout that's character oriented
(there are voids between the 5x8 LCD cells).  What this means is that
there is a ROM character set (4 by default, actually) with many
glyphs, but once you write a glyph, you can change sets without
changing glyphs you've already written since they are in the bitmapped
memory.  It's the only display I know like it, so most are going to be
HD44780 or pure-graphical, I'd say.

One major issue with "font" support is that different models and
brands of HD44780-type displays have vastly different glyphs outside
of standard alphanumerics.  I have at least three types myself - LCD
w/Japanese Katakana, LCD w/European, and VFD w/Katakana, and I think
there are one or two more major types out there.

I have been able to use non-Roman ASCII glyphs by sending the "right"
8-bit code from the client (most notably for handling "degrees" from a
weather client), but since there is no character-set mapping, if I run
that same client on different displays, I get different results (the
VFD has a single-position glyph for 'degrees F' and 'degrees C', but
the other displays have a degree-looking mark that's either a
plosive-modifier for Kana or some sort of dot in the European set).
What I've done there is to have some internal options to select one of
four different ways of expressing "degrees", some 1-char-wide, some
2-chars wide).  It's messy, but given the way that LCDproc was
designed in the first place, I don't know of a way to do it across all
or most supported displays.

I've written another client to display Japanese vocabulary words using
the Katakana set that's on many HD44780s, but if you run the same
client on a display with European accented characters up at the top of
the character set, it's gibberish, and the client has no way to know
it.

Perhaps what's called for is a mechanism where at least the client can
query the server (and indirectly LCDd.conf) if a particular character
set is present.  That way, my Japanese vocabulary builder client could
know that you don't have a Japanese-friendly display up, or my weather
client could know which methods of indicating 'degrees' will display
correctly.

You'd still have to manually map your Greek or Swedish or Japanese
chars in your client from your native set to what an HD44780 supports
in ROM, but at least you'd be able to verify first that the mapping
you are doing will produce legible output.

If what I'm saying isn't clear, please speak up and I can share one of
these clients (written in Perl) to illustrate how I'm sending these
chars from the client.

-ethan

From hansfong at zonnet.nl  Fri Nov 28 08:44:17 2008
From: hansfong at zonnet.nl (hansfong at zonnet.nl)
Date: Fri, 28 Nov 2008 15:44:17 +0100
Subject: [Lcdproc] Non-Latin characters in LCDd.conf
In-Reply-To: <f4eb766f0811261832v7ee6321fo1890e9b477e40b3f@mail.gmail.com>
References: <47da1bd90811240547r5373fb20ma9e624bd851a35e3@mail.gmail.com>
	<20081126052013.022B633C01E@tippex.mynet.homeunix.org>
	<f4eb766f0811261832v7ee6321fo1890e9b477e40b3f@mail.gmail.com>
Message-ID: <20081128154417.ts0f9z4ldoe84004@webmail.versatel.nl>

Citeren Ethan Dicks <ethan.dicks at gmail.com>:

> The overall problem with that is that LCDproc is firmly rooted in its
> roots as an HD44780-based abstraction tool, and those sorts of
> displays tend to have a small number (1-8) of user-definable
> characters, with the rest of the characters and glyphs in onboard ROM.

Thank you Ethan for this excellent explanation. Now my question is: how 
do you know what characters are in the ROM and how to address them? I 
have a picoLCD 20x4 and I can't find any info on how to set user 
definable characters. It's not (yet) in the LCDproc documentation, 
probably because the display is rather new.

Cheers,

Hans

P.S. The character I'd like to use is the degree sign: U+00B0	? (c2 b0)

From allsorts at howhill.com  Fri Nov 28 09:27:51 2008
From: allsorts at howhill.com (Dave Liquorice)
Date: Fri, 28 Nov 2008 15:27:51 +0000 (GMT)
Subject: [Lcdproc] Non-Latin characters in LCDd.conf
In-Reply-To: <20081128154417.ts0f9z4ldoe84004@webmail.versatel.nl>
Message-ID: <mailman.4.1227886115.17297.lcdproc@lists.omnipotent.net>

On Fri, 28 Nov 2008 15:44:17 +0100, hansfong at zonnet.nl wrote:

> Now my question is: how do you know what characters are in the ROM and how 
> to address them?

Normal place to look would be the displays data sheet from the manufacturer. 
Failing that, write a client that just sends each character code to the 
display, prehaps prefixed with that code. Be warned that unexpected things 
may happen, <tab>, <lf>, <cr> etc... Also it's probably not wise to send the 
<esc> character as that may put the display into command mode rather than 
display. Forgive me if we are talking a purely graphical display rather than 
one with a "text" mode, I've only half been following the thread.



From ethan.dicks at gmail.com  Fri Nov 28 09:35:51 2008
From: ethan.dicks at gmail.com (Ethan Dicks)
Date: Sat, 29 Nov 2008 04:35:51 +1300
Subject: [Lcdproc] Non-Latin characters in LCDd.conf
In-Reply-To: <20081128154417.ts0f9z4ldoe84004@webmail.versatel.nl>
References: <47da1bd90811240547r5373fb20ma9e624bd851a35e3@mail.gmail.com>
	<20081126052013.022B633C01E@tippex.mynet.homeunix.org>
	<f4eb766f0811261832v7ee6321fo1890e9b477e40b3f@mail.gmail.com>
	<20081128154417.ts0f9z4ldoe84004@webmail.versatel.nl>
Message-ID: <f4eb766f0811280735j73c2a9e3w2ec3aba719f617c7@mail.gmail.com>

On Sat, Nov 29, 2008 at 3:44 AM,  <hansfong at zonnet.nl> wrote:
> Citeren Ethan Dicks <ethan.dicks at gmail.com>:
>
>> The overall problem with that is that LCDproc is firmly rooted in its
>> roots as an HD44780-based abstraction tool, and those sorts of
>> displays tend to have a small number (1-8) of user-definable
>> characters, with the rest of the characters and glyphs in onboard ROM.
>
> Thank you Ethan for this excellent explanation.

You are welcome.  I'm glad it all made sense.

> Now my question is: how do
> you know what characters are in the ROM and how to address them?

Ultimately, you have to know what version of HD44780 display is in
there.  The two most common character sets (European and Japanese
above 0x80) are documented in datasheets for the HD44780 and various
modern chip clones.  It shouldn't be too hard to find a PDF for a real
HD44780.

You could always write a client to display 16 chars on each line, and
rotate through the character set.  It's documented in the datasheets
for the HD44780, but typically, 0x00-0x07 are the user-definable
characters, with 0x08-0x0F sometimes being echoes of them.  Printable
glyphs can start at 0x10 or sometimes 0x20.  There are a couple
versions of the HD44780, and a few knockoffs (clones), so different
displays can have subtle differences.

One thing that's com

> I have a
> picoLCD 20x4 and I can't find any info on how to set user definable
> characters. It's not (yet) in the LCDproc documentation, probably because
> the display is rather new.

I have a picoLCD 20x4 at home, but I'm on the road.  I've dug into the
code for the 20x2 picoLCD driver, and I think it was pretty
straightforward as to how it's done.  Have a look for the routine that
sets the heartbeat character - that's never in any ROM character set.
You could also look at the routines that set up the bargraph glyphs -
sometimes those are in ROM, sometimes they are in user-definable chars
- it depends on what the display can do (most HD44780 drivers do it
with soft-settable chars, but my jw002 driver uses bars from the ROM
fonts).

> P.S. The character I'd like to use is the degree sign: U+00B0   ? (c2 b0)

That one, or one close to it, is probably findable in the ROM
character set, but it will depend if you have a European or Japanese
font in your display's ROM.

One example of problems caused by different ROMs is with Matrix
Orbital displays.  10 years ago LCDproc got its start with an MO 20x4
product, which is why so many clients, etc., still assume 20x4 and 8
user-settable chars, etc., even if the real display isn't like that
anymore.  So for a certain MO USB display (I don't have one, but the
details are in the list archives over the past couple of years), older
versions have, IIRC, a Japanese font in ROM, but newer ones have a
European font in ROM, and there's no way for the software to tell them
apart.  What's worse is that I think that font change also changed
what glyph is at 0xFF from the checkerboard character that most
displays use, and for bargraphs, etc., there aren't enough spare
user-definable characters to hide that change in the driver.

But as for how to find that degree symbol, if you have a Japanese ROM,
you'll probably find that there's a small "block o" character that is
close enough - it's used in Japanese to turn a H-sound into a P-sound
(HA->PA, HE->PE...)  If you have a European ROM, I don't recall if
there is a handy char or not, but it won't be at the same address as
with the Japanese ROM.  This is where writing a client to try 16
chars/line to display the internal font could come in handy.

Sorry this is so difficult, but LCDproc is trying to abstract client
requests from display limitations, and sometimes, choices made a
decade ago based on how one particular (but very common) type of
display works.  In particular, things that perhaps should have been
abstracted weren't because at the time, there wasn't the variety of
displays we have now.  Since I've written a few drivers over the
years, I've had to deal with a large number of things that just don't
work for every single type of display, so I put a lot of flexibility
into my clients to compensate.  Some things, like "degrees", I think
should be handled by the driver, not by the clients, but that would
take some deep changes that I doubt will happen with 0.5.

-ethan

From ethan.dicks at gmail.com  Fri Nov 28 09:53:00 2008
From: ethan.dicks at gmail.com (Ethan Dicks)
Date: Sat, 29 Nov 2008 04:53:00 +1300
Subject: [Lcdproc] Non-Latin characters in LCDd.conf
In-Reply-To: <49300e0a.073e400a.2aae.fffffc8fSMTPIN_ADDED@mx.google.com>
References: <20081128154417.ts0f9z4ldoe84004@webmail.versatel.nl>
	<49300e0a.073e400a.2aae.fffffc8fSMTPIN_ADDED@mx.google.com>
Message-ID: <f4eb766f0811280753u61f7f6ew221122d8ef301f32@mail.gmail.com>

On Sat, Nov 29, 2008 at 4:27 AM, Dave Liquorice <allsorts at howhill.com> wrote:
> On Fri, 28 Nov 2008 15:44:17 +0100, hansfong at zonnet.nl wrote:
>
>> Now my question is: how do you know what characters are in the ROM and how
>> to address them?
>
> Normal place to look would be the displays data sheet from the manufacturer.

That's always the definitive answer, but I don't know how easy it is
to open up the picoLCD 20x4 to verify what display is used underneath.
 Plus, as I mentioned previously, sometimes the vendor changes
types/brands of LCD display thinking it won't matter, but it does.
:-(

> Failing that, write a client that just sends each character code to the
> display, prehaps prefixed with that code. Be warned that unexpected things
> may happen, <tab>, <lf>, <cr> etc... Also it's probably not wise to send the
> <esc> character as that may put the display into command mode rather than
> display. Forgive me if we are talking a purely graphical display rather than
> one with a "text" mode, I've only half been following the thread.

There are two mingled threads here - the first was about how a client
would be able to display strings of Greek chars, but the most recent
question is about where glyphs like a degree symbol could be found in
a ROM font of a textual display.

In general, I agree with the technique you describe - but I think it's
"safe" for an LCDproc client to send random (i.e. - "non-printing")
chars to the server because the server should escape any unsafe chars
(for example, a backslash for a jw002, or an 0xFE for a Matrix Orbital
display).  If you happen to have a parallel-attached display, then no
chars are "unsafe" since it's a raw display, not one that's trying to
interpret a serial data stream and emulate a terminal (as many serial
display to try to do).  When directly writing to an LCD without
LCDproc, it _is_ important to avoid chars that might be interpreted as
commands.  You pretty much have to hit the manual for your exact
display to learn what can and cannot be sent directly to that display.
 Every vendor command set is different - there are no standards (but
the ones you mentioned are commonly a problem).

I did run across a bug recently, with the picoLCD 20x2 driver, IIRC,
where it was not possible to send a 0x00 character from the server to
the display.  I traced the flow down into the underlying USB library
and lost track of things somewhere deep, but some bit of code was
given a byte count and a string, but still ended the string at the
zero byte.  The problem with this is that the HD44780 uses chars 0x00
- 0x07 for user-definable chars, and this bug broke "bignum" mode.
Yes... thinking back it _was_ the picoLCD 2x20 driver, because I was
trying to debug that a few months ago.  Unfortunately, since the
display itself, not the microcontroller on the picoLCD, defines what
soft-chars are, it's not possible to shift things around.  Thinking
about it now, it _might_ be possible to send a 0x08 in place of a
0x00, but I'm not sure without trying it if that display has echoed
softchars at 0x08-0x0F or not.  Certainly if it worked, it would be an
easy fix.

As for displaying one char at a time, I've found it more useful to
display 16 chars at a time... perhaps like this...

40 @ABCDEFGHIJKLMNO
50 PQRSTUVWXYZ[\]^_
60 `abcdefghijklmno
70 pqrstuvwxyz{|}~

... etc

then you can fire up the client, let it write 2 or 4 lines of those
(depending on your display geometry), and either have it page through
the char set slowly, or just tell it at start which lines to display
and hold forever.

I know I wrote a client to do this once, but it's not very complex and
wouldn't take long to write one from scratch.

-ethan

From bsdfan at nurfuerspam.de  Fri Nov 28 13:37:22 2008
From: bsdfan at nurfuerspam.de (Markus Dolze)
Date: Fri, 28 Nov 2008 20:37:22 +0100
Subject: [Lcdproc] Non-Latin characters in LCDd.conf
In-Reply-To: <20081128152812.28637gmx1@mx075.gmx.net>
References: <20081128152812.28637gmx1@mx075.gmx.net>
Message-ID: <49304872.9080700@nurfuerspam.de>

Dave Liquorice wrote:
> On Fri, 28 Nov 2008 15:44:17 +0100, hansfong at zonnet.nl wrote:
>
>   
>> Now my question is: how do you know what characters are in the ROM and how 
>> to address them?
>>     
>
> Normal place to look would be the displays data sheet from the manufacturer. 
> Failing that, write a client that just sends each character code to the 
> display, prehaps prefixed with that code. Be warned that unexpected things 
> may happen, <tab>, <lf>, <cr> etc... Also it's probably not wise to send the 
> <esc> character as that may put the display into command mode rather than 
> display. Forgive me if we are talking a purely graphical display rather than 
> one with a "text" mode, I've only half been following the thread.
>
>   
Such a thing is already part of LCDd. If LCDd is compiled with option 
LCDPROC_TESTMENUS (use "./configure --enable-testmenus") a menu item 
called "charset" appears in the menu, which displays all characters in 
the range from 0xA0 - 0xFF. This shows which characters the display 
supports.

Regards
Markus

From ethan.dicks at gmail.com  Fri Nov 28 15:28:06 2008
From: ethan.dicks at gmail.com (Ethan Dicks)
Date: Sat, 29 Nov 2008 10:28:06 +1300
Subject: [Lcdproc] Non-Latin characters in LCDd.conf
In-Reply-To: <49304872.9080700@nurfuerspam.de>
References: <20081128152812.28637gmx1@mx075.gmx.net>
	<49304872.9080700@nurfuerspam.de>
Message-ID: <f4eb766f0811281328n21a3f246y5308ca538dc0e795@mail.gmail.com>

On Sat, Nov 29, 2008 at 8:37 AM, Markus Dolze <bsdfan at nurfuerspam.de> wrote:
> Dave Liquorice wrote:
>>
>> On Fri, 28 Nov 2008 15:44:17 +0100, hansfong at zonnet.nl wrote:
>>
>>>
>>> Now my question is: how do you know what characters are in the ROM and
>>> how to address them?
>>>
>>
>> Normal place to look would be the displays data sheet from the
>> manufacturer. Failing that, write a client that just sends each character
>> code to the display...
>
> Such a thing is already part of LCDd. If LCDd is compiled with option
> LCDPROC_TESTMENUS (use "./configure --enable-testmenus") a menu item called
> "charset" appears in the menu, which displays all characters in the range
> from 0xA0 - 0xFF. This shows which characters the display supports.

Interesting.  I will have to look at that.  Certainly the range of
chars from 0xA0 to 0xFF will be more than enough to tell Japanese from
European, but I've seen at least two European and two Japanese
character sets.  In particular, Futaba VFDs (as are in my Matrix
Orbital LK204) have interesting glyphs between 0x10 and 0x20, which
this technique would not show off.

-ethan

From hansfong at zonnet.nl  Fri Nov 28 15:51:29 2008
From: hansfong at zonnet.nl (hansfong at zonnet.nl)
Date: Fri, 28 Nov 2008 22:51:29 +0100
Subject: [Lcdproc] Non-Latin characters in LCDd.conf
In-Reply-To: <49304872.9080700@nurfuerspam.de>
References: <20081128152812.28637gmx1@mx075.gmx.net>
	<49304872.9080700@nurfuerspam.de>
Message-ID: <20081128225129.3y4wsdax8o80gswc@webmail.versatel.nl>

Citeren Markus Dolze <bsdfan at nurfuerspam.de>:

> Such a thing is already part of LCDd. If LCDd is compiled with option 
> LCDPROC_TESTMENUS (use "./configure --enable-testmenus") a menu item 
> called "charset" appears in the menu, which displays all characters 
> in the range from 0xA0 - 0xFF. This shows which characters the 
> display supports.

I'm sorry, but I don't understand where to find the "menu item" you are 
talking about. I assume you are talking about a switch when invoking 
LCDd, right?

Hans

From aeriksson2 at fastmail.fm  Sat Nov 29 02:32:50 2008
From: aeriksson2 at fastmail.fm (aeriksson2 at fastmail.fm)
Date: Sat, 29 Nov 2008 09:32:50 +0100
Subject: [Lcdproc] Non-Latin characters in LCDd.conf
In-Reply-To: <f4eb766f0811261832v7ee6321fo1890e9b477e40b3f@mail.gmail.com>
References: <47da1bd90811240547r5373fb20ma9e624bd851a35e3@mail.gmail.com>
	<20081126052013.022B633C01E@tippex.mynet.homeunix.org>
	<f4eb766f0811261832v7ee6321fo1890e9b477e40b3f@mail.gmail.com>
Message-ID: <20081129083250.9BC4C93CBA1@tippex.mynet.homeunix.org>


ethan.dicks at gmail.com said:
> The overall problem with that is that LCDproc is firmly rooted in its roots
> as an HD44780-based abstraction tool, and those sorts of displays tend to
> have a small number (1-8) of user-definable characters, with the rest of the
> characters and glyphs in onboard ROM. 

Hi Ethan,

Thanks for the explanation. While I appreciate that various devices have lots 
of constaints making font loading seem like a far off vision, what is the 
charset used in the client->LCDd protocol? From an application writer's point 
of view it would be better to have a fixed (or settable) charset and let the 
drivers emulate stuff not rederable on the device, than resort to device 
specific programming go get the right glyphs out to the screen.

Is it us-ascii today? What would it take to make it utf-8?

/Anders


From peter at adpm.de  Sat Nov 29 08:23:15 2008
From: peter at adpm.de (Peter Marschall)
Date: Sat, 29 Nov 2008 15:23:15 +0100
Subject: [Lcdproc] Non-Latin characters in LCDd.conf
In-Reply-To: <20081129083250.9BC4C93CBA1@tippex.mynet.homeunix.org>
References: <47da1bd90811240547r5373fb20ma9e624bd851a35e3@mail.gmail.com>
	<f4eb766f0811261832v7ee6321fo1890e9b477e40b3f@mail.gmail.com>
	<20081129083250.9BC4C93CBA1@tippex.mynet.homeunix.org>
Message-ID: <200811291523.15688.peter@adpm.de>

Hi,

On Saturday, 29. November 2008, aeriksson2 at fastmail.fm wrote:
> Thanks for the explanation. While I appreciate that various devices have
> lots of constaints making font loading seem like a far off vision, what is
> the charset used in the client->LCDd protocol? From an application writer's
> point of view it would be better to have a fixed (or settable) charset and
> let the drivers emulate stuff not rederable on the device, than resort to
> device specific programming go get the right glyphs out to the screen.
>
> Is it us-ascii today? What would it take to make it utf-8?

This is hard to answer.
If you restrict yourself to US-ASCII you are on the safe side.

As Ethan already explained, most of the text-mode displays 
support different 8-bit character sets, that cannot be changed.

For some displays there is a mapping layer in the LCDproc driver
that tries to map Latin1 to the display's character set.
Unfortunately this is not always completely possible.

What does it take to support UTF8 ?
I fear rewriting large parts of the server core, and problably all of the 
drivers.

If you have UTF8 data that does only contain characters in the Latin1 range,
you may try to do the conversion in a client before sending it to LCDd.

Regards
peter

-- 
Peter Marschall
peter at adpm.de

From joris at robijn.net  Sat Nov 29 08:39:19 2008
From: joris at robijn.net (Joris Robijn)
Date: Sat, 29 Nov 2008 15:39:19 +0100
Subject: [Lcdproc] Non-Latin characters in LCDd.conf
In-Reply-To: <20081129083250.9BC4C93CBA1@tippex.mynet.homeunix.org>
References: <47da1bd90811240547r5373fb20ma9e624bd851a35e3@mail.gmail.com>,
	<f4eb766f0811261832v7ee6321fo1890e9b477e40b3f@mail.gmail.com>,
	<20081129083250.9BC4C93CBA1@tippex.mynet.homeunix.org>
Message-ID: <49316227.15206.DBE1BB@joris.robijn.net>

Hi Anders,

This discussion has already existed for a long time. Problem is that you 
do not want to make a protocol language that supports everything, while 
hardly any display can use it. It would be very much work to support 
UTF8. In the past the decision was made to go for the iso8859-15 charset. 
This contains most characters in latin languages. If a display does not 
support a character, its driver can decide to use a custom char for it, 
or replace it with a simplified form of the character: a-umlaut becomes 
a. The driver should know how many custom chars the display supports. 
Currently, hardly any (if any) driver supports this.

Then, to support "any" character or symbol, the idea was that a client 
could define its own icon that he could use just like the normal icons. 
The client would like to know the size of the chars on the display and 
the number of custom chars. He can define more icons than there is memory 
for, but when he places too many icons on the screen the driver cannot 
render them and will replace some by something else. The idea was that 
this be put in a library but it was  never implemented.

I hope this gives you some ideas... You can lookup the discussions on the 
mailing list. I hope the custom icon stuff finally gets implemented !

Joris



On 29 Nov 2008 at 9:32, aeriksson2 at fastmail.fm wrote:

> 
> ethan.dicks at gmail.com said:
> > The overall problem with that is that LCDproc is firmly rooted in its roots
> > as an HD44780-based abstraction tool, and those sorts of displays tend to
> > have a small number (1-8) of user-definable characters, with the rest of the
> > characters and glyphs in onboard ROM. 
> 
> Hi Ethan,
> 
> Thanks for the explanation. While I appreciate that various devices have lots 
> of constaints making font loading seem like a far off vision, what is the 
> charset used in the client->LCDd protocol? From an application writer's point 
> of view it would be better to have a fixed (or settable) charset and let the 
> drivers emulate stuff not rederable on the device, than resort to device 
> specific programming go get the right glyphs out to the screen.
> 
> Is it us-ascii today? What would it take to make it utf-8?
> 
> /Anders
> 
> _______________________________________________
> LCDproc mailing list
> LCDproc at lists.omnipotent.net
> http://lists.omnipotent.net/mailman/listinfo/lcdproc

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



From ethan.dicks at gmail.com  Sun Nov 30 06:06:23 2008
From: ethan.dicks at gmail.com (Ethan Dicks)
Date: Mon, 1 Dec 2008 01:06:23 +1300
Subject: [Lcdproc] lcdident.pl - a simple Perl client to identify your LCDd
	screens by port number
Message-ID: <f4eb766f0811300406k2f1b3467q76d0a11394266645@mail.gmail.com>

Hi, all,

I've managed to get my working environment restored on the road (I'm
in NZ at the moment), and wanted to share a simple but clean client I
wrote this year that helps me keep my environment straight.  For most
people, this will be little more than a starting point for new Perl
clients, but for some developers, it's nice to be able to tell which
display will respond to what port accesses (this past year, I've had
as many as 4 instances of LCDd running on the same machine for
development/debugging purposes - one or two of several 20x4s, a 20x2,
one of two 40x4s and a 24x8, all with different drivers - MtxOrb,
picoLCD, HD44780, and jw002, for the curious).

The client is quite simple - it opens up the requested port, gets the
geometry, then writes the port number and the reported geometry either
as one line (2-line displays) or on two lines (more than 2 lines),
then waits for a few seconds and exits.

I'm sharing this in the hopes that it will be instructional, and grant
permission to include it in the clients directory of LCDd if it's
interesting enough to warrant that.

Please let me know if you find any bugs or limitations too painful to
live with or live without.

If this does turn out to be interesting, I have a small suite of
simple clients that I've found to be handy for driver testing and
debugging that I'll be happy to share.

-ethan
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: lcdident.pl
URL: <http://lists.omnipotent.net/pipermail/lcdproc/attachments/20081201/e21345a0/attachment-0001.txt>

From peter at adpm.de  Sun Nov 30 12:47:31 2008
From: peter at adpm.de (Peter Marschall)
Date: Sun, 30 Nov 2008 19:47:31 +0100
Subject: [Lcdproc] iMon LCD device support
In-Reply-To: <1226337264.7789.14.camel@xavier.wilsonet.com>
References: <1226337264.7789.14.camel@xavier.wilsonet.com>
Message-ID: <200811301947.31343.peter@adpm.de>

Hi Jarod,

On Monday, 10. November 2008, Jarod Wilson wrote:

sorry for not getting back to you earlier.

> [...]
> Anyhow, the patch is what leads me here. I see Dean Harding posted a
> patch a while back for support of the original iMon LCD, and there's now
> a v3 of that patch. On top of that, there's a patch to that patch for
> the newer iMon LCD, which is also required for mine. Ron Frazier has
> most of the details covered[2], so I won't rehash them here.
>
> A quick search of the archives suggested the only things really needed
> to get the patch merged was some documentation, but Dean had some
> additional work he wanted to do... I guess my question is primarily for
> Dean: what really *has* to be done for this to be ready to be merged?
> Personally, I'd advocate merging it ASAP, rather than waiting until its
> perfect, so that it gets out to a wider audience of testers -- not
> everyone is comfortable patching and building from source, but many such
> people can provide useful feedback.

I guess you talk about:
http://codeka.com/blogs/index.php/c29/c30/?blog=5 

I had a look at v3 at the patch.
It still does not contain documentation.

Since I do not have the hardware, I cannot tell whether the driver works.
For me, the important missing bit is the documentation.

> Note that I maintain Fedora's lirc bits and co-maintain its lcdproc
> package, and thus intend to patch in full support for this device for
> Fedora users, but would really like to see it all upstreamed ASAP.

You can help getting this driver included into LCDproc:
Write the documentation.
It should be fairly easy if you 
- have the hardware
- are a maintainer in Fedora

Regards
Peter
-- 
Peter Marschall
peter at adpm.de

From TELarson at west.com  Sun Nov 30 21:43:34 2008
From: TELarson at west.com (Larson, Timothy E.)
Date: Sun, 30 Nov 2008 21:43:34 -0600
Subject: [Lcdproc] Non-Latin characters in LCDd.conf
In-Reply-To: <200811291523.15688.peter@adpm.de>
References: <47da1bd90811240547r5373fb20ma9e624bd851a35e3@mail.gmail.com><f4eb766f0811261832v7ee6321fo1890e9b477e40b3f@mail.gmail.com><20081129083250.9BC4C93CBA1@tippex.mynet.homeunix.org>
	<200811291523.15688.peter@adpm.de>
Message-ID: <CB5348B152BEC84F9FE88EA7DBB2CD6505AA4393@OMAEXMB02.corp.westworlds.com>

As an FYI, if someone is keen to do a character conversion like this in a
client, the Lynx web browser has a pretty good 7-bit conversion table.
(I've contributed to it in the past.)  That is, look up the Unicode
position, get an ASCII (possibly multi-char) representation to replace it
with.


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/20081130/a6756e1e/attachment.bin>