From avschie at onsneteindhoven.nl Sat Sep 5 09:59:39 2009 From: avschie at onsneteindhoven.nl (A. van Schie) Date: Sat, 5 Sep 2009 11:59:39 +0200 (CEST) Subject: [Lcdproc] Changed picoLCD IR handling Message-ID: <55107.88.159.85.214.1252144779.squirrel@webmail.onsneteindhoven.nl> Hello LCDProc picoLCD users/developers, I have a picoLCD 2x20(M200) and my remote control (RC-5) doesn't work with the current CVS version. Because irrecord is also not working, I couldn't get a working configuration. More than a year ago I made my own implementation (also using lcdproc/picolcd and lirc/udp). I noticed that the main problem of the picoLCD was that the 'sync' SPACE is not send! My previous solution to this was to queue all the data, and by a timeout (or by a double PULSE), adding a 'sync' SPACE by calculating the duration between the current time and the time of the last message and send it. But the key presses where not always detected so I did not submitted my code (I know now why). Last weeks I had time to look at my problems with the current CVS version: 1. I found that there were still PULSEs without a space in between, when using my RC-5 remote. I didn't found a working parameter setting to get it working. (Maybe also because of the next issue) 2. I found out that there not all the IR data was received from the picoLCD and found out that the call to usb_clear_halt() prevents that the second part of the message read (why this call?) FIX: Removing this code fixed my problem but I don't know if it works on a picoLCD 4x20? The comment say something about that the data is send over and over again, but is it not normal RC key repeating? and will that stop when the button is released? This repeating should be handled by the lirc client in the ~/.lircrc with repeat and/or delay. Both issues explain why irrecord doesn't work! By running LIRC in debug I noticed: 3. LIRC gives a timeout when the data is not sent quick enhough LIRC timeouts and LIRC gets then out of sync and the key is losted. FIX: I solved this by queueing all data and send it when: - the last message ends with a pulse and the new message starts with a pulse. - I see a incomplete message (ending with a PULSE) Extra (should not happen, when everything goes ok): - The send buffer will become full (I check at the begin if there is still room to add all new samples) - I also added a LircFlushThreshold param, when I see a SPACE longer that that value I send it also (without the space, see 3). - Got a timeout (0.5s) 4. LIRC expects data to start with a SPACE, sending a the SPACE on the end of the message leads, to a timeout (on plead) and lirc is out of sync. FIX: So I did't send the SPACE at the end of the message, but I put it at the begin of the next message. I notices that LIRC doesn't need that SPACE at the end, because LIRC gets a timeout and assumes it as a SPACE. The LircSync and LircSyncLength parameter didn't make sense anymore so I removed those. (I also put the in lcd_packet keydata on the stack to prevent any possible memory leak there) These changes make that irrecord works again (without any complaining) for my RC-5 and my XCCube(SPACE_ENC|CONST_LENGTH encoding) remote. The only problem I had was that irw reported no key repeats (repeat counter stayed 00). But that was solved by changing the gap value (in lircd.conf) to the value irrecord reported. Now I can use repeat = 2 (or delay = 2) in ~/.lircrc to reduce repeating keys presses. Main advances: - The user now use irrecord again. - So he doesn't need to guess possible config values to make it work (most of the time). - The dynamic 'sync' should be flexible enhough to handle all type of remote control protocols, without extra configuration. Unknown: - Don't know if picoLCD 4x20 still works, because of the removed usb_clear_halt()? - Not sure that all remotes will work? I got it working now for a week (and had no key misses) so it's time to share code. Attached is the zipped patch agains the CVS MAIN (of 4 Sep 2009). I hope that everyone with a picoLCD likes this new way of handling IR data. Best regards, Andries van Schie. From avschie at onsneteindhoven.nl Sat Sep 5 15:36:43 2009 From: avschie at onsneteindhoven.nl (A. van Schie) Date: Sat, 5 Sep 2009 17:36:43 +0200 (CEST) Subject: [Lcdproc] Changed picoLCD IR handling] Message-ID: <35687.88.159.85.214.1252165003.squirrel@webmail.onsneteindhoven.nl> Oops: now with my patch. > Hello LCDProc picoLCD users/developers, > > I have a picoLCD 2x20(M200) and my remote control (RC-5) doesn't work with > the current CVS version. > Because irrecord is also not working, I couldn't get a working > configuration. > > More than a year ago I made my own implementation (also using > lcdproc/picolcd and lirc/udp). > I noticed that the main problem of the picoLCD was that the 'sync' SPACE > is not send! > My previous solution to this was to queue all the data, and by a timeout > (or by a double PULSE), > adding a 'sync' SPACE by calculating the duration between the current time > and the time of the > last message and send it. > But the key presses where not always detected so I did not submitted my > code (I know now why). > > > Last weeks I had time to look at my problems with the current CVS version: > 1. I found that there were still PULSEs without a space in between, when > using my RC-5 remote. > I didn't found a working parameter setting to get it working. > (Maybe also because of the next issue) > 2. I found out that there not all the IR data was received from the > picoLCD and found out that > the call to usb_clear_halt() prevents that the second part of the > message read (why this call?) > FIX: Removing this code fixed my problem but I don't know if it works on a > picoLCD 4x20? > The comment say something about that the data is send over and over > again, > but is it not normal RC key repeating? and will that stop when the > button is released? > This repeating should be handled by the lirc client in the ~/.lircrc > with repeat and/or delay. > Both issues explain why irrecord doesn't work! > > By running LIRC in debug I noticed: > 3. LIRC gives a timeout when the data is not sent quick enhough LIRC > timeouts and LIRC gets then > out of sync and the key is losted. > FIX: I solved this by queueing all data and send it when: > - the last message ends with a pulse and the new message starts with a > pulse. > - I see a incomplete message (ending with a PULSE) > Extra (should not happen, when everything goes ok): > - The send buffer will become full (I check at the begin if there is > still room to add all new samples) > - I also added a LircFlushThreshold param, when I see a SPACE longer > that that value I send it also > (without the space, see 3). > - Got a timeout (0.5s) > 4. LIRC expects data to start with a SPACE, sending a the SPACE on the end > of the message leads, > to a timeout (on plead) and lirc is out of sync. > FIX: So I did't send the SPACE at the end of the message, but I put it at > the begin of the next message. > I notices that LIRC doesn't need that SPACE at the end, because LIRC > gets a timeout and assumes > it as a SPACE. > > The LircSync and LircSyncLength parameter didn't make sense anymore so I > removed those. > > (I also put the in lcd_packet keydata on the stack to prevent any possible > memory leak there) > > These changes make that irrecord works again (without any complaining) for > my RC-5 and > my XCCube(SPACE_ENC|CONST_LENGTH encoding) remote. > > The only problem I had was that irw reported no key repeats (repeat > counter stayed 00). > But that was solved by changing the gap value (in lircd.conf) to the value > irrecord reported. > Now I can use repeat = 2 (or delay = 2) in ~/.lircrc to reduce repeating > keys presses. > > Main advances: > - The user now use irrecord again. > - So he doesn't need to guess possible config values to make it work (most > of the time). > - The dynamic 'sync' should be flexible enhough to handle all type of > remote control protocols, > without extra configuration. > > Unknown: > - Don't know if picoLCD 4x20 still works, because of the removed > usb_clear_halt()? > - Not sure that all remotes will work? > > I got it working now for a week (and had no key misses) so it's time to > share code. > > Attached is the zipped patch agains the CVS MAIN (of 4 Sep 2009). > > I hope that everyone with a picoLCD likes this new way of handling IR > data. > > Best regards, > > Andries van Schie. > > > _______________________________________________ > LCDproc mailing list > LCDproc at lists.omnipotent.net > http://lists.omnipotent.net/mailman/listinfo/lcdproc > -------------- next part -------------- A non-text attachment was scrubbed... Name: picolcd-dynamic-sync.patch.gz Type: application/x-gzip Size: 6569 bytes Desc: not available URL: From tmw at uchicago.edu Tue Sep 8 02:18:22 2009 From: tmw at uchicago.edu (Theodore Wynnychenko) Date: Mon, 7 Sep 2009 21:18:22 -0500 Subject: [Lcdproc] Segmentation Fault with 0.5.2 on OpenBSD 4.3 Message-ID: <000101ca302a$ad4b8dd0$07e2a970$@edu> Hello: This is beyond my level of knowledge, so, any help would be appreciated. I was hoping to get a Crystalfontz parallel LCD working via LCDproc. In any case, I downloaded the 0.5.2 version, configured using: "./configure --prefix=/home/me --enable-drivers=hd44780 --enable-debug" Then ran make. Seemed to work fine (a few warnings about using strlcpy and not strcpy, and such). But compiled completely. Edit the config file to use the hd44780 driver, which is set to "8bit" (I also set the Device to /dev/lpt0, but I don't think that matters since it's not a serial LCD display). I then start the deamon with: "./server/LCDd -c LCDd.conf" and nothing. Running it with "-f" I see a segmentation fault. I don't really have any clue how to troubleshoot this. But, here is the info I have. ------------------------------------------------------- Running LCDd gives me: # ./server/LCDd -c LCDd.conf -f LCDd 0.5.2, LCDproc Protocol 0.3 Part of the LCDproc suite Copyright (C) 1998-2007 William Ferrell, Scott Scriven and many other contributors This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version. This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details. You should have received a copy of the GNU General Public License along with this program; if not, write to the Free Software Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA. Segmentation fault (core dumped) -------------------------------------------------- Using gdb - with backtrace: # gdb ./server/LCDd GNU gdb 6.3 Copyright 2004 Free Software Foundation, Inc. ...... (gdb) set args -c /home/me/lcdproc-0.5.2/LCDd.conf -f (gdb) run Starting program: /home/me/lcdproc-0.5.2/server/LCDd -c /home/me/lcdproc-0.5.2/LCDd.conf -f LCDd 0.5.2, LCDproc Protocol 0.3 Part of the LCDproc suite Copyright (C) 1998-2007 William Ferrell, Scott Scriven and many other contributors This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version. This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details. You should have received a copy of the GNU General Public License along with this program; if not, write to the Free Software Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA. Program received signal SIGSEGV, Segmentation fault. lcdtime_HD44780_senddata (p=0x8856e200, displayID=0 '\0', flags=1 '\001', ch=48 '0') at pio.h:147 147 __asm __volatile("outb %0,%w1" : : "a" (data), "d" (port)); (gdb) backtrace full #0 lcdtime_HD44780_senddata (p=0x8856e200, displayID=0 '\0', flags=1 '\001', ch=48 '0') at pio.h:147 portControl = 0 '\0' #1 0x05b7dd0d in hd_init_ext8bit (drvthis=0x5b7de0b) at hd44780-ext8bit.c:100 p = (PrivateData *) 0x8856e200 hd44780_functions = (HD44780_functions *) 0x81841080 #2 0x05b7b779 in HD44780_init (drvthis=0x8babe700) at hd44780.c:343 buf = "?2L\205?4\000<\037\002?\f`\000\000\000T&??\024&??\030&??\000\000\000\000\03 0&?? \000\000" s = 0x84af5310 "20x4" i = 0 if_type = 0 p = (PrivateData *) 0x8856e200 conf_charmap = "hd44780_default" #3 0x1c00ada8 in driver_load (name=0x7cb8b7c0 "hd44780", filename=0x25b79510 "HD44780_") at driver.c:130 driver = (Driver *) 0x8babe700 res = 95936011 #4 0x1c00a507 in drivers_load_driver (name=0x7cb8b7c0 "hd44780") at drivers.c:90 driver = (Driver *) 0x0 s = 0xffffffff
driverpath = 0x85cde4c0 "/home/twynnychenko/lcdproc-0.5.2/server/drivers/" filename = 0x85cde2c0 "/home/twynnychenko/lcdproc-0.5.2/server/drivers/hd44780.so" #5 0x1c003026 in init_drivers () at main.c:678 i = 0 res = 95936011 output_loaded = 0 #6 0x1c002533 in main (argc=1006670337, argv=0x0) at main.c:240 e = 0 parent_pid = 0 ---------------------------- So, if anyone has any suggestions, I would be very grateful. Thanks in advance. Bye - ted From bsdfan at nurfuerspam.de Tue Sep 8 06:15:43 2009 From: bsdfan at nurfuerspam.de (Markus Dolze) Date: Tue, 08 Sep 2009 08:15:43 +0200 Subject: [Lcdproc] Segmentation Fault with 0.5.2 on OpenBSD 4.3 In-Reply-To: <000101ca302a$ad4b8dd0$07e2a970$@edu> References: <000101ca302a$ad4b8dd0$07e2a970$@edu> Message-ID: <4AA5F68F.8030301@nurfuerspam.de> Theodore Wynnychenko wrote: > Hello: > This is beyond my level of knowledge, so, any help would be appreciated. I > was hoping to get a Crystalfontz parallel LCD working via LCDproc. > In any case, I downloaded the 0.5.2 version, configured using: "./configure > --prefix=/home/me --enable-drivers=hd44780 --enable-debug" > > Then ran make. Seemed to work fine (a few warnings about using strlcpy and > not strcpy, and such). But compiled completely. > Edit the config file to use the hd44780 driver, which is set to "8bit" (I > also set the Device to /dev/lpt0, but I don't think that matters since it's > not a serial LCD display). > I then start the deamon with: "./server/LCDd -c LCDd.conf" and nothing. > Running it with "-f" I see a segmentation fault. > I don't really have any clue how to troubleshoot this. > But, here is the info I have. > Using gdb - with backtrace: > ... > # gdb ./server/LCDd > GNU gdb 6.3 > Copyright 2004 Free Software Foundation, Inc. > ...... > (gdb) set args -c /home/me/lcdproc-0.5.2/LCDd.conf -f > (gdb) run > Starting program: /home/me/lcdproc-0.5.2/server/LCDd -c > /home/me/lcdproc-0.5.2/LCDd.conf -f > LCDd 0.5.2, LCDproc Protocol 0.3 > Part of the LCDproc suite > > ... > Program received signal SIGSEGV, Segmentation fault. > lcdtime_HD44780_senddata (p=0x8856e200, displayID=0 '\0', flags=1 '\001', > ch=48 '0') at pio.h:147 > 147 __asm __volatile("outb %0,%w1" : : "a" (data), "d" (port)); > > > (gdb) backtrace full > #0 lcdtime_HD44780_senddata (p=0x8856e200, displayID=0 '\0', flags=1 > '\001', ch=48 '0') at pio.h:147 > portControl = 0 '\0' > #1 0x05b7dd0d in hd_init_ext8bit (drvthis=0x5b7de0b) at > hd44780-ext8bit.c:100 > p = (PrivateData *) 0x8856e200 > hd44780_functions = (HD44780_functions *) 0x81841080 > Hi, thank you for reporting this. You should download version 0.5.3 from http://sourceforge.net/projects/lcdproc/ as that one replaced 0.5.2 (and yes, we know lcdproc.org is out of date). It won't make a difference anyway, because that part of the code has not been changed since the previous. LCDd fails to set access rights for the lpt port. You have to start LCDd as root (it drops *** *privileges once it has access to low level ports) if you are not already doing so. Regards, Markus From tmw at uchicago.edu Tue Sep 8 14:11:14 2009 From: tmw at uchicago.edu (Theodore Wynnychenko) Date: Tue, 8 Sep 2009 09:11:14 -0500 Subject: [Lcdproc] Segmentation Fault with 0.5.2 on OpenBSD 4.3 In-Reply-To: <4AA5F68F.8030301@nurfuerspam.de> References: <000101ca302a$ad4b8dd0$07e2a970$@edu> <4AA5F68F.8030301@nurfuerspam.de> Message-ID: <000001ca308e$3aace8a0$b006b9e0$@edu> -----Original Message----- From: Markus Dolze [mailto:bsdfan at nurfuerspam.de] Sent: Tuesday, September 08, 2009 1:16 AM To: tmw at uchicago.edu Cc: lcdproc at lists.omnipotent.net Subject: Re: [Lcdproc] Segmentation Fault with 0.5.2 on OpenBSD 4.3 Hi, thank you for reporting this. You should download version 0.5.3 from http://sourceforge.net/projects/lcdproc/ as that one replaced 0.5.2 (and yes, we know lcdproc.org is out of date). It won't make a difference anyway, because that part of the code has not been changed since the previous. LCDd fails to set access rights for the lpt port. You have to start LCDd as root (it drops *** *privileges once it has access to low level ports) if you are not already doing so. Regards, Markus --- Thanks for the suggestion, but the privileges issue had occurred to me. The output showing the segmentation fault occurs when I run LCDd from the command prompt as root. I also tried setting (in LCDd.conf) "User=root" (I was thinking, to force it to not drop root privileges), and see if that made a difference. It did not. I tried going backwards and compiled version 0.5.0. This seemed to compile fine, but also failed when run. In this case however, it gave error messages that "i386_set_ioperm" and "i386_get_ioperm" were unknown (I guess this failure probably occurs before the seg fault I am seeing with 0.5.2?). If you have any other thoughts, I would be happy to hear them. Thanks again Bye - ted From tmw at uchicago.edu Tue Sep 8 14:43:31 2009 From: tmw at uchicago.edu (Theodore Wynnychenko) Date: Tue, 8 Sep 2009 09:43:31 -0500 Subject: [Lcdproc] Segmentation Fault with 0.5.2 on OpenBSD 4.3 References: <000101ca302a$ad4b8dd0$07e2a970$@edu> <4AA5F68F.8030301@nurfuerspam.de> Message-ID: <000301ca3092$bd057390$37105ab0$@edu> -----Original Message----- From: Markus Dolze [mailto:bsdfan at nurfuerspam.de] Sent: Tuesday, September 08, 2009 1:16 AM To: tmw at uchicago.edu Cc: lcdproc at lists.omnipotent.net Subject: Re: [Lcdproc] Segmentation Fault with 0.5.2 on OpenBSD 4.3 Hi, thank you for reporting this. You should download version 0.5.3 from http://sourceforge.net/projects/lcdproc/ as that one replaced 0.5.2 (and yes, we know lcdproc.org is out of date). It won't make a difference anyway, because that part of the code has not been changed since the previous. LCDd fails to set access rights for the lpt port. You have to start LCDd as root (it drops *** *privileges once it has access to low level ports) if you are not already doing so. Regards, Markus --- Thanks for the suggestion, but the privileges issue had occurred to me. The output showing the segmentation fault occurs when I run LCDd from the command prompt as root. I also tried setting (in LCDd.conf) "User=root" (I was thinking, to force it to not drop root privileges), and see if that made a difference. It did not. I tried going backwards and compiled version 0.5.0. This seemed to compile fine, but also failed when run. In this case however, it gave error messages that "i386_set_ioperm" and "i386_get_ioperm" were unknown (I guess this failure probably occurs before the seg fault I am seeing with 0.5.2?). If you have any other thoughts, I would be happy to hear them. Thanks again Bye - ted --------------------- Sorry, I should have included this with the last message. I also tried installing version 0.5.3. Configure and make seem fine. But, when I try running as root, I get the following: /home/me/lcdproc-0.5.3 # ./server/LCDd -c LCDd.conf -f LCDd 0.5.3, LCDproc Protocol 0.3 Part of the LCDproc suite Copyright (C) 1998-2009 William Ferrell, Scott Scriven and many other contributors ...... ./server/LCDd:/home/me/lcdproc-0.5.3/server/drivers/hd44780.so: undefined symbol 'sock_send' ./server/LCDd:/home/me/lcdproc-0.5.3/server/drivers/hd44780.so: undefined symbol 'sock_connect' ./server/LCDd:/home/me/lcdproc-0.5.3/server/drivers/hd44780.so: undefined symbol 'report' ./server/LCDd:/home/me/lcdproc-0.5.3/server/drivers/hd44780.so: undefined symbol 'sock_close' ./server/LCDd:/home/me/lcdproc-0.5.3/server/drivers/hd44780.so: undefined symbol 'sock_recv' Could not open driver module /home/me/lcdproc-0.5.3/server/: Cannot load specified object Driver [hd44780] binding failed Could not load driver hd44780 There is no output driver Critical error while initializing, abort. ----------------------- I don't know if this is a better or worse result than the segmentation fault? But, I went ahead and replaced the 0.5.3 drivers with the 0.5.2 drivers, and then tried running 0.5.3. This time, the driver messages above were gone, but the segmentation fault was back (it appears the backtrace was the same as before) This is the output from 0.5.3 when starting with 0.5.2 drivers: # gdb ./server/LCDd GNU gdb 6.3 ... (gdb) set args -c LCDd.conf -f (gdb) run Starting program: /home/twynnychenko/lcdproc-0.5.3/server/LCDd -c LCDd.conf -f LCDd 0.5.3, LCDproc Protocol 0.3 Part of the LCDproc suite ... Program received signal SIGSEGV, Segmentation fault. lcdtime_HD44780_senddata (p=0x85b96400, displayID=0 '\0', flags=1 '\001', ch=48 '0') at pio.h:147 147 __asm __volatile("outb %0,%w1" : : "a" (data), "d" (port)); (gdb) backtrace full #0 lcdtime_HD44780_senddata (p=0x85b96400, displayID=0 '\0', flags=1 '\001', ch=48 '0') at pio.h:147 portControl = 0 '\0' #1 0x0b1aad0d in hd_init_ext8bit (drvthis=0xb1aae0b) at hd44780-ext8bit.c:100 p = (PrivateData *) 0x85b96400 hd44780_functions = (HD44780_functions *) 0x7f641340 #2 0x0b1a8779 in HD44780_init (drvthis=0x80d65a00) at hd44780.c:343 buf = "?27\201t6\000<\037\002?\f`\000\000\000?Y??\224Y??\230Y??\000\000\000\000\23 0Y?? \000\000" s = 0x88f65370 "20x4" i = 0 if_type = 0 p = (PrivateData *) 0x85b96400 conf_charmap = "hd44780_default" #3 0x1c00ba4c in driver_load (name=0x8397cad0 "hd44780", filename=0x2b1a6510 "HD44780_") at driver.c:157 driver = (Driver *) 0x80d65a00 res = 186297867 #4 0x1c00b137 in drivers_load_driver (name=0x8397cad0 "hd44780") at drivers.c:87 driver = (Driver *) 0x0 s = 0xffffffff
driverpath = 0x866223c0 "/home/twynnychenko/lcdproc-0.5.3/server/drivers/" filename = 0x86622480 "/home/twynnychenko/lcdproc-0.5.3/server/drivers/hd44780.so" #5 0x1c003043 in init_drivers () at main.c:690 i = 0 res = 186297867 output_loaded = 0 #6 0x1c00252f in main (argc=1006670337, argv=0x0) at main.c:243 e = 0 parent_pid = 0 -------- As I said before, any ideas would be welcome. Thanks Bye - ted From lists at digitalpcservices.com Thu Sep 10 00:03:52 2009 From: lists at digitalpcservices.com (Lists) Date: Wed, 9 Sep 2009 20:03:52 -0400 Subject: [Lcdproc] Noritake VFDs Message-ID: <004801ca31aa$31b29930$9517cb90$@com> Hi everyone, I'm providing some feedback on Noritake VFDs as stated in the User's Guide.. I can't get it to work. J Now that being said, the LCD unit came out of a system from Net Integration Technologies (now some part of IBM.) The Part Number on the LCD is CU16025ECPB-W6J. I have confirmed this is a Noritake unit after a google search. The interface between the LCD and PC is a separate board which contains an Amtel 90S8515 controller chip. The connection to the PC is using the SIR1 (serial port 2 set to HPSIR) port on the motherboard (Matsonic MS8127C+). I have verified the following lines are in the config file. [serialVFD] Device=/dev/cuad1 Speed=9600 Type=2 Size=16x2 FYI, this is running on a pfSense system. I've had to add the [serialVFD] into the config generation script manually and changed the com2 device from "/dev/cua1" to "/dev/cuad1". In the pfSense System Logs, I get this message: kernel: pid 5455 (LCDd), uid 65534: exited on signal 11 I will assist, answer and test any suggestions or modifications. I would really like this to work! J Jim -------------- next part -------------- An HTML attachment was scrubbed... URL: From epooch at cox.net Thu Sep 10 01:12:59 2009 From: epooch at cox.net (Eric Pooch) Date: Wed, 9 Sep 2009 18:12:59 -0700 Subject: [Lcdproc] Fwd: imonlcd and 0038 breakage... References: <4AA7AF58.4010701@cyberwizzard.nl> Message-ID: <46D13ECD-D5D5-4ABA-B025-682DF47CC475@cox.net> Begin forwarded message: > From: Berend Dekens > Date: September 9, 2009 6:36:24 AM PDT > Hi, > > I don't know who I should mail so I address this mail to both of > you as the last modifications to the imonlcd driver have been done > by you guys. I have a Soundgraph VFD and I used to use the imonlcd > driver from CVS from mid 2008 or so. But since it won't let me shut > down the back light I figured I tried upgrading to the latest version. > > The current CVS version is broken for me with an 0038 device but I > managed to fix it: when running LCDd, a lot of "imon: error writing > to file descriptor: -1" errors appear in the output. Because the > VFD controller can't keep up with the speed of the computer, it > chokes on the commands. I've debugged the driver to make sure the > the errors are not occuring because of a structural problem: they > appear to be mostly random and occur after bursts of "send_packet > ()" calls. > > I've updated the send_packet function to test for the VFD device > and if so, delay the packet sending with 5ms. Note that testing > showed that 2 or 3ms delays were enough to stop the errors but to > be on the safe side I've increased the delay to 5ms. > > imonlcd.c: > /** > * Sends data to the screen. > * > * \param p The private data structure containing a tx_buf with the > data to send. > */ > static void > send_packet(PrivateData *p) > { > int err; > err = write(p->imon_fd, p->tx_buf, sizeof(p->tx_buf)); > > if (err <= 0) > printf("%s: error writing to file descriptor: %d", "imon", > err); > /* If this is the VFD device, slow down communication to > prevent overloading the controller */ > if (p->protocol == PROTOCOL_0038) usleep(5000); > } > > I hope one of you can put this in CVS as I'm probably not the only > one having this problem. > > Regards, > Berend Dekens -------------- next part -------------- An HTML attachment was scrubbed... URL: From fblack947 at yahoo.com Thu Sep 10 03:29:21 2009 From: fblack947 at yahoo.com (jk) Date: Wed, 9 Sep 2009 20:29:21 -0700 (PDT) Subject: [Lcdproc] Fwd: imonlcd and 0038 breakage... In-Reply-To: <46D13ECD-D5D5-4ABA-B025-682DF47CC475@cox.net> References: <4AA7AF58.4010701@cyberwizzard.nl> <46D13ECD-D5D5-4ABA-B025-682DF47CC475@cox.net> Message-ID: <37208.47664.qm@web37501.mail.mud.yahoo.com> Berend, the lcdproc mailing list is the correct forum for this type of question. Thanks to Eric for posting it! (And reminding me to take a look at it.) Berend suggests adding usleep to the send_packet() function. For some reason, I'm wary of this. Should I not be? In fact, why would Berend's computer (or LCDproc in general) be sending so much info so quickly to the screen anyway? More detailed stuff below, in response to Berend's original e-mail. ============================================= I have a Soundgraph VFD and I used to use the imonlcd driver from CVS from mid 2008 or so. >I'm guessing that you actually have an LCD? The VFD has a slightly different driver. The fact that your device is 0038 implies LCD to me. But since it won't let me shut down the back light I figured I tried upgrading to the latest version. That still won't be solved, as I believe shutting off the backlight actually turns the whole unit off. You can mess with the "contrast" settings, though. The current CVS version is broken for me with an 0038 device but I managed to fix it: when running LCDd, a lot of "imon: error writing to file descriptor: -1" errors appear in the output. Because the VFD controller can't keep up with the speed of the computer, it chokes on the commands. I've debugged the driver to make sure the the errors are not occuring because of a structural problem: they appear to be mostly random and occur after bursts of "send_packet()" calls. Actually, I don't know of anyone else with this problem. > >I've updated the send_packet function to test for the VFD device and if so, delay the packet sending with 5ms. Note that testing showed that 2 or 3ms delays were enough to stop the errors but to be on the safe side I've increased the delay to 5ms. > > >imonlcd.c: >/** >* Sends data to the screen. >* >* \param p The private data structure containing a tx_buf with the data to send. >*/ >static void >send_packet(PrivateData *p) >{ > int err; > err = write(p->imon_fd, p->tx_buf, sizeof(p->tx_buf)); > > > if (err <= 0) > printf("%s: error writing to file descriptor: %d", "imon", err); > /* If this is the VFD device, slow down communication to prevent overloading the controller */ > if (p->protocol == PROTOCOL_0038) usleep(5000); >} > >I'm wary of putting in "usleep" commands for a device driver. Should I not be? Does this not effect the FFDC device (or others)? > >Regards, >Berend Dekens > -Jonathan -------------- next part -------------- An HTML attachment was scrubbed... URL: From berend at cyberwizzard.nl Thu Sep 10 09:17:33 2009 From: berend at cyberwizzard.nl (Berend Dekens) Date: Thu, 10 Sep 2009 11:17:33 +0200 Subject: [Lcdproc] Fwd: imonlcd and 0038 breakage... In-Reply-To: <37208.47664.qm@web37501.mail.mud.yahoo.com> References: <4AA7AF58.4010701@cyberwizzard.nl> <46D13ECD-D5D5-4ABA-B025-682DF47CC475@cox.net> <37208.47664.qm@web37501.mail.mud.yahoo.com> Message-ID: <4AA8C42D.9030706@cyberwizzard.nl> Hi, I joined the mailing list to be able to reply to everyone properly. jk schreef: > Berend, the lcdproc mailing list is the correct forum for this type of > question. Thanks to Eric for posting it! (And reminding me to take a > look at it.) > > Berend suggests adding usleep to the send_packet() function. For some > reason, I'm wary of this. Should I not be? > > In fact, why would Berend's computer (or LCDproc in general) be > sending so much info so quickly to the screen anyway? If I'm not mistaken, each character is in fact an bitmap since the iMon displays seem to be matrix displays. This means that putting up a message means bursting data to the display. This normally ain't a problem unless you send data faster than the device (or USB bus?) can handle. > > More detailed stuff below, in response to Berend's original e-mail. > > ============================================= >> I have a Soundgraph VFD and I used to use the imonlcd driver from CVS >> from mid 2008 or so. > I'm guessing that you actually have an LCD? The VFD has a slightly > different driver. The fact that your device is 0038 implies LCD to me. Its the other way around, friend of mine has the FFDC device, which is an LCD. I have the VFD which is the 0038 device. >> But since it won't let me shut down the back light I figured I tried >> upgrading to the latest version. > That still won't be solved, as I believe shutting off the backlight > actually turns the whole unit off. You can mess with the "contrast" > settings, though. Actually that is exactly the solution: shutting down the VFD disables the backlight as well. Since without the backlight there is nothing to see anyway, it's all the same to me. >> The current CVS version is broken for me with an 0038 device but I >> managed to fix it: when running LCDd, a lot of "imon: error writing >> to file descriptor: -1" errors appear in the output. Because the VFD >> controller can't keep up with the speed of the computer, it chokes on >> the commands. I've debugged the driver to make sure the the errors >> are not occuring because of a structural problem: they appear to be >> mostly random and occur after bursts of "send_packet()" calls. > Actually, I don't know of anyone else with this problem. Google for it: the first versions of the VFD driver all had this problem. As long as you used a slow computer for it (I think even an Atom qualifies as slow as I remember the thread correctly) its all peaches. As soon as you use a quad core system like mine, the computer starts sending out data so fast that the device chokes on it and you get writing errors. >> >> I've updated the send_packet function to test for the VFD device and >> if so, delay the packet sending with 5ms. Note that testing showed >> that 2 or 3ms delays were enough to stop the errors but to be on the >> safe side I've increased the delay to 5ms. >> >> imonlcd.c: >> /** >> * Sends data to the screen. >> * >> * \param p The private data structure containing a tx_buf with the >> data to send. >> */ >> static void >> send_packet(PrivateData *p) >> { >> int err; >> err = write(p->imon_fd, p->tx_buf, sizeof(p->tx_buf)); >> >> if (err <= 0) >> printf("%s: error writing to file descriptor: %d", "imon", err); >> /* If this is the VFD device, slow down communication to prevent >> overloading the controller */ >> if (p->protocol == PROTOCOL_0038) usleep(5000); >> } >> > I'm wary of putting in "usleep" commands for a device driver. Should > I not be? Does this not effect the FFDC device (or others)? Using the delay could become a parameter in de LCDd.conf file, either a boolean or the number of microseconds to delay. Also, since I do not have the FFDC device I added the conditional to only delay when this is a 0038 device. On a side note, after inserting the delay, the imonlcd driver works like a charm for the VFD. I haven't checked the workings of the icons yet as I have to figure out how to make LCDd turn them on or off. Regards, Berend Dekens From berend at cyberwizzard.nl Thu Sep 10 09:23:20 2009 From: berend at cyberwizzard.nl (Berend Dekens) Date: Thu, 10 Sep 2009 11:23:20 +0200 Subject: [Lcdproc] Fedora 11 + imon VFD not reliably setting goodbye message. In-Reply-To: <4A80710C.4040200@simmons.titandsl.co.uk> References: <4A80710C.4040200@simmons.titandsl.co.uk> Message-ID: <4AA8C588.3090001@cyberwizzard.nl> Hi Chris, I got the same case as you with the VFD (0038) device. The backlight will be turned off if you use the latest imonlcd driver from CVS. To use it, set the Protocol to 1 (as you have the 0038 and not the default FFDC) and test if it works. If you get "imon: error writing to file descriptor: -1", please let us know. I figured out how to solve this but it would be nice to know if you suffer from the same issue. Also, wrong updates of the display or just the showing of the big clock are indications that the driver fails to send its commands. Regards, Berend Dekens From epooch at cox.net Thu Sep 10 15:27:14 2009 From: epooch at cox.net (Eric Pooch) Date: Thu, 10 Sep 2009 08:27:14 -0700 Subject: [Lcdproc] Fwd: imonlcd and 0038 breakage... References: <7C4036C2-805B-4207-8781-895B013D16C5@cox.net> Message-ID: <647156E3-A234-4163-A49E-28587D945DFB@cox.net> See below: On Sep 10, 2009, at 2:17 AM, Berend Dekens wrote: > Hi, > > I joined the mailing list to be able to reply to everyone properly. > > jk schreef: >> Berend, the lcdproc mailing list is the correct forum for this >> type of question. Thanks to Eric for posting it! (And reminding >> me to take a look at it.) >> >> Berend suggests adding usleep to the send_packet() function. For >> some reason, I'm wary of this. Should I not be? >> In fact, why would Berend's computer (or LCDproc in general) be >> sending so much info so quickly to the screen anyway? > If I'm not mistaken, each character is in fact an bitmap since the > iMon displays seem to be matrix displays. This means that putting > up a message means bursting data to the display. This normally > ain't a problem unless you send data faster than the device (or USB > bus?) can handle. I forget whether the VFD is a bipmap too. However, a single screen redraw should not cause a problem, regardless of the speed of the computer. [edited out backlight info] >> >>> The current CVS version is broken for me with an 0038 device but >>> I managed to fix it: when running LCDd, a lot of "imon: error >>> writing to file descriptor: -1" errors appear in the output. >>> Because the VFD controller can't keep up with the speed of the >>> computer, it chokes on the commands. I've debugged the driver to >>> make sure the the errors are not occuring because of a structural >>> problem: they appear to be mostly random and occur after bursts >>> of "send_packet()" calls. >> Actually, I don't know of anyone else with this problem. > Google for it: the first versions of the VFD driver all had this > problem. As long as you used a slow computer for it (I think even > an Atom qualifies as slow as I remember the thread correctly) its > all peaches. As soon as you use a quad core system like mine, the > computer starts sending out data so fast that the device chokes on > it and you get writing errors. This issue was addressed by adding a screen buffer and only sending out a new screen if the data has changed, rather than a complete screen re-draw every loop as in the old driver. This was tested on several fast dual core computers. Apparently it was not sufficient for very fast processors? But I would think that a fast processor would just have more loops without changes to the buffer, and more loops without redraws per minute. A fast and slow processor should have about the same number of screen re-draws per minute. This may differ with screens that are drawing graphs that will be constantly changing though. Have you noticed any particular screens where this is occurring often? 5 ms isn't much, but I don't think a pause is the correct solution as it will slow down the redraw on computers that are not having this problem. We will also have to deal with this issue again as even faster processors come out and 5 ms is not enough of a delay for them. Assuming that the problem is actually that faster processors are sending more screen redraws per minute, maybe we could add a configuration for imonlcd like this one : # Time to wait in ms after the refresh screen has been sent [default: 0] WaitAfterRefresh = 5 Also, as I recall there is a way to slow down LCDd as a whole. --Eric >>> >>> I've updated the send_packet function to test for the VFD device >>> and if so, delay the packet sending with 5ms. Note that testing >>> showed that 2 or 3ms delays were enough to stop the errors but to >>> be on the safe side I've increased the delay to 5ms. >>> >>> imonlcd.c: >>> /** >>> * Sends data to the screen. >>> * >>> * \param p The private data structure containing a tx_buf with >>> the data to send. >>> */ >>> static void >>> send_packet(PrivateData *p) >>> { >>> int err; >>> err = write(p->imon_fd, p->tx_buf, sizeof(p->tx_buf)); >>> >>> if (err <= 0) >>> printf("%s: error writing to file descriptor: %d", "imon", >>> err); >>> /* If this is the VFD device, slow down communication to >>> prevent overloading the controller */ >>> if (p->protocol == PROTOCOL_0038) usleep(5000); >>> } >>> >> I'm wary of putting in "usleep" commands for a device driver. >> Should I not be? Does this not effect the FFDC device (or others)? > Using the delay could become a parameter in de LCDd.conf file, > either a boolean or the number of microseconds to delay. Also, > since I do not have the FFDC device I added the conditional to only > delay when this is a 0038 device. > > On a side note, after inserting the delay, the imonlcd driver works > like a charm for the VFD. I haven't checked the workings of the > icons yet as I have to figure out how to make LCDd turn them on or > off. > > Regards, > Berend Dekens > _______________________________________________ > LCDproc mailing list > LCDproc at lists.omnipotent.net > http://lists.omnipotent.net/mailman/listinfo/lcdproc -------------- next part -------------- An HTML attachment was scrubbed... URL: From berend at cyberwizzard.nl Thu Sep 10 15:39:11 2009 From: berend at cyberwizzard.nl (Berend Dekens) Date: Thu, 10 Sep 2009 17:39:11 +0200 Subject: [Lcdproc] Fwd: imonlcd and 0038 breakage... In-Reply-To: <647156E3-A234-4163-A49E-28587D945DFB@cox.net> References: <7C4036C2-805B-4207-8781-895B013D16C5@cox.net> <647156E3-A234-4163-A49E-28587D945DFB@cox.net> Message-ID: <4AA91D9F.7080206@cyberwizzard.nl> Eric Pooch schreef: > > > This issue was addressed by adding a screen buffer and only sending > out a new screen if the data has changed, rather than a complete > screen re-draw every loop as in the old driver. This was tested on > several fast dual core computers. Apparently it was not sufficient > for very fast processors? But I would think that a fast processor > would just have more loops without changes to the buffer, and more > loops without redraws per minute. A fast and slow processor should > have about the same number of screen re-draws per minute. This may > differ with screens that are drawing graphs that will be constantly > changing though. > > Have you noticed any particular screens where this is occurring often? Every screen, not even the server screen comes up with the errors. And the send_packet function is called a lot so every burst makes it fail (scrolling a screen with a limited packet size equals a lot of packets) > > 5 ms isn't much, but I don't think a pause is the correct solution as > it will slow down the redraw on computers that are not having this > problem. We will also have to deal with this issue again as even > faster processors come out and 5 ms is not enough of a delay for them. Agreed, the old driver had the same problem. Some people had it solved with 2ms delay, others with 4ms - making it a parameter sounds like a good idea. > > Assuming that the problem is actually that faster processors are > sending more screen redraws per minute, maybe we could add a > configuration for imonlcd like this one : > # Time to wait in ms after the refresh screen has been sent [default: 0] > WaitAfterRefresh = 5 > > Also, as I recall there is a way to slow down LCDd as a whole. > > --Eric Regards, Berend From fblack947 at yahoo.com Thu Sep 10 15:51:03 2009 From: fblack947 at yahoo.com (jk) Date: Thu, 10 Sep 2009 08:51:03 -0700 (PDT) Subject: [Lcdproc] imonlcd and 0038 breakage... In-Reply-To: <4AA91D9F.7080206@cyberwizzard.nl> References: <7C4036C2-805B-4207-8781-895B013D16C5@cox.net> <647156E3-A234-4163-A49E-28587D945DFB@cox.net> <4AA91D9F.7080206@cyberwizzard.nl> Message-ID: <778605.11979.qm@web37504.mail.mud.yahoo.com> To summarize the imonlcd/0038/vfd problem, I think there are a few issues: 1. The issue appears to be with a VFD, while the driver is intended for LCDs. It is disturbing that the VFD appears to report the same ID as the LCD. 2. There may be a way to slow down LCDproc in general, rather than specific to a driver. 3. Assuming that addressing the above doesn't solve the issue, a configuration parameter appears to be the way to go. With 1, I'm very concerned about using the LCD driver to run a VFD. I'm a little surprised that it works at all. To me, the right place to address imon VFD driver issues is in the imon driver, not the imonlcd driver. Two would be ideal, as I am recalling the same as Eric - I think there is a way to do this by configuring LCDproc, and may be the best solution, requiring no code changes whatsoever. Three isn't that hard, but leads to configuration file bloat, and given the above two options, I'd rather avoid it. -Jonathan From jarod at wilsonet.com Thu Sep 10 16:03:41 2009 From: jarod at wilsonet.com (Jarod Wilson) Date: Thu, 10 Sep 2009 12:03:41 -0400 Subject: [Lcdproc] imonlcd and 0038 breakage... In-Reply-To: <778605.11979.qm@web37504.mail.mud.yahoo.com> References: <7C4036C2-805B-4207-8781-895B013D16C5@cox.net> <647156E3-A234-4163-A49E-28587D945DFB@cox.net> <4AA91D9F.7080206@cyberwizzard.nl> <778605.11979.qm@web37504.mail.mud.yahoo.com> Message-ID: <01076128-F57A-4450-AC70-87CAE84FF257@wilsonet.com> On Sep 10, 2009, at 11:51 AM, jk wrote: > To summarize the imonlcd/0038/vfd problem, I think there are a few > issues: > 1. The issue appears to be with a VFD, while the driver is > intended for LCDs. It is disturbing that the VFD appears to report > the same ID as the LCD. So far as I know, all 0038 are LCD. SoundGraph stopped doing stupid crap like giving the same device ID to wildly varying hardware after the ffdc devices (there are at *least* 4 different devices with ID ffdc). 0x0034 through 0x0046 are all unique devices, to the best of my knowledge. > 2. There may be a way to slow down LCDproc in general, rather than > specific to a driver. > 3. Assuming that addressing the above doesn't solve the issue, a > configuration parameter appears to be the way to go. > > With 1, I'm very concerned about using the LCD driver to run a VFD. > I'm a little surprised that it works at all. It wouldn't, if it were actually a VFD. The lirc_imon driver[*] explicitly sets a different write fop for VFD and LCD devices. Of course, its based on being able to detect the device as an LCD or VFD, and does so by device ID for the newer devices. And again, I'm pretty sure all 0038 (and 0045) are LCD, while 0036 and 0044 are VFD. > To me, the right place to address imon VFD driver issues is in the > imon driver, not the imonlcd driver. When you say 'imon driver', do you mean the lcdproc imon driver, or the kernel driver? [*] I maintain this, so I'm quite familiar with it... -- Jarod Wilson jarod at wilsonet.com From fblack947 at yahoo.com Thu Sep 10 16:34:53 2009 From: fblack947 at yahoo.com (jk) Date: Thu, 10 Sep 2009 09:34:53 -0700 (PDT) Subject: [Lcdproc] imonlcd and 0038 breakage... In-Reply-To: <01076128-F57A-4450-AC70-87CAE84FF257@wilsonet.com> References: <7C4036C2-805B-4207-8781-895B013D16C5@cox.net> <647156E3-A234-4163-A49E-28587D945DFB@cox.net> <4AA91D9F.7080206@cyberwizzard.nl> <778605.11979.qm@web37504.mail.mud.yahoo.com> <01076128-F57A-4450-AC70-87CAE84FF257@wilsonet.com> Message-ID: <938876.46781.qm@web37501.mail.mud.yahoo.com> > So far as I know, all 0038 are LCD. SoundGraph stopped doing stupid crap like > giving the same device ID to wildly varying hardware after the ffdc devices > (there are at *least* 4 different devices with ID ffdc). 0x0034 through 0x0046 > are all unique devices, to the best of my knowledge. > That's good to know! SoundGraph does seem to WANT to drive us insane. > It wouldn't, if it were actually a VFD. The lirc_imon driver[*] explicitly sets > a different write fop for VFD and LCD devices. Of course, its based on being > able to detect the device as an LCD or VFD, and does so by device ID for the > newer devices. And again, I'm pretty sure all 0038 (and 0045) are LCD, while > 0036 and 0044 are VFD. > > > To me, the right place to address imon VFD driver issues is in the imon > driver, not the imonlcd driver. > > When you say 'imon driver', do you mean the lcdproc imon driver, or the kernel > driver? > > [*] I maintain this, so I'm quite familiar with it... > > --Jarod Wilson > jarod at wilsonet.com Oooh, good, some history. The imonlcd driver came about by formalizing the adjustments made to the original imon driver, which was (as far as I can tell) originally intended for the VFDs. The LCD adjustments were mostly housed over at codeka as patches to the lcdproc code. The code from codeka was falling a bit behind, so Eric and I cleaned it up for formal entry into lcdproc's cvs and eventually version 0.5.3. Honestly, since the branch to codeka, I haven't been paying a whole lot of attention to the lcdproc imon driver (Jarod's driver?), as I assumed it was still intended for the VFD, and required extensive patching for it to work with the LCDs. To go even further, maybe it's time to look at merging the lcdproc imon and imonlcd drivers back together. (I can hear Markus's head exploding from here). So, Jarod - did the VFD have issues similar to what Berend is seeing? What was your fix? Thanks, Jonathan From epooch at cox.net Thu Sep 10 17:37:09 2009 From: epooch at cox.net (epooch at cox.net) Date: Thu, 10 Sep 2009 10:37:09 -0700 Subject: [Lcdproc] imonlcd and 0038 breakage... Message-ID: <20090910133709.TXAQ7.137104.imail@fed1rmwml35> the imon and imonlcd drivers use totally different protocols and are separated for an apparently good reason (although I did combine them when creating a Mac OS X driver). imonlcd is not the best name for the driver though, due to the obvious confusion. imon_bitmap might have been better. As I am now remembering, the later imon VFDs are bitmap VFDs and are do not have built-in character drivers (that we know about), just like the LCDs. That is the reason the drivers are separate: imon = character driver imonlcd = graphic/ bitmap driver The old codeka driver did not have a buffer to check if there were changes to the screen and would constantly stream data to the LCD/VFD, eventually causing it to crash. I added a change buffer to prevent this. During my testing, I estimated that about 1/10 the number of screen refreshes were required with the new driver, and I never saw a crash. I assumed the problem was fixed based on my belief that the problem was due to the sheer volume of data that was being sent. However, If 5ms is sufficient to make a difference, and it is occuring on every type of screen, there may be some wait time required by the VFD/LCD between packets. This would lead me to believe that the problem is in the kernel driver. ( I never had this problem on a fast Mac that obviously did not use the linux kernel driver) It would make more sense fo the kernel driver to be enforcing this since it is a hardware requirement. What kernel driver version are people using? Is any particular version showing this problem? --Eric ---- jk wrote: > > So far as I know, all 0038 are LCD. SoundGraph stopped doing stupid crap like > > giving the same device ID to wildly varying hardware after the ffdc devices > > (there are at *least* 4 different devices with ID ffdc). 0x0034 through 0x0046 > > are all unique devices, to the best of my knowledge. > > > > That's good to know! SoundGraph does seem to WANT to drive us insane. > > > > It wouldn't, if it were actually a VFD. The lirc_imon driver[*] explicitly sets > > a different write fop for VFD and LCD devices. Of course, its based on being > > able to detect the device as an LCD or VFD, and does so by device ID for the > > newer devices. And again, I'm pretty sure all 0038 (and 0045) are LCD, while > > 0036 and 0044 are VFD. > > > > > To me, the right place to address imon VFD driver issues is in the imon > > driver, not the imonlcd driver. > > > > When you say 'imon driver', do you mean the lcdproc imon driver, or the kernel > > driver? > > > > [*] I maintain this, so I'm quite familiar with it... > > > > --Jarod Wilson > > jarod at wilsonet.com > > Oooh, good, some history. The imonlcd driver came about by formalizing the adjustments made to the original imon driver, which was (as far as I can tell) originally intended for the VFDs. The LCD adjustments were mostly housed over at codeka as patches to the lcdproc code. The code from codeka was falling a bit behind, so Eric and I cleaned it up for formal entry into lcdproc's cvs and eventually version 0.5.3. > > Honestly, since the branch to codeka, I haven't been paying a whole lot of attention to the lcdproc imon driver (Jarod's driver?), as I assumed it was still intended for the VFD, and required extensive patching for it to work with the LCDs. > > To go even further, maybe it's time to look at merging the lcdproc imon and imonlcd drivers back together. (I can hear Markus's head exploding from here). > > So, Jarod - did the VFD have issues similar to what Berend is seeing? What was your fix? > > Thanks, > Jonathan > > > > _______________________________________________ > LCDproc mailing list > LCDproc at lists.omnipotent.net > http://lists.omnipotent.net/mailman/listinfo/lcdproc From fblack947 at yahoo.com Thu Sep 10 18:11:02 2009 From: fblack947 at yahoo.com (jk) Date: Thu, 10 Sep 2009 11:11:02 -0700 (PDT) Subject: [Lcdproc] imonlcd and 0038 breakage... In-Reply-To: <20090910133709.TXAQ7.137104.imail@fed1rmwml35> References: <20090910133709.TXAQ7.137104.imail@fed1rmwml35> Message-ID: <608064.6249.qm@web37501.mail.mud.yahoo.com> ----- Original Message ---- > From: "epooch at cox.net" ... > As I am now remembering, the later imon VFDs are bitmap VFDs and are do not have > built-in character drivers (that we know about), just like the LCDs. That is > the reason the drivers are separate: > imon = character driver > imonlcd = graphic/ bitmap driver > Ahh, yes. Thanks for the clarification and the reminder. I have to wait a few days to check my computer, as I'm in the middle of a move (again). I'm running (myth-)Ubuntu 8.10 in general, though. -Jonathan From jarod at wilsonet.com Thu Sep 10 18:47:42 2009 From: jarod at wilsonet.com (Jarod Wilson) Date: Thu, 10 Sep 2009 14:47:42 -0400 Subject: [Lcdproc] imonlcd and 0038 breakage... In-Reply-To: <938876.46781.qm@web37501.mail.mud.yahoo.com> References: <7C4036C2-805B-4207-8781-895B013D16C5@cox.net> <647156E3-A234-4163-A49E-28587D945DFB@cox.net> <4AA91D9F.7080206@cyberwizzard.nl> <778605.11979.qm@web37504.mail.mud.yahoo.com> <01076128-F57A-4450-AC70-87CAE84FF257@wilsonet.com> <938876.46781.qm@web37501.mail.mud.yahoo.com> Message-ID: On Sep 10, 2009, at 12:34 PM, jk wrote: > Oooh, good, some history. The imonlcd driver came about by > formalizing the adjustments made to the original imon driver, which > was (as far as I can tell) originally intended for the VFDs. The > LCD adjustments were mostly housed over at codeka as patches to the > lcdproc code. The code from codeka was falling a bit behind, so > Eric and I cleaned it up for formal entry into lcdproc's cvs and > eventually version 0.5.3. Yep, I know, I was actually patching the stuff from codeka into the Fedora lcdproc packages for a while... :) > Honestly, since the branch to codeka, I haven't been paying a whole > lot of attention to the lcdproc imon driver (Jarod's driver?), Nope, not mine. > as I assumed it was still intended for the VFD, and required > extensive patching for it to work with the LCDs. > > To go even further, maybe it's time to look at merging the lcdproc > imon and imonlcd drivers back together. (I can hear Markus's head > exploding from here). For whatever its worth, all imon devices are driven by the same kernel driver, so it wouldn't be without precedent. The IR handling is pretty uniform between all the devices (identical between current LCD and VFD and display-less devices), the only thing that's different is really the display device write fop. > So, Jarod - did the VFD have issues similar to what Berend is > seeing? What was your fix? I have no clue. The only device I have is the 0045 LCD, which is an Antec Veris Premiere, a rebadged version of the iMON UltraBay. I used the Fedora 0.5.2 lcdproc packages patched with the imonlcd bits for a while, and currently use the Fedora 0.5.3 lcdproc packages. -- Jarod Wilson jarod at wilsonet.com From jarod at wilsonet.com Thu Sep 10 18:55:27 2009 From: jarod at wilsonet.com (Jarod Wilson) Date: Thu, 10 Sep 2009 14:55:27 -0400 Subject: [Lcdproc] imonlcd and 0038 breakage... In-Reply-To: <20090910133709.TXAQ7.137104.imail@fed1rmwml35> References: <20090910133709.TXAQ7.137104.imail@fed1rmwml35> Message-ID: <0CB63D76-24DE-483B-835C-24564920919B@wilsonet.com> On Sep 10, 2009, at 1:37 PM, wrote: > the imon and imonlcd drivers use totally different protocols and are > separated for an apparently good reason (although I did combine them > when creating a Mac OS X driver). imonlcd is not the best name for > the driver though, due to the obvious confusion. imon_bitmap might > have been better. > > As I am now remembering, the later imon VFDs are bitmap VFDs and are > do not have built-in character drivers (that we know about), just > like the LCDs. That is the reason the drivers are separate: > imon = character driver > imonlcd = graphic/ bitmap driver What driver does someone with the 0036 imon device choose? I honestly don't know... Its definitely a VFD, and uses a different write fop than the 0038 in the lirc_imon kernel driver, but I don't actually know what lcdproc driver is appropriate for it... > The old codeka driver did not have a buffer to check if there were > changes to the screen and would constantly stream data to the LCD/ > VFD, eventually causing it to crash. > > I added a change buffer to prevent this. During my testing, I > estimated that about 1/10 the number of screen refreshes were > required with the new driver, and I never saw a crash. I assumed > the problem was fixed based on my belief that the problem was due to > the sheer volume of data that was being sent. > However, If 5ms is sufficient to make a difference, and it is > occuring on every type of screen, there may be some wait time > required by the VFD/LCD between packets. This would lead me to > believe that the problem is in the kernel driver. ( I never had > this problem on a fast Mac that obviously did not use the linux > kernel driver) It would make more sense fo the kernel driver to be > enforcing this since it is a hardware requirement. That's certainly doable. I've not had any issues with my own LCD device, but its in a lowly Atom system right now, and I don't really care about shutdown issues, as it never gets shut down... Never really had issues (other than it not powering off on shutdown) in a dual-core opteron system either though. > What kernel driver version are people using? Is any particular > version showing this problem? $ modinfo lirc_imon filename: /lib/modules/2.6.29.6-217.2.16.fc11.x86_64/kernel/ drivers/input/lirc/lirc_imon.ko license: GPL version: 0.6 ... More or less matches current lirc cvs and my lirc git tree. -- Jarod Wilson jarod at wilsonet.com From epooch at cox.net Thu Sep 10 20:49:07 2009 From: epooch at cox.net (epooch at cox.net) Date: Thu, 10 Sep 2009 16:49:07 -0400 Subject: [Lcdproc] imonlcd and 0038 breakage... In-Reply-To: <0CB63D76-24DE-483B-835C-24564920919B@wilsonet.com> Message-ID: <20090910164907.5JB7O.140567.imail@fed1rmwml35> Berend, please double check your imon device. We believe you have an LCD based on: 1) device ID 2) your mention of icons on the device (the LCDs have these) which does it look like: LCD http://codeka.com/blogs/media/imonlcd-0.3.jpg or: VFD http://members.cox.net/~epooch/images/imon_0x0036.jpg I think the write error imonlcd is receiving is coming from lirc. Does lirc have any logging that can be enabled? If we receive a write error from lirc, can we "re-init" the lcd and continue, or is the lcd just dead until a full power on and off? Jarod, See below: ---- Jarod Wilson wrote: > On Sep 10, 2009, at 1:37 PM, wrote: > What driver does someone with the 0036 imon device choose? I honestly > don't know... Its definitely a VFD, and uses a different write fop > than the 0038 in the lirc_imon kernel driver, but I don't actually > know what lcdproc driver is appropriate for it... > I just checked the imonlcd driver and it is a bit misleading. If you have an LCD, or you have a VFD that is graphical, then you should use the imonlcd driver. As I recall, from lirc_imon, the VFDs and LCDs are the ones included in: lcd_device_list[] or vfd_proto_6p_list[] which includes 0x0036 Only one driver or the other should work. I don't think there are any imon products that have a text and pixel abilities, and if they do, it probably hasn't been implemented in the lirc driver. From wyldfire00101010 at yahoo.com Thu Sep 10 20:52:00 2009 From: wyldfire00101010 at yahoo.com (Leif Hassell) Date: Thu, 10 Sep 2009 13:52:00 -0700 (PDT) Subject: [Lcdproc] imonlcd and 0038 breakage... Message-ID: <181687.72239.qm@web57702.mail.re3.yahoo.com> Decided to bite the bullet and subscribe so I could join in on this. I have an Imon LCD (model 15c2:ffdc) and it has been giving me fits. It has been randomly freezing as well, and I'm unsure as to the cause. Perhaps I could provide some real-world test data to assist? I'm running ubuntu 9.04, lirc 0.8.6, and lcdproc 0.5.2-0ubuntu2. Under this config, lirc works, but lcdproc produces nothing. I had previously been using the codeka-patched lcdproc, and was getting info to the LCD screen, but it kept locking up, which is why I tried a fresh install of lcdproc. Can anyone suggest a good course of action? I can post any logs required. Thanks, Leif -------------- next part -------------- An HTML attachment was scrubbed... URL: From wyldfire00101010 at yahoo.com Thu Sep 10 22:30:54 2009 From: wyldfire00101010 at yahoo.com (Leif Hassell) Date: Thu, 10 Sep 2009 15:30:54 -0700 (PDT) Subject: [Lcdproc] (no subject) Message-ID: <148012.9700.qm@web57702.mail.re3.yahoo.com> Ok... after quite a bit of feeling around in the dark, I've set up 0.5.3 on my machine. It is working now; the real question is if I get the same lockups as before. I will update you in the next couple of days, or when it locks up, whichever comes first. Thanks for the help. Leif P.S. Just as an aside, is there any way to get the BigClock function to display in 12-hour rather than 24-hour mode? -------------- next part -------------- An HTML attachment was scrubbed... URL: From wyldfire00101010 at yahoo.com Thu Sep 10 23:17:56 2009 From: wyldfire00101010 at yahoo.com (Leif Hassell) Date: Thu, 10 Sep 2009 16:17:56 -0700 (PDT) Subject: [Lcdproc] imonlcd and 0038 breakage... Message-ID: <947581.44273.qm@web57708.mail.re3.yahoo.com> lcdproc 0.5.3 and lirc are still locking up. Unsure as to where to go from here. Any logfiles that would help? Thanks, Leif ________________________________ From: jk To: Leif Hassell Sent: Thursday, September 10, 2009 4:04:52 PM Subject: Re: [Lcdproc] imonlcd and 0038 breakage... I have an Imon LCD (model 15c2:ffdc) and it has been giving me fits. It has been randomly freezing as well, and I'm unsure as to the cause. Perhaps I could provide some real-world test data to assist? > > >I'm running ubuntu 9.04, lirc 0.8.6, and lcdproc 0.5.2-0ubuntu2. ... > >I'd suggest trying lcdproc 0.5.3. As Eric mentioned, it implements a frame buffer which should help with the stability (in fact, he wrote it). I have the same LCD, and it runs fine under ubuntu 8.10 and lcdproc 0.5.3. I have to check what version of lirc I have. -Jonathan -------------- next part -------------- An HTML attachment was scrubbed... URL: From jarod at wilsonet.com Fri Sep 11 00:57:58 2009 From: jarod at wilsonet.com (Jarod Wilson) Date: Thu, 10 Sep 2009 20:57:58 -0400 Subject: [Lcdproc] imonlcd and 0038 breakage... In-Reply-To: <947581.44273.qm@web57708.mail.re3.yahoo.com> References: <947581.44273.qm@web57708.mail.re3.yahoo.com> Message-ID: <4AA9A096.4000607@wilsonet.com> On 09/10/2009 07:17 PM, Leif Hassell wrote: > lcdproc 0.5.3 and lirc are still locking up. Unsure as to where to go > from here. > > Any logfiles that would help? Kernel messages from the lockup would be good -- don't suppose you can set up serial console output? Anyhow, I've double-checked some things in the lirc_imon code, and I do see at least one case where I do think a deadlock is possible... Within ir_open(), imon_set_ir_protocol() can get called, and when it is, its called without the context lock held, and that in turn calls send_packet(), which calls mutex_unlock() followed by mutex_lock() on that lock wasn't already held. However, from what I can see, this would *only* trigger if you were shifting ir protocols on the fly. The initial setting of protocol happens with the lock properly held. I'll definitely fix this of course, but I'm guessing its not the cause of your lockup. > ------------------------------------------------------------------------ > *From:* jk > *To:* Leif Hassell > *Sent:* Thursday, September 10, 2009 4:04:52 PM > *Subject:* Re: [Lcdproc] imonlcd and 0038 breakage... > > > **I have an Imon LCD (model 15c2:ffdc) and it has been giving me > fits. It has been randomly freezing as well, and I'm unsure as to > the cause. Perhaps I could provide some real-world test data to assist? > > I'm running ubuntu 9.04, lirc 0.8.6, and lcdproc 0.5.2-0ubuntu2. ... > > > I'd suggest trying lcdproc 0.5.3. As Eric mentioned, it implements a > frame buffer which should help with the stability (in fact, he wrote it). > > I have the same LCD, and it runs fine under ubuntu 8.10 and lcdproc > 0.5.3. I have to check what version of lirc I have. -- Jarod Wilson jarod at wilsonet.com From jarod at wilsonet.com Fri Sep 11 01:18:46 2009 From: jarod at wilsonet.com (Jarod Wilson) Date: Thu, 10 Sep 2009 21:18:46 -0400 Subject: [Lcdproc] imonlcd and 0038 breakage... In-Reply-To: <20090910164907.5JB7O.140567.imail@fed1rmwml35> References: <20090910164907.5JB7O.140567.imail@fed1rmwml35> Message-ID: <4AA9A576.1070805@wilsonet.com> On 09/10/2009 04:49 PM, epooch at cox.net wrote: > Berend, > please double check your imon device. We believe you have an LCD based on: > 1) device ID > 2) your mention of icons on the device (the LCDs have these) > which does it look like: > LCD > http://codeka.com/blogs/media/imonlcd-0.3.jpg > or: > VFD > http://members.cox.net/~epooch/images/imon_0x0036.jpg > > I think the write error imonlcd is receiving is coming from lirc. Does lirc have any logging that can be enabled? The driver is already quite chatty when anything fails inside lcd_write() and semi-chatty inside send_packet(), which lcd_write() calls, but if lirc_imon is loaded with debug=1, it'll also print out info on successful writes. Probably not useful in this case though, the relevant failure stuff should already be spewed into dmesg... > If we receive a write error from lirc, can we "re-init" the lcd and continue, or is the lcd just dead until a full power on and off? The driver returns the number of bytes written in the success case, and assorted other values, depending on the failure mode... But typically something in the negative value range. > ---- Jarod Wilson wrote: >> On Sep 10, 2009, at 1:37 PM, wrote: > >> What driver does someone with the 0036 imon device choose? I honestly >> don't know... Its definitely a VFD, and uses a different write fop >> than the 0038 in the lirc_imon kernel driver, but I don't actually >> know what lcdproc driver is appropriate for it... >> > > I just checked the imonlcd driver and it is a bit misleading. > If you have an LCD, or you have a VFD that is graphical, then you should use the imonlcd driver. As I recall, from lirc_imon, the VFDs and LCDs are the ones included in: > lcd_device_list[] > or > vfd_proto_6p_list[] > which includes 0x0036 Yep, that looks right. Looks like the only thing that *doesn't* cover is the ancient 0x0aa8:0xffda VFD... > Only one driver or the other should work. I don't think there are any imon products that have a text and pixel abilities, and if they do, it probably hasn't been implemented in the lirc driver. Hrm. Its supposed to support the original imon device that uses the old imon lcdproc driver... Have to agree, imonlcd seems like it might not be the best name for the newer driver... :) -- Jarod Wilson jarod at wilsonet.com From jarod at wilsonet.com Fri Sep 11 01:30:49 2009 From: jarod at wilsonet.com (Jarod Wilson) Date: Thu, 10 Sep 2009 21:30:49 -0400 Subject: [Lcdproc] imonlcd and 0038 breakage... In-Reply-To: <695908.12772.qm@web57706.mail.re3.yahoo.com> References: <947581.44273.qm@web57708.mail.re3.yahoo.com> <4AA9A096.4000607@wilsonet.com> <695908.12772.qm@web57706.mail.re3.yahoo.com> Message-ID: <4AA9A849.7060702@wilsonet.com> On 09/10/2009 09:12 PM, Leif Hassell wrote: > Attaching a zip of the kernel log. The thing is far too big. I am CC-ing > it directly to you as well, as I am not sure that the mailing list will > forward attachments. Got it via off-list, I presume, and have looked it over. And first up... Huaglhaglah. You're running a rather old lirc_imon driver, not anything close to the current one. The driver has been massively overhauled in the past year or so, but ubuntu is apparently still shipping an ancient driver. I can't be of much help debugging that, would suggest you upgrade to the current cvs driver. Chances are that it'll behave much much better. > As for a serial console, I am not afraid to admit I > have no idea how to do that. But I can be instructed. What do I need to do? Hold off on that until you've tried the current driver. > ------------------------------------------------------------------------ > *From:* Jarod Wilson > *To:* Leif Hassell > *Cc:* lcdproc at lists.omnipotent.net > *Sent:* Thursday, September 10, 2009 7:57:58 PM > *Subject:* Re: [Lcdproc] imonlcd and 0038 breakage... > > On 09/10/2009 07:17 PM, Leif Hassell wrote: > > lcdproc 0.5.3 and lirc are still locking up. Unsure as to where to go > > from here. > > > > Any logfiles that would help? > > Kernel messages from the lockup would be good -- don't suppose you can > set up serial console output? > > Anyhow, I've double-checked some things in the lirc_imon code, and I do > see at least one case where I do think a deadlock is possible... Within > ir_open(), imon_set_ir_protocol() can get called, and when it is, its > called without the context lock held, and that in turn calls > send_packet(), which calls mutex_unlock() followed by mutex_lock() on > that lock wasn't already held. > > However, from what I can see, this would *only* trigger if you were > shifting ir protocols on the fly. The initial setting of protocol > happens with the lock properly held. I'll definitely fix this of course, > but I'm guessing its not the cause of your lockup. > > > > > ------------------------------------------------------------------------ > > *From:* jk > > > *To:* Leif Hassell > > > *Sent:* Thursday, September 10, 2009 4:04:52 PM > > *Subject:* Re: [Lcdproc] imonlcd and 0038 breakage... > > > > > > **I have an Imon LCD (model 15c2:ffdc) and it has been giving me > > fits. It has been randomly freezing as well, and I'm unsure as to > > the cause. Perhaps I could provide some real-world test data to assist? > > > > I'm running ubuntu 9.04, lirc 0.8.6, and lcdproc 0.5.2-0ubuntu2. ... > > > > > > I'd suggest trying lcdproc 0.5.3. As Eric mentioned, it implements a > > frame buffer which should help with the stability (in fact, he wrote it). > > > > I have the same LCD, and it runs fine under ubuntu 8.10 and lcdproc > > 0.5.3. I have to check what version of lirc I have. -- Jarod Wilson jarod at wilsonet.com From wyldfire00101010 at yahoo.com Fri Sep 11 01:31:05 2009 From: wyldfire00101010 at yahoo.com (Leif Hassell) Date: Thu, 10 Sep 2009 18:31:05 -0700 (PDT) Subject: [Lcdproc] imonlcd and 0038 breakage... In-Reply-To: <4AA9A849.7060702@wilsonet.com> References: <947581.44273.qm@web57708.mail.re3.yahoo.com> <4AA9A096.4000607@wilsonet.com> <695908.12772.qm@web57706.mail.re3.yahoo.com> <4AA9A849.7060702@wilsonet.com> Message-ID: <376783.4277.qm@web57703.mail.re3.yahoo.com> I am running lirc 0.8.6-cvs. That should have the latest lirc_imon driver, right? How would I change that? ________________________________ From: Jarod Wilson To: Leif Hassell Cc: lcdproc at lists.omnipotent.net Sent: Thursday, September 10, 2009 8:30:49 PM Subject: Re: [Lcdproc] imonlcd and 0038 breakage... On 09/10/2009 09:12 PM, Leif Hassell wrote: > Attaching a zip of the kernel log. The thing is far too big. I am CC-ing > it directly to you as well, as I am not sure that the mailing list will > forward attachments. Got it via off-list, I presume, and have looked it over. And first up... Huaglhaglah. You're running a rather old lirc_imon driver, not anything close to the current one. The driver has been massively overhauled in the past year or so, but ubuntu is apparently still shipping an ancient driver. I can't be of much help debugging that, would suggest you upgrade to the current cvs driver. Chances are that it'll behave much much better. > As for a serial console, I am not afraid to admit I > have no idea how to do that. But I can be instructed. What do I need to do? Hold off on that until you've tried the current driver. > ------------------------------------------------------------------------ > *From:* Jarod Wilson > *To:* Leif Hassell > *Cc:* lcdproc at lists.omnipotent.net > *Sent:* Thursday, September 10, 2009 7:57:58 PM > *Subject:* Re: [Lcdproc] imonlcd and 0038 breakage... > > On 09/10/2009 07:17 PM, Leif Hassell wrote: > > lcdproc 0.5.3 and lirc are still locking up. Unsure as to where to go > > from here. > > > > Any logfiles that would help? > > Kernel messages from the lockup would be good -- don't suppose you can > set up serial console output? > > Anyhow, I've double-checked some things in the lirc_imon code, and I do > see at least one case where I do think a deadlock is possible... Within > ir_open(), imon_set_ir_protocol() can get called, and when it is, its > called without the context lock held, and that in turn calls > send_packet(), which calls mutex_unlock() followed by mutex_lock() on > that lock wasn't already held. > > However, from what I can see, this would *only* trigger if you were > shifting ir protocols on the fly. The initial setting of protocol > happens with the lock properly held. I'll definitely fix this of course, > but I'm guessing its not the cause of your lockup. > > > > > ------------------------------------------------------------------------ > > *From:* jk > > > *To:* Leif Hassell > > > *Sent:* Thursday, September 10, 2009 4:04:52 PM > > *Subject:* Re: [Lcdproc] imonlcd and 0038 breakage... > > > > > > **I have an Imon LCD (model 15c2:ffdc) and it has been giving me > > fits. It has been randomly freezing as well, and I'm unsure as to > > the cause. Perhaps I could provide some real-world test data to assist? > > > > I'm running ubuntu 9.04, lirc 0.8.6, and lcdproc 0.5.2-0ubuntu2. ... > > > > > > I'd suggest trying lcdproc 0.5.3. As Eric mentioned, it implements a > > frame buffer which should help with the stability (in fact, he wrote it). > > > > I have the same LCD, and it runs fine under ubuntu 8.10 and lcdproc > > 0.5.3. I have to check what version of lirc I have. -- Jarod Wilson jarod at wilsonet.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From jarod at wilsonet.com Fri Sep 11 01:38:09 2009 From: jarod at wilsonet.com (Jarod Wilson) Date: Thu, 10 Sep 2009 21:38:09 -0400 Subject: [Lcdproc] imonlcd and 0038 breakage... In-Reply-To: <376783.4277.qm@web57703.mail.re3.yahoo.com> References: <947581.44273.qm@web57708.mail.re3.yahoo.com> <4AA9A096.4000607@wilsonet.com> <695908.12772.qm@web57706.mail.re3.yahoo.com> <4AA9A849.7060702@wilsonet.com> <376783.4277.qm@web57703.mail.re3.yahoo.com> Message-ID: <4AA9AA01.4040100@wilsonet.com> On 09/10/2009 09:31 PM, Leif Hassell wrote: > > I am running lirc 0.8.6-cvs. That should have the latest lirc_imon > driver, right? How would I change that? You're running lirc 0.8.6-cvs userspace. You need to also run the lirc_imon.ko from cvs. You've got the lirc_imon.ko shipped with the ubuntu kernel loading instead of the cvs one. Put the cvs-built ko files in a depmod path that overrides the stock ones, or just nuke the stock ones, and run depmod, then reload the driver. -- Jarod Wilson jarod at wilsonet.com From wyldfire00101010 at yahoo.com Fri Sep 11 02:26:38 2009 From: wyldfire00101010 at yahoo.com (Leif Hassell) Date: Thu, 10 Sep 2009 19:26:38 -0700 (PDT) Subject: [Lcdproc] imonlcd and 0038 breakage... In-Reply-To: <4AA9AA01.4040100@wilsonet.com> References: <947581.44273.qm@web57708.mail.re3.yahoo.com> <4AA9A096.4000607@wilsonet.com> <695908.12772.qm@web57706.mail.re3.yahoo.com> <4AA9A849.7060702@wilsonet.com> <376783.4277.qm@web57703.mail.re3.yahoo.com> <4AA9AA01.4040100@wilsonet.com> Message-ID: <205886.29711.qm@web57703.mail.re3.yahoo.com> I cannot find the cvs imon_lcd.ko file. Where would it be? Can I download it somewhere? ________________________________ From: Jarod Wilson To: Leif Hassell Cc: lcdproc at lists.omnipotent.net Sent: Thursday, September 10, 2009 8:38:09 PM Subject: Re: [Lcdproc] imonlcd and 0038 breakage... On 09/10/2009 09:31 PM, Leif Hassell wrote: > > I am running lirc 0.8.6-cvs. That should have the latest lirc_imon > driver, right? How would I change that? You're running lirc 0.8.6-cvs userspace. You need to also run the lirc_imon.ko from cvs. You've got the lirc_imon.ko shipped with the ubuntu kernel loading instead of the cvs one. Put the cvs-built ko files in a depmod path that overrides the stock ones, or just nuke the stock ones, and run depmod, then reload the driver. -- Jarod Wilson jarod at wilsonet.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From jarod at wilsonet.com Fri Sep 11 02:41:01 2009 From: jarod at wilsonet.com (Jarod Wilson) Date: Thu, 10 Sep 2009 22:41:01 -0400 Subject: [Lcdproc] imonlcd and 0038 breakage... In-Reply-To: <205886.29711.qm@web57703.mail.re3.yahoo.com> References: <947581.44273.qm@web57708.mail.re3.yahoo.com> <4AA9A096.4000607@wilsonet.com> <695908.12772.qm@web57706.mail.re3.yahoo.com> <4AA9A849.7060702@wilsonet.com> <376783.4277.qm@web57703.mail.re3.yahoo.com> <4AA9AA01.4040100@wilsonet.com> <205886.29711.qm@web57703.mail.re3.yahoo.com> Message-ID: <4AA9B8BD.10400@wilsonet.com> On 09/10/2009 10:26 PM, Leif Hassell wrote: > > I cannot find the cvs imon_lcd.ko file. Where would it be? Can I > download it somewhere? Its built from lirc cvs source... Are you running lirc cvs binary userspace packages from Jeremy Yoder's PPA, or your own build? Jeremy's PPA includes an lirc-modules-source package as well, iirc, which uses dkms (again, iirc) to build and install updated kernel modules. (All iirc, because I don't run ubuntu). > ------------------------------------------------------------------------ > *From:* Jarod Wilson > *To:* Leif Hassell > *Cc:* lcdproc at lists.omnipotent.net > *Sent:* Thursday, September 10, 2009 8:38:09 PM > *Subject:* Re: [Lcdproc] imonlcd and 0038 breakage... > > On 09/10/2009 09:31 PM, Leif Hassell wrote: > > > > I am running lirc 0.8.6-cvs. That should have the latest lirc_imon > > driver, right? How would I change that? > > You're running lirc 0.8.6-cvs userspace. You need to also run the > lirc_imon.ko from cvs. You've got the lirc_imon.ko shipped with the > ubuntu kernel loading instead of the cvs one. Put the cvs-built ko files > in a depmod path that overrides the stock ones, or just nuke the stock > ones, and run depmod, then reload the driver. -- Jarod Wilson jarod at wilsonet.com From berend at cyberwizzard.nl Fri Sep 11 08:22:42 2009 From: berend at cyberwizzard.nl (Berend Dekens) Date: Fri, 11 Sep 2009 10:22:42 +0200 Subject: [Lcdproc] imonlcd and 0038 breakage... In-Reply-To: <20090910164907.5JB7O.140567.imail@fed1rmwml35> References: <20090910164907.5JB7O.140567.imail@fed1rmwml35> Message-ID: <4AAA08D2.4020505@cyberwizzard.nl> epooch at cox.net schreef: > Berend, > please double check your imon device. We believe you have an LCD based on: > 1) device ID > 2) your mention of icons on the device (the LCDs have these) > which does it look like: > LCD > http://codeka.com/blogs/media/imonlcd-0.3.jpg > or: > VFD > http://members.cox.net/~epooch/images/imon_0x0036.jpg > Thanks for that, I just made pictures myself. Looking at them I assume I have an LCD and *not* a VFD... I'm feeling sort of screwed though as I ordered the VFD for better readability and thought the display was shoddy at best since I unboxed it. To be sure, here is a picture of my display: http://www.flickr.com/photos/41748755 at N08/3906626228/ On a side note, the driver is still errorless after running for a full day with the delays. The only issue I have now is that the contrast sometimes seems to disappear making the whole LCD light up (looking at it from a weird angle shows that there is still text on the display, its just not readable). Berend Dekens From allsorts at howhill.com Fri Sep 11 08:57:34 2009 From: allsorts at howhill.com (Dave Liquorice) Date: Fri, 11 Sep 2009 09:57:34 +0100 (BST) Subject: [Lcdproc] imonlcd and 0038 breakage... In-Reply-To: <4AAA08D2.4020505@cyberwizzard.nl> Message-ID: On Fri, 11 Sep 2009 10:22:42 +0200, Berend Dekens wrote: > To be sure, here is a picture of my display: > http://www.flickr.com/photos/41748755 at N08/3906626228/ Well at first glance that looks VFD to me but these days some LCDs also have a similar appearance. > The only issue I have now is that the contrast sometimes seems to > disappear making the whole LCD light up (looking at it from a weird angle > shows that there is still text on the display, its just not readable). Not sure I follow that. Best bet is to look at the actual display module itself without any filters or stuff in the way. A VFD will be a vacuum sealed glass enclosure with lots of fine wires, grids and meshes inside. A LCD will be a flat sandwich of a couple of bits of thin glass with no bits of wire or mesh. -- Cheers Dave. From ethan.dicks at gmail.com Fri Sep 11 15:48:11 2009 From: ethan.dicks at gmail.com (Ethan Dicks) Date: Fri, 11 Sep 2009 11:48:11 -0400 Subject: [Lcdproc] imonlcd and 0038 breakage... In-Reply-To: <4aaa1154.4444f10a.2393.ffffc3e0SMTPIN_ADDED@mx.google.com> References: <4AAA08D2.4020505@cyberwizzard.nl> <4aaa1154.4444f10a.2393.ffffc3e0SMTPIN_ADDED@mx.google.com> Message-ID: On Fri, Sep 11, 2009 at 4:57 AM, Dave Liquorice wrote: > On Fri, 11 Sep 2009 10:22:42 +0200, Berend Dekens wrote: > >> To be sure, here is a picture of my display: >> http://www.flickr.com/photos/41748755 at N08/3906626228/ > > Well at first glance that looks VFD to me but these days some LCDs also have > a similar appearance. > >> The only issue I have now is that the contrast sometimes seems to >> disappear making the whole LCD light up (looking at it from a weird angle >> shows that there is still text on the display, its just not readable). > > Not sure I follow that. If you are talking about 'contrast', it's LCD. VFDs have brightness since the elements emit light. LCDs block light, either from room ambient light (reflective) or a backlight (transmissive). LCDs are polarized elements, so they have a viewing angle issue that VFDs do not. > Best bet is to look at the actual display module itself without any filters > or stuff in the way. A VFD will be a vacuum sealed glass enclosure with lots > of fine wires, grids and meshes inside. A LCD will be a flat sandwich of a > couple of bits of thin glass with no bits of wire or mesh. Yep. Also, if you take it apart far enough to inspect, VFDs have a vacuum "nipple" that LCDs do not. -ethan From jarod at wilsonet.com Fri Sep 11 16:04:37 2009 From: jarod at wilsonet.com (Jarod Wilson) Date: Fri, 11 Sep 2009 12:04:37 -0400 Subject: [Lcdproc] imonlcd and 0038 breakage... In-Reply-To: <20090911085825.F3FED9446C8@mail.wilsonet.com> References: <20090911085825.F3FED9446C8@mail.wilsonet.com> Message-ID: <4AAA7515.70202@wilsonet.com> On 09/11/2009 04:57 AM, Dave Liquorice wrote: > On Fri, 11 Sep 2009 10:22:42 +0200, Berend Dekens wrote: > >> To be sure, here is a picture of my display: >> http://www.flickr.com/photos/41748755 at N08/3906626228/ > > Well at first glance that looks VFD to me but these days some LCDs also have > a similar appearance. That's an iMON LCD. Their VFD don't have all the icons. (I have an iMON LCD myself, the display there is identical). -- Jarod Wilson jarod at wilsonet.com From wyldfire00101010 at yahoo.com Sat Sep 12 00:17:17 2009 From: wyldfire00101010 at yahoo.com (Leif Hassell) Date: Fri, 11 Sep 2009 17:17:17 -0700 (PDT) Subject: [Lcdproc] imonlcd and 0038 breakage... In-Reply-To: <4AAA7515.70202@wilsonet.com> References: <20090911085825.F3FED9446C8@mail.wilsonet.com> <4AAA7515.70202@wilsonet.com> Message-ID: <378527.26728.qm@web57703.mail.re3.yahoo.com> Finally got everything updated to the latest version. Had to wipe and start from scratch to get it where it needed to be. So far, so good. Thanks for all the help. Will update if situation goes bad. Leif ________________________________ From: Jarod Wilson To: Dave Liquorice Cc: "LCDproc at lists.omnipotent.net" Sent: Friday, September 11, 2009 11:04:37 AM Subject: Re: [Lcdproc] imonlcd and 0038 breakage... On 09/11/2009 04:57 AM, Dave Liquorice wrote: > On Fri, 11 Sep 2009 10:22:42 +0200, Berend Dekens wrote: > >> To be sure, here is a picture of my display: >> http://www.flickr.com/photos/41748755 at N08/3906626228/ > > Well at first glance that looks VFD to me but these days some LCDs also have > a similar appearance. That's an iMON LCD. Their VFD don't have all the icons. (I have an iMON LCD myself, the display there is identical). -- Jarod Wilson jarod at wilsonet.com _______________________________________________ LCDproc mailing list LCDproc at lists.omnipotent.net http://lists.omnipotent.net/mailman/listinfo/lcdproc -------------- next part -------------- An HTML attachment was scrubbed... URL: From wyldfire00101010 at yahoo.com Sat Sep 12 00:19:26 2009 From: wyldfire00101010 at yahoo.com (Leif Hassell) Date: Fri, 11 Sep 2009 17:19:26 -0700 (PDT) Subject: [Lcdproc] imonlcd and 0038 breakage... In-Reply-To: <4AAA7515.70202@wilsonet.com> References: <20090911085825.F3FED9446C8@mail.wilsonet.com> <4AAA7515.70202@wilsonet.com> Message-ID: <424547.36499.qm@web57705.mail.re3.yahoo.com> Finally got everything updated to the latest version. Had to wipe and start from scratch to get it where it needed to be. So far, so good. Thanks for all the help. Will update if situation goes bad. Leif ________________________________ From: Jarod Wilson To: Dave Liquorice Cc: "LCDproc at lists.omnipotent.net" Sent: Friday, September 11, 2009 11:04:37 AM Subject: Re: [Lcdproc] imonlcd and 0038 breakage... On 09/11/2009 04:57 AM, Dave Liquorice wrote: > On Fri, 11 Sep 2009 10:22:42 +0200, Berend Dekens wrote: > >> To be sure, here is a picture of my display: >> http://www.flickr.com/photos/41748755 at N08/3906626228/ > > Well at first glance that looks VFD to me but these days some LCDs also have > a similar appearance. That's an iMON LCD. Their VFD don't have all the icons. (I have an iMON LCD myself, the display there is identical). -- Jarod Wilson jarod at wilsonet.com _______________________________________________ LCDproc mailing list LCDproc at lists.omnipotent.net http://lists.omnipotent.net/mailman/listinfo/lcdproc -------------- next part -------------- An HTML attachment was scrubbed... URL: From wyldfire00101010 at yahoo.com Sat Sep 12 01:13:28 2009 From: wyldfire00101010 at yahoo.com (Leif Hassell) Date: Fri, 11 Sep 2009 18:13:28 -0700 (PDT) Subject: [Lcdproc] imonlcd and 0038 breakage... In-Reply-To: <424547.36499.qm@web57705.mail.re3.yahoo.com> References: <20090911085825.F3FED9446C8@mail.wilsonet.com> <4AAA7515.70202@wilsonet.com> <424547.36499.qm@web57705.mail.re3.yahoo.com> Message-ID: <516501.52584.qm@web57703.mail.re3.yahoo.com> Well, that was quick. I can confirm that I am running the lirc_imon module version 0.6, lirc 0.8.6-CVS, and lcdproc 0.5.3 and am still locking up. I can find nothing that jumps out to my untrained eyes in the kernel log (or any of the other logs I could think to check.) I can say that it has only locked up when I wasn't paying attention. Could it be something to do with the computer being idle? At any rate, I'm wondering where to go next. Thanks, Leif Hassell ________________________________ From: Leif Hassell To: LCDproc at lists.omnipotent.net Sent: Friday, September 11, 2009 7:19:26 PM Subject: Re: [Lcdproc] imonlcd and 0038 breakage... Finally got everything updated to the latest version. Had to wipe and start from scratch to get it where it needed to be. So far, so good. Thanks for all the help. Will update if situation goes bad. Leif ________________________________ From: Jarod Wilson To: Dave Liquorice Cc: "LCDproc at lists.omnipotent.net" Sent: Friday, September 11, 2009 11:04:37 AM Subject: Re: [Lcdproc] imonlcd and 0038 breakage... On 09/11/2009 04:57 AM, Dave Liquorice wrote: > On Fri, 11 Sep 2009 10:22:42 +0200, Berend Dekens wrote: > >> To be sure, here is a picture of my display: >> http://www.flickr.com/photos/41748755 at N08/3906626228/ > > Well at first glance that looks VFD to me but these days some LCDs also have > a similar appearance. That's an iMON LCD. Their VFD don't have all the icons. (I have an iMON LCD myself, the display there is identical). -- Jarod Wilson jarod at wilsonet.com _______________________________________________ LCDproc mailing list LCDproc at lists.omnipotent.net http://lists.omnipotent.net/mailman/listinfo/lcdproc -------------- next part -------------- An HTML attachment was scrubbed... URL: From wyldfire00101010 at yahoo.com Sat Sep 12 01:16:00 2009 From: wyldfire00101010 at yahoo.com (Leif Hassell) Date: Fri, 11 Sep 2009 18:16:00 -0700 (PDT) Subject: [Lcdproc] imonlcd and 0038 breakage... In-Reply-To: <424547.36499.qm@web57705.mail.re3.yahoo.com> References: <20090911085825.F3FED9446C8@mail.wilsonet.com> <4AAA7515.70202@wilsonet.com> <424547.36499.qm@web57705.mail.re3.yahoo.com> Message-ID: <991126.86525.qm@web57706.mail.re3.yahoo.com> Well, that was quick. I can confirm that I am running the lirc_imon module version 0.6, lirc 0.8.6-CVS, and lcdproc 0.5.3 and am still locking up. I can find nothing that jumps out to my untrained eyes in the kernel log (or any of the other logs I could think to check.) I can say that it has only locked up when I wasn't paying attention. Could it be something to do with the computer being idle? At any rate, I'm wondering where to go next. Thanks, Leif Hassell ________________________________ From: Leif Hassell To: LCDproc at lists.omnipotent.net Sent: Friday, September 11, 2009 7:19:26 PM Subject: Re: [Lcdproc] imonlcd and 0038 breakage... Finally got everything updated to the latest version. Had to wipe and start from scratch to get it where it needed to be. So far, so good. Thanks for all the help. Will update if situation goes bad. Leif ________________________________ From: Jarod Wilson To: Dave Liquorice Cc: "LCDproc at lists.omnipotent.net" Sent: Friday, September 11, 2009 11:04:37 AM Subject: Re: [Lcdproc] imonlcd and 0038 breakage... On 09/11/2009 04:57 AM, Dave Liquorice wrote: > On Fri, 11 Sep 2009 10:22:42 +0200, Berend Dekens wrote: > >> To be sure, here is a picture of my display: >> http://www.flickr.com/photos/41748755 at N08/3906626228/ > > Well at first glance that looks VFD to me but these days some LCDs also have > a similar appearance. That's an iMON LCD. Their VFD don't have all the icons. (I have an iMON LCD myself, the display there is identical). -- Jarod Wilson jarod at wilsonet.com _______________________________________________ LCDproc mailing list LCDproc at lists.omnipotent.net http://lists.omnipotent.net/mailman/listinfo/lcdproc -------------- next part -------------- An HTML attachment was scrubbed... URL: From wyldfire00101010 at yahoo.com Sat Sep 12 01:16:05 2009 From: wyldfire00101010 at yahoo.com (Leif Hassell) Date: Fri, 11 Sep 2009 18:16:05 -0700 (PDT) Subject: [Lcdproc] imonlcd and 0038 breakage... In-Reply-To: <424547.36499.qm@web57705.mail.re3.yahoo.com> References: <20090911085825.F3FED9446C8@mail.wilsonet.com> <4AAA7515.70202@wilsonet.com> <424547.36499.qm@web57705.mail.re3.yahoo.com> Message-ID: <44270.83751.qm@web57705.mail.re3.yahoo.com> Well, that was quick. I can confirm that I am running the lirc_imon module version 0.6, lirc 0.8.6-CVS, and lcdproc 0.5.3 and am still locking up. I can find nothing that jumps out to my untrained eyes in the kernel log (or any of the other logs I could think to check.) I can say that it has only locked up when I wasn't paying attention. Could it be something to do with the computer being idle? At any rate, I'm wondering where to go next. Thanks, Leif Hassell ________________________________ From: Leif Hassell To: LCDproc at lists.omnipotent.net Sent: Friday, September 11, 2009 7:19:26 PM Subject: Re: [Lcdproc] imonlcd and 0038 breakage... Finally got everything updated to the latest version. Had to wipe and start from scratch to get it where it needed to be. So far, so good. Thanks for all the help. Will update if situation goes bad. Leif ________________________________ From: Jarod Wilson To: Dave Liquorice Cc: "LCDproc at lists.omnipotent.net" Sent: Friday, September 11, 2009 11:04:37 AM Subject: Re: [Lcdproc] imonlcd and 0038 breakage... On 09/11/2009 04:57 AM, Dave Liquorice wrote: > On Fri, 11 Sep 2009 10:22:42 +0200, Berend Dekens wrote: > >> To be sure, here is a picture of my display: >> http://www.flickr.com/photos/41748755 at N08/3906626228/ > > Well at first glance that looks VFD to me but these days some LCDs also have > a similar appearance. That's an iMON LCD. Their VFD don't have all the icons. (I have an iMON LCD myself, the display there is identical). -- Jarod Wilson jarod at wilsonet.com _______________________________________________ LCDproc mailing list LCDproc at lists.omnipotent.net http://lists.omnipotent.net/mailman/listinfo/lcdproc -------------- next part -------------- An HTML attachment was scrubbed... URL: From jarod at wilsonet.com Sat Sep 12 04:06:56 2009 From: jarod at wilsonet.com (Jarod Wilson) Date: Sat, 12 Sep 2009 00:06:56 -0400 Subject: [Lcdproc] imonlcd and 0038 breakage... In-Reply-To: <516501.52584.qm@web57703.mail.re3.yahoo.com> References: <20090911085825.F3FED9446C8@mail.wilsonet.com> <4AAA7515.70202@wilsonet.com> <424547.36499.qm@web57705.mail.re3.yahoo.com> <516501.52584.qm@web57703.mail.re3.yahoo.com> Message-ID: On Sep 11, 2009, at 9:13 PM, Leif Hassell wrote: > Well, that was quick. I can confirm that I am running the lirc_imon > module version 0.6, lirc 0.8.6-CVS, and lcdproc 0.5.3 and am still > locking up. I can find nothing that jumps out to my untrained eyes > in the kernel log (or any of the other logs I could think to check.) > I can say that it has only locked up when I wasn't paying > attention. Could it be something to do with the computer being idle? > > At any rate, I'm wondering where to go next. Hit me with an updated log with the module loaded w/debug=1, and I'll see what I can see. From there, we can try to set up serial console output. To be honest, your prior log had me thinking you have a hardware issue of some sort with the usb controller in your system, but I was hoping maybe it something that the latest driver might have fixed... > From: Leif Hassell > To: LCDproc at lists.omnipotent.net > Sent: Friday, September 11, 2009 7:19:26 PM > Subject: Re: [Lcdproc] imonlcd and 0038 breakage... > > Finally got everything updated to the latest version. Had to wipe > and start from scratch to get it where it needed to be. So far, so > good. > > Thanks for all the help. Will update if situation goes bad. > > Leif > > From: Jarod Wilson > To: Dave Liquorice > Cc: "LCDproc at lists.omnipotent.net" > Sent: Friday, September 11, 2009 11:04:37 AM > Subject: Re: [Lcdproc] imonlcd and 0038 breakage... > > On 09/11/2009 04:57 AM, Dave Liquorice wrote: > > On Fri, 11 Sep 2009 10:22:42 +0200, Berend Dekens wrote: > > > >> To be sure, here is a picture of my display: > >> http://www.flickr.com/photos/41748755 at N08/3906626228/ > > > > Well at first glance that looks VFD to me but these days some LCDs > also have > > a similar appearance. > > That's an iMON LCD. Their VFD don't have all the icons. (I have an > iMON > LCD myself, the display there is identical). > > > -- > Jarod Wilson > jarod at wilsonet.com > _______________________________________________ > LCDproc mailing list > LCDproc at lists.omnipotent.net > http://lists.omnipotent.net/mailman/listinfo/lcdproc > > > _______________________________________________ > LCDproc mailing list > LCDproc at lists.omnipotent.net > http://lists.omnipotent.net/mailman/listinfo/lcdproc -- Jarod Wilson jarod at wilsonet.com From wyldfire00101010 at yahoo.com Sat Sep 12 12:04:58 2009 From: wyldfire00101010 at yahoo.com (Leif Hassell) Date: Sat, 12 Sep 2009 05:04:58 -0700 (PDT) Subject: [Lcdproc] imonlcd and 0038 breakage... In-Reply-To: References: <20090911085825.F3FED9446C8@mail.wilsonet.com> <4AAA7515.70202@wilsonet.com> <424547.36499.qm@web57705.mail.re3.yahoo.com> <516501.52584.qm@web57703.mail.re3.yahoo.com> Message-ID: <579949.55261.qm@web57708.mail.re3.yahoo.com> Actually, I think I've found the problem. Last night, I rebooted and left it running overnight, to get a fresh log. The unit is still working this morning. The only difference from normal is that I didn't start Boxee (a media frontend), Boxee doesn't handle lirc events like other programs I've seen; it seems to be talking to /dev/lircd directly. I think that somehow it may be causing the problem. Does that make sense to you? Leif ________________________________ From: Jarod Wilson To: Leif Hassell Cc: LCDproc at lists.omnipotent.net Sent: Friday, September 11, 2009 11:06:56 PM Subject: Re: [Lcdproc] imonlcd and 0038 breakage... On Sep 11, 2009, at 9:13 PM, Leif Hassell wrote: > Well, that was quick. I can confirm that I am running the lirc_imon module version 0.6, lirc 0.8.6-CVS, and lcdproc 0.5.3 and am still locking up. I can find nothing that jumps out to my untrained eyes in the kernel log (or any of the other logs I could think to check.) I can say that it has only locked up when I wasn't paying attention. Could it be something to do with the computer being idle? > > At any rate, I'm wondering where to go next. Hit me with an updated log with the module loaded w/debug=1, and I'll see what I can see. From there, we can try to set up serial console output. To be honest, your prior log had me thinking you have a hardware issue of some sort with the usb controller in your system, but I was hoping maybe it something that the latest driver might have fixed... > From: Leif Hassell > To: LCDproc at lists.omnipotent.net > Sent: Friday, September 11, 2009 7:19:26 PM > Subject: Re: [Lcdproc] imonlcd and 0038 breakage... > > Finally got everything updated to the latest version. Had to wipe and start from scratch to get it where it needed to be. So far, so good. > > Thanks for all the help. Will update if situation goes bad. > > Leif > > From: Jarod Wilson > To: Dave Liquorice > Cc: "LCDproc at lists.omnipotent.net" > Sent: Friday, September 11, 2009 11:04:37 AM > Subject: Re: [Lcdproc] imonlcd and 0038 breakage... > > On 09/11/2009 04:57 AM, Dave Liquorice wrote: > > On Fri, 11 Sep 2009 10:22:42 +0200, Berend Dekens wrote: > > > >> To be sure, here is a picture of my display: > >> http://www.flickr.com/photos/41748755 at N08/3906626228/ > > > > Well at first glance that looks VFD to me but these days some LCDs also have > > a similar appearance. > > That's an iMON LCD. Their VFD don't have all the icons. (I have an iMON > LCD myself, the display there is identical). > > > --Jarod Wilson > jarod at wilsonet.com > _______________________________________________ > LCDproc mailing list > LCDproc at lists.omnipotent.net > http://lists.omnipotent.net/mailman/listinfo/lcdproc > > > _______________________________________________ > LCDproc mailing list > LCDproc at lists.omnipotent.net > http://lists.omnipotent.net/mailman/listinfo/lcdproc --Jarod Wilson jarod at wilsonet.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From bsdfan at nurfuerspam.de Sat Sep 12 13:50:13 2009 From: bsdfan at nurfuerspam.de (Markus Dolze) Date: Sat, 12 Sep 2009 15:50:13 +0200 Subject: [Lcdproc] Segmentation Fault with 0.5.2 on OpenBSD 4.3 In-Reply-To: <000001ca3284$9f19a3d0$dd4ceb70$@edu> References: <000101ca302a$ad4b8dd0$07e2a970$@edu> <4AA5F68F.8030301@nurfuerspam.de> <000001ca3284$9f19a3d0$dd4ceb70$@edu> Message-ID: <20090912135013.226660@gmx.net> Hi Ted, it looks like some of your system's feature are not correctly detected. LCDd does not fail when acquiring access to the lpt port as I first read, but when writing to the port for the first time. It fails with '__asm __volatile("outb"' which should not be used on OpenBSD. While trying it myself with an OpenBSD VMware image but I ran into another problem: Loading the hd44780 driver fails with server/LCDd:server/drivers/hd44780.so: undefined symbol 'sock_send' server/LCDd:server/drivers/hd44780.so: undefined symbol 'sock_connect' server/LCDd:server/drivers/hd44780.so: undefined symbol 'report' server/LCDd:server/drivers/hd44780.so: undefined symbol 'sock_close' server/LCDd:server/drivers/hd44780.so: undefined symbol 'sock_recv' Could not open driver module server/drivers/hd44780.so: Cannot load specified object Driver [hd44780] binding failed Could not load driver hd44780 Can you give me a hint about your steps to configure/compile lcdproc on your system. Additionally the 'config.log' file might be helpful. Regards, Markus PS: I tried sending mail to tmw at uchicago.edu, but the mail was rejected by that domain's mail system. -------- Original-Nachricht -------- > Datum: Thu, 10 Sep 2009 21:07:30 -0500 > Von: "Theodore Wynnychenko" > An: "\'Markus Dolze\'" > Betreff: RE: [Lcdproc] Segmentation Fault with 0.5.2 on OpenBSD 4.3 > Hi: > I was wondering if you had any further insight. I sent a message to the > list, but there were no replies. > I am not trying to be pushy or anything, but I wanted to be sure that you > saw my response to the list. > BTW, I have also tried it with the current CVS snapshot (AM 9/10/9), with > the same segmentation fault and backtrace output. > I really appreciate the time you have already given me. > Thanks again > Bye - ted > > -----Original Message----- > From: Markus Dolze [mailto:bsdfan at nurfuerspam.de] > Sent: Tuesday, September 08, 2009 1:16 AM > To: tmw at uchicago.edu > Cc: lcdproc at lists.omnipotent.net > Subject: Re: [Lcdproc] Segmentation Fault with 0.5.2 on OpenBSD 4.3 > > Theodore Wynnychenko wrote: > > Hello: > > This is beyond my level of knowledge, so, any help would be appreciated. > I > > was hoping to get a Crystalfontz parallel LCD working via LCDproc. > > In any case, I downloaded the 0.5.2 version, configured using: > "./configure > > --prefix=/home/me --enable-drivers=hd44780 --enable-debug" > > > > Then ran make. Seemed to work fine (a few warnings about using strlcpy > and > > not strcpy, and such). But compiled completely. > > Edit the config file to use the hd44780 driver, which is set to "8bit" > (I > > also set the Device to /dev/lpt0, but I don't think that matters since > it's > > not a serial LCD display). > > I then start the deamon with: "./server/LCDd -c LCDd.conf" and nothing. > > Running it with "-f" I see a segmentation fault. > > I don't really have any clue how to troubleshoot this. > > But, here is the info I have. > > Using gdb - with backtrace: > > > ... > > # gdb ./server/LCDd > > GNU gdb 6.3 > > Copyright 2004 Free Software Foundation, Inc. > > ...... > > (gdb) set args -c /home/me/lcdproc-0.5.2/LCDd.conf -f > > (gdb) run > > Starting program: /home/me/lcdproc-0.5.2/server/LCDd -c > > /home/me/lcdproc-0.5.2/LCDd.conf -f > > LCDd 0.5.2, LCDproc Protocol 0.3 > > Part of the LCDproc suite > > > > > ... > > Program received signal SIGSEGV, Segmentation fault. > > lcdtime_HD44780_senddata (p=0x8856e200, displayID=0 '\0', flags=1 > '\001', > > ch=48 '0') at pio.h:147 > > 147 __asm __volatile("outb %0,%w1" : : "a" (data), "d" > (port)); > > > > > > (gdb) backtrace full > > #0 lcdtime_HD44780_senddata (p=0x8856e200, displayID=0 '\0', flags=1 > > '\001', ch=48 '0') at pio.h:147 > > portControl = 0 '\0' > > #1 0x05b7dd0d in hd_init_ext8bit (drvthis=0x5b7de0b) at > > hd44780-ext8bit.c:100 > > p = (PrivateData *) 0x8856e200 > > hd44780_functions = (HD44780_functions *) 0x81841080 > > > Hi, > > thank you for reporting this. You should download version 0.5.3 from > http://sourceforge.net/projects/lcdproc/ as that one replaced 0.5.2 (and > yes, we know lcdproc.org is out of date). > > It won't make a difference anyway, because that part of the code has not > been changed since the previous. > > LCDd fails to set access rights for the lpt port. You have to start LCDd > as root (it drops *** > *privileges > once it has access to low level ports) if you are not already doing so. > > Regards, > Markus > From herdler at gmx.de Sat Sep 12 21:05:07 2009 From: herdler at gmx.de (Stefan Herdler) Date: Sat, 12 Sep 2009 23:05:07 +0200 Subject: [Lcdproc] Noritake VFDs In-Reply-To: <004801ca31aa$31b29930$9517cb90$@com> References: <004801ca31aa$31b29930$9517cb90$@com> Message-ID: <4AAC0D03.40006@gmx.de> Lists wrote: > > Hi everyone, > > I?m providing some feedback on Noritake VFDs as stated in the User?s > Guide?. I can?t get it to work. J > > Now that being said, the LCD unit came out of a system from Net > Integration Technologies (now some part of IBM.) > > The Part Number on the LCD is CU16025ECPB-W6J. I have confirmed this > is a Noritake unit after a google search. > Hi Jim, this VFD seem so be HD44780 compatible. > > The interface between the LCD and PC is a separate board which > contains an Amtel 90S8515 controller chip. > I don't know, what the UC does. I think you have two options: -Connect the display directly and use the HD44780 driver. That should work. -Try to find a driver and connectiontype, that works with the Atmel-board. The best chances will be the serialVFD in Futaba mode or the serialPOS driver, I think. > > The connection to the PC is using the SIR1 (serial port 2 set to > HPSIR) port on the motherboard (Matsonic MS8127C+). > > I have verified the following lines are in the config file. > > [serialVFD] > > Device=/dev/cuad1 > > Speed=9600 > > Type=2 > > Size=16x2 > > FYI, this is running on a pfSense system. I?ve had to add the > [serialVFD] into the config generation script manually and changed the > com2 device from ?/dev/cua1? to ?/dev/cuad1?. > > In the pfSense System Logs, I get this message: > > /kernel: pid 5455 (LCDd), uid 65534: exited on signal 11/ > Perhaps LCDproc version to old? Try to run it by hand to get more debug output. Regards Stefan > > // > > I will assist, answer and test any suggestions or modifications. I > would really like this to work! J > > Jim > > ------------------------------------------------------------------------ > > _______________________________________________ > LCDproc mailing list > LCDproc at lists.omnipotent.net > http://lists.omnipotent.net/mailman/listinfo/lcdproc > From jarod at wilsonet.com Sun Sep 13 00:44:43 2009 From: jarod at wilsonet.com (Jarod Wilson) Date: Sat, 12 Sep 2009 20:44:43 -0400 Subject: [Lcdproc] imonlcd and 0038 breakage... In-Reply-To: <579949.55261.qm@web57708.mail.re3.yahoo.com> References: <20090911085825.F3FED9446C8@mail.wilsonet.com> <4AAA7515.70202@wilsonet.com> <424547.36499.qm@web57705.mail.re3.yahoo.com> <516501.52584.qm@web57703.mail.re3.yahoo.com> <579949.55261.qm@web57708.mail.re3.yahoo.com> Message-ID: On Sep 12, 2009, at 8:04 AM, Leif Hassell wrote: > Actually, I think I've found the problem. Last night, I rebooted > and left it running overnight, to get a fresh log. The unit is > still working this morning. The only difference from normal is that > I didn't start Boxee (a media frontend), Boxee doesn't handle lirc > events like other programs I've seen; it seems to be talking to /dev/ > lircd directly. I think that somehow it may be causing the > problem. Does that make sense to you? Nope, but based on the email Jeremy Yoder forwarded to the lirc list, that's not it anyway. I'm thinking you have a hardware issue, but we can further chase this over on the lirc list, since I think if this isn't a hardware issue, its an lirc driver issue. > From: Jarod Wilson > To: Leif Hassell > Cc: LCDproc at lists.omnipotent.net > Sent: Friday, September 11, 2009 11:06:56 PM > Subject: Re: [Lcdproc] imonlcd and 0038 breakage... > > On Sep 11, 2009, at 9:13 PM, Leif Hassell wrote: > > > Well, that was quick. I can confirm that I am running the > lirc_imon module version 0.6, lirc 0.8.6-CVS, and lcdproc 0.5.3 and > am still locking up. I can find nothing that jumps out to my > untrained eyes in the kernel log (or any of the other logs I could > think to check.) I can say that it has only locked up when I wasn't > paying attention. Could it be something to do with the computer > being idle? > > > > At any rate, I'm wondering where to go next. > > > Hit me with an updated log with the module loaded w/debug=1, and > I'll see what I can see. From there, we can try to set up serial > console output. To be honest, your prior log had me thinking you > have a hardware issue of some sort with the usb controller in your > system, but I was hoping maybe it something that the latest driver > might have fixed... > > > > From: Leif Hassell > > To: LCDproc at lists.omnipotent.net > > Sent: Friday, September 11, 2009 7:19:26 PM > > Subject: Re: [Lcdproc] imonlcd and 0038 breakage... > > > > Finally got everything updated to the latest version. Had to wipe > and start from scratch to get it where it needed to be. So far, so > good. > > > > Thanks for all the help. Will update if situation goes bad. > > > > Leif > > > > From: Jarod Wilson > > To: Dave Liquorice > > Cc: "LCDproc at lists.omnipotent.net" > > Sent: Friday, September 11, 2009 11:04:37 AM > > Subject: Re: [Lcdproc] imonlcd and 0038 breakage... > > > > On 09/11/2009 04:57 AM, Dave Liquorice wrote: > > > On Fri, 11 Sep 2009 10:22:42 +0200, Berend Dekens wrote: > > > > > >> To be sure, here is a picture of my display: > > >> http://www.flickr.com/photos/41748755 at N08/3906626228/ > > > > > > Well at first glance that looks VFD to me but these days some > LCDs also have > > > a similar appearance. > > > > That's an iMON LCD. Their VFD don't have all the icons. (I have an > iMON > > LCD myself, the display there is identical). > > > > > > --Jarod Wilson > > jarod at wilsonet.com > > _______________________________________________ > > LCDproc mailing list > > LCDproc at lists.omnipotent.net > > http://lists.omnipotent.net/mailman/listinfo/lcdproc > > > > > > _______________________________________________ > > LCDproc mailing list > > LCDproc at lists.omnipotent.net > > http://lists.omnipotent.net/mailman/listinfo/lcdproc > > --Jarod Wilson > jarod at wilsonet.com > > > > > > _______________________________________________ > LCDproc mailing list > LCDproc at lists.omnipotent.net > http://lists.omnipotent.net/mailman/listinfo/lcdproc -- Jarod Wilson jarod at wilsonet.com From bsdfan at nurfuerspam.de Sun Sep 13 23:09:33 2009 From: bsdfan at nurfuerspam.de (Markus Dolze) Date: Mon, 14 Sep 2009 01:09:33 +0200 Subject: [Lcdproc] Segmentation Fault with 0.5.2 on OpenBSD 4.3 In-Reply-To: <000101ca302a$ad4b8dd0$07e2a970$@edu> References: <000101ca302a$ad4b8dd0$07e2a970$@edu> Message-ID: <4AAD7BAD.6080500@nurfuerspam.de> Theodore Wynnychenko wrote: > Hello: > This is beyond my level of knowledge, so, any help would be appreciated. I > was hoping to get a Crystalfontz parallel LCD working via LCDproc. > In any case, I downloaded the 0.5.2 version, configured using: "./configure > --prefix=/home/me --enable-drivers=hd44780 --enable-debug" > > Then ran make. Seemed to work fine (a few warnings about using strlcpy and > not strcpy, and such). But compiled completely. > Edit the config file to use the hd44780 driver, which is set to "8bit" (I > also set the Device to /dev/lpt0, but I don't think that matters since it's > not a serial LCD display). > I then start the deamon with: "./server/LCDd -c LCDd.conf" and nothing. > Running it with "-f" I see a segmentation fault. > I don't really have any clue how to troubleshoot this. > But, here is the info I have. > ------------------------------------------------------- > Running LCDd gives me: > > Hi, LCDd cannot set I/O permissions if securelevel is set (default is 1 on OpenBSD). You either have to start LCDd before the securelevel is set or you have to run your system with securelevel set to -1. Tried and it works with securelevel = -1. While testing with 0.5.3 I found several issues (which should not be present in 0.5.2) releated to unsatified link dependencies. I will create a patch for 0.5.3 some day. Regards, Markus From fblack947 at yahoo.com Tue Sep 15 09:18:14 2009 From: fblack947 at yahoo.com (jk) Date: Tue, 15 Sep 2009 02:18:14 -0700 (PDT) Subject: [Lcdproc] imonlcd and 0038 breakage... In-Reply-To: References: <20090911085825.F3FED9446C8@mail.wilsonet.com> <4AAA7515.70202@wilsonet.com> <424547.36499.qm@web57705.mail.re3.yahoo.com> <516501.52584.qm@web57703.mail.re3.yahoo.com> <579949.55261.qm@web57708.mail.re3.yahoo.com> Message-ID: <82131.21083.qm@web37504.mail.mud.yahoo.com> This is where I think we stand on the imonlcd driver and really fast (at least some really fast) computers. - Adding a 5 ms usleep to the send_packet routine in imonlcd.c is a hack which should work (although you may have to adjust the timing). - This appears to be more of an issue with the lirc imon driver (which the lcproc imonlcd driver uses as the interface to the imon display). - The lirc guys are looking into it (Jarod?) - Most systems appear to cause the lcd to light up again on shutdown, regardless of what the lcdproc driver tells it to do. This remains an open issue. Currently, I'd recommend not changing the lcdproc imonlcd driver. Anyone with a blazing system and symptoms described by Berend should try his fix. Thoughts? -Jonathan From eldavidillo at hotmail.com Fri Sep 18 00:05:38 2009 From: eldavidillo at hotmail.com (David Lopez Perez) Date: Fri, 18 Sep 2009 00:05:38 +0000 Subject: [Lcdproc] [PATCH] 2 wrong symbols in HD44780 driver charmap Message-ID: Hello list, I was trying out LCDproc and I noticed a few wrong symbols in the character map for the HD44780 driver. The '?' (greek letter mu) was mapped to a different glyph (11111001 in the HD44780 table) when it should be 11100100. Also, the letter '?' (n with a ~ on top) was mapped to the same glyph as the 'n'. There is a glyph in the table for the '?' (11101110), and it is a completely different letter from the n, so it should be mapped to this glyph. Same goes for the uppercase '?' (just like '?' and '?' are both mapped to the '?' glyph). Attached is a patch for LCDproc 0.5.2 to fix these issues. --- hd44780-charmap.h 2009-09-18 01:33:04.000000000 +0200 +++ hd44780-charmap.h.original 2009-09-18 01:30:43.000000000 +0200 @@ -59,17 +59,17 @@ /* #160 */ 160, 33, 236, 237, 164, 92, 124, 167, 34, 169, 170, 171, 172, 173, 174, 175, - 223, 177, 178, 179, 39, 228, 247, 165, + 223, 177, 178, 179, 39, 249, 247, 165, 44, 185, 186, 187, 188, 189, 190, 63, /* #192 */ 65, 65, 65, 65, 225, 65, 65, 67, 69, 69, 69, 69, 73, 73, 73, 73, - 68, 238, 79, 79, 79, 79, 239, 120, + 68, 78, 79, 79, 79, 79, 239, 120, 48, 85, 85, 85, 245, 89, 240, 226, /* #224 */ 97, 97, 97, 97, 225, 97, 97, 99, 101, 101, 101, 101, 105, 105, 105, 105, - 111, 238, 111, 111, 111, 111, 239, 253, + 111, 110, 111, 111, 111, 111, 239, 253, 48, 117, 117, 117, 245, 121, 240, 255 }; _________________________________________________________________ Messenger cumple 10 a?os ?Desc?rgate ya los nuevos emoticonos! http://www.vivelive.com/felicidades -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: hd44780-charmap.patch Type: text/x-patch Size: 945 bytes Desc: not available URL: From joris at robijn.net Fri Sep 18 07:46:59 2009 From: joris at robijn.net (joris at robijn.net) Date: Fri, 18 Sep 2009 09:46:59 +0200 (CEST) Subject: [Lcdproc] [PATCH] 2 wrong symbols in HD44780 driver charmap In-Reply-To: Message-ID: <20090918074700.5B6381C9DB6@wizard.robijn.net> > > Hello list, > > I was trying out LCDproc and I noticed a few wrong symbols in the character map for the HD44780 driver. Hi David, Your new mapping is not equal to the original Hitachi HD44780 mapping. I think you have used documentation of a different display claiming to be HD44780 compliant. There are many different charsets, and there are also multiple charsets of the original HD44780 (extensions A00 and A02). There is an n with ~ in the original char set. I guess the char was mapped to a normal n was because there were too many charsets that did not support it. Maybe the HD44780 standard could better have been sticked to. Some years ago we defined to translate from ISO 8859-1. Since -15 is practically compatible maybe that one is better. You can always add your own translation char set. Maybe more of these should exist to choose from for "almost compatible" displays. Why don't these manufacturers just stick to the existing standard ? Regards, Joris > The '?' (greek letter mu) was mapped to a different glyph (11111001 in the HD44780 table) when it should be 11100100. > > Also, the letter '?' (n with a ~ on top) was mapped to the same glyph as the 'n'. There is a glyph in the table for the '?' (11101110), and it is a completely different letter from the n, so it should be mapped to this glyph. Same goes for the uppercase '?' (just like '?' and '?' are both mapped to the '?' glyph). > > Attached is a patch for LCDproc 0.5.2 to fix these issues. > > --- hd44780-charmap.h 2009-09-18 01:33:04.000000000 +0200 > +++ hd44780-charmap.h.original 2009-09-18 01:30:43.000000000 +0200 > @@ -59,17 +59,17 @@ > /* #160 */ > 160, 33, 236, 237, 164, 92, 124, 167, > 34, 169, 170, 171, 172, 173, 174, 175, > - 223, 177, 178, 179, 39, 228, 247, 165, > + 223, 177, 178, 179, 39, 249, 247, 165, > 44, 185, 186, 187, 188, 189, 190, 63, > /* #192 */ > 65, 65, 65, 65, 225, 65, 65, 67, > 69, 69, 69, 69, 73, 73, 73, 73, > - 68, 238, 79, 79, 79, 79, 239, 120, > + 68, 78, 79, 79, 79, 79, 239, 120, > 48, 85, 85, 85, 245, 89, 240, 226, > /* #224 */ > 97, 97, 97, 97, 225, 97, 97, 99, > 101, 101, 101, 101, 105, 105, 105, 105, > - 111, 238, 111, 111, 111, 111, 239, 253, > + 111, 110, 111, 111, 111, 111, 239, 253, > 48, 117, 117, 117, 245, 121, 240, 255 > }; > > > _________________________________________________________________ > Messenger cumple 10 a?os ?Desc?rgate ya los nuevos emoticonos! > http://www.vivelive.com/felicidades [ Attachment, skipping... ] > _______________________________________________ > LCDproc mailing list > LCDproc at lists.omnipotent.net > http://lists.omnipotent.net/mailman/listinfo/lcdproc -- Joris Robijn Mobile: +31 6 288 41 964 From 4freefinders at gmail.com Sun Sep 20 08:33:04 2009 From: 4freefinders at gmail.com (grant donald) Date: Sun, 20 Sep 2009 02:33:04 -0600 Subject: [Lcdproc] hd44780 driver Message-ID: Hello World, LCDd can't find the driver because i don't know where to point it. Lcdproc is supposed to have it @/usr/bin/lcdproc but he don't got it. Do you know where it is. Search don't find it. txs screenshot.png gdonald2007 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: snapshot1.png Type: image/png Size: 87630 bytes Desc: not available URL: From eldavidillo at hotmail.com Sun Sep 20 11:55:59 2009 From: eldavidillo at hotmail.com (David Lopez Perez) Date: Sun, 20 Sep 2009 11:55:59 +0000 Subject: [Lcdproc] [PATCH] 2 wrong symbols in HD44780 driver charmap In-Reply-To: <20090918074700.5B6381C9DB6@wizard.robijn.net> References: <20090918074700.5B6381C9DB6@wizard.robijn.net> Message-ID: > Hi David, > > Your new mapping is not equal to the original Hitachi HD44780 mapping. > I think you have used documentation of a different display claiming to > be HD44780 compliant. There are many different charsets, and there > are also multiple charsets of the original HD44780 (extensions A00 > and A02). My LCDs have Hitachi chips labeled "HD44780" on the back, and the documentation I used is from the Hitachi Semiconductor HD44780 datasheet: http://pdf1.alldatasheet.com/datasheet-pdf/view/63673/HITACHI/HD44780.html > There is an n with ~ in the original char set. I guess the char was > mapped to a normal n was because there were too many charsets that did > not support it. Maybe the HD44780 standard could better have been sticked > to. Well, I am sticking to the standard: the original charset table on the official datasheet from Hitachi Semiconductor, extension A00 (page 17). Comparing that table to the HD44780_default charmap, you can see that the greek letter mu is currently being mapped to the glyph for the large 'y', when there is a proper glyph for the mu letter on the same table. Also, the HD44780_default charmap already maps 'a', 'u' and 'o' with diacritic mark (?), both upper and lowercase, to the proper lowercase glyphs - IMHO it should do the same for the 'N/n' + '~' because the glyph is also there on the standard charmap. > Some years ago we defined to translate from ISO 8859-1. Since -15 is > practically compatible maybe that one is better. You can always add your > own translation char set. Maybe more of these should exist to choose > from for "almost compatible" displays. Why don't these manufacturers > just stick to the existing standard ? My original intention was to add my own new charmap, but then I realized that the HD44780_default one was quite right, only those two characters were wrong, so I decided to change it instead. I'm not against adding more charmaps to improve compatibility for other LCDs that do not stick to the standard, but my LCD does, and the default charmap does not. Or should we have two different charmaps "HD44780_default" and "HD44780_standard"? That's the beautiful thing about standards: there are so many to choose from... > Regards, > Joris > > > > The '?' (greek letter mu) was mapped to a different glyph (11111001 in the HD44780 table) when it should be 11100100. > > > > Also, the letter '?' (n with a ~ on top) was mapped to the same glyph as the 'n'. There is a glyph in the table for the '?' (11101110), and it is a completely different letter from the n, so it should be mapped to this glyph. Same goes for the uppercase '?' (just like '?' and '?' are both mapped to the '?' glyph). > > > > Attached is a patch for LCDproc 0.5.2 to fix these issues. > > > > --- hd44780-charmap.h 2009-09-18 01:33:04.000000000 +0200 > > +++ hd44780-charmap.h.original 2009-09-18 01:30:43.000000000 +0200 > > @@ -59,17 +59,17 @@ > > /* #160 */ > > 160, 33, 236, 237, 164, 92, 124, 167, > > 34, 169, 170, 171, 172, 173, 174, 175, > > - 223, 177, 178, 179, 39, 228, 247, 165, > > + 223, 177, 178, 179, 39, 249, 247, 165, > > 44, 185, 186, 187, 188, 189, 190, 63, > > /* #192 */ > > 65, 65, 65, 65, 225, 65, 65, 67, > > 69, 69, 69, 69, 73, 73, 73, 73, > > - 68, 238, 79, 79, 79, 79, 239, 120, > > + 68, 78, 79, 79, 79, 79, 239, 120, > > 48, 85, 85, 85, 245, 89, 240, 226, > > /* #224 */ > > 97, 97, 97, 97, 225, 97, 97, 99, > > 101, 101, 101, 101, 105, 105, 105, 105, > > - 111, 238, 111, 111, 111, 111, 239, 253, > > + 111, 110, 111, 111, 111, 111, 239, 253, > > 48, 117, 117, 117, 245, 121, 240, 255 > > }; > > > > _________________________________________________________________ Comparte tus mejores momentos del verano ?Hazlo con Windows Live Fotos! http://www.vivelive.com/compartirfotos -------------- next part -------------- An HTML attachment was scrubbed... URL: From gareth at omnipotent.net Sun Sep 20 18:25:57 2009 From: gareth at omnipotent.net (Gareth Watts) Date: Sun, 20 Sep 2009 11:25:57 -0700 Subject: [Lcdproc] This list will be offline sep/21 thru sep/23 Message-ID: After many years in its current rack in Illinois, the server hosting this mailing list and the lcdproc web site is going to be relocated to a colo in San Francisco and onto a significantly faster Internet connection. The server will be taken offline during the morning of Monday, September 21st 2009 to be fully backed up prior to shipping and should be installed and back online by the end of Wednesday, September 23rd if all goes to plan. I have temporarily relocated the lcdproc web site to another server I have available so it won't be down during the transition, but this mailing list will be offline during the move - If you send a message to the list during that time it should be queued up by your local mail server and will make it to the list some time after the server comes back up. Thanks for your patience Gareth Watts From gareth at omnipotent.net Sun Sep 20 19:15:45 2009 From: gareth at omnipotent.net (Gareth Watts) Date: Sun, 20 Sep 2009 12:15:45 -0700 Subject: [Lcdproc] This list will be offline sep/21 thru sep/23 In-Reply-To: References: Message-ID: <7BD81B4E-CD29-49CA-9022-30A57F1F7CDD@omnipotent.net> Additionally if you need to reach me during the move, I can be emailed at gwatts at gmail.com as my @omnipotent.net account is also hosted on the same box ;-) Gareth On Sep 20, 2009, at 11:25 AM, Gareth Watts wrote: > After many years in its current rack in Illinois, the server hosting > this mailing list and the lcdproc web site is going to be relocated > to a colo in San Francisco and onto a significantly faster Internet > connection. > > The server will be taken offline during the morning of Monday, > September 21st 2009 to be fully backed up prior to shipping and > should be installed and back online by the end of Wednesday, > September 23rd if all goes to plan. > > I have temporarily relocated the lcdproc web site to another server > I have available so it won't be down during the transition, but this > mailing list will be offline during the move - If you send a message > to the list during that time it should be queued up by your local > mail server and will make it to the list some time after the server > comes back up. > > Thanks for your patience > > Gareth Watts > > _______________________________________________ > LCDproc mailing list > LCDproc at lists.omnipotent.net > http://lists.omnipotent.net/mailman/listinfo/lcdproc From joris at robijn.net Sun Sep 20 20:05:30 2009 From: joris at robijn.net (Joris Robijn) Date: Sun, 20 Sep 2009 22:05:30 +0200 Subject: [Lcdproc] [PATCH] 2 wrong symbols in HD44780 driver charmap In-Reply-To: References: , <20090918074700.5B6381C9DB6@wizard.robijn.net>, Message-ID: <4AB6A72A.31441.2D04E7@joris.robijn.net> Hi David, You're right about the chars. standard and default maps sounds good. In the past a lot of displays with an "inverted P" as char 255 came up... I do not remember which "compatible" controller that was, but I'm sure it has a completely different charset. > > Some years ago we defined to translate from ISO 8859-1. Since -15 is > > practically compatible maybe that one is better. You can always add your > > own translation char set. Maybe more of these should exist to choose > > from for "almost compatible" displays. Why don't these manufacturers > > just stick to the existing standard ? > > That's the beautiful thing about standards: there are so many to choose > from... Ah yes I see, so they add more to make us happy ;) Joris -- Joris Robijn Mobile: +31 6 288 41 964 From joerg.hohwieler at pyramid.de Wed Sep 23 11:58:17 2009 From: joerg.hohwieler at pyramid.de (=?ISO-8859-1?Q?J=F6rg_Hohwieler?=) Date: Wed, 23 Sep 2009 13:58:17 +0200 Subject: [Lcdproc] pyramid display timer/highres issue Message-ID: <4ABA0D59.80105@pyramid.de> Dear all, Pyramid Computer ships an LCD display which is also supported by LCDproc. The driver is called pyramid. The hardware consists of an FTDI chip, thus you've to use the ftdi_sio kernel module to have an usb-to-serial converter. I have some customers that have problems with the display. The customers said the display is very slow, so it doesn't really make fun using it. I also found out that the display doesn't work flawlessly with recent kernels. It is very slow and it seems to be some kind of luck if the server screen comes up. Also some screens won't be shown during rotation. The last kernel that worked perfect was 2.6.20. To get the display working properly with recent kernel I have to - make sure that timer freq. is < 1000 Hz - 100 Hz works best - disable high resolution timers by adding highres=off to kernel cmd line if ACPI is activated in the kernel. Adding acpi=off would also help. Kernel 2.6.20 worked perfect because it doesn't have the high resolution timers. They were added with kernel 2.6.21. Are there any know issues with lcdproc and this timer issue or is it just related to the pyramid lcd? Is it possible to workaround this problem from within lcdproc? Best regards Joerg Hohwieler From 4freefinders at gmail.com Wed Sep 23 09:14:05 2009 From: 4freefinders at gmail.com (grant donald) Date: Wed, 23 Sep 2009 03:14:05 -0600 Subject: [Lcdproc] lcd HNQH UC204A Message-ID: Hello listers I had this lcd hooked to a mini cpu and it worked fine. Then I saw this program and switched it over to the parallel port. I was not able to get it running. Seems there is no driver or root/usr/bin/lcdproc isn't where it is. either or i gave up and hooked it back up to the cpu and it lights but no text. So now did i screw it up by hooking it? I mean i tried to load the hd44780 driver. This unit is supposed to be compatible. Just more confusion i'm having a hard time with this mainly trying to understand what's exactly happening between the feed and the chip which is where the text is. And what was it using for a driver before? And why i didn't know it used one. And why if it had one why did it need another one for lcdproc.?thx GD -------------- next part -------------- An HTML attachment was scrubbed... URL: From pavkamlc at gmail.com Wed Sep 30 21:32:45 2009 From: pavkamlc at gmail.com (=?UTF-8?B?UGF2ZWwgTWzEjW9jaA==?=) Date: Wed, 30 Sep 2009 17:32:45 -0400 Subject: [Lcdproc] lcdproc.conf Message-ID: <4AC3CE7D.8090107@gmail.com> Hello, I need help with configure lcdproc client. I have DM140 LCD from MSI in Ubuntu 9.10. I have compiled driver and it works fine. But all the time is displayed text "LCDproc server" with clients and screens info. After use clients like mythtv on display is displayed right text from application. But I'd like only simplier configuration, like BigTime and nothing else. I tried read documentation but I cannot know how to do it. Can someone helps me? Best regards, Pavel Mlcoch