From speedsix.lists at googlemail.com Fri Jan 1 14:49:48 2010 From: speedsix.lists at googlemail.com (Dom H) Date: Fri, 1 Jan 2010 14:49:48 +0000 Subject: [Lcdproc] Need help troubleshooting a possible faulty VFD unit Message-ID: Hi all, I have a Zalman HD135 HTPC case which includes a VLSystem Mplay Blast combined VFD/IR unit. While attempting to fix an LCDproc issue (by installing a newer version) I seem to have caused a weird issue with the IR portion of the unit. As soon as I put power to the machine the little red led next to the IR sensor lights and stays on permanently, it seems no IR signals are being passed through the interface either (shared with the VFD on /dev/ttyUSB0 using the FTDI serial module) Powering down doesn't help, as does removing all traces of LCDproc/Lirc etc. I know this isn't strictly an LCDproc issue but I'm at a total loss on how to fix/ this and wondered if anyone had any thoughts on what the issue could be. It's possible the unit has gone faulty or maybe the bios for the display has got into an inconsistent state? Any ideas at all welcome. Thanks From david.glaude at gmail.com Sun Jan 3 01:30:54 2010 From: david.glaude at gmail.com (David Glaude) Date: Sun, 3 Jan 2010 02:30:54 +0100 Subject: [Lcdproc] #twatch network LCD backpack Message-ID: <73314fc51001021730x1073a96ch9fd5a5bab9976b90@mail.gmail.com> Hello, For those that remind me (David Glaude)... no I am not back yet into LCDproc developpement... mostly because I don't have a linux computer handy for that and because I should clear with my day job any issue about my right to release software I develop during the night under GPL. I contact you because I made a nice discovery, fastly followed by an aquisition (the hardware is now running next to me). And I would love (I am not alone) to use that under LCDproc control. It is a networked LCD with enough hardware to hold a twitter "client" and emulate a subset of Matrix Orbital protocol when those byte are send over a TCP connection on port 1337. http://dangerousprototypes.com/twatch-manual/ http://dangerousprototypes.com/category/twatch/ I don't think this hardware can run a full LCDproc server... so it still need an LCDproc server to drive it. What is missing is a new driver (a simplified MatrixOrbital driver wich open the TCP connection). Maybe it is possible to write a program that fake and /dev/ttyS device and make the TCP connection and bridge every byte. Then run the MO driver to send to this "device" (assuming enough of MO protocol is emulated). Is there any driver currently in LCDproc CVS that does a TCP connection? I remember that years ago, I had the plan to separate in driver what is relative to the "protocol" and what is relative to the "communication channel". Somehow, each and every driver does rewrite (copy and paste) the code to open a serial interface and set the speed (or else). Here (maybe for the first time) we have a known protocol (MO) with an unknow communication channel (Open a TCP connection). Did anybody work on this idea? If #twatch firmware was to be modified or rewritten from scratch, what would you have done differently? My idea: * Drop the twitter client * Make it more LCDproc specific (trying to match LCDproc driver API) At least, there is a potential for LCDproc specific firmware or feature. Was MO protocol decision the best one? (I was more impress by CF633 packet protocol that could be done over UDP)? Well, I wanted to let you know about this device, let you know that I might start working on it, gather information from the list about the option. Thanks in advance. David Glaude PS: This is what someone posted on http://dangerousprototypes.com/2009/09/17/prototype-network-lcd-backpack-with-lcd-smartie/ ** "LCD Smartie and LCDproc are open source, so anyone can add a few enhancements for ethernet LCD backpacks. It would be great if they could control an LCD backpack directly over TCP, without a bridge." -------------- next part -------------- An HTML attachment was scrubbed... URL: From ethan.dicks at gmail.com Sun Jan 3 01:39:37 2010 From: ethan.dicks at gmail.com (Ethan Dicks) Date: Sat, 2 Jan 2010 20:39:37 -0500 Subject: [Lcdproc] #twatch network LCD backpack In-Reply-To: <73314fc51001021730x1073a96ch9fd5a5bab9976b90@mail.gmail.com> References: <73314fc51001021730x1073a96ch9fd5a5bab9976b90@mail.gmail.com> Message-ID: On 1/2/10, David Glaude wrote: > Hello, Hi, David, > For those that remind me (David Glaude)... no I am not back yet into LCDproc > development... mostly because I don't have a linux computer handy for that > and because I should clear with my day job any issue about my right to > release software I develop during the night under GPL. Fair enough, but it's good to hear from you again. > I contact you because I made a nice discovery, fastly followed by an > aquisition (the hardware is now running next to me). And I would love (I am > not alone) to use that under LCDproc control. > > It is a networked LCD with enough hardware to hold a twitter "client" and > emulate a subset of Matrix Orbital protocol when those byte are send over a > TCP connection on port 1337. > http://dangerousprototypes.com/twatch-manual/ > http://dangerousprototypes.com/category/twatch/ I happen to have one, too. I've powered it up, but haven't had time over the holidays to do much with it. > If #twatch firmware was to be modified or rewritten from scratch, what would > you have done differently? > My idea: > * Drop the twitter client Yes. > * Make it more LCDproc specific (trying to match LCDproc driver API) Sounds good. > At least, there is a potential for LCDproc specific firmware or feature. Indeed. I'm working on other projects right now (like Makerbots/RepRaps) and don't have enough free time to spearhead a new LCDproc driver, but I'm happy to help and test. I'm perfectly happy to test new firmware, etc., not just server code. -ethan From bsdfan at nurfuerspam.de Sun Jan 3 12:36:40 2010 From: bsdfan at nurfuerspam.de (Markus Dolze) Date: Sun, 03 Jan 2010 13:36:40 +0100 Subject: [Lcdproc] Feedback for CVS nightly build (20091227)... Message-ID: <20100103123640.193380@gmx.net> -------- Original-Nachricht -------- > Datum: Thu, 31 Dec 2009 10:35:05 +0100 > Von: "Thorsten Godau" > An: lcdproc at lists.omnipotent.net > Betreff: Re: [Lcdproc] Feedback for CVS nightly build (20091227)... > Hi, > > i did some further experiments: > > the I2C-patch causes the segmentation fault. > Without this patch and by changing "#include "report.h" > to "#include "shared/report.h" in hd44780-i2c.c it works. > > Sorry Markus, the patch doesn't work :-( > > Regards, Thorsten > _______________________________________________ > LCDproc mailing list > LCDproc at lists.omnipotent.net > http://lists.omnipotent.net/mailman/listinfo/lcdproc If you run LCDd with the attached patch and "-f -r 4" what is printed to the console before it crashes? I'm asking myself where the problem could be as it works fine in other drivers. I found a second bug, which is corrected in the attached patch as well. Regards, Markus -------------- next part -------------- A non-text attachment was scrubbed... Name: patch-hd44780-i2c.diff Type: application/octet-stream Size: 1213 bytes Desc: not available URL: From dl9sec at gmx.net Sun Jan 3 17:03:48 2010 From: dl9sec at gmx.net (Thorsten Godau) Date: Sun, 03 Jan 2010 18:03:48 +0100 Subject: [Lcdproc] Feedback for CVS nightly build (20091227)... In-Reply-To: <20100103123640.193380@gmx.net> References: <20100103123640.193380@gmx.net> Message-ID: <20100103170348.246630@gmx.net> Hi Markus, > If you run LCDd with the attached patch and "-f -r 4" what is printed to > the console before it crashes? I'm asking myself where the problem could > be as it works fine in other drivers. > I found a second bug, which is corrected in the attached patch as well. With your latest patch it runs like a charm. No chash anymore. Seems to be the second bug which causes the crash. Well done! ;-) Regards, Thorsten From TELarson at west.com Mon Jan 4 16:08:09 2010 From: TELarson at west.com (Larson, Timothy E.) Date: Mon, 4 Jan 2010 10:08:09 -0600 Subject: [Lcdproc] #twatch network LCD backpack In-Reply-To: <73314fc51001021730x1073a96ch9fd5a5bab9976b90@mail.gmail.com> References: <73314fc51001021730x1073a96ch9fd5a5bab9976b90@mail.gmail.com> Message-ID: <226316B3E1F749498E28ACA66321D5BA0130E7FBFB@oma00cexmbx03.corp.westworlds.com> > For those that remind me (David Glaude)... no I am not back yet into > LCDproc developpement... mostly because I don't have a linux computer > handy for that Well, it doesn't _have_ to be Linux. :) > and because I should clear with my day job any issue > about my right to release software I develop during the night under > GPL. I've heard about places like that. :( Kind of sad to think that "your own time" isn't really, but that's reality for ya... Tim From david.glaude at gmail.com Mon Jan 4 21:01:07 2010 From: david.glaude at gmail.com (David Glaude) Date: Mon, 4 Jan 2010 22:01:07 +0100 Subject: [Lcdproc] #twatch network LCD backpack In-Reply-To: <226316B3E1F749498E28ACA66321D5BA0130E7FBFB@oma00cexmbx03.corp.westworlds.com> References: <73314fc51001021730x1073a96ch9fd5a5bab9976b90@mail.gmail.com> <226316B3E1F749498E28ACA66321D5BA0130E7FBFB@oma00cexmbx03.corp.westworlds.com> Message-ID: <73314fc51001041301k7a5119adyde2344f26fe9c5d5@mail.gmail.com> 2010/1/4 Larson, Timothy E. > > For those that remind me (David Glaude)... no I am not back yet into > > LCDproc developpement... mostly because I don't have a linux computer > > handy for that > > Well, it doesn't _have_ to be Linux. :) > I did not mean "Linux" per se... but any Free or Open operating system running on a common desktop CPU (I have two NLSU2 and other hardware running linux inside but not really fitted for making a "normal" compile). However, I have a Mac mini running Snow Leopard under my finger... A nice asset if there is no active maintainer for the OSX version of LCDproc. Does it build without too much trouble with Apple provided compiler and other tools? If it compile and work on my Box and that Ethan can double check that the same code compile and run as expected on his how hardware (+ an additionnal friend with the same hardware) then I think it should be good enough for merging into a futur release of LCDproc. But I am not coding yet and I need to clear the thing below. > and because I should clear with my day job any issue > about my right to release software I develop during the night under > GPL. I've heard about places like that. :( Kind of sad to think that "your own > time" isn't really, but that's reality for ya... > I am not sure I work in a place like that... but I know I need to check first because the place were I work is bounded by a lot of legal and administrative rules. I just want to avoir jeopardise any GPL project without double checking first and having some written trace that it is OK. David Glaude -------------- next part -------------- An HTML attachment was scrubbed... URL: From ethan.dicks at gmail.com Mon Jan 4 21:11:17 2010 From: ethan.dicks at gmail.com (Ethan Dicks) Date: Mon, 4 Jan 2010 16:11:17 -0500 Subject: [Lcdproc] #twatch network LCD backpack In-Reply-To: <73314fc51001041301k7a5119adyde2344f26fe9c5d5@mail.gmail.com> References: <73314fc51001021730x1073a96ch9fd5a5bab9976b90@mail.gmail.com> <226316B3E1F749498E28ACA66321D5BA0130E7FBFB@oma00cexmbx03.corp.westworlds.com> <73314fc51001041301k7a5119adyde2344f26fe9c5d5@mail.gmail.com> Message-ID: On Mon, Jan 4, 2010 at 4:01 PM, David Glaude wrote: > However, I have a Mac mini running Snow Leopard under my finger... > A nice asset if there is no active maintainer for the OSX version of > LCDproc. > Does it build without too much trouble with Apple provided compiler and > other tools? I have built LCDproc in the past (2007/2008) on a Macbook pro (Intel, 10.4.3). It was a work laptop that I returned some months ago, so I no longer have it, but ISTR it was easy to get working with libusb and an LCD2USB (Till Harbaum's device) once I figured out that the hardware worked better on the other side of a USB hub (voltage problems with the older rev hardware). The same rig worked just fine with a Matrix Orbital serial-interface VFD. It was my desktop machine for over a year and I had LCDproc running on it the entire time. > If it compile and work on my Box and that Ethan can double check that the > same code compile and run as expected on his how hardware (+ an additionnal > friend with the same hardware) then I think it should be good enough for > merging into a futur release of LCDproc. Happy to help. I have a Linux laptop ready to go. > But I am not coding yet and I need to clear the thing below. > >> and because I should clear with my day job any issue >> about my right to release software I develop during the night under >> GPL. Entirely understood. I've worked at places that wanted me to sign an intellectual property agreement. I have responded with "if you sign mine, too" - I do that to exclude some commercial products I've sold in the past as well as open source projects I've worked with - that way, I have it on paper that my new employer agrees that they do not own any interest or ownership in works related to those specific projects - yes, I have explicitly included LCDproc by name in those agreements over the years. Since I'm clear about what the company does not own, I've never had an employer refuse to sign mine when I sign theirs. It does help to get it clear on the way in the door, though. -ethan From bsdfan at nurfuerspam.de Tue Jan 5 19:52:28 2010 From: bsdfan at nurfuerspam.de (Markus Dolze) Date: Tue, 05 Jan 2010 20:52:28 +0100 Subject: [Lcdproc] #twatch network LCD backpack In-Reply-To: <73314fc51001021730x1073a96ch9fd5a5bab9976b90@mail.gmail.com> References: <73314fc51001021730x1073a96ch9fd5a5bab9976b90@mail.gmail.com> Message-ID: <4B43987C.2020500@nurfuerspam.de> David Glaude wrote: > Hello, > > For those that remind me (David Glaude)... no I am not back yet into > LCDproc developpement... mostly because I don't have a linux computer > handy for that and because I should clear with my day job any issue > about my right to release software I develop during the night under GPL. Since Peter disappeared a year ago, I am happy for any support to the project, especially by people who worked on it before. > > I contact you because I made a nice discovery, fastly followed by an > aquisition (the hardware is now running next to me). And I would love > (I am not alone) to use that under LCDproc control. > > It is a networked LCD with enough hardware to hold a twitter "client" > and emulate a subset of Matrix Orbital protocol when those byte are > send over a TCP connection on port 1337. > http://dangerousprototypes.com/twatch-manual/ > http://dangerousprototypes.com/category/twatch/ > > I don't think this hardware can run a full LCDproc server... so it > still need an LCDproc server to drive it. > > What is missing is a new driver (a simplified MatrixOrbital driver > wich open the TCP connection). > Maybe it is possible to write a program that fake and /dev/ttyS device > and make the TCP connection and bridge every byte. Then run the MO > driver to send to this "device" (assuming enough of MO protocol is > emulated). > > Is there any driver currently in LCDproc CVS that does a TCP connection? The hd44780-ethlcd driver does this. > > I remember that years ago, I had the plan to separate in driver what > is relative to the "protocol" and what is relative to the > "communication channel". > Somehow, each and every driver does rewrite (copy and paste) the code > to open a serial interface and set the speed (or else). > Here (maybe for the first time) we have a known protocol (MO) with an > unknow communication channel (Open a TCP connection). > Did anybody work on this idea? I recently changed some driver's serial port handling (by using cfmakeraw) and was short to refactor the serial code, because touching 24+ drivers is hell. And we are getting more drivers... Some MO support an I2C interface. I hope to have an I2C interface for my development machine soon, so I can test I2C for other drivers. And I thought of trying it with my MO LK202. Regards, Markus From bsdfan at nurfuerspam.de Tue Jan 5 19:58:15 2010 From: bsdfan at nurfuerspam.de (Markus Dolze) Date: Tue, 05 Jan 2010 20:58:15 +0100 Subject: [Lcdproc] Question about LCD2USB... In-Reply-To: <20091230181554.230710@gmx.net> References: <20091230181554.230710@gmx.net> Message-ID: <4B4399D7.1070008@nurfuerspam.de> Thorsten Godau wrote: > Hi, > > i have some questions about LCD2USB used together with LCDproc. > > How do i have to specify the device (/dev/...) for the LCD2USB adaptor? > Or is the adaptor defined by the VendorID/ProductID? If yes, what is > the correct VID/PID for the LCD2USB? > > What is the difference between the both USB-implementations > (avrusb/tinyusb) of the LCD2USB firmware apart from the licensing? > Is there a difference in performance? Which firmware should be used > for best results with LCDproc? > > Thanks in advance. > > Regards, Thorsten > Hi, the LCD2USB devices are recognized only by VID/PID pair (VID = 0x0403, PID = 0xc630). Regarding the firmware differences you may ask Mr. Harbaum about it. For my devices I use the avrusb (now V-USB) version. It is this one I test LCDproc with. Regards, Markus From speedsix.lists at googlemail.com Wed Jan 6 10:36:59 2010 From: speedsix.lists at googlemail.com (Dom H) Date: Wed, 6 Jan 2010 10:36:59 +0000 Subject: [Lcdproc] Need help troubleshooting a possible faulty VFD unit In-Reply-To: References: Message-ID: Well I've solved the issue but I am utterly confused what the problem was. I booted an XP virtual machine in VirtualBox and enabled the Mplay USB device for the guest OS and installed the windows drivers from the Zalman CD download. Now, the serial driver installed fine but the Zalman software couldn't find the device BUT eventually the IR LED went out (flicking on with each button push as before) and after rebooting the remote functioned as before with LIRC How can the device get into such a state that isn't reset with a long power off and what put it into this state in the first place?? Thanks 2010/1/1 Dom H : > Hi all, > > I have a Zalman HD135 HTPC case which includes a VLSystem Mplay Blast > combined VFD/IR unit. While attempting to fix an LCDproc issue (by > installing a newer version) I seem to have caused a weird issue with > the IR portion of the unit. As soon as I put power to the machine the > little red led next to the IR sensor lights and stays on permanently, > it seems no IR signals are being passed through the interface either > (shared with the VFD on /dev/ttyUSB0 using the FTDI serial module) > Powering down doesn't help, as does removing all traces of > LCDproc/Lirc etc. I know this isn't strictly an LCDproc issue but I'm > at a total loss on how to fix/ this and wondered if anyone had any > thoughts on what the issue could be. It's possible the unit has gone > faulty or maybe the bios for the display has got into an inconsistent > state? > > > Any ideas at all welcome. > > > Thanks > From bsdfan at nurfuerspam.de Wed Jan 6 17:29:10 2010 From: bsdfan at nurfuerspam.de (Markus Dolze) Date: Wed, 06 Jan 2010 18:29:10 +0100 Subject: [Lcdproc] Serial port programming In-Reply-To: <4B25748C.4050904@nurfuerspam.de> References: <4B16C26A.3020003@nurfuerspam.de> <4B25748C.4050904@nurfuerspam.de> Message-ID: <4B44C866.40207@nurfuerspam.de> Markus Dolze wrote: > Markus Dolze wrote: > >> ... >> >> Additionally it is a mistake to believe /portset/ cannot be modified >> after using cfmakeraw - it can be modified, especially to set the >> timeout values! Some drivers (serialPOS, MtxOrb) refuse to use cfmakeraw >> (by commenting it out) because the author wanted to set timeouts. In the >> CrystalFontz drivers, the complete init routine if contained even twice: >> One time for serial ports using the above code and a second time for USB >> connected displays. >> >> > Hi, > > as said above, I have rewritten the serial initialization for several > drivers to use cfmakeraw: CFontz, CFontz633, CFontzPacket, CwLnx, > EyeboxOne, MtxOrb, hd44780-lis2, serialPOS. > > Commited this. Markus From bsdfan at nurfuerspam.de Wed Jan 6 18:26:42 2010 From: bsdfan at nurfuerspam.de (Markus Dolze) Date: Wed, 06 Jan 2010 19:26:42 +0100 Subject: [Lcdproc] [PATCH] 2 wrong symbols in HD44780 driver charmap In-Reply-To: References: Message-ID: <4B44D5E2.1010007@nurfuerspam.de> David Lopez Perez wrote: > 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). > Hi, committed this change (?/? to 'n with bar') to CVS. Regards, Markus From bsdfan at nurfuerspam.de Wed Jan 6 19:42:21 2010 From: bsdfan at nurfuerspam.de (Markus Dolze) Date: Wed, 06 Jan 2010 20:42:21 +0100 Subject: [Lcdproc] lcdproc ported for QNX [update] In-Reply-To: <4ADCD657.8000404@nurfuerspam.de> References: <2c26506d0910052255o19a5a86gb176007a0db8508b@mail.gmail.com> <4AD3F87C.6070901@nurfuerspam.de> <2c26506d0910132222g506877a6ga4a6f2e5683c24ad@mail.gmail.com> <4ADCD657.8000404@nurfuerspam.de> Message-ID: <4B44E79D.1080502@nurfuerspam.de> Hello, today I commited the changes related to serial port initialization. Up to now, the following parts from your QNX patch have been incorporated or fixed otherwise: * errno.h inclusion * getopt.h inclusion * min() macro usage * SA_RESTART flag usage * serial port initialization * a few declaration/code mixes What's left: * The machine depended client part. You may try again with the latest CVS version / *next* nightly build. Keep in mind that using GCC is required. Regards, Markus From ethan.dicks at gmail.com Wed Jan 6 20:41:38 2010 From: ethan.dicks at gmail.com (Ethan Dicks) Date: Wed, 6 Jan 2010 15:41:38 -0500 Subject: [Lcdproc] lcdproc ported for QNX [update] In-Reply-To: <4B44E79D.1080502@nurfuerspam.de> References: <2c26506d0910052255o19a5a86gb176007a0db8508b@mail.gmail.com> <4AD3F87C.6070901@nurfuerspam.de> <2c26506d0910132222g506877a6ga4a6f2e5683c24ad@mail.gmail.com> <4ADCD657.8000404@nurfuerspam.de> <4B44E79D.1080502@nurfuerspam.de> Message-ID: On 1/6/10, Markus Dolze wrote: > Hello, > > today I commited the changes related to serial port initialization. Up > to now, the following parts from your QNX patch have been incorporated > or fixed otherwise: . . . > You may try again with the latest CVS version / *next* nightly build. > Keep in mind that using GCC is required. Is this effort specific to a certain version of QNX? In particular, I'm interested in trying it out with my 3Com Audrey (which runs, IIRC, QNX Neutrino 6.0, but can be updated to QNX 6.1 - in particular, the un-updated Audrey has binaries linked against libc.so.1 not libc.so.2). I'd be setting up a cross-compiling environment from an Intel Linux box and using, as you say, gcc. Thanks, -ethan From bsdfan at nurfuerspam.de Thu Jan 7 22:03:09 2010 From: bsdfan at nurfuerspam.de (Markus Dolze) Date: Thu, 07 Jan 2010 23:03:09 +0100 Subject: [Lcdproc] Can't get this thing working... In-Reply-To: <20091226162338.142560@gmx.net> References: <20091201191709.262770@gmx.net> <20091202174011.87960@gmx.net> <4B16B611.0@nurfuerspam.de> <20091202192411.87960@gmx.net> <4B16D598.6000208@nurfuerspam.de> <20091203184119.145560@gmx.net> <20091226093644.255210@gmx.net> <4B35E5A9.6030706@nurfuerspam.de> <20091226162338.142560@gmx.net> Message-ID: <4B465A1D.6050600@nurfuerspam.de> Thorsten Godau wrote: > It's a pity. I really like the LCDproc package and the final aim is > still to have the display running directly via parallel port. > IMHO it is an unfortunate combination of things that makes my > display not running corrctly with LCDproc. > One thing could be a critical timing together with a bad initalisation > sequence and the other thing could be, that most of the signals on my > parallel port are high in idle state (pulled up with a resistor according > to the manual of the SBC). I also can see this with my scope. Most of the > time all the display controlling signals are high, going low for short > pulses. I expected an opposite beaviour. Maybe that's the crux. > Something in the inialisation phase confuses the display and corrupts > the init sequence. Othewise it would not run with ldc4linux... > > Hello list, today I received my EA DIP204-4. Together with a PCB Thorsten sent to me I was able to get LCDproc running. There was no change necessary. The only thing to note is that the contrast setting is different from most other HD44780 displays. On these displays one sets the contrast to show the black lines afte power-up. With the DIP204-4 setting the contrast this way is wrong, one has to set it to just *not* show the the black lines. I tried it successfully with the 4bit and winamp wiring. It even works with a LCD2USB device, although the device's initialization fails. Once LCDd did the reset by instruction it works anyway. Even brightness and contrast settings work, although the latter has its values reversed (higher values mean less contrast). For a limited time a video showing the working device can be found here: http://mdolze.gmxhome.de/images/ea_dip204-4.wmv We are suspecting something like quoted above is going wrong with Thorsten's SBC and we will continue to find out what. Regards, Markus From bsdfan at nurfuerspam.de Thu Jan 7 22:13:35 2010 From: bsdfan at nurfuerspam.de (Markus Dolze) Date: Thu, 07 Jan 2010 23:13:35 +0100 Subject: [Lcdproc] hd44780-i2c for FreeBSD Message-ID: <4B465C8F.4010600@nurfuerspam.de> Hello, just a note: part of the hardware delivery I received today was a PCF8574. After building a small I2C bit-banging interface for the parallel port (see http://www.freebsd.org/cgi/man.cgi?query=lpbb) and the hd44780-i2c wiring, I modified that driver to also work with FreeBSD's iic devices. It is currently a quick hack only, without all the autotools stuff needed to import it into LCDproc. Furthermore it is very slow and takes a lot of CPU time (20% on my P4), which is even worse than hd44680-serialLpt, but it works. Regards, Markus From chmeredith at gmail.com Mon Jan 11 05:27:02 2010 From: chmeredith at gmail.com (Christopher Meredith) Date: Sun, 10 Jan 2010 23:27:02 -0600 Subject: [Lcdproc] PT6311-LQ VFD? Message-ID: <4d73dc1a1001102127y3cb90e3cod90e74eea3ef43e7@mail.gmail.com> I have a VFD with a chip stamped "PT6311-LQ." It has what appears to be a 6-pin connection from the motherboard with leads marked: DATA - CS - CLK - I.R. - GND - GPIO24 I found a datasheet for the PT6311 here: http://www.datasheetcatalog.com/datasheets_pdf/P/T/6/3/PT6311.shtml (first one, by PTC) I suspect the PT6311-LQ is similar. Is there any chance of getting this to work with lcdproc or am I barking up the wrong tree? This is a VFD used in a standalone Bluray player and I'd like to see if I can put it to my own uses. Thanks! From satzklauer at googlemail.com Mon Jan 11 10:40:44 2010 From: satzklauer at googlemail.com (Satz Klauer) Date: Mon, 11 Jan 2010 11:40:44 +0100 Subject: [Lcdproc] lcdproc ported for QNX [update] In-Reply-To: References: <2c26506d0910052255o19a5a86gb176007a0db8508b@mail.gmail.com> <4AD3F87C.6070901@nurfuerspam.de> <2c26506d0910132222g506877a6ga4a6f2e5683c24ad@mail.gmail.com> <4ADCD657.8000404@nurfuerspam.de> <4B44E79D.1080502@nurfuerspam.de> Message-ID: <2c26506d1001110240i72498a6eye34064893308486e@mail.gmail.com> On 1/6/10, Ethan Dicks wrote: > Is this effort specific to a certain version of QNX? I used version 6.3.2 but it should work with other variants too, it doesn't uses too exotic QNX-functions. I'll check the nightly build soon on my machine. From ethan.dicks at gmail.com Mon Jan 11 15:30:33 2010 From: ethan.dicks at gmail.com (Ethan Dicks) Date: Mon, 11 Jan 2010 10:30:33 -0500 Subject: [Lcdproc] PT6311-LQ VFD? In-Reply-To: <4d73dc1a1001102127y3cb90e3cod90e74eea3ef43e7@mail.gmail.com> References: <4d73dc1a1001102127y3cb90e3cod90e74eea3ef43e7@mail.gmail.com> Message-ID: On 1/11/10, Christopher Meredith wrote: > I have a VFD with a chip stamped "PT6311-LQ." It has what appears to > be a 6-pin connection from the motherboard with leads marked: > > DATA - CS - CLK - I.R. - GND - GPIO24 > > I found a datasheet for the PT6311 here: > > http://www.datasheetcatalog.com/datasheets_pdf/P/T/6/3/PT6311.shtml Looks like a fun little chip. > I suspect the PT6311-LQ is similar. Is there any chance of getting > this to work with lcdproc or am I barking up the wrong tree? This is a > VFD used in a standalone Bluray player and I'd like to see if I can > put it to my own uses. It has, according to the datasheet, a 3-wire interface - you'd have to find the right datasheet with the command protocol, then build an interface (probably easiest off of a parallel port unless you wanted to hack an existing USB-based AVR project), then map what command bits go to which segments (since the chip doesn't know/doesn't care). Even with an eventual target of a USB interface (because so few machines have parallel ports anymore), it would probably be easier to get the interface working and map out the segments if you directly attached the VFD to your development machine. You could start with the USB MCU in-between from the get-go, but you'd be debugging two command channels simultaneously, adding to the complexity. Yes, I think it could be done. Yes, it will require a lot of coding. -ethan From chmeredith at gmail.com Mon Jan 11 16:10:16 2010 From: chmeredith at gmail.com (Christopher Meredith) Date: Mon, 11 Jan 2010 10:10:16 -0600 Subject: [Lcdproc] PT6311-LQ VFD? In-Reply-To: References: <4d73dc1a1001102127y3cb90e3cod90e74eea3ef43e7@mail.gmail.com> Message-ID: <4d73dc1a1001110810j6fd9d372yd2f96d74893586b@mail.gmail.com> On Mon, Jan 11, 2010 at 9:30 AM, Ethan Dicks wrote: > On 1/11/10, Christopher Meredith wrote: >> I have a VFD with a chip stamped "PT6311-LQ." It has what appears to >> be a 6-pin connection from the motherboard with leads marked: >> >> DATA - CS - CLK - I.R. - GND - GPIO24 >> >> I found a datasheet for the PT6311 here: >> >> http://www.datasheetcatalog.com/datasheets_pdf/P/T/6/3/PT6311.shtml > > Looks like a fun little chip. > >> I suspect the PT6311-LQ is similar. Is there any chance of getting >> this to work with lcdproc or am I barking up the wrong tree? This is a >> VFD used in a standalone Bluray player and I'd like to see if I can >> put it to my own uses. > > It has, according to the datasheet, a 3-wire interface - you'd have to > find the right datasheet with the command protocol, then build an > interface (probably easiest off of a parallel port unless you wanted > to hack an existing USB-based AVR project), then map what command bits > go to which segments (since the chip doesn't know/doesn't care). ?Even > with an eventual target of a USB interface (because so few machines > have parallel ports anymore), it would probably be easier to get the > interface working and map out the segments if you directly attached > the VFD to your development machine. ?You could start with the USB MCU > in-between from the get-go, but you'd be debugging two command > channels simultaneously, adding to the complexity. > > Yes, I think it could be done. ?Yes, it will require a lot of coding. Hi Ethan, thanks for your response. I found a more detailed datasheet from the manufacturer here: http://www.princeton.com.tw/downloadprocess/downloadfile.asp?mydownload=PT6311.pdf This datasheet also accounts for the differences between the PT6311 and the PT6311-LQ (which is the one I have). I've also taken some photos of the module I have. Those pictures are located here: http://monopedilos.com/mediagallery/album.php?aid=70&page=1 You can click through to see the full-res pictures. As you can see, it's not a multipurpose display, but it has elements for numbers in time format as well as video and audio formats. As I said, this would be a great HTPC module, if it could be made to work. I am not a programmer, but I would really like to see this thing working. I will do anything I can to help, including loaning the module to someone who is wiling to do the coding. Are there any takers? Thanks! From dl9sec at gmx.net Mon Jan 11 18:51:17 2010 From: dl9sec at gmx.net (Thorsten Godau) Date: Mon, 11 Jan 2010 19:51:17 +0100 Subject: [Lcdproc] How to build a Debian-package from the LCDproc sources? Message-ID: <20100111185117.315380@gmx.net> Hi all, the latest LCDproc Debian package is 0.5.2-3 from the testing target. Because i need some new functionality and some bugs fixed, i took one of the nightly CVS tarballs and built it myself from the sources. Is there an easy way to create a .deb-package from the sources to make the whole package cleanly installable/removable via dpkg or apt? The Debian package includes all the startup-script stuff and to be honest, i try to avoid to twiddle around manually to get my self-made LCDproc fairly integrated into my system. Any ideas, suggestions, hints? Thanks in advance. Regards, Thorsten From dl9sec at gmx.net Mon Jan 11 19:00:43 2010 From: dl9sec at gmx.net (Thorsten Godau) Date: Mon, 11 Jan 2010 20:00:43 +0100 Subject: [Lcdproc] Question about command execution by pressing a button... Message-ID: <20100111190043.315390@gmx.net> Hi again, is there a way to execute e.g. a system command by pressing a keypad button without going through the whole LCDproc menu structure? Some kind of "one-touch" command execution? I played around with lcdexec but can't find a way for such a "direct action"... Regards, Thorsten From christian.leuschen at gmx.de Mon Jan 11 21:02:30 2010 From: christian.leuschen at gmx.de (Christian Leuschen) Date: Mon, 11 Jan 2010 22:02:30 +0100 Subject: [Lcdproc] [PATCH] Custom "good bye file" Message-ID: <4B4B91E6.7060603@gmx.de> Hello list, to display information after LCDd exited, I created a patch that allows reading the content of a custom file. The lines in this file are then displayed e.g. during standby of the computer (if the display is provided with power in standby). New entry in LCDd.conf: # Custom file for setting the goodbye message with runtime information that is not available at server startup GoodByeFile=/etc/LCDd.goodbye The content of the file may be something like (a timer for a recording that shall be done - depending on the number of lines your display provides): "07.01. 20:13 ProSieb Die gro?e Quatsch Winter Show" Maybe the patch is useful for any other person except me, maybe it might be include into the lcdproc sources ... However, I did not put much effort into debugging it. It works as is for me ;-). Greets, Christian -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: lcdproc-0.5.3-customGoodbyeFile.diff URL: From david.glaude at gmail.com Mon Jan 11 21:58:38 2010 From: david.glaude at gmail.com (David Glaude) Date: Mon, 11 Jan 2010 22:58:38 +0100 Subject: [Lcdproc] [PATCH] Custom "good bye file" In-Reply-To: <4B4B91E6.7060603@gmx.de> References: <4B4B91E6.7060603@gmx.de> Message-ID: <73314fc51001111358g21787eafxed962931a34cdc89@mail.gmail.com> Sound interesting feature... I understand it is easy to have it comming from a file (so that something else can create and update the file). But what about this? GoodByeFile=/etc/passwd Is there some priviledge escalation that could come from this. Someone that has the right to modify LCDd.conf as the right to display on the LCD any file that LCDproc can access? I would prefer some other way to update the "GoodByeScreen". It could be a "special lcdproc client" that use a new feature of LCDproc API in order to "record" what should be the content of the GoodByeScreen next time it is needed. It would permit to use all the feature that are available in LCDproc such as: * custom icon * hbar/vbar * bignum It would be a normal client that say: 1) Hello I am about to build a GoodByeScreen (= do not display what I will tell you) 2) Display this / put that hbar there / use that bignum here / place that icon there / ... 3) Take a snapshoot of what should be on screen if I was currently the only client actif (without hartbeat or other distraction) 4) Goodbye That could be a LCDproc way of implementing this feature... anybody that can display something on screen can also set/change what will be display at the exit. No priviledge issue and full feature set available... just "a lot" of coding required on the server side. The other option is to have the full GoodByeScreen in the configuration file. What do you think? David Glaude 2010/1/11 Christian Leuschen > Hello list, > > to display information after LCDd exited, I created a patch that allows > reading the content of a custom file. The lines in this file are then > displayed e.g. during standby of the computer (if the display is provided > with power in standby). > > New entry in LCDd.conf: > # Custom file for setting the goodbye message with runtime information that > is not available at server startup > GoodByeFile=/etc/LCDd.goodbye > > The content of the file may be something like (a timer for a recording that > shall be done - depending on the number of lines your display provides): > "07.01. 20:13 ProSieb > Die gro?e Quatsch Winter Show" > > Maybe the patch is useful for any other person except me, maybe it might be > include into the lcdproc sources ... > However, I did not put much effort into debugging it. It works as is for me > ;-). > > Greets, > Christian > > _______________________________________________ > LCDproc mailing list > LCDproc at lists.omnipotent.net > http://lists.omnipotent.net/mailman/listinfo/lcdproc > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bsdfan at nurfuerspam.de Mon Jan 11 22:45:56 2010 From: bsdfan at nurfuerspam.de (Markus Dolze) Date: Mon, 11 Jan 2010 23:45:56 +0100 Subject: [Lcdproc] Testing of Crystalfontz displays Message-ID: <4B4BAA24.8000805@nurfuerspam.de> Hello, thanks to a generous hardware donation from Crystalfontz America, Inc. I am now able to test different models supported by LCDproc myself. It will not happen immediately, but surely within the next weeks. Regards, Markus From eldavidillo at hotmail.com Tue Jan 12 14:17:19 2010 From: eldavidillo at hotmail.com (David) Date: Tue, 12 Jan 2010 15:17:19 +0100 Subject: [Lcdproc] How to build a Debian-package from the LCDproc sources? In-Reply-To: <105e65561001120615u42115a89id6687f8f4b26fe1b@mail.gmail.com> References: <20100111185117.315380@gmx.net> <105e65561001120615u42115a89id6687f8f4b26fe1b@mail.gmail.com> Message-ID: You could create a .deb package using "checkinstall" instead of "make install": cd /path/to/lcdproc-source ./configure make sudo checkinstall That's what I do in Ubuntu when I want to install software from source, and it works well. It will generate a .deb package in the source directory, and then install it. The package can be updated or removed through apt-get, aptitude or synaptic. Since Ubuntu is Debian based, I guess it should work just the same on Debian. Hope that helps. On Mon, Jan 11, 2010 at 7:51 PM, Thorsten Godau wrote: > Hi all, > > the latest LCDproc Debian package is 0.5.2-3 from the testing target. > Because i need some new functionality and some bugs fixed, i took > one of the nightly CVS tarballs and built it myself from the sources. > > Is there an easy way to create a .deb-package from the sources to make > the whole package cleanly installable/removable via dpkg or apt? > The Debian package includes all the startup-script stuff and to be honest, > i try to avoid to twiddle around manually to get my self-made LCDproc > fairly integrated into my system. > > Any ideas, suggestions, hints? > > Thanks in advance. > > Regards, Thorsten > _______________________________________________ > LCDproc mailing list > LCDproc at lists.omnipotent.net > http://lists.omnipotent.net/mailman/listinfo/lcdproc > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dl9sec at gmx.net Wed Jan 13 18:34:03 2010 From: dl9sec at gmx.net (Thorsten Godau) Date: Wed, 13 Jan 2010 19:34:03 +0100 Subject: [Lcdproc] How to build a Debian-package from the LCDproc sources? In-Reply-To: References: <20100111185117.315380@gmx.net> Message-ID: <20100113183403.119380@gmx.net> Hi David, > You could create a .deb package using "checkinstall" instead of "make > install": > > cd /path/to/lcdproc-source > ./configure > make > sudo checkinstall Yes, i know checkinstall. As far as i understood, checkinstall "wraps" around "make install" and monitors what "make install" would do. The binaries are packed together with the generated install scripts. > That's what I do in Ubuntu when I want to install software from source, > and it works well. It will generate a .deb package in the source > directory, and then install it. The package can be updated or removed > through apt-get, aptitude or synaptic. Since Ubuntu is Debian based, > I guess it should work just the same on Debian. I already tried this, but that's not what i want. Someone built the official Debian lcdproc package. Therefore he/she has to configure the makefile and to tune the thing with all these parameters to integrate seamless into an existing Debian installation, including all the scripting-stuff to start the daemon within the bootprocess. But what are these parameters?? I saw, that there is a directory "/scrips" and "scrips/debian". Maybe all the stuff inside is exactly what i need, but i don't know how! The little README says: "Simply copy the debian/ directory to the top-level source directory, adapt the call in debian/rules to your wishes, call dpkg -rfakeoot -sd and you're done." What the hell are "my whishes"? ;-)) Should i really poke around in a configuration file i do not understand? Is the top-level source directory where "CREDITS" is located? Why is the "/debian"-directory not located there right from the start? And: what happens with "dpkg -rfakeoot -sd". Will a .deb-package appear, which installs exactly like the package from the Debian repository? So this little sentence above poses more questions than gave me answers :-)) I would be really great if someone can provide a little how-to... Thanks in advance. Regards, Thorsten From shane at blackett.co.nz Sun Jan 17 01:02:05 2010 From: shane at blackett.co.nz (Shane Blackett) Date: Sun, 17 Jan 2010 14:02:05 +1300 Subject: [Lcdproc] Older vfd lockups Message-ID: <4B52618D.4090509@blackett.co.nz> Hi, I have been working with the imon lcd driver for about a year. Initially I used Ubuntu 9.04 and sometimes it would work for days at a time but occasionally it would lock hard and you could not unload the module or restart LCDd. Upon upgrading to Ubuntu 9.10 it now works for about a second after each reboot and then locks hard the same. Intially it wrote some urb errors, which I found a thread on, and started experimenting with some delays. I didn't have any success though finding any values that helped me. However now it doesn't write the same errors to the log, it just locks up. I installed the special package for enabling development of the lirc kernel source modules from source and have been tinkering with these. I believe my kernel source for the lirc_imon driver is up to date (although I didn't sync up the rest of the lirc kernel module I don't think it's very out of date). I added some printf debugging for the write and reads (which you will see in the dmesg log). I haven't actually tried to use the IR in the device as the IR in the Hauppauge tuner card that I have has always worked well so I've used that instead. [ 18.670927] lirc_dev: IR Remote Control driver registered, major 61 [ 18.672324] lirc_imon: Driver for SoundGraph iMON MultiMedia IR/Display, v0.6.1 [ 18.672354] lirc_imon: imon_probe: overriding display type to 1 via modparam [ 18.672357] lirc_imon: imon_probe: found iMON device (15c2:ffdc, intf0) [ 18.672361] lirc_imon: imon_probe: found IR endpoint [ 18.672362] lirc_imon: imon_probe: found display endpoint [ 18.672364] lirc_imon: imon_probe: ir_onboard_decode: 1 [ 18.672366] lirc_imon: imon_probe: vfd_proto_6p: 1 [ 18.672374] lirc_dev: lirc_register_driver: sample_rate: 0 [ 18.672415] lirc_imon: Registered iMON driver (lirc minor: 0) [ 18.672468] input: iMON PAD IR Mouse (15c2:ffdc) as /devices/pci0000:00/0000:00:02.0/usb3/3-4/3-4:1.0/input/input6 [ 18.672518] lirc_imon: imon_probe: Registering iMON display with sysfs [ 18.676539] lirc_imon: send_packet ffff8801105b48ac 8 I'm happy to try suggestions to try and debug this further but I don't really have an idea where to look next. I do still have the 9.04 installation in a partition too, if I can use this to compare what is going on. I read the thread for the "imonlcd and 0038 breakage" and didn't really see anything else I should try although I may have missed some ideas in there. Hoping I can help, Shane. From satzklauer at googlemail.com Mon Jan 18 12:36:31 2010 From: satzklauer at googlemail.com (Satz Klauer) Date: Mon, 18 Jan 2010 13:36:31 +0100 Subject: [Lcdproc] lcdproc ported for QNX [update] In-Reply-To: <2c26506d1001110240i72498a6eye34064893308486e@mail.gmail.com> References: <2c26506d0910052255o19a5a86gb176007a0db8508b@mail.gmail.com> <4AD3F87C.6070901@nurfuerspam.de> <2c26506d0910132222g506877a6ga4a6f2e5683c24ad@mail.gmail.com> <4ADCD657.8000404@nurfuerspam.de> <4B44E79D.1080502@nurfuerspam.de> <2c26506d1001110240i72498a6eye34064893308486e@mail.gmail.com> Message-ID: <2c26506d1001180436k5716e57akbbca14c358540fb2@mail.gmail.com> OK, where can I find the nighly CVS snapshot? The one from http://lcdproc.sourceforge.net/nightly/lcdproc-CVS-current.tar.gz does not seem to contain any of the modifications... On 1/11/10, Satz Klauer wrote: > On 1/6/10, Ethan Dicks wrote: > >> Is this effort specific to a certain version of QNX? > > I used version 6.3.2 but it should work with other variants too, it > doesn't uses too exotic QNX-functions. > > I'll check the nightly build soon on my machine. > From fblack947 at yahoo.com Mon Jan 18 14:15:15 2010 From: fblack947 at yahoo.com (jk) Date: Mon, 18 Jan 2010 06:15:15 -0800 (PST) Subject: [Lcdproc] Older vfd lockups In-Reply-To: <4B52618D.4090509@blackett.co.nz> References: <4B52618D.4090509@blackett.co.nz> Message-ID: <230904.1620.qm@web37504.mail.mud.yahoo.com> Are you sure you're using the correct lcdproc driver (LCD vs VFD)? (more below) ----- Original Message ---- > From: Shane Blackett > Sent: Sat, January 16, 2010 8:02:05 PM > Subject: [Lcdproc] Older vfd lockups > > I have been working with the imon lcd driver for about a year. > Initially I used Ubuntu 9.04 and sometimes it would work for days at a time but > occasionally it would lock hard and you could not unload the module or restart > LCDd. > > Upon upgrading to Ubuntu 9.10 it now works for about a second after each reboot > and then locks hard the same. > > Intially it wrote some urb errors, which I found a thread on, and started > experimenting with some delays. I didn't have any success though finding any > values that helped me. > However now it doesn't write the same errors to the log, it just locks up. > > I installed the special package for enabling development of the lirc kernel > source modules from source and have been tinkering with these... > ... > [ 18.672357] lirc_imon: imon_probe: found iMON device (15c2:ffdc, intf0) > ... > > Shane. It looks like you have device version 15c2:ffdc, which can be an LCD or VFD, and the lcdproc drivers are different for each. After confirming that you actually have a VFD (or LCD), I recommend removing all aspects of lirc and lcdproc (all config files, etc) and then reinstalling them. An :ffdc device should work out of the box with the newer versions of lirc (>=0.8.4a) and lcdproc (0.5.3). A VFD probably works with older versions than that. Unfortunately, SoundGraph likes to change is protocols around a lot, and that causes the issues between the VFD and LCD, and even with different versions of the LCD. It's even more annoying that the :ffdc device designation is assigned to a VFD and an LCD. LIRC has been working with :ffdc devices for a while now, and LCDPROC since it's most recent version, v0.5.3. Other than ensuring that your configuration files are correct, you shouldn't have to mess with anything to get them working. Things are a bit different for newer versions of the LCD, which required more tweaks to LIRC. Some references: * http://www.mythtv.org/wiki/Imon - older information (circa 2008), but good pictures and overall descriptions. * https://help.ubuntu.com/community/IMON_VFD_and_LCD (see the notes on the bottom) * http://ubuntuforums.org/showthread.php?t=1069267 - an old thread that deals with lcdproc v0.5.2 and ubuntu 8.10, but has some background on what's going on. lcdproc v0.5.3 has slightly different options in the LCDd.conf file. -jonathan From bsdfan at nurfuerspam.de Mon Jan 18 23:23:53 2010 From: bsdfan at nurfuerspam.de (Markus Dolze) Date: Tue, 19 Jan 2010 00:23:53 +0100 Subject: [Lcdproc] Parallel port keyboard issue In-Reply-To: <4B2A0494.9030705@nurfuerspam.de> References: <4B216804.7050207@nurfuerspam.de> <20091213083447.245570@gmx.net> <4B257397.8040304@nurfuerspam.de> <4B2A0494.9030705@nurfuerspam.de> Message-ID: <4B54ED89.5040203@nurfuerspam.de> Markus Dolze wrote: > Markus Dolze wrote: > >> Hi, >> >> attached is a patch which corrects the behaviour by excluding the >> backlight line when scanning for a keypad. It affects CT '4bit' and >> '8bit'. Up to now I have only tested the 4bit CT. >> >> For the 8bit CT the last keypad line is lost, but nothing else has to be >> changed. For the 4bit CT however, any existing keypad wirings using more >> than 5 rows have to be changed. >> > Hi, > > I updated the patch. It now takes into account if a switchable backlight > is configured or not. If it is, it's line is excluded from the keypad scan. > > So, for anyone who is currently using a keypad with more than 5 rows but > no switchable backlight nothing changes. > > Regards, > Markus > Committed, along with some documentation updates. Markus From matpoc at mail.ru Tue Jan 19 17:36:29 2010 From: matpoc at mail.ru (Yura Scheglyuk) Date: Wed, 20 Jan 2010 00:36:29 +0700 Subject: [Lcdproc] [PATCH] hd44780-charmap.h Russian charmaps Message-ID: <4B55ED9D.8000404@mail.ru> Hi! I made patch for Russian charmaps KOI8-R, CP-1251 (Windows-1251), ISO 8859-5. Patch for lcdproc 0.5.3 hd44780-charmap.h for displays with a ROM mask supporting the european charset (ROM code A02). This patch also contains AS-IS charmap for apps that already remapping chars by itself. It may be useful for debugging and making own charmaps. -- Best regards, Yura Scheglyuk. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: docs-lcdproc-user-driversv-hd44780.docbook.patch URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: LCDd-hd44780.conf.patch URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: server-drivers-hd44780-charmap.h.patch URL: From matpoc at mail.ru Tue Jan 19 17:54:40 2010 From: matpoc at mail.ru (Yura Scheglyuk) Date: Wed, 20 Jan 2010 00:54:40 +0700 Subject: [Lcdproc] [PATCH] imon driver charmap support Message-ID: <4B55F1E0.6090607@mail.ru> Hi! I made patch for imon driver charmap support (lcdproc 0.5.3). This patch based on hd44780 patches by Pillon Matteo and hd44780-charmap.h charmaps. Now you can select CharMap in LCDd.conf for imon as it made for hd44780 driver. Also this patch using my previous patch for hd44780 Russian charmaps. -- Best regards, Yura Scheglyuk. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: docs-lcdproc-user-driversv-imon.docbook.patch URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: LCDd-imon.conf.patch URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: server-drivers-imon.c.patch URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: server-drivers-Makefile.in.patch URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: server-driversv-Makefile.am.patch URL: From bsdfan at nurfuerspam.de Wed Jan 20 05:52:07 2010 From: bsdfan at nurfuerspam.de (Markus Dolze) Date: Wed, 20 Jan 2010 06:52:07 +0100 Subject: [Lcdproc] Renewed server input buffer In-Reply-To: <20091227102621.24610@gmx.net> References: <20091227102621.24610@gmx.net> Message-ID: <4B569A07.7050207@nurfuerspam.de> Markus Dolze wrote: > Hello, > > back in February I started a discussion about how to improve LCDd's way to buffer incoming client messages (see http://lists.omnipotent.net/pipermail/lcdproc/2009-February/012744.html). > > I now completely rewrote the input buffer handling and introduced a circular buffer for incoming messages. > > As I would like to commit this soon, I encourage everybody to try it. It runs stable for days on my displays right now. > > One additional improvement could be to have such a buffer per client. Right now there is one such buffer for the whole server and the buffer is cleared when it exits sock_read_from_client() for a single client. > > Regards, > Markus > Committed this. Markus From bsdfan at nurfuerspam.de Wed Jan 20 05:57:29 2010 From: bsdfan at nurfuerspam.de (Markus Dolze) Date: Wed, 20 Jan 2010 06:57:29 +0100 Subject: [Lcdproc] [PATCH] hd44780-charmap.h Russian charmaps In-Reply-To: <4B55ED9D.8000404@mail.ru> References: <4B55ED9D.8000404@mail.ru> Message-ID: <4B569B49.4090702@nurfuerspam.de> Yura Scheglyuk wrote: > Hi! > > I made patch for Russian charmaps KOI8-R, CP-1251 (Windows-1251), ISO > 8859-5. > > Patch for lcdproc 0.5.3 hd44780-charmap.h for displays with a ROM mask > supporting the european charset (ROM code A02). > > This patch also contains AS-IS charmap for apps that already remapping > chars by itself. It may be useful for debugging and making own charmaps. Hi, since several days, the HD44780 contains a 'none' charmap, which does not map any characters. This is the same as your AS-IS charmap. For the other ones I am not yet convinced to commit them. Up to now we assume that everything the server received is in ISO8859-1 and map that on the output side. Your patches assume that something different than ISO8859-1 arrives on the input side and map that to the same output charset. Starting with a patch like this, we may end up with (m*n) mappings (m = input charset, n= output charset). I would like to hear other people's comments on this. Regards, Markus From matpoc at mail.ru Wed Jan 20 06:22:13 2010 From: matpoc at mail.ru (Yura Scheglyuk) Date: Wed, 20 Jan 2010 13:22:13 +0700 Subject: [Lcdproc] =?koi8-r?b?W1BBVENIXSBoZDQ0NzgwLWNoYXJtYXAuaCBSdXNzaWFu?= =?koi8-r?b?IGNoYXJtYXBz?= In-Reply-To: <4B569B49.4090702@nurfuerspam.de> References: <4B569B49.4090702@nurfuerspam.de> Message-ID: Hi! Markus Dolze wrote: > For the other ones I am not yet convinced to commit them. Up to now we > assume that everything the server received is in ISO8859-1 and map that > on the output side. Your patches assume that something different than > ISO8859-1 arrives on the input side and map that to the same output charset. ISO8859-1 encodes what it refers to as "Latin alphabet no. 1,". But Russian is based on a Cyrillic alphabet and there are 3 commonly used charsets for it: KOI8-R, CP-1251 (Windows-1251), ISO 8859-5. So you can commit only one Russian charmap, for example CP-1251 (Windows-1251) that is the mostly used. -- Best regards, Yura Scheglyuk. From shane at blackett.co.nz Wed Jan 20 08:48:01 2010 From: shane at blackett.co.nz (Shane Blackett) Date: Wed, 20 Jan 2010 21:48:01 +1300 Subject: [Lcdproc] Older vfd lockups In-Reply-To: <230904.1620.qm@web37504.mail.mud.yahoo.com> References: <4B52618D.4090509@blackett.co.nz> <230904.1620.qm@web37504.mail.mud.yahoo.com> Message-ID: <4B56C341.80507@blackett.co.nz> On 19/01/10 03:15, jk wrote: > Are you sure you're using the correct lcdproc driver (LCD vs VFD)? I think I understand the misused device numbers. I believe I have a VFD device, it looks identical to the image in for the VFD in the link you provided below: http://www.mythtv.org/wiki/Imon The display did work with Ubuntu 9.04 (although locked up after a long time, sometimes running for more than a week). It does start up now, but always locks after a few frames of the LCDd server scrolling, resulting in text which is similar to the image for the VFD at http://www.mythtv.org/wiki/Imon I have to power the machine off at the wall to reset it. I'm surprised that if I have the wrong device that it would might work at all, I guess the I assumed that fact that it starts up implied to me that it is getting the right device type. > (more below) > > ----- Original Message ---- >> From: Shane Blackett >> Sent: Sat, January 16, 2010 8:02:05 PM >> Subject: [Lcdproc] Older vfd lockups >> >> I have been working with the imon lcd driver for about a year. >> Initially I used Ubuntu 9.04 and sometimes it would work for days at a time but >> occasionally it would lock hard and you could not unload the module or restart >> LCDd. >> >> Upon upgrading to Ubuntu 9.10 it now works for about a second after each reboot >> and then locks hard the same. >> >> Intially it wrote some urb errors, which I found a thread on, and started >> experimenting with some delays. I didn't have any success though finding any >> values that helped me. >> However now it doesn't write the same errors to the log, it just locks up. >> >> I installed the special package for enabling development of the lirc kernel >> source modules from source and have been tinkering with these... >> ... >> [ 18.672357] lirc_imon: imon_probe: found iMON device (15c2:ffdc, intf0) >> ... >> >> Shane. > > It looks like you have device version 15c2:ffdc, which can be an LCD or VFD, and the lcdproc drivers are different for each. > > After confirming that you actually have a VFD (or LCD), I recommend removing all aspects of lirc and lcdproc (all config files, etc) and then reinstalling them. An :ffdc device should work out of the box with the newer versions of lirc (>=0.8.4a) and lcdproc (0.5.3). A VFD probably works with older versions than that. My lirc is 0.8.6 from the ubuntu lirc-modules-source package. I diffed this with 0.8.6 lirc src tar ball and there are only packaging differences as far as I can see. My lcdproc is 0.5.3, I will have another go. I hadn't seen this page before, although there is very little in it: https://help.ubuntu.com/community/IMON_VFD_and_LCD_Karmic_9.10 As I upgraded this box from 9.04 to 9.10 there could be some issue with a mismatched configuration, but I have read all the files many times before resorting to building from source. > Unfortunately, SoundGraph likes to change is protocols around a lot, and that causes the issues between the VFD and LCD, and even with different versions of the LCD. It's even more annoying that the :ffdc device designation is assigned to a VFD and an LCD. > > LIRC has been working with :ffdc devices for a while now, and LCDPROC since it's most recent version, v0.5.3. Yes I see that it has been supported for a while. I guess I was wondering if something that is changing in the underlying kernel is causing these devices to break. Problems with locking up seem to be relatively common on this list, across a number of devices, somewhat resolved with some delays, which is why I tried this. > Other than ensuring that your configuration files are correct, you shouldn't have to mess with anything to get them working. > > Things are a bit different for newer versions of the LCD, which required more tweaks to LIRC. > > Some references: > * http://www.mythtv.org/wiki/Imon - older information (circa 2008), but good pictures and overall descriptions. > * https://help.ubuntu.com/community/IMON_VFD_and_LCD (see the notes on the bottom) > * http://ubuntuforums.org/showthread.php?t=1069267 - an old thread that deals with lcdproc v0.5.2 and ubuntu 8.10, but has some background on what's going on. lcdproc v0.5.3 has slightly different options in the LCDd.conf file. Thanks for giving lots of information. I have read these many times before and read these again today. I guess I could be missing something. I stopped the LCDd service from starting so I could control the start myself. It just starts up and nothing seems to be written, maybe I need to up its output. blackett at blackett-mythtv:~$ sudo LCDd -f -s 0 -r 4 LCDd version 0.5.3 starting Built on Oct 14 2009, protocol version 0.3, API version 0.5 Using Configuration File: /etc/LCDd.conf Set report level to 4, output to stderr 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 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. Server running in foreground Listening for queries on 127.0.0.1:13666 imon: using Device /dev/lcd0 Key "Escape" is now reserved exclusively by client [-1] Key "Enter" is now reserved shared by client [-1] Key "Up" is now reserved shared by client [-1] Key "Down" is now reserved shared by client [-1] screenlist_switch: switched to screen [_server_screen] From the dmesg log I get to see the transition from working to failing with my printf debugging: [ 51.257096] lirc_imon: Writing data 32 70200707 [ 51.261100] lirc_imon: send_packet ffff880122632cac 8 [ 51.345084] lirc_imon: send_packet ffff880122632cac 8 [ 51.356815] lirc_imon: send_packet ffff880122632cac 8 [ 51.364907] lirc_imon: send_packet ffff880122632cac 8 [ 51.373113] lirc_imon: send_packet ffff880122632cac 8 [ 51.380840] lirc_imon: send_packet ffff880122632cac 8 [ 51.385009] lirc_imon: Writing data 32 44200707 [ 51.389009] lirc_imon: send_packet ffff880122632cac 8 [ 51.470104] lirc_imon: send_packet ffff880122632cac 8 [ 71.972696] lirc_imon: send_packet: task interrupted [ 71.976703] lirc_imon: send_packet ffff880122632cac 8 [ 71.976706] lirc_imon: send_packet: error submitting urb(-22) [ 71.976708] lirc_imon: vfd_write: send packet failed for packet #1 [ 71.980726] lirc_imon: send_packet ffff880122632cac 8 [ 71.980730] lirc_imon: send_packet: error submitting urb(-22) [ 71.980732] lirc_imon: vfd_write: send packet failed for packet #0 [ 71.980737] display port closed [ 74.549012] display port opened [ 74.553383] lirc_imon: send_packet ffff880122632cac 8 [ 74.553386] lirc_imon: send_packet: error submitting urb(-22) [ 74.553389] lirc_imon: vfd_write: send packet failed for packet #0 [ 74.678589] lirc_imon: send_packet ffff880122632cac 8 [ 74.678592] lirc_imon: send_packet: error submitting urb(-22) [ 74.678594] lirc_imon: vfd_write: send packet failed for packet #0 [ 74.803680] lirc_imon: send_packet ffff880122632cac 8 [ 74.803682] lirc_imon: send_packet: error submitting urb(-22) [ 74.803684] lirc_imon: vfd_write: send packet failed for packet #0 [ 74.928515] lirc_imon: send_packet ffff880122632cac 8 [ 74.928517] lirc_imon: send_packet: error submitting urb(-22) [ 74.928519] lirc_imon: vfd_write: send packet failed for packet #0 [ 75.053571] lirc_imon: send_packet ffff880122632cac 8 The display port entries coincide with me restarting LCDd. When the device is locked I cannot remove the module either. sudo modprobe -r lirc_imon hangs and never returns. Thanks for your patience. Shane. From matpoc at mail.ru Wed Jan 20 10:11:48 2010 From: matpoc at mail.ru (Yura Scheglyuk) Date: Wed, 20 Jan 2010 17:11:48 +0700 Subject: [Lcdproc] =?koi8-r?b?W1BBVENIXSBoZDQ0NzgwLWNoYXJtYXAuaCBSdXNzaWFu?= =?koi8-r?b?IGNoYXJtYXBz?= In-Reply-To: References: Message-ID: Hi! Yura Scheglyuk wrote: > ISO8859-1 encodes what it refers to as "Latin alphabet no. 1,". But Russian is based on a Cyrillic alphabet and there are 3 commonly used charsets for it: KOI8-R, CP-1251 (Windows-1251), ISO 8859-5. > > So you can commit only one Russian charmap, for example CP-1251 (Windows-1251) that is the mostly used. I think we need as minimum two charset: KOI8-R for Unix, and CP-1251 (Windows-1251) that is the mostly used in Windows. -- Best regards, Yura Scheglyuk. From fblack947 at yahoo.com Wed Jan 20 14:10:08 2010 From: fblack947 at yahoo.com (jk) Date: Wed, 20 Jan 2010 06:10:08 -0800 (PST) Subject: [Lcdproc] Older vfd lockups In-Reply-To: <4B56C341.80507@blackett.co.nz> References: <4B52618D.4090509@blackett.co.nz> <230904.1620.qm@web37504.mail.mud.yahoo.com> <4B56C341.80507@blackett.co.nz> Message-ID: <663685.30764.qm@web37502.mail.mud.yahoo.com> I'm shooting from the hip on this one. If anyone with more imon (vfd) driver experience wants to drop in, it'd be appreciated! > I will have another go. I hadn't seen this page before, although there is very > little in it: https://help.ubuntu.com/community/IMON_VFD_and_LCD_Karmic_9.10 > ... That's a pretty good page. Not much on troubleshooting, but I'll have to keep it in my bookmarks... > > LIRC has been working with :ffdc devices for a while now, and LCDPROC > since it's most recent version, v0.5.3. > > Yes I see that it has been supported for a while. I guess I was wondering if > something that is changing in the underlying kernel is causing these devices to > break. Problems with locking up seem to be relatively common on this list, > across a number of devices, somewhat resolved with some delays, which is why I > tried this. > I'm far more familiar with the imonlcd driver, which branched off from the imon (vfd) driver a while ago. A buffer was added to the imonlcd driver, so that it wouldn't update the display if nothing changed. This apparently helped with "faster" computers. I think there also was (still is?) a parameter setting to limit the frequency of the screen refresh, which might still be there, and might help. Is there a way you can isolate lcdproc from lirc to determine whether the issue is in lcdproc client, lcdproc server, lirc, or something else? You're lirc debugging looks to be going in that direction. For example, what causes "send_packet: task interrupted" and "send_packet: error submitting urb(-22)" ? Good luck, and keep us posted! -jonathan From jarod at wilsonet.com Wed Jan 20 14:30:09 2010 From: jarod at wilsonet.com (Jarod Wilson) Date: Wed, 20 Jan 2010 09:30:09 -0500 Subject: [Lcdproc] Older vfd lockups In-Reply-To: <663685.30764.qm@web37502.mail.mud.yahoo.com> References: <4B52618D.4090509@blackett.co.nz> <230904.1620.qm@web37504.mail.mud.yahoo.com> <4B56C341.80507@blackett.co.nz> <663685.30764.qm@web37502.mail.mud.yahoo.com> Message-ID: On Wed, Jan 20, 2010 at 9:10 AM, jk wrote: > I'm shooting from the hip on this one. ?If anyone with more imon (vfd) driver experience wants to drop in, it'd be appreciated! > >> I will have another go. ?I hadn't seen this page before, although there is very >> little in it: https://help.ubuntu.com/community/IMON_VFD_and_LCD_Karmic_9.10 >> ... > > That's a pretty good page. ?Not much on troubleshooting, but I'll have to keep it in my bookmarks... This part is rather misleading: "But wait - Just because you no longer have to patch anything doesn't mean that you don't still need to determine which display you have and enable the correct settings in /etc/LCDd.conf and also add the correct kernel options for lirc_imon at /etc/modrobe.d/lirc.conf." Outside of the ffdc devices, you shouldn't have to touch a damned thing, auto-detection of display type and auto-config of stuff should Just Work. > A buffer was added to the imonlcd driver, so that it wouldn't update the display if nothing changed. ?This apparently helped with "faster" computers. ?I think there also was (still is?) a parameter setting to limit the frequency of the screen refresh, which might still be there, and might help. Is this in the lcdproc driver? Nobody ever got back to me with any useful feedback on whether adding a delay in the kernel driver helped with this issue... > Is there a way you can isolate lcdproc from lirc to determine whether the issue is in lcdproc client, lcdproc server, lirc, or something else? ?You're lirc debugging looks to be going in that direction. > > For example, what causes "send_packet: task interrupted" and "send_packet: error submitting urb(-22)" ? Its in the imon driver's send_packet function: retval = usb_submit_urb(ictx->tx_urb, GFP_KERNEL); if (retval) { ictx->tx.busy = 0; smp_rmb(); /* ensure later readers know we're not busy */ err("%s: error submitting urb(%d)", __func__, retval); } else { /* Wait for transmission to complete (or abort) */ mutex_unlock(&ictx->lock); retval = wait_for_completion_interruptible( &ictx->tx.finished); if (retval) err("%s: task interrupted", __func__); mutex_lock(&ictx->lock); retval = ictx->tx.status; if (retval) err("%s: packet tx failed (%d)", __func__, retval); } -22 is -EINVAL, not quite sure what happened to the completion event there. Would be much easier to debug these problems if I actually had an imon device that exhibited them, both my (newer than ffdc) VFD and LCD work flawlessly though. :\ -- Jarod Wilson jarod at wilsonet.com From christian.leuschen at gmx.de Wed Jan 20 18:01:32 2010 From: christian.leuschen at gmx.de (Christian Leuschen) Date: Wed, 20 Jan 2010 19:01:32 +0100 Subject: [Lcdproc] [PATCH] imonlcd driver fix (special icon) Message-ID: <4B5744FC.6040502@gmx.de> Hello, the patch included in this mail fixes an issue with a special icon on the imon-lcd that does not get displayed without the patch. It also switches vbars to "norrow style" as a spectrum analyzer with "full style" looks awful - IMHO. Greets, Christian lcdproc-0.5.3-imonlcd-mpg-audio-icon.diff --- /var/tmp/portage/app-misc/lcdproc-0.5.3/work/lcdproc-0.5.3/server/drivers/imonlcd.c 2009-06-20 15:48:34.000000000 +0200 +++ /tmp/lcdproc-0.5.3/server/drivers/imonlcd.c 2010-01-18 21:12:14.000000000 +0100 @@ -654,7 +654,7 @@ * rest */ lib_vbar_static(drvthis, x, y, len, promille, options, - p->cellheight, IMONLCD_FONT_START_VBAR_FULL - 1); + p->cellheight, IMONLCD_FONT_START_VBAR_NARROW-1); } @@ -1035,7 +1035,7 @@ if (((state& IMON_OUTPUT_BMICONS_MASK) != 0)) { switch (((state& IMON_OUTPUT_BMICONS_MASK)>> 16)) { case 1: - icon |= IMON_ICON_MPG; + icon |= IMON_ICON_MPG2; break; case 2: icon |= IMON_ICON_AC3; -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: lcdproc-0.5.3-imonlcd-mpg-audio-icon.diff URL: From TELarson at west.com Wed Jan 20 18:46:30 2010 From: TELarson at west.com (Larson, Timothy E.) Date: Wed, 20 Jan 2010 12:46:30 -0600 Subject: [Lcdproc] install-server target installs client doco Message-ID: <226316B3E1F749498E28ACA66321D5BA01318FA1C6@oma00cexmbx03.corp.westworlds.com> Following are two patches (against 0.5.3) to try to separate installation of doco depending on whether "make install-server" or "make install-clients" is used. Some of the work had already been done, but looked like it had been left unfinished. These patches seem to work, but more testing is, of course, appreciated. However, there are no corresponding uninstall-server/uninstall-clients targets. I am no expert on makefiles, so I didn't want to go hacking into it myself. It ought to be fairly simple to someone more knowledge than myself, though. Thanks, Tim --- docs/Makefile.am.orig Sat Jun 20 08:48:34 2009 +++ docs/Makefile.am Wed Jan 20 11:57:21 2010 @@ -1,6 +1,8 @@ ## Process this file with automake to produce Makefile.in -man_MANS = lcdproc.1 lcdexec.1 lcdvc.1 LCDd.8 lcdproc-config.5 +man1_MANS = lcdproc.1 lcdexec.1 lcdvc.1 +man5_MANS = lcdproc-config.5 +man8_MANS = LCDd.8 SUBDIRS = lcdproc-user lcdproc-dev doxygen_input = header.html footer.html --- docs/Makefile.in.orig Sun Jun 21 10:09:27 2009 +++ docs/Makefile.in Wed Jan 20 12:00:16 2010 @@ -60,7 +60,7 @@ man5dir = $(mandir)/man5 man8dir = $(mandir)/man8 NROFF = nroff -MANS = $(man_MANS) +MANS = $(man1_MANS) $(man5_MANS) $(man8_MANS) ETAGS = etags CTAGS = ctags DIST_SUBDIRS = $(SUBDIRS) @@ -182,7 +182,9 @@ sharedstatedir = @sharedstatedir@ sysconfdir = @sysconfdir@ target_alias = @target_alias@ -man_MANS = lcdproc.1 lcdexec.1 lcdvc.1 LCDd.8 lcdproc-config.5 +man1_MANS = lcdproc.1 lcdexec.1 lcdvc.1 +man5_MANS = lcdproc-config.5 +man8_MANS = LCDd.8 SUBDIRS = lcdproc-user lcdproc-dev doxygen_input = header.html footer.html EXTRA_DIST = lcdproc.1.in \ From fblack947 at yahoo.com Wed Jan 20 18:50:08 2010 From: fblack947 at yahoo.com (jk) Date: Wed, 20 Jan 2010 10:50:08 -0800 (PST) Subject: [Lcdproc] [PATCH] imonlcd driver fix (special icon) In-Reply-To: <4B5744FC.6040502@gmx.de> References: <4B5744FC.6040502@gmx.de> Message-ID: <593796.29799.qm@web37501.mail.mud.yahoo.com> >From: Christian Leuschen > >>the patch included in this mail fixes an issue with a special icon on >the imon-lcd that does not get displayed without the patch. Nice catch. > >>It also switches vbars to "norrow style" as a spectrum analyzer with >"full style" looks awful - IMHO. > I don't really have an opinion on the vbar style, but the comment on line 652 should be updated accordingly. -jonathan From shane at blackett.co.nz Wed Jan 20 20:48:41 2010 From: shane at blackett.co.nz (Shane Blackett) Date: Thu, 21 Jan 2010 09:48:41 +1300 Subject: [Lcdproc] Older vfd lockups In-Reply-To: References: <4B52618D.4090509@blackett.co.nz> <230904.1620.qm@web37504.mail.mud.yahoo.com> <4B56C341.80507@blackett.co.nz> <663685.30764.qm@web37502.mail.mud.yahoo.com> Message-ID: <4B576C29.2030907@blackett.co.nz> On 21/01/2010 3:30 a.m., Jarod Wilson wrote: > On Wed, Jan 20, 2010 at 9:10 AM, jk wrote: >> I'm shooting from the hip on this one. If anyone with more imon (vfd) driver experience wants to drop in, it'd be appreciated! >> >>> I will have another go. I hadn't seen this page before, although there is very >>> little in it: https://help.ubuntu.com/community/IMON_VFD_and_LCD_Karmic_9.10 >>> ... >> >> That's a pretty good page. Not much on troubleshooting, but I'll have to keep it in my bookmarks... > > This part is rather misleading: > > "But wait - Just because you no longer have to patch anything doesn't > mean that you don't still need to determine which display you have and > enable the correct settings in /etc/LCDd.conf and also add the correct > kernel options for lirc_imon at /etc/modrobe.d/lirc.conf." > > Outside of the ffdc devices, you shouldn't have to touch a damned > thing, auto-detection of display type and auto-config of stuff should > Just Work. > >> A buffer was added to the imonlcd driver, so that it wouldn't update the display if nothing changed. This apparently helped with "faster" computers. I think there also was (still is?) a parameter setting to limit the frequency of the screen refresh, which might still be there, and might help. I'll have a look to see if there are some clues in the imonlcd driver for me to try. > Is this in the lcdproc driver? Nobody ever got back to me with any > useful feedback on whether adding a delay in the kernel driver helped > with this issue... > >> Is there a way you can isolate lcdproc from lirc to determine whether the issue is in lcdproc client, lcdproc server, lirc, or something else? You're lirc debugging looks to be going in that direction. >> >> For example, what causes "send_packet: task interrupted" and "send_packet: error submitting urb(-22)" ? > > Its in the imon driver's send_packet function: > > retval = usb_submit_urb(ictx->tx_urb, GFP_KERNEL); > if (retval) { > ictx->tx.busy = 0; > smp_rmb(); /* ensure later readers know we're not busy */ > err("%s: error submitting urb(%d)", __func__, retval); > } else { > /* Wait for transmission to complete (or abort) */ > mutex_unlock(&ictx->lock); > retval = wait_for_completion_interruptible( > &ictx->tx.finished); > if (retval) > err("%s: task interrupted", __func__); > mutex_lock(&ictx->lock); > > retval = ictx->tx.status; > if (retval) > err("%s: packet tx failed (%d)", __func__, retval); > } > > > -22 is -EINVAL, not quite sure what happened to the completion event there. [ 51.385009] lirc_imon: Writing data 32 44200707 [ 51.389009] lirc_imon: send_packet ffff880122632cac 8 [ 51.470104] lirc_imon: send_packet ffff880122632cac 8 [ 71.972696] lirc_imon: send_packet: task interrupted [ 71.976703] lirc_imon: send_packet ffff880122632cac 8 [ 71.976706] lirc_imon: send_packet: error submitting urb(-22) [ 71.976708] lirc_imon: vfd_write: send packet failed for packet #1 [ 71.980726] lirc_imon: send_packet ffff880122632cac 8 [ 71.980730] lirc_imon: send_packet: error submitting urb(-22) [ 71.980732] lirc_imon: vfd_write: send packet failed for packet #0 [ 71.980737] display port closed I'm not sure, but I think the "task interrupted" is because I killed the LCDd job, there is a significant jump in the logging number. This call just didn't really return and the display had locked up. After waiting ten seconds or so I stopped LCDd, resulting in "task interrupted" and it probably tries to write goodbye. From then on I get the urb errors as the driver is locked. > > Would be much easier to debug these problems if I actually had an imon > device that exhibited them, both my (newer than ffdc) VFD and LCD work > flawlessly though. :\ I have two ideas I'm thinking about for errors at the moment. It proabably seems related to the speed the data is coming, I wonder if either in the actual imon device or possibly in the USB HUB that the device is connected to? I'm used to developing code, although not kernel/driver stuff. When I try to unload the lirc_imon kernel module once it has locked, not only does the modprobe never finish but other usb devices lock up too. Shane. From fblack947 at yahoo.com Wed Jan 20 21:28:53 2010 From: fblack947 at yahoo.com (jk) Date: Wed, 20 Jan 2010 13:28:53 -0800 (PST) Subject: [Lcdproc] Older vfd lockups In-Reply-To: References: <4B52618D.4090509@blackett.co.nz> <230904.1620.qm@web37504.mail.mud.yahoo.com> <4B56C341.80507@blackett.co.nz> <663685.30764.qm@web37502.mail.mud.yahoo.com> Message-ID: <586583.14602.qm@web37508.mail.mud.yahoo.com> ----- Original Message ---- > From: Jarod Wilson > ... > Outside of the ffdc devices, you shouldn't have to touch a damned > thing, auto-detection of display type and auto-config of stuff should > Just Work. > Agreed, but is this a function of Ubuntu packaging, or should lcdproc be figuring things out? A philosophical question to be sure, but my approach was to let the end-user (or the ubuntu packager) adjust the configuration file are required. > Would be much easier to debug these problems if I actually had an imon > device that exhibited them, both my (newer than ffdc) VFD and LCD work > flawlessly though. :\ Yeah, that's a tough one - too many friggin different devices and protocols. Coupled with a complete lack of linux support from SoundGraph. Sigh. > > ...I think there also was (still is?) a parameter setting to limit the frequency of >> the screen refresh, which might still be there, and might help. > > Is this in the lcdproc driver? Nobody ever got back to me with any > useful feedback on whether adding a delay in the kernel driver helped > with this issue... Actually, it might be a driver-specific thing. Some drivers have this function, others don't (see DELAYMULT parameter in hd44780-low.h and hd44780.c). I don't remember the discussion about delays in the kernel driver. Might have been before I was involved. -jonathan From jarod at wilsonet.com Wed Jan 20 21:34:40 2010 From: jarod at wilsonet.com (Jarod Wilson) Date: Wed, 20 Jan 2010 16:34:40 -0500 Subject: [Lcdproc] Older vfd lockups In-Reply-To: <4B576C29.2030907@blackett.co.nz> References: <4B52618D.4090509@blackett.co.nz> <230904.1620.qm@web37504.mail.mud.yahoo.com> <4B56C341.80507@blackett.co.nz> <663685.30764.qm@web37502.mail.mud.yahoo.com> <4B576C29.2030907@blackett.co.nz> Message-ID: On Wed, Jan 20, 2010 at 3:48 PM, Shane Blackett wrote: ... >>> For example, what causes "send_packet: task interrupted" and >>> "send_packet: error submitting urb(-22)" ? >> >> Its in the imon driver's send_packet function: >> >> ? ? ? ? retval = usb_submit_urb(ictx->tx_urb, GFP_KERNEL); >> ? ? ? ? if (retval) { >> ? ? ? ? ? ? ? ? ictx->tx.busy = 0; >> ? ? ? ? ? ? ? ? smp_rmb(); /* ensure later readers know we're not busy */ >> ? ? ? ? ? ? ? ? err("%s: error submitting urb(%d)", __func__, retval); >> ? ? ? ? } else { >> ? ? ? ? ? ? ? ? /* Wait for transmission to complete (or abort) */ >> ? ? ? ? ? ? ? ? mutex_unlock(&ictx->lock); >> ? ? ? ? ? ? ? ? retval = wait_for_completion_interruptible( >> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? &ictx->tx.finished); >> ? ? ? ? ? ? ? ? if (retval) >> ? ? ? ? ? ? ? ? ? ? ? ? err("%s: task interrupted", __func__); >> ? ? ? ? ? ? ? ? mutex_lock(&ictx->lock); >> >> ? ? ? ? ? ? ? ? retval = ictx->tx.status; >> ? ? ? ? ? ? ? ? if (retval) >> ? ? ? ? ? ? ? ? ? ? ? ? err("%s: packet tx failed (%d)", __func__, >> retval); >> ? ? ? ? } >> >> >> -22 is -EINVAL, not quite sure what happened to the completion event >> there. > > [ ? 51.385009] lirc_imon: Writing data 32 44200707 > [ ? 51.389009] lirc_imon: ?send_packet ffff880122632cac 8 > [ ? 51.470104] lirc_imon: ?send_packet ffff880122632cac 8 > [ ? 71.972696] lirc_imon: send_packet: task interrupted > [ ? 71.976703] lirc_imon: ?send_packet ffff880122632cac 8 > [ ? 71.976706] lirc_imon: send_packet: error submitting urb(-22) > [ ? 71.976708] lirc_imon: vfd_write: send packet failed for packet #1 > [ ? 71.980726] lirc_imon: ?send_packet ffff880122632cac 8 > [ ? 71.980730] lirc_imon: send_packet: error submitting urb(-22) > [ ? 71.980732] lirc_imon: vfd_write: send packet failed for packet #0 > [ ? 71.980737] display port closed > > I'm not sure, but I think the "task interrupted" is because I killed the > LCDd job, there is a significant jump in the logging number. ?This call just > didn't really return and the display had locked up. ?After waiting ten > seconds or so I stopped LCDd, resulting in "task interrupted" and it > probably tries to write goodbye. ?From then on I get the urb errors as the > driver is locked. Okay, that much makes sense. So this sounds like the same problem a few people have reported over on the lirc list. >> Would be much easier to debug these problems if I actually had an imon >> device that exhibited them, both my (newer than ffdc) VFD and LCD work >> flawlessly though. :\ > > I have two ideas I'm thinking about for errors at the moment. ?It proabably > seems related to the speed the data is coming, I wonder if either in the > actual imon device or possibly in the USB HUB that the device is connected > to? Dunno. I floated a test patch out there that simply added (iirc) an mdelay(10) to the end of send_packet() to see if stalling return from that function a bit effectively throttled how fast we were sending data to the display, to the point where it could actually keep up. I can't remember a definitive reply that said it didn't help, so if you can slap that in and test it out, it would be much appreciated. > I'm used to developing code, although not kernel/driver stuff. > > When I try to unload the lirc_imon kernel module once it has locked, not > only does the modprobe never finish but other usb devices lock up too. Bleah. Wedging the entire bus (or subsystem), apparently. -- Jarod Wilson jarod at wilsonet.com From fblack947 at yahoo.com Wed Jan 20 21:38:51 2010 From: fblack947 at yahoo.com (jk) Date: Wed, 20 Jan 2010 13:38:51 -0800 (PST) Subject: [Lcdproc] Older vfd lockups In-Reply-To: <4B576C29.2030907@blackett.co.nz> References: <4B52618D.4090509@blackett.co.nz> <230904.1620.qm@web37504.mail.mud.yahoo.com> <4B56C341.80507@blackett.co.nz> <663685.30764.qm@web37502.mail.mud.yahoo.com> <4B576C29.2030907@blackett.co.nz> Message-ID: <785467.19603.qm@web37508.mail.mud.yahoo.com> ----- Original Message ---- > From: Shane Blackett ... > [ 51.385009] lirc_imon: Writing data 32 44200707 > [ 51.389009] lirc_imon: send_packet ffff880122632cac 8 > [ 51.470104] lirc_imon: send_packet ffff880122632cac 8 > [ 71.972696] lirc_imon: send_packet: task interrupted > [ 71.976703] lirc_imon: send_packet ffff880122632cac 8 > [ 71.976706] lirc_imon: send_packet: error submitting urb(-22) > [ 71.976708] lirc_imon: vfd_write: send packet failed for packet #1 > [ 71.980726] lirc_imon: send_packet ffff880122632cac 8 > [ 71.980730] lirc_imon: send_packet: error submitting urb(-22) > [ 71.980732] lirc_imon: vfd_write: send packet failed for packet #0 > [ 71.980737] display port closed > > I'm not sure, but I think the "task interrupted" is because I killed the LCDd > job, there is a significant jump in the logging number. This call just didn't > really return and the display had locked up. After waiting ten seconds or so I > stopped LCDd, resulting in "task interrupted" and it probably tries to write > goodbye. From then on I get the urb errors as the driver is locked. > > > > > Would be much easier to debug these problems if I actually had an imon > > device that exhibited them, both my (newer than ffdc) VFD and LCD work > > flawlessly though. :\ > > I have two ideas I'm thinking about for errors at the moment. It proabably > seems related to the speed the data is coming, I wonder if either in the actual > imon device or possibly in the USB HUB that the device is connected to? > > I'm used to developing code, although not kernel/driver stuff. > > When I try to unload the lirc_imon kernel module once it has locked, not only > does the modprobe never finish but other usb devices lock up too. > > Shane. Hmm, seems like a tough one. Here's what I'd recommend for debugging: Try to access LCDd via telnet, after killing off any running clients. This takes the lcdproc client out of the picture, which should stop too-fast requests coming. Details on the telnet interface can be found here: http://lcdproc.sourceforge.net/docs/current-dev.html#language-open-session FWIW, this is the first driver stuff I've done too... :} -jonathan From jarod at wilsonet.com Wed Jan 20 21:40:23 2010 From: jarod at wilsonet.com (Jarod Wilson) Date: Wed, 20 Jan 2010 16:40:23 -0500 Subject: [Lcdproc] Older vfd lockups In-Reply-To: <586583.14602.qm@web37508.mail.mud.yahoo.com> References: <4B52618D.4090509@blackett.co.nz> <230904.1620.qm@web37504.mail.mud.yahoo.com> <4B56C341.80507@blackett.co.nz> <663685.30764.qm@web37502.mail.mud.yahoo.com> <586583.14602.qm@web37508.mail.mud.yahoo.com> Message-ID: On Wed, Jan 20, 2010 at 4:28 PM, jk wrote: >> From: Jarod Wilson >> ... >> Outside of the ffdc devices, you shouldn't have to touch a damned >> thing, auto-detection of display type and auto-config of stuff should >> Just Work. > > Agreed, but is this a function of Ubuntu packaging, or should lcdproc be figuring things out? > A philosophical question to be sure, but my approach was to let the end-user (or the ubuntu packager) adjust the configuration file are required. I think lcdproc still needs some manual config to tell it exactly what device type it is you want it to talk to, otherwise, (I assume) it would have to load up *all* drivers and try them out, and/or have its own internal device ID to driver mapping table or other similar insanity. It *would* be nice, however, if the imonlcd driver could figure out from usb device ID whether it needed to use Protocol=0 or 1, and eliminate the user having to figure that out/remember to put it into their config. Not a big deal though, only has to be done once, so I haven't bothered to look into it myself... >> Would be much easier to debug these problems if I actually had an imon >> device that exhibited them, both my (newer than ffdc) VFD and LCD work >> flawlessly though. :\ > > Yeah, that's a tough one - too many friggin different devices and > protocols. ? Coupled with a complete lack of linux support from > SoundGraph. ?Sigh. Yeah, SoundGraph was completely and totally unresponsive when I tried pinging them for *any* sort of information, even with the "hey, I'm trying to make your device fully supported under linux, and you guys don't have to do an ounce of development work, just please help me out with a bit of data" caveat added... >> > ...I think there also was (still is?) a parameter setting to limit the frequency of >>> the screen refresh, which might still be there, and might help. >> >> Is this in the lcdproc driver? Nobody ever got back to me with any >> useful feedback on whether adding a delay in the kernel driver helped >> with this issue... > > Actually, it might be a driver-specific thing. ?Some drivers have this function, others don't (see DELAYMULT parameter in hd44780-low.h and hd44780.c). Ah, hm. So maybe we need it added to the imon{,lcd} drivers? > I don't remember the discussion about delays in the kernel driver. ?Might have been before I was involved. It was over on the lirc list, if I'm thinking clearly. -- Jarod Wilson jarod at wilsonet.com From fblack947 at yahoo.com Wed Jan 20 22:18:15 2010 From: fblack947 at yahoo.com (jk) Date: Wed, 20 Jan 2010 14:18:15 -0800 (PST) Subject: [Lcdproc] Older vfd lockups In-Reply-To: References: <4B52618D.4090509@blackett.co.nz> <230904.1620.qm@web37504.mail.mud.yahoo.com> <4B56C341.80507@blackett.co.nz> <663685.30764.qm@web37502.mail.mud.yahoo.com> <586583.14602.qm@web37508.mail.mud.yahoo.com> Message-ID: <145498.38706.qm@web37508.mail.mud.yahoo.com> ----- Original Message ---- > From: Jarod Wilson > > I think lcdproc still needs some manual config to tell it exactly what > device type it is you want it to talk to, otherwise, (I assume) it > would have to load up *all* drivers and try them out, and/or have its > own internal device ID to driver mapping table or other similar > insanity. It *would* be nice, however, if the imonlcd driver could > figure out from usb device ID whether it needed to use Protocol=0 or > 1, and eliminate the user having to figure that out/remember to put it > into their config. Not a big deal though, only has to be done once, so > I haven't bothered to look into it myself... I looked into this when I was helping to bring the imonlcd driver up to release-ready. I was actually wondering why we needed to depend on lirc for the USB interface, and then I looked at the lirc code... Decided to keep as-is and use a simple (and hopefully well-documented) configuration parameter. Allows for future expansion for different protocols too. > >> Is this in the lcdproc driver? Nobody ever got back to me with any > >> useful feedback on whether adding a delay in the kernel driver helped > >> with this issue... > > > > Actually, it might be a driver-specific thing. Some drivers have this > function, others don't (see DELAYMULT parameter in hd44780-low.h and hd44780.c). > > Ah, hm. So maybe we need it added to the imon{,lcd} drivers? > > > I don't remember the discussion about delays in the kernel driver. Might have > been before I was involved. > > It was over on the lirc list, if I'm thinking clearly. > Ahhh. I try to leave lirc to the experts. :} You also hit the nail on the head with some of the issues with lcdproc development: too many different displays, too few developers. Heck, my display isn't even hooked up these days! (Only because I've made the switch to digital cable, which rendered the htpc mostly redundant - plus the fact that we still haven't figured out why the imon lcd backlight comes back on after shutdown). -jonathan From shane at blackett.co.nz Wed Jan 20 23:15:54 2010 From: shane at blackett.co.nz (Shane Blackett) Date: Thu, 21 Jan 2010 12:15:54 +1300 Subject: [Lcdproc] Older vfd lockups In-Reply-To: References: <4B52618D.4090509@blackett.co.nz> <230904.1620.qm@web37504.mail.mud.yahoo.com> <4B56C341.80507@blackett.co.nz> <663685.30764.qm@web37502.mail.mud.yahoo.com> <4B576C29.2030907@blackett.co.nz> Message-ID: <4B578EAA.1010509@blackett.co.nz> On 21/01/2010 10:34 a.m., Jarod Wilson wrote: > On Wed, Jan 20, 2010 at 3:48 PM, Shane Blackett wrote: > ... >>>> For example, what causes "send_packet: task interrupted" and >>>> "send_packet: error submitting urb(-22)" ? >>> >>> Its in the imon driver's send_packet function: >>> >>> retval = usb_submit_urb(ictx->tx_urb, GFP_KERNEL); >>> if (retval) { >>> ictx->tx.busy = 0; >>> smp_rmb(); /* ensure later readers know we're not busy */ >>> err("%s: error submitting urb(%d)", __func__, retval); >>> } else { >>> /* Wait for transmission to complete (or abort) */ >>> mutex_unlock(&ictx->lock); >>> retval = wait_for_completion_interruptible( >>> &ictx->tx.finished); >>> if (retval) >>> err("%s: task interrupted", __func__); >>> mutex_lock(&ictx->lock); >>> >>> retval = ictx->tx.status; >>> if (retval) >>> err("%s: packet tx failed (%d)", __func__, >>> retval); >>> } >>> >>> >>> -22 is -EINVAL, not quite sure what happened to the completion event >>> there. >> >> [ 51.385009] lirc_imon: Writing data 32 44200707 >> [ 51.389009] lirc_imon: send_packet ffff880122632cac 8 >> [ 51.470104] lirc_imon: send_packet ffff880122632cac 8 >> [ 71.972696] lirc_imon: send_packet: task interrupted >> [ 71.976703] lirc_imon: send_packet ffff880122632cac 8 >> [ 71.976706] lirc_imon: send_packet: error submitting urb(-22) >> [ 71.976708] lirc_imon: vfd_write: send packet failed for packet #1 >> [ 71.980726] lirc_imon: send_packet ffff880122632cac 8 >> [ 71.980730] lirc_imon: send_packet: error submitting urb(-22) >> [ 71.980732] lirc_imon: vfd_write: send packet failed for packet #0 >> [ 71.980737] display port closed >> >> I'm not sure, but I think the "task interrupted" is because I killed the >> LCDd job, there is a significant jump in the logging number. This call just >> didn't really return and the display had locked up. After waiting ten >> seconds or so I stopped LCDd, resulting in "task interrupted" and it >> probably tries to write goodbye. From then on I get the urb errors as the >> driver is locked. > > Okay, that much makes sense. So this sounds like the same problem a > few people have reported over on the lirc list. > >>> Would be much easier to debug these problems if I actually had an imon >>> device that exhibited them, both my (newer than ffdc) VFD and LCD work >>> flawlessly though. :\ >> >> I have two ideas I'm thinking about for errors at the moment. It proabably >> seems related to the speed the data is coming, I wonder if either in the >> actual imon device or possibly in the USB HUB that the device is connected >> to? > > Dunno. I floated a test patch out there that simply added (iirc) an > mdelay(10) to the end of send_packet() to see if stalling return from > that function a bit effectively throttled how fast we were sending > data to the display, to the point where it could actually keep up. I > can't remember a definitive reply that said it didn't help, so if you > can slap that in and test it out, it would be much appreciated. Yep I read this thread as I got there from the urb(-22) search I did early on. I tried several values for mdelay in these routines (it is currently 4 I think). I tried it exactly as suggested in the patch by the person debugging it and in the slightly different form that you recommended. Unfortunately it didn't seem to make much difference to me. I'll play around with such a delay again a bit more rigourously when I get a chance and then list what I have tried here. >> I'm used to developing code, although not kernel/driver stuff. >> >> When I try to unload the lirc_imon kernel module once it has locked, not >> only does the modprobe never finish but other usb devices lock up too. > > Bleah. Wedging the entire bus (or subsystem), apparently. Shane. From parmeshwer.prasad at dexceldesigns.com Thu Jan 21 09:31:54 2010 From: parmeshwer.prasad at dexceldesigns.com (Parmeshwer Prasad) Date: Thu, 21 Jan 2010 15:01:54 +0530 Subject: [Lcdproc] un subscribe Message-ID: <430CFF3583611447A2950F7E826A30A141BF7F@server2.domain.dexceldesigns.com> Please remove me from list.. -Regards Parmeshwr Prasad DeXcel Electronics Designs Tel : +91-80-2521 6221/222 Xtn : 107 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jarod at wilsonet.com Thu Jan 21 15:38:05 2010 From: jarod at wilsonet.com (Jarod Wilson) Date: Thu, 21 Jan 2010 10:38:05 -0500 Subject: [Lcdproc] Older vfd lockups In-Reply-To: <4B578EAA.1010509@blackett.co.nz> References: <4B52618D.4090509@blackett.co.nz> <230904.1620.qm@web37504.mail.mud.yahoo.com> <4B56C341.80507@blackett.co.nz> <663685.30764.qm@web37502.mail.mud.yahoo.com> <4B576C29.2030907@blackett.co.nz> <4B578EAA.1010509@blackett.co.nz> Message-ID: On Wed, Jan 20, 2010 at 6:15 PM, Shane Blackett wrote: ... >>> I have two ideas I'm thinking about for errors at the moment. ?It >>> proabably >>> seems related to the speed the data is coming, I wonder if either in the >>> actual imon device or possibly in the USB HUB that the device is >>> connected >>> to? >> >> Dunno. I floated a test patch out there that simply added (iirc) an >> mdelay(10) to the end of send_packet() to see if stalling return from >> that function a bit effectively throttled how fast we were sending >> data to the display, to the point where it could actually keep up. I >> can't remember a definitive reply that said it didn't help, so if you >> can slap that in and test it out, it would be much appreciated. > > Yep I read this thread as I got there from the urb(-22) search I did early > on. > I tried several values for mdelay in these routines (it is currently 4 I > think). ?I tried it exactly as suggested in the patch by the person > debugging it and in the slightly different form that you recommended. > Unfortunately it didn't seem to make much difference to me. Okay, good to at least have concrete confirmation of that. :) > I'll play around with such a delay again a bit more rigourously when I get a > chance and then list what I have tried here. I keep forgetting... There's another change that might help... When I sent the new input layer imon driver[*] upstream for review, it was pointed out that the atomic_foo() calls *probably* aren't doing what they were intended to do -- which is safeguard against having multiple writes in flight at the same time. I rewrote that bit of code to use memory barriers, which should properly remedy any caching effects, so we always get a consistent picture of whether or not there's actually write traffic in flight already... Unfortunately, I don't have a patch against lirc_imon handy at the moment, but it should be fairly trivial to port: http://git.kernel.org/?p=linux/kernel/git/jarod/linux-2.6-lirc.git;a=commitdiff;h=75c2fe9117de538386c18231fa8521dd48ef7b59 [*] I've split off support for ffdc and newer devices that do onboard decoding into a pure input layer driver, per some lirc discussion on lkml, leaving lirc_imon to handle only the four very very old devices that don't do onboard decoding. Not making this change in lirc cvs yet though, only in my git tree... -- Jarod Wilson jarod at wilsonet.com From umpelev at gmail.com Fri Jan 22 06:04:49 2010 From: umpelev at gmail.com (Sergey Umpelev) Date: Fri, 22 Jan 2010 11:04:49 +0500 Subject: [Lcdproc] [PATCH] imonlcd driver fix (special icon) In-Reply-To: <583b06611001212203i4dc680dape283a33ee4de9821@mail.gmail.com> References: <4B5744FC.6040502@gmx.de> <583b06611001212203i4dc680dape283a33ee4de9821@mail.gmail.com> Message-ID: <583b06611001212204l6694b661u4daf94ec909df58f@mail.gmail.com> ---------- Forwarded message ---------- From: Sergey Umpelev Date: 2010/1/22 Subject: Re: [Lcdproc] [PATCH] imonlcd driver fix (special icon) To: Christian Leuschen Hi, Christian, to my mind, the same issue as for the MPG icon exists for the WMA icon in the imonlcd driver. I made a patch trying to correct both of these issues. Would you please to check if there an issue with the WMA icon exists and try my patch? Thanks, Sergey 2010/1/20 Christian Leuschen > Hello, > > the patch included in this mail fixes an issue with a special icon on the > imon-lcd that does not get displayed without the patch. > It also switches vbars to "norrow style" as a spectrum analyzer with "full > style" looks awful - IMHO. > > Greets, > Christian > > lcdproc-0.5.3-imonlcd-mpg-audio-icon.diff > --- /var/tmp/portage/app-misc/lcdproc-0.5.3/work/lcdproc-0.5.3/server/drivers/imonlcd.c 2009-06-20 15:48:34.000000000 +0200 > +++ /tmp/lcdproc-0.5.3/server/drivers/imonlcd.c 2010-01-18 21:12:14.000000000 +0100 > @@ -654,7 +654,7 @@ > * rest > */ > lib_vbar_static(drvthis, x, y, len, promille, options, > - p->cellheight, IMONLCD_FONT_START_VBAR_FULL - 1); > + p->cellheight, IMONLCD_FONT_START_VBAR_NARROW-1); > } > > > @@ -1035,7 +1035,7 @@ > if (((state & IMON_OUTPUT_BMICONS_MASK) != 0)) { > switch (((state & IMON_OUTPUT_BMICONS_MASK) >> 16)) { > case 1: > - icon |= IMON_ICON_MPG; > + icon |= IMON_ICON_MPG2; > break; > case 2: > icon |= IMON_ICON_AC3; > > > _______________________________________________ > LCDproc mailing list > LCDproc at lists.omnipotent.net > http://lists.omnipotent.net/mailman/listinfo/lcdproc > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: lcdproc-0.5.3-imonlcd-MPG-WMA-icons-patch.diff Type: application/octet-stream Size: 673 bytes Desc: not available URL: From umpelev at gmail.com Fri Jan 22 07:06:32 2010 From: umpelev at gmail.com (Sergey Umpelev) Date: Fri, 22 Jan 2010 12:06:32 +0500 Subject: [Lcdproc] [PATCH] imonlcd loadable font support Message-ID: <583b06611001212306y4fac0c29v7761271888f07410@mail.gmail.com> Hi, Here is the patch for imonlcd driver to enable loading bitmap fonts from a file. This patch also modifies output of the info command to print the charset of a loaded font. A new configuration parameter Font is added to specify a file, from which font will be loaded. If Font parameter is not specified or there were any errors while loading a font, the builtin font (iso-8859-15 charset) will be loaded (original imonlcd behavour). Font file format is as follows: Zero-terminated string "imonlcd" (for file identification purposes) Zero-terminated font charset string (for use in the info command) 256*6=1536 bytes of character images data. Individual character image is coded as it is noticed in the imonlcd_font.h: the character is 6x8 pixels in size, each byte of the character definition represents one column of pixels. The most significant bit is the top row, the least significant bit is the bottom row. I also attached two font files to use with the patched imonlcd driver. One of these completely resembles the builtin font and other is based on builtin font in which characters with codes 160-255 are replaced with characters from Windows-1251 codepage (cyrillic letters). I think, fonts for other languages that are using their specific letters could easily be made as it will be needed. Best regards, Sergey -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: lcdproc-0.5.3-imonlcd_loadable_font_support.diff Type: application/octet-stream Size: 7663 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: iso8859_15.fnt Type: application/octet-stream Size: 1556 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: cp1251.fnt Type: application/octet-stream Size: 1557 bytes Desc: not available URL: From bsdfan at nurfuerspam.de Mon Jan 25 20:58:22 2010 From: bsdfan at nurfuerspam.de (Markus Dolze) Date: Mon, 25 Jan 2010 21:58:22 +0100 Subject: [Lcdproc] Updates to CFontzPacket Message-ID: <4B5E05EE.6060707@nurfuerspam.de> Hi there, here come some updates to the CFontzPacket driver: * I added CFA_Model structure which holds default values for speed, size, charmap and some flags. * Added the CFA-533 to the list of known modules. * The 633 and 533 use a HD44780 compatible controller, therefore I load the default HD44780_charmap for those. The 631 and 635 have the same CGROM as EA_DIP204, but I have not yet checked if the EA_KS0073 charmap could be used. Currently CFontz_charmap is still used. * The flags describe some features those models have by default. I changed most occurances of (p->model == 633) checks into ones for features. * The "NewFirmware" setting was renamed into "OldFirmware" (it was no-op up anyway). * For all displays the partial screen update algorithm is used, unless one has a 633 and OldFirmware=true set. * Models 631 and 635 have a gapless display with 6x8 pixels. I found that the block character (31d) used for the title ugly interferes with the text. Therefore I modified the icon to use a CC instead. For those displays all CC have the last line cleared (this affects the block and heartbeat chars). * Some changes in whitespace and comment style. The changes have been tested with the following displays: 1. CFA-533 USB 2. CFA-633 USB 3. CFA-631 USB 4. CFA-635 USB I appreciate any feedback on the changes. As they are working on all supported displays I will apply only a short "comment timeout" of aprox. two weeks! Regards, Markus -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: patch-CFontzPacket.diff URL: From bsdfan at nurfuerspam.de Mon Jan 25 21:03:03 2010 From: bsdfan at nurfuerspam.de (Markus Dolze) Date: Mon, 25 Jan 2010 22:03:03 +0100 Subject: [Lcdproc] CFontz633 vs CFontzPacket driver Message-ID: <4B5E0707.1050202@nurfuerspam.de> Hi there, when I first received my Crystalfontz displays I was a little puzzled about the difference between the CFontz633 and CFontzPacket driver. While updating the latter I had a closer look at the former and found that the CFontzPacket seems to have been created from a copy of the CFontz633driver. Is there any need to keep both? Note that I am not talking about the CFontz633io library they share, but the driver source CFontz633.[ch]. I would like to deprecate the CFontz633 in favor of CFontzPacket for the next release and remove it afterwards. Regards, Markus From stewartputnam at comcast.net Tue Jan 26 01:54:30 2010 From: stewartputnam at comcast.net (Stewart Putnam) Date: Mon, 25 Jan 2010 17:54:30 -0800 Subject: [Lcdproc] CFontz633 vs CFontzPacket driver In-Reply-To: <4B5E0707.1050202@nurfuerspam.de> References: <4B5E0707.1050202@nurfuerspam.de> Message-ID: <4B5E4B56.4070002@comcast.net> Peter Marschall created CFontzPacket as a fork from CFontz633 -- I think when he started working with a CF 635 around mid 2005. Your patch applied and compiled cleanly on the 20100125 nightly tarball, and on a short quick test nothing is broken. CF 633 serial on Debian 5.0 lenny, with a 2.6.32 kernel from kernel org. Markus Dolze wrote: > Hi there, > > when I first received my Crystalfontz displays I was a little puzzled > about the difference between the CFontz633 and CFontzPacket driver. > While updating the latter I had a closer look at the former and found > that the CFontzPacket seems to have been created from a copy of the > CFontz633driver. > > Is there any need to keep both? Note that I am not talking about the > CFontz633io library they share, but the driver source CFontz633.[ch]. > > I would like to deprecate the CFontz633 in favor of CFontzPacket for the > next release and remove it afterwards. > > Regards, > Markus > > _______________________________________________ > LCDproc mailing list > LCDproc at lists.omnipotent.net > http://lists.omnipotent.net/mailman/listinfo/lcdproc > > From Christian.Stoss at sie.at Tue Jan 26 14:33:46 2010 From: Christian.Stoss at sie.at (=?iso-8859-1?Q?Sto=DF_Christian?=) Date: Tue, 26 Jan 2010 15:33:46 +0100 Subject: [Lcdproc] Touch Message-ID: <2F3951A78535124D960B1EFBB992F6D10365B857@mailserver.sienet.local> Is there a way to get the infos from a touchscreen (x,y) mounted on an external lcd? From bsdfan at nurfuerspam.de Thu Jan 28 18:59:29 2010 From: bsdfan at nurfuerspam.de (Markus Dolze) Date: Thu, 28 Jan 2010 19:59:29 +0100 Subject: [Lcdproc] lcdproc ported for QNX [update] In-Reply-To: <2c26506d1001180436k5716e57akbbca14c358540fb2@mail.gmail.com> References: <2c26506d0910052255o19a5a86gb176007a0db8508b@mail.gmail.com> <4AD3F87C.6070901@nurfuerspam.de> <2c26506d0910132222g506877a6ga4a6f2e5683c24ad@mail.gmail.com> <4ADCD657.8000404@nurfuerspam.de> <4B44E79D.1080502@nurfuerspam.de> <2c26506d1001110240i72498a6eye34064893308486e@mail.gmail.com> <2c26506d1001180436k5716e57akbbca14c358540fb2@mail.gmail.com> Message-ID: <4B61DE91.20301@nurfuerspam.de> Satz Klauer wrote: > OK, where can I find the nighly CVS snapshot? The one from > http://lcdproc.sourceforge.net/nightly/lcdproc-CVS-current.tar.gz does > not seem to contain any of the modifications... > Hi, the nightly tarball contains all the changes I believe to be necessary to build LCDd. It does not include the client. The compiler contraints described in http://lists.omnipotent.net/pipermail/lcdproc/2009-October/013111.html still apply as well. Regards, Markus From bsdfan at nurfuerspam.de Thu Jan 28 19:07:54 2010 From: bsdfan at nurfuerspam.de (Markus Dolze) Date: Thu, 28 Jan 2010 20:07:54 +0100 Subject: [Lcdproc] install-server target installs client doco In-Reply-To: <226316B3E1F749498E28ACA66321D5BA01318FA1C6@oma00cexmbx03.corp.westworlds.com> References: <226316B3E1F749498E28ACA66321D5BA01318FA1C6@oma00cexmbx03.corp.westworlds.com> Message-ID: <4B61E08A.5020606@nurfuerspam.de> Larson, Timothy E. wrote: > Following are two patches (against 0.5.3) to try to separate installation of doco depending on whether "make install-server" or "make install-clients" is used. Some of the work had already been done, but looked like it had been left unfinished. These patches seem to work, but more testing is, of course, appreciated. > > However, there are no corresponding uninstall-server/uninstall-clients targets. I am no expert on makefiles, so I didn't want to go hacking into it myself. It ought to be fairly simple to someone more knowledge than myself, though. > > > Thanks, > Tim > > > --- docs/Makefile.am.orig Sat Jun 20 08:48:34 2009 > +++ docs/Makefile.am Wed Jan 20 11:57:21 2010 > @@ -1,6 +1,8 @@ > ## Process this file with automake to produce Makefile.in > > -man_MANS = lcdproc.1 lcdexec.1 lcdvc.1 LCDd.8 lcdproc-config.5 > +man1_MANS = lcdproc.1 lcdexec.1 lcdvc.1 > +man5_MANS = lcdproc-config.5 > +man8_MANS = LCDd.8 > SUBDIRS = lcdproc-user lcdproc-dev > doxygen_input = header.html footer.html > > > > > --- docs/Makefile.in.orig Sun Jun 21 10:09:27 2009 > +++ docs/Makefile.in Wed Jan 20 12:00:16 2010 > @@ -60,7 +60,7 @@ > man5dir = $(mandir)/man5 > man8dir = $(mandir)/man8 > NROFF = nroff > -MANS = $(man_MANS) > +MANS = $(man1_MANS) $(man5_MANS) $(man8_MANS) > ETAGS = etags > CTAGS = ctags > DIST_SUBDIRS = $(SUBDIRS) > @@ -182,7 +182,9 @@ > sharedstatedir = @sharedstatedir@ > sysconfdir = @sysconfdir@ > target_alias = @target_alias@ > -man_MANS = lcdproc.1 lcdexec.1 lcdvc.1 LCDd.8 lcdproc-config.5 > +man1_MANS = lcdproc.1 lcdexec.1 lcdvc.1 > +man5_MANS = lcdproc-config.5 > +man8_MANS = LCDd.8 > SUBDIRS = lcdproc-user lcdproc-dev > doxygen_input = header.html footer.html > EXTRA_DIST = lcdproc.1.in \ > _______________________________________________ > LCDproc mailing list > LCDproc at lists.omnipotent.net > http://lists.omnipotent.net/mailman/listinfo/lcdproc > > Hi, I can't reproduce the problem you describe. Here are my test results: mmdolze at elenore:test2> make install-server ... make -C docs install-server-man test -z "/tmp/test2/share/man/man8" || .././install-sh -c -d "/tmp/test2/share/man/man8" /usr/bin/install -c -m 644 './LCDd.8' '/tmp/test2/share/man/man8/LCDd.8' test -z "/tmp/test2/share/man/man5" || .././install-sh -c -d "/tmp/test2/share/man/man5" /usr/bin/install -c -m 644 './lcdproc-config.5' '/tmp/test2/share/man/man5/lcdproc-config.5' mmdolze at elenore:test2> make install-clients ... make -C docs install-client-man test -z "/tmp/test2/share/man/man1" || .././install-sh -c -d "/tmp/test2/share/man/man1" /usr/bin/install -c -m 644 './lcdproc.1' '/tmp/test2/share/man/man1/lcdproc.1' /usr/bin/install -c -m 644 './lcdexec.1' '/tmp/test2/share/man/man1/lcdexec.1' /usr/bin/install -c -m 644 './lcdvc.1' '/tmp/test2/share/man/man1/lcdvc.1' test -z "/tmp/test2/share/man/man5" || .././install-sh -c -d "/tmp/test2/share/man/man5" /usr/bin/install -c -m 644 './lcdproc-config.5' '/tmp/test2/share/man/man5/lcdproc-config.5' For server LCDd.8 and lcdproc-config.5 are installed. For clients lcdproc.1, lcdexec.1, lcdvc.1, and lcdproc-config.5 are installed. That's correct. man_MANS and man#_MANS should have the same result in our case, as we name the man files by their correct section number (.1 .5 .8). I don't know why there are no separate uninstall targets, but a 'make uninstall' suceeds in both cases. On most OS uninstallation is handled OS specific packaging tools anyway. Regards, Markus From bsdfan at nurfuerspam.de Thu Jan 28 19:15:49 2010 From: bsdfan at nurfuerspam.de (Markus Dolze) Date: Thu, 28 Jan 2010 20:15:49 +0100 Subject: [Lcdproc] [PATCH] imonlcd driver fix (special icon) In-Reply-To: <593796.29799.qm@web37501.mail.mud.yahoo.com> References: <4B5744FC.6040502@gmx.de> <593796.29799.qm@web37501.mail.mud.yahoo.com> Message-ID: <4B61E265.7070509@nurfuerspam.de> jk wrote: >> From: Christian Leuschen >> >> >>> the patch included in this mail fixes an issue with a special icon on >>> >> the imon-lcd that does not get displayed without the patch. >> > > Nice catch. > > >>> It also switches vbars to "norrow style" as a spectrum analyzer with >>> >> "full style" looks awful - IMHO. >> >> > > I don't really have an opinion on the vbar style, but the comment on line 652 should be updated accordingly. > > -jonathan > > Committed both. Regards, Markus From bsdfan at nurfuerspam.de Thu Jan 28 19:20:15 2010 From: bsdfan at nurfuerspam.de (Markus Dolze) Date: Thu, 28 Jan 2010 20:20:15 +0100 Subject: [Lcdproc] [Fwd: Futaba dm-140gink VFD device needs driver] Message-ID: <4B61E36F.4050701@nurfuerspam.de> Hello list, I would like you to refer to this newly submitted feature request (see below) and request your opinion. I am specially concerned about adding 3rd party code from AMD (although released under GPL) into LCDproc. Who is going to support this? Right now, I will not add the patch due to formal reasons. See SF ticket. Regards, Markus -------- Original Message -------- Subject: [ lcdproc-Feature Requests-2941314 ] Futaba dm-140gink VFD device needs driver Date: Wed, 27 Jan 2010 23:32:24 +0000 From: SourceForge.net To: noreply at sourceforge.net Feature Requests item #2941314, was opened at 2010-01-28 00:32 Message generated for change (Tracker Item Submitted) made by You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350119&aid=2941314&group_id=119 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Priority: 5 Private: No Submitted By: DustWolf () Assigned to: Nobody/Anonymous (nobody) Summary: Futaba dm-140gink VFD device needs driver Initial Comment: Please add support for the Fatuba dm-140gink VFD device. See this bug report for details including existing driver source code: https://bugs.launchpad.net/ubuntu/+source/lcdproc/+bug/302919 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350119&aid=2941314&group_id=119 From bsdfan at nurfuerspam.de Thu Jan 28 19:29:26 2010 From: bsdfan at nurfuerspam.de (Markus Dolze) Date: Thu, 28 Jan 2010 20:29:26 +0100 Subject: [Lcdproc] [PATCH] hd44780-charmap.h Russian charmaps In-Reply-To: References: Message-ID: <4B61E596.4060600@nurfuerspam.de> Yura Scheglyuk wrote: > Hi! > > Yura Scheglyuk wrote: > > >> ISO8859-1 encodes what it refers to as "Latin alphabet no. 1,". But Russian is based on a Cyrillic alphabet and there are 3 commonly used charsets for it: KOI8-R, CP-1251 (Windows-1251), ISO 8859-5. >> >> So you can commit only one Russian charmap, for example CP-1251 (Windows-1251) that is the mostly used. >> > > I think we need as minimum two charset: KOI8-R for Unix, and CP-1251 (Windows-1251) that is the mostly used in Windows. > > Hi, I have committed the KOI8-R charmap. This should be useful on most Unix platforms that LCDd runs on. Please note that I still believe this is not a way to handle input to LCDd in encodings other than ISO8859-1. Therefore I will neiver add charmap selection code to our other driver's nor will I add charmap tables for additional encodings. Regards, Markus From bsdfan at nurfuerspam.de Thu Jan 28 19:42:30 2010 From: bsdfan at nurfuerspam.de (Markus Dolze) Date: Thu, 28 Jan 2010 20:42:30 +0100 Subject: [Lcdproc] Removing win32 support In-Reply-To: <4B257503.30808@nurfuerspam.de> References: <4AC76E58.9080401@nurfuerspam.de> <4B257503.30808@nurfuerspam.de> Message-ID: <4B61E8A6.1080303@nurfuerspam.de> On 14.12.2009 00:13, Markus Dolze wrote: > Markus Dolze wrote: > >> Hi, >> >> when was the last time someone successfully compiled LCDproc natively >> for win32? >> >> There are several conditionals scattered across the code for win32, >> but I doubt anyone is using them. Note that I am talking about >> compiling it natively, not using Cygwin! >> >> For Windows there are far more advanced solutions available (i.e. >> LCDHype, LCD Smartie). >> >> Instead of trying to catch up on the latest Windows version I'd like >> to remove these parts from LCDproc. >> >> So - if nobody requires win32 support for LCDproc, I am going to >> remove it. >> >> Regards, >> Markus >> > > Hi, > > here is a patch that removes win32 support. If I receive no objections I > will commit it. > > Regards, > Markus > Hello, some time has passed and I did only receive minimal feedback, both pro and cons. Therefore I will put a last call: If I don't receive feedback on a successful native compile (not Cygwin or MinGW) on at least Windows Vista (Windows 7 would be better) with some usable driver (perhaps serial/USB) until March, 22nd 2010 I will apply the patch removing win32 support. If someone manages to compile LCDd, I am happy to test it using Vista. Regards, Markus From wyatt at prairieturtle.ca Thu Jan 28 23:00:08 2010 From: wyatt at prairieturtle.ca (Daryl F) Date: Thu, 28 Jan 2010 17:00:08 -0600 (CST) Subject: [Lcdproc] [Fwd: Futaba dm-140gink VFD device needs driver] In-Reply-To: <4B61E36F.4050701@nurfuerspam.de> References: <4B61E36F.4050701@nurfuerspam.de> Message-ID: On Thu, 28 Jan 2010, Markus Dolze wrote: > Hello list, > > I would like you to refer to this newly submitted feature request (see > below) and request your opinion. I am specially concerned about adding > 3rd party code from AMD (although released under GPL) into LCDproc. Who > is going to support this? > > Right now, I will not add the patch due to formal reasons. See SF ticket. > > Regards, > Markus > > -------- Original Message -------- > Subject: [ lcdproc-Feature Requests-2941314 ] Futaba dm-140gink VFD > device needs driver > Date: Wed, 27 Jan 2010 23:32:24 +0000 > From: SourceForge.net > To: noreply at sourceforge.net > > > > Feature Requests item #2941314, was opened at 2010-01-28 00:32 > Message generated for change (Tracker Item Submitted) made by > You can respond by visiting: > https://sourceforge.net/tracker/?func=detail&atid=350119&aid=2941314&group_id=119 > > Please note that this message will contain a full copy of the comment thread, > including the initial issue submission, for this request, > not just the latest update. > Category: None > Group: None > Status: Open > Priority: 5 > Private: No > Submitted By: DustWolf () > Assigned to: Nobody/Anonymous (nobody) > Summary: Futaba dm-140gink VFD device needs driver > > Initial Comment: > Please add support for the Fatuba dm-140gink VFD device. > > See this bug report for details including existing driver source code: > https://bugs.launchpad.net/ubuntu/+source/lcdproc/+bug/302919 > > ---------------------------------------------------------------------- > > You can respond by visiting: > https://sourceforge.net/tracker/?func=detail&atid=350119&aid=2941314&group_id=119 > > Hi Markus, I'm not a GPL attorney so this is only my opinion. Some of the file _seem_ to be covered by GPL by Advanced Micro Devices. It would be best if we knew where they came from originally to verify that someone along the way didn't simply put the GPL in them. Other files, like dm140.c, is copyright by Henrik, with no mention of either AMD or a GPL release. This is where I get edgy. It would be better if Henrik clearly releases his code under GPL. Also, there is an AMD logo built in to the graphics. See amd_logo in led.c. It doesn't seem to be used anywhere but I imagine AMD has strict controls on their logo. It should be removed so it is never accidently displayed in the future. When I wrote the lis driver by snooping the wire protocol from the non-free Windows drivers, Peter wanted clear, public, permission from the vendor before incorporating it to lcdproc. Better to err on the safe side than jeopardize the future of lcdproc and the hardwork everyone has put into all of it. I would suggest that Henrik or some of the other users that are interested in the driver should contact AMD for specific permission to use the code in this manner. Finally, I want to thank you for stepping up for Peter. You've been doing a great service. -Daryl From TELarson at west.com Fri Jan 29 14:32:30 2010 From: TELarson at west.com (Larson, Timothy E.) Date: Fri, 29 Jan 2010 08:32:30 -0600 Subject: [Lcdproc] install-server target installs client doco In-Reply-To: <4B61E08A.5020606@nurfuerspam.de> References: <226316B3E1F749498E28ACA66321D5BA01318FA1C6@oma00cexmbx03.corp.westworlds.com> <4B61E08A.5020606@nurfuerspam.de> Message-ID: <226316B3E1F749498E28ACA66321D5BA0131B307B5@oma00cexmbx03.corp.westworlds.com> > For server LCDd.8 and lcdproc-config.5 are installed. For clients > lcdproc.1, lcdexec.1, lcdvc.1, and lcdproc-config.5 are installed. > That's correct. > > man_MANS and man#_MANS should have the same result in our case, as > we > name the man files by their correct section number (.1 .5 .8). IIRC, there was some handling for the man#_MANS, but they were just never defined separately, AFAICT. That's why it seemed unfinished to me. > I don't know why there are no separate uninstall targets, but a > 'make > uninstall' suceeds in both cases. On most OS uninstallation is > handled > OS specific packaging tools anyway. Correct. I'm packaging lcdproc as "server" and "clients" packages, as there will certainly be times when you only want clients. I don't want uninstalling one to wipe out the docs for the other. That's how I stumbled upon this. Tim From bsdfan at nurfuerspam.de Fri Jan 29 19:16:51 2010 From: bsdfan at nurfuerspam.de (Markus Dolze) Date: Fri, 29 Jan 2010 20:16:51 +0100 Subject: [Lcdproc] lcdproc ported for QNX [update] In-Reply-To: <2c26506d1001290033o226c1b04scec190f05e8a55cf@mail.gmail.com> References: <2c26506d0910052255o19a5a86gb176007a0db8508b@mail.gmail.com> <4AD3F87C.6070901@nurfuerspam.de> <2c26506d0910132222g506877a6ga4a6f2e5683c24ad@mail.gmail.com> <4ADCD657.8000404@nurfuerspam.de> <4B44E79D.1080502@nurfuerspam.de> <2c26506d1001110240i72498a6eye34064893308486e@mail.gmail.com> <2c26506d1001180436k5716e57akbbca14c358540fb2@mail.gmail.com> <4B61DE91.20301@nurfuerspam.de> <2c26506d1001290033o226c1b04scec190f05e8a55cf@mail.gmail.com> Message-ID: <4B633423.4020706@nurfuerspam.de> On 29.01.2010 09:33, Satz Klauer wrote: > On 1/28/10, Markus Dolze wrote: >> Satz Klauer wrote: >>> OK, where can I find the nighly CVS snapshot? The one from >>> http://lcdproc.sourceforge.net/nightly/lcdproc-CVS-current.tar.gz does >>> not seem to contain any of the modifications... >>> >> the nightly tarball contains all the changes I believe to be necessary >> to build LCDd. It does not include the client. The compiler contraints >> described in >> http://lists.omnipotent.net/pipermail/lcdproc/2009-October/013111.html >> still apply as well. > > No, the server misses the changes, it still uses the - for QNX invalid > - SA_RESTART definition. > > The same for the drivers: here still the CTSRTS definition is used > that should have be replaced by the patch. > > So at the moment I really can't see what has been applied exactly. > Hi, yes, both have not been modified like in the patch you submitted. However: SA_RESTART if #ifdef protected now and its usability is detected by ./configure. All serial drivers use cfmakeraw() now, which is available on QNX to my knowledge (and you did not patch those drivers where cfmakeraw() had already been used), so QNX should not be affected by the use of CTSRTS anymore. So, does it compile or not? If not, please provide config.log, config.h, and make output. Thanks, Markus From bsdfan at nurfuerspam.de Fri Jan 29 19:17:37 2010 From: bsdfan at nurfuerspam.de (Markus Dolze) Date: Fri, 29 Jan 2010 20:17:37 +0100 Subject: [Lcdproc] install-server target installs client doco In-Reply-To: <226316B3E1F749498E28ACA66321D5BA0131B307B5@oma00cexmbx03.corp.westworlds.com> References: <226316B3E1F749498E28ACA66321D5BA01318FA1C6@oma00cexmbx03.corp.westworlds.com> <4B61E08A.5020606@nurfuerspam.de> <226316B3E1F749498E28ACA66321D5BA0131B307B5@oma00cexmbx03.corp.westworlds.com> Message-ID: <4B633451.4090109@nurfuerspam.de> On 29.01.2010 15:32, Larson, Timothy E. wrote: >> For server LCDd.8 and lcdproc-config.5 are installed. For clients >> lcdproc.1, lcdexec.1, lcdvc.1, and lcdproc-config.5 are installed. >> That's correct. >> >> man_MANS and man#_MANS should have the same result in our case, as >> we name the man files by their correct section number (.1 .5 .8). > > IIRC, there was some handling for the man#_MANS, but they were just > never defined separately, AFAICT. That's why it seemed unfinished to > me. Yes, I was surprised by that, too. Although I couldn't find that behaviour described in automake documentation, the Makefile.in generated from Makefile.am does contain install-man# targets for each man section and parses the content of man_MANS as well. > >> I don't know why there are no separate uninstall targets, but a >> 'make uninstall' suceeds in both cases. On most OS uninstallation >> is handled OS specific packaging tools anyway. > > Correct. I'm packaging lcdproc as "server" and "clients" packages, > as there will certainly be times when you only want clients. I don't > want uninstalling one to wipe out the docs for the other. That's how > I stumbled upon this. > That's a good point. If you actually have installed both and only want to uninstall one of server / clients, we would need separate uninstall targets for them. As uninstall-man# targets are already automatically created by automake it should not be too difficult to implement this. Regards, Markus From bsdfan at nurfuerspam.de Fri Jan 29 19:18:27 2010 From: bsdfan at nurfuerspam.de (Markus Dolze) Date: Fri, 29 Jan 2010 20:18:27 +0100 Subject: [Lcdproc] [Fwd: Futaba dm-140gink VFD device needs driver] In-Reply-To: References: <4B61E36F.4050701@nurfuerspam.de> Message-ID: <4B633483.9030407@nurfuerspam.de> On 29.01.2010 00:00, Daryl F wrote: > On Thu, 28 Jan 2010, Markus Dolze wrote: > >> Hello list, >> >> I would like you to refer to this newly submitted feature request (see >> below) and request your opinion. I am specially concerned about adding >> 3rd party code from AMD (although released under GPL) into LCDproc. Who >> is going to support this? >> >> Right now, I will not add the patch due to formal reasons. See SF ticket. >> >> Regards, >> Markus >> >> -------- Original Message -------- >> Subject: [ lcdproc-Feature Requests-2941314 ] Futaba dm-140gink VFD >> device needs driver >> Date: Wed, 27 Jan 2010 23:32:24 +0000 >> From: SourceForge.net >> To: noreply at sourceforge.net >> >> >> >> Feature Requests item #2941314, was opened at 2010-01-28 00:32 >> Message generated for change (Tracker Item Submitted) made by >> You can respond by visiting: >> https://sourceforge.net/tracker/?func=detail&atid=350119&aid=2941314&group_id=119 >> >> > > Hi Markus, > > I'm not a GPL attorney so this is only my opinion. > > Some of the file _seem_ to be covered by GPL by Advanced Micro Devices. > It would be best if we knew where they came from originally to verify > that someone along the way didn't simply put the GPL in them. > > Other files, like dm140.c, is copyright by Henrik, with no mention of > either AMD or a GPL release. This is where I get edgy. It would be > better if Henrik clearly releases his code under GPL. > > Also, there is an AMD logo built in to the graphics. See amd_logo in > led.c. It doesn't seem to be used anywhere but I imagine AMD has strict > controls on their logo. It should be removed so it is never accidently > displayed in the future. > > When I wrote the lis driver by snooping the wire protocol from the > non-free Windows drivers, Peter wanted clear, public, permission from > the vendor before incorporating it to lcdproc. > > Better to err on the safe side than jeopardize the future of lcdproc and > the hardwork everyone has put into all of it. > > I would suggest that Henrik or some of the other users that are > interested in the driver should contact AMD for specific permission to > use the code in this manner. > > Finally, I want to thank you for stepping up for Peter. You've been > doing a great service. > > > -Daryl > Actually I had seen that Ubuntu bug when I prepared 0.5.3 but decided not to take action on my own. Searching for "libvfd" shows that only a few other projects (linuxmce, minimyth) use this code as well, but there is no trace to an offical AMD source. If "libvfd" was a 3rd party library that we could dynamically link against it would be much more easier to include only the "bridge" driver, like we have ones for svga, xosd... In my response to the Sourceforge ticket I put the rules I apply for new drivers. They address most of what you mentioned above. Markus From TELarson at west.com Fri Jan 29 19:37:14 2010 From: TELarson at west.com (Larson, Timothy E.) Date: Fri, 29 Jan 2010 13:37:14 -0600 Subject: [Lcdproc] install-server target installs client doco In-Reply-To: <4B633451.4090109@nurfuerspam.de> References: <226316B3E1F749498E28ACA66321D5BA01318FA1C6@oma00cexmbx03.corp.westworlds.com> <4B61E08A.5020606@nurfuerspam.de> <226316B3E1F749498E28ACA66321D5BA0131B307B5@oma00cexmbx03.corp.westworlds.com> <4B633451.4090109@nurfuerspam.de> Message-ID: <226316B3E1F749498E28ACA66321D5BA0131B30989@oma00cexmbx03.corp.westworlds.com> > > Correct. I'm packaging lcdproc as "server" and "clients" > packages, > > as there will certainly be times when you only want clients. I > don't > > want uninstalling one to wipe out the docs for the other. That's > how > > I stumbled upon this. > > > > That's a good point. If you actually have installed both and only > want > to uninstall one of server / clients, we would need separate > uninstall > targets for them. As uninstall-man# targets are already > automatically > created by automake it should not be too difficult to implement > this. If you can think of a good way to do it, let me know, and I can backport the changes into my 0.5.3 package. When it gets into autoconf/automake my eyes start to glaze over. Tim From christian.leuschen at gmx.de Sat Jan 30 12:15:44 2010 From: christian.leuschen at gmx.de (Christian Leuschen) Date: Sat, 30 Jan 2010 13:15:44 +0100 Subject: [Lcdproc] [PATCH] imonlcd driver fix (special icon) In-Reply-To: <4B61E265.7070509@nurfuerspam.de> References: <4B5744FC.6040502@gmx.de> <593796.29799.qm@web37501.mail.mud.yahoo.com> <4B61E265.7070509@nurfuerspam.de> Message-ID: <4B6422F0.7060501@gmx.de> Hi Markus, thanks a lot! Sergey Umpelev found another icon that suffers from the same mistake, as can be found in the patch included. Would you be so kind to commit this icon either? Regards, Christian Leuschen Am 28.01.2010 20:15, schrieb Markus Dolze: > jk wrote: > >>> From: Christian Leuschen >>> >>> >>> >>>> the patch included in this mail fixes an issue with a special icon on >>>> >>>> >>> the imon-lcd that does not get displayed without the patch. >>> >>> >> Nice catch. >> >> >> >>>> It also switches vbars to "norrow style" as a spectrum analyzer with >>>> >>>> >>> "full style" looks awful - IMHO. >>> >>> >>> >> I don't really have an opinion on the vbar style, but the comment on line 652 should be updated accordingly. >> >> -jonathan >> >> >> > Committed both. > > Regards, > Markus > > > > -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: lcdproc-0.5.3-imonlcd-missing-icons.diff URL: From eldavidillo at hotmail.com Sat Jan 30 21:48:56 2010 From: eldavidillo at hotmail.com (David) Date: Sat, 30 Jan 2010 22:48:56 +0100 Subject: [Lcdproc] Shuttle XPC M1000 VFD In-Reply-To: <105e65561001300723p185d8610k72eedbef5167bcb8@mail.gmail.com> References: <105e65561001300723p185d8610k72eedbef5167bcb8@mail.gmail.com> Message-ID: I'm trying to set up lcdproc to handle the VFD on the front of a Shuttle XPC M1000 box. AFAIK it should be supported by the shuttleVFD driver so I compiled lcdproc with --enable-drivers=shuttleVFD, no problem there. However when I try to run LCDd I get: shuttleVFD: unable to find Shuttle VFD Driver [shuttleVFD] init failed, return code -1 Could not load driver shuttleVFD There is no output driver Critical error while initializing, abort. Any pointers? -------------- next part -------------- An HTML attachment was scrubbed... URL: From eldavidillo at hotmail.com Sat Jan 30 23:14:44 2010 From: eldavidillo at hotmail.com (David) Date: Sun, 31 Jan 2010 00:14:44 +0100 Subject: [Lcdproc] Shuttle XPC M1000 VFD In-Reply-To: <105e65561001301348t4c461903v253e8213ee2d0b58@mail.gmail.com> References: <105e65561001300723p185d8610k72eedbef5167bcb8@mail.gmail.com> <105e65561001301348t4c461903v253e8213ee2d0b58@mail.gmail.com> Message-ID: Solved! The vendor ID of the VFD reported by lsusb on my M1000 did not match what was defined in the driver. Simply changing #define SHUTTLE_VFD_VENDOR_ID from 0x051c to 0x1308 in server/drivers/shuttleVFD.h and recompiling did the trick. LCDd now recognizes the VFD and runs fine. On Sat, Jan 30, 2010 at 10:48 PM, David wrote: > I'm trying to set up lcdproc to handle the VFD on the front of a Shuttle > XPC M1000 box. > AFAIK it should be supported by the shuttleVFD driver so I compiled lcdproc > with --enable-drivers=shuttleVFD, no problem there. > However when I try to run LCDd I get: > > shuttleVFD: unable to find Shuttle VFD > Driver [shuttleVFD] init failed, return code -1 > Could not load driver shuttleVFD > There is no output driver > Critical error while initializing, abort. > > Any pointers? > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bsdfan at nurfuerspam.de Sun Jan 31 10:16:25 2010 From: bsdfan at nurfuerspam.de (Markus Dolze) Date: Sun, 31 Jan 2010 11:16:25 +0100 Subject: [Lcdproc] Shuttle XPC M1000 VFD In-Reply-To: References: <105e65561001300723p185d8610k72eedbef5167bcb8@mail.gmail.com> <105e65561001301348t4c461903v253e8213ee2d0b58@mail.gmail.com> Message-ID: <4B655879.2000808@nurfuerspam.de> On 31.01.2010 00:14, David wrote: > Solved! The vendor ID of the VFD reported by lsusb on my M1000 did not > match what was defined in the driver. > Simply changing #define SHUTTLE_VFD_VENDOR_ID from 0x051c to 0x1308 in > server/drivers/shuttleVFD.h and recompiling did the trick. LCDd now > recognizes the VFD and runs fine. > > On Sat, Jan 30, 2010 at 10:48 PM, David > wrote: > > I'm trying to set up lcdproc to handle the VFD on the front of a > Shuttle XPC M1000 box. > AFAIK it should be supported by the shuttleVFD driver so I > compiled lcdproc with --enable-drivers=shuttleVFD, no problem there. > However when I try to run LCDd I get: > > shuttleVFD: unable to find Shuttle VFD > Driver [shuttleVFD] init failed, return code -1 > Could not load driver shuttleVFD > There is no output driver > Critical error while initializing, abort. > > Any pointers? > > Hi, thanks for pointing this out. I found that the driver originally supported this device. Later support for newer models was added and the Vendor ID for the old devices got lost. I will fix this, although may take a while. Regards, Markus