From ethan.dicks at gmail.com Mon Dec 1 05:27:28 2008 From: ethan.dicks at gmail.com (Ethan Dicks) Date: Tue, 2 Dec 2008 00:27:28 +1300 Subject: [Lcdproc] lcdident.pl - a minor update Message-ID: All, After noodling around a bit today, I've spruced up the POD documentation for lcdident.pl and bumped up its minor version number. I haven't changed any of the functionality of the code, but if you care to use it as a starting point for your own clients, this version (1.05) is slightly better. I'll probably incorporate these documentation changes to my other simple clients before sharing them. -ethan -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: lcdident.pl URL: From juan.nm at vaelsys.com Tue Dec 2 09:16:09 2008 From: juan.nm at vaelsys.com (Juanelo) Date: Tue, 02 Dec 2008 16:16:09 +0100 Subject: [Lcdproc] cwlinux 12832 driver fix Message-ID: <49355139.9050402@vaelsys.com> Hi, I have been playing with this LCD; to make it work with the current CVS driver, I had to edit the file CwLnx.c and add a condition to an if, so the following line: else if (p->model == 12232) { // the graphical model i propose to change it to something like: ... else if (p->model==12232 || p->model==12832) { ... } else { printf("CwLnx_set_char(): MODEL %d NOT SUPPORTED!\n", p->model); return; } in both CwLnx_set_char_unrestricted() and CwLnx_set_char() by the way, there is also a #define: #define LCD_OFF_CURSOR 72 /* is this correct?*/ that according to the documentation doesn't seem to apply to the 12832 model; in fact the value "72" has already been defined previously in the same file: #define LCD_INIT_INSERT 72 /* go to home */ From peter at adpm.de Sat Dec 6 11:00:52 2008 From: peter at adpm.de (Peter Marschall) Date: Sat, 6 Dec 2008 18:00:52 +0100 Subject: [Lcdproc] lcdident.pl - a minor update In-Reply-To: References: Message-ID: <200812061800.52920.peter@adpm.de> Hi Ethan, On Monday, 1. December 2008, Ethan Dicks wrote: > After noodling around a bit today, I've spruced up the POD > documentation for lcdident.pl and bumped up its minor version number. > I haven't changed any of the functionality of the code, but if you > care to use it as a starting point for your own clients, this version > (1.05) is slightly better. I added lcdident.pl to the CVS version of LCDproc. Regards Peter -- Peter Marschall peter at adpm.de From peter at adpm.de Sat Dec 6 11:32:52 2008 From: peter at adpm.de (Peter Marschall) Date: Sat, 6 Dec 2008 18:32:52 +0100 Subject: [Lcdproc] cwlinux 12832 driver fix In-Reply-To: <49355139.9050402@vaelsys.com> References: <49355139.9050402@vaelsys.com> Message-ID: <200812061832.52654.peter@adpm.de> Hi, On Tuesday, 2. December 2008, Juanelo wrote: > Hi, I have been playing with this LCD; to make it work with the current > CVS driver, I had to edit the file CwLnx.c and add a condition to an if, > so the following line: > > else if (p->model == 12232) { // the graphical model > > i propose to change it to something like: > > ... > else if (p->model==12232 || p->model==12832) { > ... > } > else { > printf("CwLnx_set_char(): MODEL %d NOT SUPPORTED!\n", p->model); > return; > } > > in both CwLnx_set_char_unrestricted() and CwLnx_set_char() It is good to see some tests on my extensions that I did with only the documentation, but with out the hardware. I added the first part of your patch. The scond part (the "else { ..." part) is not necessary as the driver's init function only allows the displays tested in the "if" and "else if" branches. > by the way, there is also a #define: > #define LCD_OFF_CURSOR 72 /* is this correct?*/ > > that according to the documentation doesn't seem to apply to the 12832 > model; in fact the value "72" has already been defined previously in > the same file: > #define LCD_INIT_INSERT 72 /* go to home */ I know; I wrote this comment as I saw the the collision in the definition. But without the hardware I wasn't able to test, so I left it in. Could you try to test with the line CwLnx_hidecursor(p->fd); commented, and report back whether it still works. Regards Peter -- Peter Marschall peter at adpm.de From herdler at gmx.de Mon Dec 8 08:41:56 2008 From: herdler at gmx.de (Stefan Herdler) Date: Mon, 08 Dec 2008 15:41:56 +0100 Subject: [Lcdproc] SerialVFD update for BA63/BA66 VFD In-Reply-To: <200811231411.07888.peter@adpm.de> References: <492870FF.6080204@gmx.de> <200811231411.07888.peter@adpm.de> Message-ID: <493D3234.30902@gmx.de> Hi Peter, at first sorry for the delay. Peter Marschall wrote: > Hi Stefan, > > On Saturday, 22. November 2008, Stefan Herdler wrote: > >> I just want to point on a patch I sent to the list some time ago. >> The Patch adds support of the BA63/BA66 VFD from Simens / Wincor-Nixdorf. >> >> Link to the original Message: >> http://lists.omnipotent.net/pipermail/lcdproc/2008-July/012253.html >> >> Meanwhile I got some positive feedback, so I assume the driver works >> like it should do ;-) . >> > > sorry this flew below my radar back then. > > Thanks for supporting LCDproc despite my lazyness/ignorance ;-) > Peter > > No problem thanks for including the patch. Also than thanks in the name of the BA63/66 users who don't need to bother me about installing the patch any more ;). Regards Stefan From herdler at gmx.de Mon Dec 8 08:54:36 2008 From: herdler at gmx.de (Stefan Herdler) Date: Mon, 08 Dec 2008 15:54:36 +0100 Subject: [Lcdproc] Non-Latin characters in LCDd.conf In-Reply-To: <200811291523.15688.peter@adpm.de> References: <47da1bd90811240547r5373fb20ma9e624bd851a35e3@mail.gmail.com> <20081129083250.9BC4C93CBA1@tippex.mynet.homeunix.org> <200811291523.15688.peter@adpm.de> Message-ID: <493D352C.6030604@gmx.de> Hi, Peter Marschall wrote: > Hi, > > On Saturday, 29. November 2008, aeriksson2 at fastmail.fm wrote: > >> Thanks for the explanation. While I appreciate that various devices have >> lots of constaints making font loading seem like a far off vision, what is >> the charset used in the client->LCDd protocol? From an application writer's >> point of view it would be better to have a fixed (or settable) charset and >> let the drivers emulate stuff not rederable on the device, than resort to >> device specific programming go get the right glyphs out to the screen. >> >> Unfortunately the number of Usercharacters of the most displays is very limited. I doubt it is possible to produce a usable greek or cyrillic output with the US-ASCII character set and only 8 user defineable characters. >> Is it us-ascii today? What would it take to make it utf-8? >> > > This is hard to answer. > If you restrict yourself to US-ASCII you are on the safe side. > > As Ethan already explained, most of the text-mode displays > support different 8-bit character sets, that cannot be changed. > Some display like the BA63/66 have different selectable, predefined character sets for different languages. The BA63/66 is the display with the best language compatibility I've seen so far. It has character sets for almost every language (including greek, cyrillic, katakana, ...) on board. > For some displays there is a mapping layer in the LCDproc driver > that tries to map Latin1 to the display's character set. > Unfortunately this is not always completely possible. > > What does it take to support UTF8 ? > I fear rewriting large parts of the server core, and problably all of the > drivers. > > If you have UTF8 data that does only contain characters in the Latin1 range, > you may try to do the conversion in a client before sending it to LCDd. > Well perhaps there is a way to achieve UTF8 compatibility more easily. All display I've seen so far are only having a 8bit code. I assume it would be possible to install a UTF8 -> 8bit-displaycode converter somewhere "early" in the LCDd and leave the rest untouched. If Display specific conversion tables needed they could be stored in and loaded from the in the driver. Otherwise a standard UTF8 -> Latin1 table should be used. Unfortunately my knowledge about UTF8 is very limited and I don't use UTF8 on the system I've LCDproc running on, but I'm afraid I have to deal with that problem at the next system update. Regards Stefan From TELarson at west.com Mon Dec 8 09:14:01 2008 From: TELarson at west.com (Larson, Timothy E.) Date: Mon, 8 Dec 2008 09:14:01 -0600 Subject: [Lcdproc] Non-Latin characters in LCDd.conf In-Reply-To: <493D352C.6030604@gmx.de> References: <47da1bd90811240547r5373fb20ma9e624bd851a35e3@mail.gmail.com> <20081129083250.9BC4C93CBA1@tippex.mynet.homeunix.org><200811291523.15688.peter@adpm.de> <493D352C.6030604@gmx.de> Message-ID: On Monday, December 08, 2008 8:55 AM, Stefan Herdler <> scribbled: > Well perhaps there is a way to achieve UTF8 compatibility more easily. > > All display I've seen so far are only having a 8bit code. > I assume it would be possible to install a UTF8 -> 8bit-displaycode > converter somewhere "early" in the LCDd and leave the rest untouched. > If Display specific conversion tables needed they could be stored in > and loaded from the in the driver. > Otherwise a standard UTF8 -> Latin1 table should be used. I'll plug Lynx's translation tables again, just because they'd save reinventing the wheel. It has a number of 8-bit tables, and a 7-bit fallback table. Tim -- Tim Larson AMT2 Unix Systems Administrator InterCall, a division of West Corporation Eschew obfuscation! -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 9455 bytes Desc: not available URL: From Mark.Vallevand at UNISYS.com Tue Dec 9 12:41:24 2008 From: Mark.Vallevand at UNISYS.com (Vallevand, Mark K) Date: Tue, 9 Dec 2008 12:41:24 -0600 Subject: [Lcdproc] Memory leak Message-ID: In server/commands/menu_commands.c there is a malloc without a corresponding free. See function argv2string(). We are seeing a memory leak in LCDd in our embedded product. This is the first leak found in the LCDd code, but there may be others. I'm looking hard because LCDd will grow to fill memory in only 8 days on our product. Regards. Mark K Vallevand "I got free checking at Bear Stearns!" THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. -------------- next part -------------- An HTML attachment was scrubbed... URL: From andy at siliconlandmark.com Tue Dec 9 13:00:49 2008 From: andy at siliconlandmark.com (Andre Guibert de Bruet) Date: Tue, 9 Dec 2008 14:00:49 -0500 Subject: [Lcdproc] Memory leak In-Reply-To: References: Message-ID: On Dec 9, 2008, at 1:41 PM, Vallevand, Mark K wrote: > In server/commands/menu_commands.c there is a malloc without a > corresponding free. See function argv2string(). Look carefully at what the function is intended to do. The returning of a malloc()'ed buffer is by design. It is up to the caller to call free() against the returned buffer (If it doesn't, you end up with leaking memory). > We are seeing a memory leak in LCDd in our embedded product. This > is the first leak found in the LCDd code, but there may be others. > I?m looking hard because LCDd will grow to fill memory in only 8 > days on our product. If you are using Linux, run LCDd under valgrind on your development/ reference system. It will help point out any memory allocation issues. As with all software projects there's always room for improvement. Do submit patches! Cheers, /* Andre Guibert de Bruet * 436f 6465 2070 6f65 742e 2042 6974 206a */ /* Managing Partner * 6f63 6b65 792e 2053 7973 4164 6d69 6e2e */ /* GSM: +1 734 846 8758 * 2055 4e49 5820 736c 6575 7468 2e00 0000 */ /* WWW: siliconlandmark.com * C/C++, Java, Perl, PHP, SQL, XHTML, XML */ From andy at siliconlandmark.com Tue Dec 9 14:03:15 2008 From: andy at siliconlandmark.com (Andre Guibert de Bruet) Date: Tue, 9 Dec 2008 15:03:15 -0500 Subject: [Lcdproc] Memory leak In-Reply-To: References: Message-ID: <218631F6-489A-4A31-8FF7-B77AA36F03BD@siliconlandmark.com> On Dec 9, 2008, at 2:00 PM, Andre Guibert de Bruet wrote: > On Dec 9, 2008, at 1:41 PM, Vallevand, Mark K wrote: > >> In server/commands/menu_commands.c there is a malloc without a >> corresponding free. See function argv2string(). > > Look carefully at what the function is intended to do. The returning > of a malloc()'ed buffer is by design. It is up to the caller to call > free() against the returned buffer (If it doesn't, you end up with > leaking memory). And it turns out the caller wasn't. Good catch! :) >> We are seeing a memory leak in LCDd in our embedded product. This >> is the first leak found in the LCDd code, but there may be others. >> I?m looking hard because LCDd will grow to fill memory in only 8 >> days on our product. > > If you are using Linux, run LCDd under valgrind on your development/ > reference system. It will help point out any memory allocation issues. > > As with all software projects there's always room for improvement. > Do submit patches! I cooked up a patch which addresses the issue you have brought up as well as a possible NULL-pointer dereference in the malloc() failure case. It turns out that LCDd is leaking memory in the call to debug() whether or not debugging is turned on, every time menu_set_item_func() gets called! Please give the attached patch a spin and let the list know if this helps alleviate the memory issues you are running into on your test system. Cheers, /* Andre Guibert de Bruet * 436f 6465 2070 6f65 742e 2042 6974 206a */ /* Managing Partner * 6f63 6b65 792e 2053 7973 4164 6d69 6e2e */ /* GSM: +1 734 846 8758 * 2055 4e49 5820 736c 6575 7468 2e00 0000 */ /* WWW: siliconlandmark.com * C/C++, Java, Perl, PHP, SQL, XHTML, XML */ -------------- next part -------------- A non-text attachment was scrubbed... Name: argv2string.diff Type: application/octet-stream Size: 1245 bytes Desc: not available URL: -------------- next part -------------- From Mark.Vallevand at UNISYS.com Tue Dec 9 14:38:19 2008 From: Mark.Vallevand at UNISYS.com (Vallevand, Mark K) Date: Tue, 9 Dec 2008 14:38:19 -0600 Subject: [Lcdproc] Memory leak In-Reply-To: <218631F6-489A-4A31-8FF7-B77AA36F03BD@siliconlandmark.com> References: <218631F6-489A-4A31-8FF7-B77AA36F03BD@siliconlandmark.com> Message-ID: The patch won't work. I didn't see any free() in the calling code. (My work-around is to comment out the debug() call. Then, I'll test to see if there are still leaks. But, I'm having technical difficulties, so that might be a few hours or tomorrow.) Regards. Mark K Vallevand "I got free checking at Bear Stearns!" THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. -----Original Message----- From: Andre Guibert de Bruet [mailto:andy at siliconlandmark.com] Sent: Tuesday, December 09, 2008 2:03 PM To: Vallevand, Mark K Cc: lcdproc at lists.omnipotent.net Subject: Re: [Lcdproc] Memory leak On Dec 9, 2008, at 2:00 PM, Andre Guibert de Bruet wrote: > On Dec 9, 2008, at 1:41 PM, Vallevand, Mark K wrote: > >> In server/commands/menu_commands.c there is a malloc without a >> corresponding free. See function argv2string(). > > Look carefully at what the function is intended to do. The returning > of a malloc()'ed buffer is by design. It is up to the caller to call > free() against the returned buffer (If it doesn't, you end up with > leaking memory). And it turns out the caller wasn't. Good catch! :) >> We are seeing a memory leak in LCDd in our embedded product. This >> is the first leak found in the LCDd code, but there may be others. >> I'm looking hard because LCDd will grow to fill memory in only 8 >> days on our product. > > If you are using Linux, run LCDd under valgrind on your development/ > reference system. It will help point out any memory allocation issues. > > As with all software projects there's always room for improvement. > Do submit patches! I cooked up a patch which addresses the issue you have brought up as well as a possible NULL-pointer dereference in the malloc() failure case. It turns out that LCDd is leaking memory in the call to debug() whether or not debugging is turned on, every time menu_set_item_func() gets called! Please give the attached patch a spin and let the list know if this helps alleviate the memory issues you are running into on your test system. Cheers, /* Andre Guibert de Bruet * 436f 6465 2070 6f65 742e 2042 6974 206a */ /* Managing Partner * 6f63 6b65 792e 2053 7973 4164 6d69 6e2e */ /* GSM: +1 734 846 8758 * 2055 4e49 5820 736c 6575 7468 2e00 0000 */ /* WWW: siliconlandmark.com * C/C++, Java, Perl, PHP, SQL, XHTML, XML */ From andy at siliconlandmark.com Tue Dec 9 14:51:27 2008 From: andy at siliconlandmark.com (Andre Guibert de Bruet) Date: Tue, 9 Dec 2008 15:51:27 -0500 Subject: [Lcdproc] Memory leak In-Reply-To: References: <218631F6-489A-4A31-8FF7-B77AA36F03BD@siliconlandmark.com> Message-ID: <6E064C0D-B8D0-4C8C-9EB4-2C12B289153D@siliconlandmark.com> On Dec 9, 2008, at 3:38 PM, Vallevand, Mark K wrote: > The patch won't work. I didn't see any free() in the calling code. > > (My work-around is to comment out the debug() call. Then, I'll test > to > see if there are still leaks. But, I'm having technical difficulties, > so that might be a few hours or tomorrow.) It turns out that I sent you an old diff. I'm having a heck of a day... Give this one a shot. Cheers, /* Andre Guibert de Bruet * 436f 6465 2070 6f65 742e 2042 6974 206a */ /* Managing Partner * 6f63 6b65 792e 2053 7973 4164 6d69 6e2e */ /* GSM: +1 734 846 8758 * 2055 4e49 5820 736c 6575 7468 2e00 0000 */ /* WWW: siliconlandmark.com * C/C++, Java, Perl, PHP, SQL, XHTML, XML */ -------------- next part -------------- A non-text attachment was scrubbed... Name: argv2string.diff Type: application/octet-stream Size: 1264 bytes Desc: not available URL: -------------- next part -------------- From umberto.bernardi at gmail.com Tue Dec 9 17:09:26 2008 From: umberto.bernardi at gmail.com (Umberto Bernardi) Date: Wed, 10 Dec 2008 00:09:26 +0100 Subject: [Lcdproc] Ks0108 serdisplib Message-ID: <99984a220812091509p45823a03n459a73b3e55e1e37@mail.gmail.com> Hello all! I'm trying to have my KS0108 display working, but for now no chance... I've read that this display is working through GRAPHLCD-DRIVER, but there's no way to compile this library under my system (debian lenny). I think because the library is too old. I'm able to use the display with "serdisplib". there's a way to bypass GRAPHLCD and use serdisplib instead? Thanks a lot bye -- Umberto "crash_override" Bernardi Linux Registered User #353811 --------------------------------------------------- Impossibilia nemo tenetur.... -------------- next part -------------- An HTML attachment was scrubbed... URL: From stefanh at on-luebeck.de Wed Dec 10 01:41:24 2008 From: stefanh at on-luebeck.de (=?ISO-8859-1?Q?Stefan_Hu=DFfeldt?=) Date: Wed, 10 Dec 2008 08:41:24 +0100 Subject: [Lcdproc] Ks0108 serdisplib In-Reply-To: <99984a220812091509p45823a03n459a73b3e55e1e37@mail.gmail.com> References: <99984a220812091509p45823a03n459a73b3e55e1e37@mail.gmail.com> Message-ID: <493F72A4.1090308@on-luebeck.de> Umberto Bernardi schrieb: > I'm trying to have my KS0108 display working, but for now no chance... > I've read that this display is working through GRAPHLCD-DRIVER, but > there's no way to compile this library under my system (debian lenny). > I think because the library is too old. Here i'm running a gLCD (t6963c, 240x128) via graphlcd under Ubuntu intrepid 64bit. I had to patch graphlcd-base-0.1.5.tgz? and glcdprocdriver-0.0.4.tar.bz2 to work with gcc 4.3. ?http://bugs.gentoo.org/show_bug.cgi?id=227125 -- Und Tsch?ss. Stefan ### Kilroy was here ### 2.6.20.2 up 82 days -------------- next part -------------- A non-text attachment was scrubbed... Name: glcdprocdriver-0.0.4-gcc43.patch.gz Type: application/x-gzip Size: 253 bytes Desc: not available URL: From Mark.Vallevand at UNISYS.com Wed Dec 10 10:32:06 2008 From: Mark.Vallevand at UNISYS.com (Vallevand, Mark K) Date: Wed, 10 Dec 2008 10:32:06 -0600 Subject: [Lcdproc] Memory leak In-Reply-To: <6E064C0D-B8D0-4C8C-9EB4-2C12B289153D@siliconlandmark.com> References: <218631F6-489A-4A31-8FF7-B77AA36F03BD@siliconlandmark.com> <6E064C0D-B8D0-4C8C-9EB4-2C12B289153D@siliconlandmark.com> Message-ID: Works for me. Regards. Mark K Vallevand "I got free checking at Bear Stearns!" THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. -----Original Message----- From: Andre Guibert de Bruet [mailto:andy at siliconlandmark.com] Sent: Tuesday, December 09, 2008 2:51 PM To: Vallevand, Mark K Cc: lcdproc at lists.omnipotent.net Subject: Re: [Lcdproc] Memory leak On Dec 9, 2008, at 3:38 PM, Vallevand, Mark K wrote: > The patch won't work. I didn't see any free() in the calling code. > > (My work-around is to comment out the debug() call. Then, I'll test > to > see if there are still leaks. But, I'm having technical difficulties, > so that might be a few hours or tomorrow.) It turns out that I sent you an old diff. I'm having a heck of a day... Give this one a shot. Cheers, /* Andre Guibert de Bruet * 436f 6465 2070 6f65 742e 2042 6974 206a */ /* Managing Partner * 6f63 6b65 792e 2053 7973 4164 6d69 6e2e */ /* GSM: +1 734 846 8758 * 2055 4e49 5820 736c 6575 7468 2e00 0000 */ /* WWW: siliconlandmark.com * C/C++, Java, Perl, PHP, SQL, XHTML, XML */ From peter at adpm.de Sat Dec 13 02:16:02 2008 From: peter at adpm.de (Peter Marschall) Date: Sat, 13 Dec 2008 09:16:02 +0100 Subject: [Lcdproc] Memory leak In-Reply-To: <6E064C0D-B8D0-4C8C-9EB4-2C12B289153D@siliconlandmark.com> References: <6E064C0D-B8D0-4C8C-9EB4-2C12B289153D@siliconlandmark.com> Message-ID: <200812130916.03124.peter@adpm.de> Hi, On Tuesday, 9. December 2008, Andre Guibert de Bruet wrote: > On Dec 9, 2008, at 3:38 PM, Vallevand, Mark K wrote: > > The patch won't work. I didn't see any free() in the calling code. > > > > (My work-around is to comment out the debug() call. Then, I'll test > > to > > see if there are still leaks. But, I'm having technical difficulties, > > so that might be a few hours or tomorrow.) > > It turns out that I sent you an old diff. I'm having a heck of a day... > > Give this one a shot. Committed to CVS Thanks for supporting LCDproc Peter -- Peter Marschall peter at adpm.de From andy at siliconlandmark.com Sat Dec 13 14:44:33 2008 From: andy at siliconlandmark.com (Andre Guibert de Bruet) Date: Sat, 13 Dec 2008 15:44:33 -0500 Subject: [Lcdproc] [PATCH] Memory leaks / NULL pointer dereference on malloc() failure in widget.c Message-ID: Hi, I came across a couple of problems in widget_create(). On a system with sufficient memory (Common case scenario), the function works as expected. Under tight memory conditions, the function doesn't fare so well: * When strdup() fails the allocation of w->id, the function returns NULL. We previously allocated w, which doesn't get free()'ed before the return statement. * frame_name is used without checking if the returned pointer is NULL. My fix adds a debug report() call, the freeing of w->id and w, as well as causing the function to return NULL, much like the other allocation failures. Could you commit the attached patch upon review? Cheers, /* Andre Guibert de Bruet * 436f 6465 2070 6f65 742e 2042 6974 206a */ /* Managing Partner * 6f63 6b65 792e 2053 7973 4164 6d69 6e2e */ /* GSM: +1 734 846 8758 * 2055 4e49 5820 736c 6575 7468 2e00 0000 */ /* WWW: siliconlandmark.com * C/C++, Java, Perl, PHP, SQL, XHTML, XML */ -------------- next part -------------- A non-text attachment was scrubbed... Name: widget.diff Type: application/octet-stream Size: 789 bytes Desc: not available URL: -------------- next part -------------- From peter at adpm.de Sun Dec 14 04:05:02 2008 From: peter at adpm.de (Peter Marschall) Date: Sun, 14 Dec 2008 11:05:02 +0100 Subject: [Lcdproc] [PATCH] Memory leaks / NULL pointer dereference on malloc() failure in widget.c In-Reply-To: References: Message-ID: <200812141105.02575.peter@adpm.de> Hi, On Saturday, 13. December 2008, Andre Guibert de Bruet wrote: > I came across a couple of problems in widget_create(). On a system > with sufficient memory (Common case scenario), the function works as > expected. Under tight memory conditions, the function doesn't fare so > well: > > * When strdup() fails the allocation of w->id, the function returns > NULL. We previously allocated w, which doesn't get free()'ed before > the return statement. > > * frame_name is used without checking if the returned pointer is NULL. > My fix adds a debug report() call, the freeing of w->id and w, as well > as causing the function to return NULL, much like the other allocation > failures. > > Could you commit the attached patch upon review? Yepp. Thanks for the patch. I found another leak in widget_create,which I plugged as well. In addition to that I reset free()'d pointers to NULL in widget_destroy() and documented the methods with Doxygen. To make it more complete I did the same in server/screen.c Please test. Thanks for supporting LCdproc Peter -- Peter Marschall peter at adpm.de From andy at siliconlandmark.com Sun Dec 14 08:36:48 2008 From: andy at siliconlandmark.com (Andre Guibert de Bruet) Date: Sun, 14 Dec 2008 09:36:48 -0500 Subject: [Lcdproc] [PATCH] Memory leaks / NULL pointer dereference on malloc() failure in widget.c In-Reply-To: <200812141105.02575.peter@adpm.de> References: <200812141105.02575.peter@adpm.de> Message-ID: <2B47A06F-9800-4A8E-927C-3F51E17B274C@siliconlandmark.com> On Dec 14, 2008, at 5:05 AM, Peter Marschall wrote: > On Saturday, 13. December 2008, Andre Guibert de Bruet wrote: >> I came across a couple of problems in widget_create(). On a system >> with sufficient memory (Common case scenario), the function works as >> expected. Under tight memory conditions, the function doesn't fare so >> well: >> >> * When strdup() fails the allocation of w->id, the function returns >> NULL. We previously allocated w, which doesn't get free()'ed before >> the return statement. >> >> * frame_name is used without checking if the returned pointer is >> NULL. >> My fix adds a debug report() call, the freeing of w->id and w, as >> well >> as causing the function to return NULL, much like the other >> allocation >> failures. >> >> Could you commit the attached patch upon review? > > Yepp. > Thanks for the patch. > > I found another leak in widget_create,which I plugged as well. > In addition to that I reset free()'d pointers to NULL in > widget_destroy() and documented the methods with Doxygen. > > To make it more complete I did the same in server/screen.c > > Please test. Looks good except for one tiny change in screen.c (See attached patch). Cheers, /* Andre Guibert de Bruet * 436f 6465 2070 6f65 742e 2042 6974 206a */ /* Managing Partner * 6f63 6b65 792e 2053 7973 4164 6d69 6e2e */ /* GSM: +1 734 846 8758 * 2055 4e49 5820 736c 6575 7468 2e00 0000 */ /* WWW: siliconlandmark.com * C/C++, Java, Perl, PHP, SQL, XHTML, XML */ -------------- next part -------------- A non-text attachment was scrubbed... Name: screen.patch Type: application/octet-stream Size: 489 bytes Desc: not available URL: -------------- next part -------------- From andy at siliconlandmark.com Sun Dec 14 08:57:21 2008 From: andy at siliconlandmark.com (Andre Guibert de Bruet) Date: Sun, 14 Dec 2008 09:57:21 -0500 Subject: [Lcdproc] LCDproc v0.5.3? Message-ID: <0E1B3C19-D053-4808-93CB-C7E59E84FCC3@siliconlandmark.com> Hi, What does the schedule look like for the next release of LCDproc? There are a number of desirable driver updates and important bug fixes which users may want to take advantage of, in CVS. In particular, I am thinking of packages that ship with OSes (FreeBSD ports, the various Linux distributions), that usually don't ship code straight from a project's CVS tree. Cheers, /* Andre Guibert de Bruet * 436f 6465 2070 6f65 742e 2042 6974 206a */ /* Managing Partner * 6f63 6b65 792e 2053 7973 4164 6d69 6e2e */ /* GSM: +1 734 846 8758 * 2055 4e49 5820 736c 6575 7468 2e00 0000 */ /* WWW: siliconlandmark.com * C/C++, Java, Perl, PHP, SQL, XHTML, XML */ From peter at adpm.de Sun Dec 14 10:16:44 2008 From: peter at adpm.de (Peter Marschall) Date: Sun, 14 Dec 2008 17:16:44 +0100 Subject: [Lcdproc] [PATCH] Memory leaks / NULL pointer dereference on malloc() failure in widget.c In-Reply-To: <2B47A06F-9800-4A8E-927C-3F51E17B274C@siliconlandmark.com> References: <200812141105.02575.peter@adpm.de> <2B47A06F-9800-4A8E-927C-3F51E17B274C@siliconlandmark.com> Message-ID: <200812141716.45066.peter@adpm.de> Hi, On Sunday, 14. December 2008, Andre Guibert de Bruet wrote: > Looks good except for one tiny change in screen.c (See attached patch). Ooops, you're right. Committed. Thanks again Peter -- Peter Marschall peter at adpm.de From peter at adpm.de Sun Dec 14 10:18:57 2008 From: peter at adpm.de (Peter Marschall) Date: Sun, 14 Dec 2008 17:18:57 +0100 Subject: [Lcdproc] LCDproc v0.5.3? In-Reply-To: <0E1B3C19-D053-4808-93CB-C7E59E84FCC3@siliconlandmark.com> References: <0E1B3C19-D053-4808-93CB-C7E59E84FCC3@siliconlandmark.com> Message-ID: <200812141718.57875.peter@adpm.de> Hi, On Sunday, 14. December 2008, Andre Guibert de Bruet wrote: > What does the schedule look like for the next release of LCDproc? > There are a number of desirable driver updates and important bug fixes > which users may want to take advantage of, in CVS. > > In particular, I am thinking of packages that ship with OSes (FreeBSD > ports, the various Linux distributions), that usually don't ship code > straight from a project's CVS tree. I hope I'll get 'round to doing it over my christmas holiday. Usually when I accounce such dates, every one wants to have his/her lat minute changes in, which then stops me from releasing ;-) Hopefully this time it is different. Regards Peter -- Peter Marschall peter at adpm.de From honyuenkwun at gmail.com Wed Dec 17 23:34:01 2008 From: honyuenkwun at gmail.com (Hon Yuen Kwun) Date: Thu, 18 Dec 2008 00:34:01 -0500 Subject: [Lcdproc] HD44780 Parallel Port permission issues Message-ID: <4949E0C9.90403@gmail.com> I have a HD44780 display using the 'winamp' wiring connected to the parallel port. If I run LCDd as root without dropping the user, the program runs correctly. However, if I drop priviledges to normal user like 'nobody' the program hangs after displaying HD44780 20x4 LPT 0x378 on the character display. I think it's a permission issue, but even if I change my parport file permissions to 666 from 660, it still doesn't work. I have another machine that's running the 2.6.24 kernel and it has no problems with LCDd. I think I first saw problems around the 2.6.25/26 timeframe. Now I'm running 2.6.27. Are these problems caused by the changes to how 'capabilties' are handled by processes in 2.6.25? Am I suppose to use setcap to allow CAP_SYS_RAWIO by all users? I'm not sure where to start looking. I tried looking up CAP_SYS_RAWIO and LCDproc in Google but that did not help. Anyone else have problems? Do I need to make sure I have CONFIG_SECURITY_FILE_CAPABILITIES set in my kernel? Jimmy From avdongen at xs4all.nl Thu Dec 18 03:23:51 2008 From: avdongen at xs4all.nl (Arthur van Dongen) Date: Thu, 18 Dec 2008 10:23:51 +0100 Subject: [Lcdproc] How to handle separate icon area on LCD/VFD glass Message-ID: <1229592232.5397.87.camel@TangoLinux.lan> Hi all, (I already sent a similar post to this list, but this one is further developed. Please ignore the previous one.) I have both a Medion MD8800 VFD and a Shuttle with VFD. Drivers within LCDproc exist for both displays. I want to control the icons from mythtv. For a better understanding of what I mean with these icons, here are two links to pages with photos of the displays in action: http://jeremy.infogami.com/SetVFD http://www.martinm-76.dk/md8800/LCD/md8800-lcd.jpg I searched the net for the best way to implement icons, but the contributions are either focused on LEDs attached to a small number of GPIO ports of the display, or drawing custom characters on the LCD dot matrix. The current drivers for MD8800 and ShuttleVFD already attempt to support the icons, but implement the other interface. Currently both implementations do not fulfill the (my) requirements, and I see the need for an extension to the protocols. Back to the drawing table.... Requirements ============ * Device-independent interface from client to server. If a client wants to light the "Play" light on the display, it does not need to know if it is implemented by a GPIO output attached to a LED or by a triangular LCD segment somewehere on the glass. * Extensible. If a new LCD or VFD display appears that has a new set of icons, it should not require much effort to add support. * Special handling of grouped segments. For example, both VFDs have a "Volume" region, with different number of bars. The client can be hidden from this detail by allowing a "volume 50%" command. * Queryable. A client can request whether an "Envelope" icon is supported by the device, and decide to display a "New mail" text based on the result of this request. * Separate control of the icons. One client can control the "Play" icon, and another can control the "Envelope" icon. * Combined control of icons. Switching from "FF" to "Play" icon should be possible in a single command. There is no sense in controlling these from different clients. * Efficiency. The list of all icon names can only grow, and searching for an icon in the list should not take too long. Grouping? * Flexibility in defining combined icons. For example an icon set for the video source can contain "TV" and "Film" on one device and "DVB-T", "Sat", "MPEG", "DivX", "unknown-codec-of-the-future" icons on another. Design outline ============== Client-Server interface ----------------------- Example: screen_add scrn0 widget_add scrn0 iconWidget icon widget_set scrn0 iconWidget 0 0 PLAYMODE.FF widget_set scrn0 iconWidget 0 0 MAIL.OFF widget_set scrn0 iconWidget 0 0 VIDSRC.TV widget_set scrn0 iconWidget 0 0 VIDSRC.TV_Sat Server-Device API ----------------- _icon(Driver *drvthis, const char iconDef[]); When using icon names of the form GROUP.SELECTION and passing this unaltered to the driver, the driver can then decide what to do with it. I do not know how the screen priorities affect this, when multiple clients set icons on the same location. The driver should split the GROUP from the SELECTION and parse these. If they are known the driver can turn on the right segments in the group, and otherwise revert to a default. Using partial matching, like the TV and TV_SAT selection, the driver can revert to a more common icon. So what do you experts think? Am I heading in the right direction? Thanks for any corrections, ideas, directions, eye openers and other info ;-) Arthur -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From honyuenkwun at gmail.com Thu Dec 18 22:36:23 2008 From: honyuenkwun at gmail.com (=?UTF-8?b?6Z+p5YWD5bSR?=) Date: Fri, 19 Dec 2008 04:36:23 +0000 (UTC) Subject: [Lcdproc] HD44780 Parallel Port permission issues References: <4949E0C9.90403@gmail.com> Message-ID: On Thu, 18 Dec 2008 00:34:01 -0500, Hon Yuen Kwun wrote: > I'm not sure where to start looking. I tried looking up CAP_SYS_RAWIO > and LCDproc in Google but that did not help. Anyone else have problems? > Do I need to make sure I have CONFIG_SECURITY_FILE_CAPABILITIES set in > my kernel? So I tried recompiling my kernel with CONFIG_SECURITY_FILE_CAPABILITIES and LCDd runs as the 'nobody' user again. I guess it's my setup. Jimmy From jskinner58 at sbcglobal.net Fri Dec 19 10:40:14 2008 From: jskinner58 at sbcglobal.net (Jim Skinner) Date: Fri, 19 Dec 2008 08:40:14 -0800 (PST) Subject: [Lcdproc] LCDproc and palmorb... Message-ID: <384644.19297.qm@web83603.mail.sp1.yahoo.com> I have this working but am getting lots of garbage on the display.? In looking for possible solutions I have found some discussions that different Matrix Orbital displays use slightly different commands for some functions.? Palmorb emulates an LK204-25 (or at least claims to).? I have found a few patches for both LCDproc and palmorb but they are over 5 years old so I suspect they are incorporated into the code I have - I recently downloaded them and think I have the latest for both. ? I installed LCDproc using the package available for Fedora 8 with yum(0.5.2). ? I also want to use a PIC with some standard 2 x 16 line displays by using MO emulation code from here but haven't got that running yet... I need the serial link for distance from the PC. ? http://hyper.sunjapan.com.cn/~hz/PIC/index.html ? ? I am a newbie...? Any suggestions to resolve this?? The display is clean and interface works both ways when using a terminal program instead of LCDproc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ethan.dicks at gmail.com Fri Dec 19 15:32:48 2008 From: ethan.dicks at gmail.com (Ethan Dicks) Date: Fri, 19 Dec 2008 16:32:48 -0500 Subject: [Lcdproc] LCDproc and palmorb... In-Reply-To: <384644.19297.qm@web83603.mail.sp1.yahoo.com> References: <384644.19297.qm@web83603.mail.sp1.yahoo.com> Message-ID: On Fri, Dec 19, 2008 at 11:40 AM, Jim Skinner wrote: > I have this working but am getting lots of garbage on the display. In > looking for possible solutions I have found some discussions that different > Matrix Orbital displays use slightly different commands for some functions. > Palmorb emulates an LK204-25 (or at least claims to). I have found a few > patches for both LCDproc and palmorb but they are over 5 years old so I > suspect they are incorporated into the code I have - I recently downloaded > them and think I have the latest for both. The latest released LCDproc (0.5.2) has drivers bugs in the Matrix Orbital drivers. > I installed LCDproc using the package available for Fedora 8 with > yum(0.5.2). Yes. That version. > I am a newbie... Any suggestions to resolve this? The display is clean and > interface works both ways when using a terminal program instead of LCDproc. You will need a more recent (year old or less?) copy of the source from either the CVS tree or one of the nightly tarballs. I don't recell exactly when I submitted the Matrix Orbital fixes, but you could find that out by browsing the CVS source tree if it's important. If you get a "nightly tarball" that is only days or weeks old (not years), the fix will be in it for certain. I believe the cycle is about to start up for a soonish 0.5.3 release, but I don't know when, precisely, that will happen. I will ensure that I check any 0.5.3 release candidates against all the displays I can (MtxOrb, jw002, PicoLCD, and usb2lcd, at least). That reminds me - I need to submit my jw002 driver in time for the next release. -ethan From bsdfan at nurfuerspam.de Sun Dec 21 23:17:32 2008 From: bsdfan at nurfuerspam.de (Markus Dolze) Date: Mon, 22 Dec 2008 00:17:32 +0100 Subject: [Lcdproc] hd44780 display update timing Message-ID: <20081221231732.230080@gmx.net> Hi, a few weeks ago I got an old Matrix Orbital and was impressed by its screen update speed. During the last days I was also working on some parallel port bidirectional programming and so I tried to implement checking HD44780 controller's busy flag by using read mode. But first I needed some time measurement. So I added a few lines to check how long a hd44780_flush() takes to update a screen. It is based on getimeofday and may be inaccurate, but I took it to start from (attached as patch-hd44780-timing.c). Here are some interesting results: 1. A plain unmodified hd44780-winamp 16x2 connected display with no extra delays: ==== HD44780: flushed 32 chars (4 moves) in 0.719918 sec (startup screen) HD44780: flushed 28 chars (6 moves) in 0.673611 sec (server screen) HD44780: flushed 10 chars (2 moves) in 0.239884 sec (scrolling title) 2. The same unmodified hd44780-winamp with 'delaybus=true' ==== HD44780: flushed 32 chars (4 moves) in 2.159951 sec HD44780: flushed 28 chars (6 moves) in 2.034169 sec HD44780: flushed 32 chars (4 moves) in 2.159911 sec HD44780: flushed 10 chars (2 moves) in 0.719928 sec Adding delaybus slows down things a lot more than I expected and even without, it takes nearly 3/4 second to update a complete 16x2 screen! Then I implemented some code using bidirectional communication for the hd44780-winamp (attached as patch-hd44780-bidirectional.c). It works well at first sight, but suffers from some characters in the scrolling title beeing incorrectly updated. Therefore I had to add 'RefreshDisplay=10' to the config. If you want to try that patch, please make sure that your parallel port supports bidirectional aka PS/2 mode. It will most likely not work with the parallel port set to EPP or ECP mode. If you port is not configured correctly there is a risk to damage your parallel port! The patch is purely experimental. Use at your own risk! 3. Results with bidirectional communication patch ==== HD44780: flushed 32 chars (4 moves) in 0.399964 sec HD44780: flushed 28 chars (6 moves) in 0.393933 sec HD44780: flushed 10 chars (2 moves) in 0.139749 sec Screen update times decrease by 40% although the nanosleeps used have been decreased from 40 usec to 0.250 usec! At last I added the checkbf() function introduced in the previous step to hd44780-lcd2usb. Lcd2usb does not support checking for a the busy flag by LCDd, but it does not seem to need any delays at all! It worked fine without. 4. Results with hd44780-lcd2usb 16x2 (no delays in checkbf()) ==== HD44780: flushed 32 chars (4 moves) in 0.107698 sec HD44780: flushed 26 chars (7 moves) in 0.098927 sec HD44780: flushed 10 chars (2 moves) in 0.035973 sec This appears really fast. The screen is nearly "immediately" updated. So at the end I would like to discuss the following points: 1. What are the timings on your system? I use FreeBSD 7.0 on a P4 2GHz. Are the display update times a bad as mine? 2. Would it make sense to have a hardware depended delay function? Something like the checkbf() which maps to uPause by default, but can be overwritten by a driver (like I did in lcd2usb). Regards Markus -------------- next part -------------- 1. A plain unmodified hd44780-winamp connected display with no extra delays: ==== Server running in foreground Listening for queries on 127.0.0.1:13666 HD44780: using ConnectionType: winamp hd44780: Using hd44780_default charmap HD44780: flushed 32 chars (4 moves) in 0.719918 sec Driver [hd44780] loaded Key "Escape" is now reserved exclusively by client [-1] Key "Enter" is now reserved shared by client [-1] Key "Down" is now reserved shared by client [-1] screenlist_switch: switched to screen [_server_screen] HD44780: flushed 28 chars (6 moves) in 0.673611 sec HD44780: flushed 10 chars (2 moves) in 0.239884 sec HD44780: flushed 10 chars (2 moves) in 0.239873 sec HD44780: flushed 10 chars (2 moves) in 0.239634 sec ^CServer shutting down on SIGINT HD44780: flushed 27 chars (7 moves) in 0.677905 sec Closing driver [hd44780] Key "Escape" reserved exclusively by client [-1] and is now released Key "Enter" reserved shared by client [-1] and is now released Key "Down" reserved shared by client [-1] and is now released Exiting. 2. The same unmodified hd44780-winamp with 'delaybus=true' ==== Server running in foreground Listening for queries on 127.0.0.1:13666 HD44780: using ConnectionType: winamp hd44780: Using hd44780_default charmap HD44780: flushed 32 chars (4 moves) in 2.159951 sec Driver [hd44780] loaded Key "Escape" is now reserved exclusively by client [-1] Key "Enter" is now reserved shared by client [-1] Key "Down" is now reserved shared by client [-1] screenlist_switch: switched to screen [_server_screen] HD44780: flushed 28 chars (6 moves) in 2.034169 sec HD44780: flushed 32 chars (4 moves) in 2.159911 sec HD44780: flushed 10 chars (2 moves) in 0.719928 sec HD44780: flushed 10 chars (2 moves) in 0.719818 sec HD44780: flushed 10 chars (2 moves) in 0.719723 sec ^CServer shutting down on SIGINT HD44780: flushed 29 chars (5 moves) in 2.039060 sec Closing driver [hd44780] Key "Escape" reserved exclusively by client [-1] and is now released Key "Enter" reserved shared by client [-1] and is now released Key "Down" reserved shared by client [-1] and is now released Exiting. 3. Results with bidirectional communication patch ==== Server running in foreground Listening for queries on 127.0.0.1:13666 HD44780: using ConnectionType: winamp hd44780: Using hd44780_default charmap HD44780: flushed 32 chars (4 moves) in 0.399964 sec Driver [hd44780] loaded Key "Escape" is now reserved exclusively by client [-1] Key "Enter" is now reserved shared by client [-1] Key "Down" is now reserved shared by client [-1] screenlist_switch: switched to screen [_server_screen] HD44780: flushed 28 chars (6 moves) in 0.393933 sec HD44780: flushed 10 chars (2 moves) in 0.139749 sec HD44780: flushed 10 chars (2 moves) in 0.139834 sec HD44780: flushed 10 chars (2 moves) in 0.139882 sec ^CServer shutting down on SIGINT HD44780: flushed 27 chars (7 moves) in 0.403233 sec Closing driver [hd44780] Key "Escape" reserved exclusively by client [-1] and is now released Key "Enter" reserved shared by client [-1] and is now released Key "Down" reserved shared by client [-1] and is now released Exiting. 4. Results with hd44780-lcd2usb 16x2 (no delays in checkbf()) ==== Server running in foreground Listening for queries on 127.0.0.1:13666 HD44780: using ConnectionType: lcd2usb HD44780: Direct key 0: "Enter" HD44780: Direct key 1: "Down" HD44780: Direct key 2: "Escape" hd44780: Using hd44780_default charmap hd_init_lcd2usb: device with firmware version 1.08 found HD44780: flushed 32 chars (4 moves) in 0.107698 sec Driver [hd44780] loaded Key "Escape" is now reserved exclusively by client [-1] Key "Enter" is now reserved shared by client [-1] Key "Down" is now reserved shared by client [-1] screenlist_switch: switched to screen [_server_screen] HD44780: flushed 26 chars (7 moves) in 0.098927 sec HD44780: flushed 10 chars (2 moves) in 0.035973 sec HD44780: flushed 10 chars (2 moves) in 0.035961 sec HD44780: flushed 10 chars (2 moves) in 0.035975 sec ^CServer shutting down on SIGINT HD44780: flushed 27 chars (7 moves) in 0.102056 sec Closing driver [hd44780] Key "Escape" reserved exclusively by client [-1] and is now released Key "Enter" reserved shared by client [-1] and is now released Key "Down" reserved shared by client [-1] and is now released Exiting. -------------- next part -------------- A non-text attachment was scrubbed... Name: patch-hd44780-bidirectional.c Type: application/octet-stream Size: 6832 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: patch-hd44780-timing.c Type: application/octet-stream Size: 1399 bytes Desc: not available URL: From peter at adpm.de Mon Dec 22 12:05:47 2008 From: peter at adpm.de (Peter Marschall) Date: Mon, 22 Dec 2008 13:05:47 +0100 Subject: [Lcdproc] How to handle separate icon area on LCD/VFD glass In-Reply-To: <1229592232.5397.87.camel@TangoLinux.lan> References: <1229592232.5397.87.camel@TangoLinux.lan> Message-ID: <200812221305.47461.peter@adpm.de> Hi Arthur, On Thursday, 18. December 2008, Arthur van Dongen wrote: > I searched the net for the best way to implement icons, but the > contributions are either focused on LEDs attached to a small number of > GPIO ports of the display, or drawing custom characters on the LCD dot > matrix. The current drivers for MD8800 and ShuttleVFD already attempt to > support the icons, but implement the other interface. LCDproc currently supports icon widgets. These widgets can be placed on the display inside the "regular" display area (i.e. at specific positions among the text). This is one of the core features of LCDproc, used by other features, and cannot easily be replaced. So, the "icon" widget is out of reach for your ideas. > Currently both implementations do not fulfill the (my) requirements, and > I see the need for an extension to the protocols. Back to the drawing > table.... Let me play devil's advocate, and ask questions, bring counter-arguments, ... ;-) > Requirements > ============ > * Device-independent interface from client to server. If a client wants > to light the "Play" light on the display, it does not need to know if it > is implemented by a GPIO output attached to a LED or by a triangular LCD > segment somewehere on the glass. This is only true, if e.g. the PLAY icon is not required to be at a specific position. You assume the icon is always context free. How can programmers of clients know what external icons are available and where they are placed in relation to the regular text. > * Extensible. If a new LCD or VFD display appears that has a new set of > icons, it should not require much effort to add support. What about displays that do not support such external icons ? Shall the clients on those displays leave e.g. the last line empty ? > * Special handling of grouped segments. For example, both VFDs have a > "Volume" region, with different number of bars. The client can be hidden > from this detail by allowing a "volume 50%" command. Hmm, this is much more than an a simple icon. It > * Queryable. A client can request whether an "Envelope" icon is > supported by the device, and decide to display a "New mail" text based > on the result of this request. Here I concur in principle. But to make the interface generic you need to standardize on names and properties for these new icons/widgets. Only with a standardized set of these widgets and their properties clients can be written that support more than one specific display. > * Separate control of the icons. One client can control the "Play" icon, > and another can control the "Envelope" icon. > * Combined control of icons. Switching from "FF" to "Play" icon should > be possible in a single command. There is no sense in controlling these > from different clients. > * Efficiency. The list of all icon names can only grow, and searching > for an icon in the list should not take too long. Grouping? > * Flexibility in defining combined icons. For example an icon set for > the video source can contain "TV" and "Film" on one device and "DVB-T", > "Sat", "MPEG", "DivX", "unknown-codec-of-the-future" icons on another. > > Design outline > ============== > Client-Server interface > ----------------------- > Example: > screen_add scrn0 > widget_add scrn0 iconWidget icon > widget_set scrn0 iconWidget 0 0 PLAYMODE.FF > widget_set scrn0 iconWidget 0 0 MAIL.OFF > widget_set scrn0 iconWidget 0 0 VIDSRC.TV > widget_set scrn0 iconWidget 0 0 VIDSRC.TV_Sat > > Server-Device API > ----------------- > _icon(Driver *drvthis, const char iconDef[]); Please don't force the individual drivers to interpret text. This is up to the server core so that it can be done once (and correctly). What about the query function ? > When using icon names of the form GROUP.SELECTION and passing this > unaltered to the driver, the driver can then decide what to do with it. > I do not know how the screen priorities affect this, when multiple > clients set icons on the same location. > The driver should split the GROUP from the SELECTION and parse these. If > they are known the driver can turn on the right segments in the group, > and otherwise revert to a default. Using partial matching, like the TV > and TV_SAT selection, the driver can revert to a more common icon. Drivers have no notion of clients & client screens, so doing the grouping in the driver cannot work. BTW how do screen changes (every x seconds) interact with the extended icons? > So what do you experts think? Am I heading in the right direction? > > Thanks for any corrections, ideas, directions, eye openers and other > info ;-) As I wrote above, changing the icon widget is not possible. Changing the protocol will also not happen inside the 0.5 series. I can understand your pain, but from a "harmonization" point of view, I consider the extended icons on the different displays too different to be able to get a common system. So, for the short term I suggest using the output command to get the icons. Regards Peter -- Peter Marschall peter at adpm.de From herdler at gmx.de Tue Dec 23 02:46:39 2008 From: herdler at gmx.de (Stefan Herdler) Date: Tue, 23 Dec 2008 03:46:39 +0100 Subject: [Lcdproc] How to handle separate icon area on LCD/VFD glass In-Reply-To: <1229592232.5397.87.camel@TangoLinux.lan> References: <1229592232.5397.87.camel@TangoLinux.lan> Message-ID: <4950510F.4050504@gmx.de> Hi Arthur, Arthur van Dongen wrote: > Hi all, > > (I already sent a similar post to this list, but this one is further > developed. Please ignore the previous one.) > > I have both a Medion MD8800 VFD and a Shuttle with VFD. Drivers within > LCDproc exist for both displays. I want to control the icons from > mythtv. For a better understanding of what I mean with these icons, here > are two links to pages with photos of the displays in action: > http://jeremy.infogami.com/SetVFD > http://www.martinm-76.dk/md8800/LCD/md8800-lcd.jpg > > I searched the net for the best way to implement icons, but the > contributions are either focused on LEDs attached to a small number of > GPIO ports of the display, or drawing custom characters on the LCD dot > matrix. The current drivers for MD8800 and ShuttleVFD already attempt to > support the icons, but implement the other interface. > Interface? I just (mis)used the output command to push the display specific commands trough the LCDd ;-) . > Currently both implementations do not fulfill the (my) requirements, and > I see the need for an extension to the protocols. Back to the drawing > table.... > > While writing the MD8800 driver I thought about making a better and more generic solution for the Icons. But at that time it was the only display with such icons I've known, so I dropped that plan. > Requirements > ============ > * Device-independent interface from client to server. If a client wants > to light the "Play" light on the display, it does not need to know if it > is implemented by a GPIO output attached to a LED or by a triangular LCD > segment somewehere on the glass. > * Extensible. If a new LCD or VFD display appears that has a new set of > icons, it should not require much effort to add support. > * Special handling of grouped segments. For example, both VFDs have a > "Volume" region, with different number of bars. The client can be hidden > from this detail by allowing a "volume 50%" command. > * Queryable. A client can request whether an "Envelope" icon is > supported by the device, and decide to display a "New mail" text based > on the result of this request. > The icon should indicate a event independent to the screen shown. Having a icon setup of every client doesn't make much sense to me. I think one global icon setting is enough too. Having only one (global) icon setup will make the implementation much easier. The LCDd just had to hand over the request to the displaydriver. The complete icon handling can be done in the driver that is most flexible and "future proof" way I think. > * Separate control of the icons. One client can control the "Play" icon, > and another can control the "Envelope" icon. > * Combined control of icons. Switching from "FF" to "Play" icon should > be possible in a single command. There is no sense in controlling these > from different clients. > * Efficiency. The list of all icon names can only grow, and searching > for an icon in the list should not take too long. Grouping? > * Flexibility in defining combined icons. For example an icon set for > the video source can contain "TV" and "Film" on one device and "DVB-T", > "Sat", "MPEG", "DivX", "unknown-codec-of-the-future" icons on another. > > Design outline > ============== > Client-Server interface > ----------------------- > Example: > screen_add scrn0 > widget_add scrn0 iconWidget icon > widget_set scrn0 iconWidget 0 0 PLAYMODE.FF > widget_set scrn0 iconWidget 0 0 MAIL.OFF > widget_set scrn0 iconWidget 0 0 VIDSRC.TV > widget_set scrn0 iconWidget 0 0 VIDSRC.TV_Sat > > Server-Device API > ----------------- > _icon(Driver *drvthis, const char iconDef[]); > The client interface I had in mind has 3 functions: - icon_info shows the supported icons and their possible values. Example of the return value: "icons: DVD:on,off,animate Mail:on,off,animate Volume:percent,off State:stop,play,rec,ff,fr,pause ..." "DVD" and "Mail" are "normal" icons. "animate" means "blinking" or highlighting in a other way. "Volume" is an example of a bargraph and "State" of the playstate-indicator I think we should define some "standard" icons which should be preferred by client and driver, but individual icons could be defined as well. -icon_set Sets the value of one or more icons. Example: icon_set DVD:on State:play Volume:57 -icon_get can be used to retrieve the state of a icon. Example: icon_get DVD Volume -> Icon_state: DVD:on Volume:57 All the icon states would be global, so there is no need to define a screen or position of the icon I think. Every client could change the state every icon. The allocation of the icons will be up to the configuration of clients. > When using icon names of the form GROUP.SELECTION and passing this > unaltered to the driver, the driver can then decide what to do with it. > I do not know how the screen priorities affect this, when multiple > clients set icons on the same location. > The driver should split the GROUP from the SELECTION and parse these. If > they are known the driver can turn on the right segments in the group, > and otherwise revert to a default. Using partial matching, like the TV > and TV_SAT selection, the driver can revert to a more common icon. > > So what do you experts think? Am I heading in the right direction? > Definitely the right direction, I think! Client programmer will appreciate a common way to control the icons. And the display owner would be happy if more clients would be able to control the Icons. > Thanks for any corrections, ideas, directions, eye openers and other > info ;-) > > Arthur > > ------------------------------------------------------------------------ > > _______________________________________________ > LCDproc mailing list > LCDproc at lists.omnipotent.net > http://lists.omnipotent.net/mailman/listinfo/lcdproc > regards Stefan p.s. I don't own a display with icons, but if you need help modifying the MD8800 driver may contact me. It's a long time since I've written the driver, but I will see what I can do ;-) . From bsdfan at nurfuerspam.de Tue Dec 23 14:49:38 2008 From: bsdfan at nurfuerspam.de (Markus Dolze) Date: Tue, 23 Dec 2008 15:49:38 +0100 Subject: [Lcdproc] hd44780 display update timing Message-ID: <20081223144938.183220@gmx.net> Hello, I tought I had submitted this mail on Sunday evening - but as it has not yet arrived here it comes again: a few weeks ago I got an old Matrix Orbital device and was impressed by the screen update speed. So I took a look at the hd44780 driver I use with parallel port and lcd2usb devices. I first added some time measurement code around the 'flush()' call (attached as patch-hd44780-timing.c). After applying the patch run LCDd with '-s false -r 4 -f' All tests are done using a 16x2 display. OS is FreeBSD 7.0, timing is default DELAY_NANOSLEEP. Here are some results: 1. A unmodified hd44780-winamp connected display with no extra delays: ==== HD44780: flushed 32 chars (4 moves) in 0.719918 sec HD44780: flushed 28 chars (6 moves) in 0.673611 sec HD44780: flushed 10 chars (2 moves) in 0.239884 sec 2. The same hd44780-winamp with 'delaybus=true' ==== HD44780: flushed 32 chars (4 moves) in 2.159951 sec HD44780: flushed 28 chars (6 moves) in 2.034169 sec HD44780: flushed 32 chars (4 moves) in 2.159911 sec The first thing to note is that it takes about 3/4 second to update a complete 16x2 screen. The second is that adding 'delaybus=true' slows down things far more than I expected. I had a look how other implementations do this and found that ethlcd and uss720 overwrite the uPause locally. I did this for the lcd2usb device as well and the results are really nice (the patch will be submitted sperately). 3. Results with modified hd44780-lcd2usb ==== HD44780: flushed 32 chars (4 moves) in 0.107890 sec HD44780: flushed 26 chars (7 moves) in 0.098938 sec HD44780: flushed 10 chars (2 moves) in 0.035978 sec It would be nice if someone with an hd44780-winamp connected display could do the same test on a different OS to see if the slow timing is specific to FreeBSD. Regards Markus -------------- next part -------------- A non-text attachment was scrubbed... Name: patch-hd44780-timing.c Type: application/octet-stream Size: 1399 bytes Desc: not available URL: -------------- next part -------------- 1. A plain unmodified hd44780-winamp connected display with no extra delays: ==== Server running in foreground Listening for queries on 127.0.0.1:13666 HD44780: using ConnectionType: winamp hd44780: Using hd44780_default charmap HD44780: flushed 32 chars (4 moves) in 0.719918 sec Driver [hd44780] loaded Key "Escape" is now reserved exclusively by client [-1] Key "Enter" is now reserved shared by client [-1] Key "Down" is now reserved shared by client [-1] screenlist_switch: switched to screen [_server_screen] HD44780: flushed 28 chars (6 moves) in 0.673611 sec HD44780: flushed 10 chars (2 moves) in 0.239884 sec HD44780: flushed 10 chars (2 moves) in 0.239873 sec HD44780: flushed 10 chars (2 moves) in 0.239634 sec ^CServer shutting down on SIGINT HD44780: flushed 27 chars (7 moves) in 0.677905 sec Closing driver [hd44780] Key "Escape" reserved exclusively by client [-1] and is now released Key "Enter" reserved shared by client [-1] and is now released Key "Down" reserved shared by client [-1] and is now released Exiting. 2. The same unmodified hd44780-winamp with 'delaybus=true' ==== Server running in foreground Listening for queries on 127.0.0.1:13666 HD44780: using ConnectionType: winamp hd44780: Using hd44780_default charmap HD44780: flushed 32 chars (4 moves) in 2.159951 sec Driver [hd44780] loaded Key "Escape" is now reserved exclusively by client [-1] Key "Enter" is now reserved shared by client [-1] Key "Down" is now reserved shared by client [-1] screenlist_switch: switched to screen [_server_screen] HD44780: flushed 28 chars (6 moves) in 2.034169 sec HD44780: flushed 32 chars (4 moves) in 2.159911 sec HD44780: flushed 10 chars (2 moves) in 0.719928 sec HD44780: flushed 10 chars (2 moves) in 0.719818 sec HD44780: flushed 10 chars (2 moves) in 0.719723 sec ^CServer shutting down on SIGINT HD44780: flushed 29 chars (5 moves) in 2.039060 sec Closing driver [hd44780] Key "Escape" reserved exclusively by client [-1] and is now released Key "Enter" reserved shared by client [-1] and is now released Key "Down" reserved shared by client [-1] and is now released Exiting. 3. Results with modified hd44780-lcd2usb ==== Server running in foreground Listening for queries on 127.0.0.1:13666 HD44780: using ConnectionType: lcd2usb HD44780: Direct key 0: "Enter" HD44780: Direct key 1: "Down" HD44780: Direct key 2: "Escape" hd44780: Using hd44780_default charmap hd_init_lcd2usb: device with firmware version 1.08 found HD44780: flushed 32 chars (4 moves) in 0.107890 sec Driver [hd44780] loaded Key "Escape" is now reserved exclusively by client [-1] Key "Enter" is now reserved shared by client [-1] Key "Down" is now reserved shared by client [-1] screenlist_switch: switched to screen [_server_screen] HD44780: flushed 26 chars (7 moves) in 0.098938 sec HD44780: flushed 10 chars (2 moves) in 0.035978 sec ^CServer shutting down on SIGINT HD44780: flushed 27 chars (7 moves) in 0.101212 sec Closing driver [hd44780] Key "Escape" reserved exclusively by client [-1] and is now released Key "Enter" reserved shared by client [-1] and is now released Key "Down" reserved shared by client [-1] and is now released Exiting. From avdongen at xs4all.nl Tue Dec 23 15:56:30 2008 From: avdongen at xs4all.nl (Arthur van Dongen) Date: Tue, 23 Dec 2008 16:56:30 +0100 Subject: [Lcdproc] How to handle separate icon area on LCD/VFD glass Message-ID: <1230047790.5274.17.camel@TangoLinux.lan> Hi Stefan and others on this list, Thanks for your reply. -------- Forwarded Message -------- > From: Stefan Herdler > To: Arthur van Dongen > Cc: lcdproc at lists.omnipotent.net > Subject: Re: [Lcdproc] How to handle separate icon area on LCD/VFD > glass > Date: Tue, 23 Dec 2008 03:46:39 +0100 > > Hi Arthur, > > Arthur van Dongen wrote: > > Hi all, > > > > (I already sent a similar post to this list, but this one is further > > developed. Please ignore the previous one.) > > > > I have both a Medion MD8800 VFD and a Shuttle with VFD. Drivers within > > LCDproc exist for both displays. I want to control the icons from > > mythtv. For a better understanding of what I mean with these icons, here > > are two links to pages with photos of the displays in action: > > http://jeremy.infogami.com/SetVFD > > http://www.martinm-76.dk/md8800/LCD/md8800-lcd.jpg > > > > I searched the net for the best way to implement icons, but the > > contributions are either focused on LEDs attached to a small number of > > GPIO ports of the display, or drawing custom characters on the LCD dot > > matrix. The current drivers for MD8800 and ShuttleVFD already attempt to > > support the icons, but implement the other interface. > > > Interface? > I just (mis)used the output command to push the display specific > commands trough the LCDd ;-) . > > Currently both implementations do not fulfill the (my) requirements, and > > I see the need for an extension to the protocols. Back to the drawing > > table.... > > > > > While writing the MD8800 driver I thought about making a better and more > generic solution for the Icons. > But at that time it was the only display with such icons I've known, so > I dropped that plan. > > Requirements > > ============ > > * Device-independent interface from client to server. If a client wants > > to light the "Play" light on the display, it does not need to know if it > > is implemented by a GPIO output attached to a LED or by a triangular LCD > > segment somewehere on the glass. > > * Extensible. If a new LCD or VFD display appears that has a new set of > > icons, it should not require much effort to add support. > > * Special handling of grouped segments. For example, both VFDs have a > > "Volume" region, with different number of bars. The client can be hidden > > from this detail by allowing a "volume 50%" command. > > * Queryable. A client can request whether an "Envelope" icon is > > supported by the device, and decide to display a "New mail" text based > > on the result of this request. > > > The icon should indicate a event independent to the screen shown. > Having a icon setup of every client doesn't make much sense to me. > I think one global icon setting is enough too. > > Having only one (global) icon setup will make the implementation much > easier. The LCDd just had to hand over the request to the displaydriver. > The complete icon handling can be done in the driver that is most > flexible and "future proof" way I think. > > * Separate control of the icons. One client can control the "Play" icon, > > and another can control the "Envelope" icon. > > * Combined control of icons. Switching from "FF" to "Play" icon should > > be possible in a single command. There is no sense in controlling these > > from different clients. > > * Efficiency. The list of all icon names can only grow, and searching > > for an icon in the list should not take too long. Grouping? > > * Flexibility in defining combined icons. For example an icon set for > > the video source can contain "TV" and "Film" on one device and "DVB-T", > > "Sat", "MPEG", "DivX", "unknown-codec-of-the-future" icons on another. > > > > Design outline > > ============== > > Client-Server interface > > ----------------------- > > Example: > > screen_add scrn0 > > widget_add scrn0 iconWidget icon > > widget_set scrn0 iconWidget 0 0 PLAYMODE.FF > > widget_set scrn0 iconWidget 0 0 MAIL.OFF > > widget_set scrn0 iconWidget 0 0 VIDSRC.TV > > widget_set scrn0 iconWidget 0 0 VIDSRC.TV_Sat > > > > Server-Device API > > ----------------- > > _icon(Driver *drvthis, const char iconDef[]); > > > The client interface I had in mind has 3 functions: > > - icon_info > shows the supported icons and their possible values. > Example of the return value: > "icons: DVD:on,off,animate Mail:on,off,animate Volume:percent,off > State:stop,play,rec,ff,fr,pause ..." > > "DVD" and "Mail" are "normal" icons. "animate" means "blinking" or > highlighting in a other way. > "Volume" is an example of a bargraph and "State" of the playstate-indicator > I think we should define some "standard" icons which should be preferred > by client and driver, but individual icons could be defined as well. To avoid a mess of similar but slightly different names, there should indeed be a list of common names. The names should be descriptive, so "State" is not a good candidate IMO. What about the naming of the functions? The "DRIVER_icon()" function name is already in use. Is DRIVER_namedicon_set() a good choice? Or use "DRIVER_icon_info" like in your example and risk confusion with the current DRIVER_icon() function? > > -icon_set > Sets the value of one or more icons. > Example: > icon_set DVD:on State:play Volume:57 > > -icon_get > can be used to retrieve the state of a icon. > Example: > icon_get DVD Volume > -> > Icon_state: DVD:on Volume:57 > > All the icon states would be global, so there is no need to define a > screen or position of the icon I think. > Every client could change the state every icon. > The allocation of the icons will be up to the configuration of clients. I agree with your suggestion to make it global, instead of screen-oriented. What should happen if a client disconnects? Should the server remember the icons that are set by this client, and clear them? And what if two clients set the same group? The last one sets it and the earlier setting is lost? > > When using icon names of the form GROUP.SELECTION and passing this > > unaltered to the driver, the driver can then decide what to do with it. > > I do not know how the screen priorities affect this, when multiple > > clients set icons on the same location. > > The driver should split the GROUP from the SELECTION and parse these. If > > they are known the driver can turn on the right segments in the group, > > and otherwise revert to a default. Using partial matching, like the TV > > and TV_SAT selection, the driver can revert to a more common icon. > > > > So what do you experts think? Am I heading in the right direction? > > > Definitely the right direction, I think! > > Client programmer will appreciate a common way to control the icons. > And the display owner would be happy if more clients would be able to > control the Icons. > > Thanks for any corrections, ideas, directions, eye openers and other > > info ;-) > > > > Arthur > > > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > LCDproc mailing list > > LCDproc at lists.omnipotent.net > > http://lists.omnipotent.net/mailman/listinfo/lcdproc > > > regards > Stefan > > p.s. > I don't own a display with icons, but if you need help modifying the > MD8800 driver may contact me. > It's a long time since I've written the driver, but I will see what I > can do ;-) . -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From avdongen at xs4all.nl Wed Dec 24 00:15:50 2008 From: avdongen at xs4all.nl (Arthur van Dongen) Date: Wed, 24 Dec 2008 01:15:50 +0100 Subject: [Lcdproc] [PATCH] Icon support on MD8800 VFD Message-ID: <1230077750.5274.29.camel@TangoLinux.lan> Hi Stefan, hi all, I created a patch to support the icons on the MD8800 VFD, for more info see earlier in the lcdproc mailing list. The diff is based on the CVS trunk, synced last week. The icons can be controlled by issuing a "namedicon_set . command, for example "namedicon_set PLAYMODE.STOP". The current status can be queried by issuing a "namedicon_get {ALL|}" command, the list of possible values with "namedicon_info". Please have a look at the patch and send me any feedback. If all is OK, I will implement the same functions for my ShuttleVFD display, and try to control these icons from MythTV. Best regards, Arthur van Dongen -------------- next part -------------- ? .cdtproject ? .project ? .settings ? LDCd_test.conf ? cvsdiff.out ? clients/.cdtproject ? clients/.project ? clients/.settings ? docs/LCDd.8 ? docs/lcdproc-config.5 ? docs/lcdproc.1 ? docs/lcdproc-dev/README.tex ? docs/lcdproc-dev/a1960.html ? docs/lcdproc-dev/add-your-driver.tex ? docs/lcdproc-dev/bookinfo.tex ? docs/lcdproc-dev/c1245.html ? docs/lcdproc-dev/c150.html ? docs/lcdproc-dev/c1608.html ? docs/lcdproc-dev/c1707.html ? docs/lcdproc-dev/c35.html ? docs/lcdproc-dev/c47.html ? docs/lcdproc-dev/driver-api.tex ? docs/lcdproc-dev/introduction.tex ? docs/lcdproc-dev/language.tex ? docs/lcdproc-dev/lcdproc-dev.tex ? docs/lcdproc-dev/license.tex ? docs/lcdproc-dev/make-driver.tex ? docs/lcdproc-dev/shared-files.tex ? docs/lcdproc-dev/x11.html ? docs/lcdproc-dev/x114.html ? docs/lcdproc-dev/x1158.html ? docs/lcdproc-dev/x12.html ? docs/lcdproc-dev/x1255.html ? docs/lcdproc-dev/x1266.html ? docs/lcdproc-dev/x155.html ? docs/lcdproc-dev/x161.html ? docs/lcdproc-dev/x1614.html ? docs/lcdproc-dev/x1669.html ? docs/lcdproc-dev/x1713.html ? docs/lcdproc-dev/x1970.html ? docs/lcdproc-dev/x1980.html ? docs/lcdproc-dev/x1984.html ? docs/lcdproc-dev/x1990.html ? docs/lcdproc-dev/x2026.html ? docs/lcdproc-dev/x2031.html ? docs/lcdproc-dev/x2035.html ? docs/lcdproc-dev/x2039.html ? docs/lcdproc-dev/x2042.html ? docs/lcdproc-dev/x2045.html ? docs/lcdproc-dev/x2050.html ? docs/lcdproc-dev/x21.html ? docs/lcdproc-dev/x22.html ? docs/lcdproc-dev/x25.html ? docs/lcdproc-dev/x31.html ? docs/lcdproc-dev/x52.html ? docs/lcdproc-dev/x6.html ? docs/lcdproc-dev/x62.html ? docs/lcdproc-dev/x67.html ? docs/lcdproc-dev/x68.html ? docs/lcdproc-dev/x7.html ? docs/lcdproc-dev/x72.html ? docs/lcdproc-dev/x76.html ? docs/lcdproc-dev/x80.html ? docs/lcdproc-dev/x83.html ? docs/lcdproc-dev/x86.html ? docs/lcdproc-dev/x91.html ? docs/lcdproc-dev/x962.html ? scripts/init-LCDd.LSB ? scripts/init-lcdexec.LSB ? scripts/init-lcdexec.debian ? scripts/init-lcdproc.LSB ? scripts/init-lcdvc.LSB ? scripts/init-lcdvc.debian ? server/.cdtproject ? server/.project ? server/.settings Index: server/driver.c =================================================================== RCS file: /cvsroot/lcdproc/lcdproc/server/driver.c,v retrieving revision 1.21 diff -w -u -r1.21 driver.c --- server/driver.c 14 Dec 2008 23:38:42 -0000 1.21 +++ server/driver.c 24 Dec 2008 00:02:59 -0000 @@ -76,6 +76,9 @@ { "output", offsetof(Driver, output), 0 }, { "get_key", offsetof(Driver, get_key), 0 }, { "get_info", offsetof(Driver, get_info), 0 }, + { "namedicon_set", offsetof(Driver, namedicon_set), 0 }, + { "namedicon_get", offsetof(Driver, namedicon_get), 0 }, + { "namedicon_info", offsetof(Driver, namedicon_info), 0 }, { NULL, 0, 0 } }; @@ -654,7 +657,6 @@ drv->chr(drv, x+1, y, ch2); } - /** Set cursor position and state. * Fallback for the driver's \c cursor method if the driver does not provide one. * \param drv Pointer to driver structure. Index: server/drivers.c =================================================================== RCS file: /cvsroot/lcdproc/lcdproc/server/drivers.c,v retrieving revision 1.23 diff -w -u -r1.23 drivers.c --- server/drivers.c 30 Nov 2008 22:31:20 -0000 1.23 +++ server/drivers.c 24 Dec 2008 00:02:59 -0000 @@ -388,8 +388,111 @@ } } +/** + * Write named icon to all drivers. + * For drivers that define a namedicon_set() function, call it; + * \param icon symbolic value representing the icon. + * \return 0 if OK or first error returned from any driver. + */ +int +drivers_namedicon_set(const char *icon) +{ + Driver *drv; + int retval = 0; + int r = 0; + debug(RPT_DEBUG, "%s(icon=%s)", __FUNCTION__, icon); + + ForAllDrivers(drv) { + /* Does the driver have the icon function ? */ + if (drv->namedicon_set) { + /* Try driver call */ + r = drv->namedicon_set(drv, icon); + if (retval == 0) + retval = r; + } + } + return retval; // 0 if OK or first error returned from any driver +} /** + * Get icon state from all drivers for a specified icon group. + * For drivers that define a namedicon() function, call it; + * \param icon symbolic value representing the icon. + * \return pointer to allocated buffer with the text describing the icon state. + * Buffer must be freed by the caller! + */ +const char * +drivers_namedicon_get(const char *icon) +{ + Driver *drv; + char *retval = NULL; + const char *newretval = NULL; + debug(RPT_DEBUG, "%s(icon=%s)", __FUNCTION__, icon); + + ForAllDrivers(drv) { + /* Does the driver have the icon function ? */ + if (drv->namedicon_get) { + /* Try driver call */ + newretval = drv->namedicon_get(drv, icon); + if (newretval != NULL) + { + if (retval != NULL) // not the first + { + retval = realloc(retval, strlen(retval)+strlen(newretval)+1); + strcat(retval, newretval); + free(newretval); + } + else + { + retval = malloc(strlen(newretval)+1); + strcpy(retval, newretval); + free(newretval); + } + } + } + } + return retval; +} + +/** + * Write named icon to all drivers. + * For drivers that define a namedicon_info() function, call it; + * \return pointer to allocated buffer with the text describing the possible icon states. + * Buffer must be freed by the caller! + */ +const char * +drivers_namedicon_info(void) +{ + Driver *drv; + char *retval = NULL; + const char *newretval = NULL; + debug(RPT_DEBUG, "%s()", __FUNCTION__); + + ForAllDrivers(drv) { + /* Does the driver have the icon function ? */ + if (drv->namedicon_info) { + /* Try driver call */ + newretval = drv->namedicon_info(drv); + if (newretval != NULL) + { + if (retval != NULL) // not the first + { + retval = realloc(retval, strlen(retval)+strlen(newretval)+1); + strcat(retval, newretval); + free(newretval); + } + else + { + retval = malloc(strlen(newretval)+1); + strcpy(retval, newretval); + free(newretval); + } + } + } + } + return retval; +} +/** * Set cursor on all loaded drivers. * For drivers that define a cursor() function, call it; * otherwise call the general driver_alt_cursor() function from the server core. Index: server/drivers.h =================================================================== RCS file: /cvsroot/lcdproc/lcdproc/server/drivers.h,v retrieving revision 1.13 diff -w -u -r1.13 drivers.h --- server/drivers.h 30 Nov 2008 22:31:20 -0000 1.13 +++ server/drivers.h 24 Dec 2008 00:02:59 -0000 @@ -80,6 +80,15 @@ void drivers_backlight(int brightness); +int +drivers_namedicon_set(const char *icon); + +const char * +drivers_namedicon_get(const char *icon); + +const char * +drivers_namedicon_info(void); + void drivers_output(int state); Index: server/widget.h =================================================================== RCS file: /cvsroot/lcdproc/lcdproc/server/widget.h,v retrieving revision 1.16 diff -w -u -r1.16 widget.h Index: server/commands/client_commands.c =================================================================== RCS file: /cvsroot/lcdproc/lcdproc/server/commands/client_commands.c,v retrieving revision 1.12 diff -w -u -r1.12 client_commands.c --- server/commands/client_commands.c 30 Nov 2008 22:42:34 -0000 1.12 +++ server/commands/client_commands.c 24 Dec 2008 00:03:00 -0000 @@ -268,6 +268,85 @@ } +/******************************************************************************* + * namedicon_set_func + * + * Usage: namedicon_set_func ... + */ +int +namedicon_set_func(Client *c, int argc, char **argv) +{ + int i; + int retval = 0; + int r = 0; + if (c->state != ACTIVE) + return 1; + + if (argc < 2) { + sock_send_error(c->sock, "Usage: namedicon_set {ALL.OFF|. [. ...]}\n"); + return 0; + } + for (i = 1; i < argc; i++) + { + r = drivers_namedicon_set(argv[i]); + if (retval == 0) + retval = r; + } + return retval; // return 0 or first error from drivers_namedicon_set() call +} + +/******************************************************************************* + * namedicon_get_func + * + * Usage: namedicon_get_func ... + */ +int +namedicon_get_func(Client *c, int argc, char **argv) +{ + int i; + const char *p; + if (c->state != ACTIVE) + return 1; + + if (argc < 2) { + sock_send_error(c->sock, "Usage: namedicon_get {ALL| [ ...]}\n"); + return 0; + } + for (i = 1; i < argc; i++) + { + p = drivers_namedicon_get(argv[i]); + sock_printf(c->sock, "%s\n", p); + free(p); + } + return 0; +} + +/******************************************************************************* + * namedicon_info_func + * + * Usage: namedicon_info_func ... + */ +int +namedicon_info_func(Client *c, int argc, char **argv) +{ + const char *p; + if (c->state != ACTIVE) + return 1; + + if (argc != 1) { + sock_send_error(c->sock, "Usage: namedicon_info\n"); + return 0; + } + p = drivers_namedicon_info(); + if (p != NULL) + { + sock_printf(c->sock, "%s\n", p); + free(p); + } + return 0; +} + + /**************************************************************************** * info_func * Index: server/commands/client_commands.h =================================================================== RCS file: /cvsroot/lcdproc/lcdproc/server/commands/client_commands.h,v retrieving revision 1.5 diff -w -u -r1.5 client_commands.h --- server/commands/client_commands.h 30 Nov 2008 22:42:34 -0000 1.5 +++ server/commands/client_commands.h 24 Dec 2008 00:03:00 -0000 @@ -20,6 +20,8 @@ int client_add_key_func(Client *c, int argc, char **argv); int client_del_key_func(Client *c, int argc, char **argv); int backlight_func(Client *c, int argc, char **argv); - +int namedicon_set_func(Client *c, int argc, char **argv); +int namedicon_get_func(Client *c, int argc, char **argv); +int namedicon_info_func(Client *c, int argc, char **argv); #endif Index: server/commands/command_list.c =================================================================== RCS file: /cvsroot/lcdproc/lcdproc/server/commands/command_list.c,v retrieving revision 1.8 diff -w -u -r1.8 command_list.c --- server/commands/command_list.c 30 Nov 2008 22:42:34 -0000 1.8 +++ server/commands/command_list.c 24 Dec 2008 00:03:00 -0000 @@ -49,6 +49,9 @@ /* Misc stuff...*/ { "backlight", backlight_func }, { "output", output_func }, + { "namedicon_set", namedicon_set_func }, + { "namedicon_get", namedicon_get_func }, + { "namedicon_info", namedicon_info_func }, { "noop", noop_func }, { "info", info_func }, { "sleep", sleep_func }, Index: server/drivers/MD8800.c =================================================================== RCS file: /cvsroot/lcdproc/lcdproc/server/drivers/MD8800.c,v retrieving revision 1.5 diff -w -u -r1.5 MD8800.c --- server/drivers/MD8800.c 7 Dec 2008 19:41:36 -0000 1.5 +++ server/drivers/MD8800.c 24 Dec 2008 00:03:00 -0000 @@ -1,6 +1,6 @@ /* This is the LCDproc driver for the VFD of the Medion MD8800 PC - Copyright (C) 2006 Stefan Herdler in collaboration with Martin M?. + Copyright (C) 2006 Stefan Herdler in collaboration with Martin M?ller. This source Code is based on the NoritakeVFD, the serialVFD and the CFontzPacket Driver of this package. @@ -25,7 +25,7 @@ ============================================================================== Known hardware-commands of the MD8800 display - discovered by Martin M? (listed in octal notation): + discovered by Martin M?ller (listed in octal notation): \33\0abcdef (abcdef can be anything, it seems) - set clock, I think. The mapping is: bb:aa dd.cc.eeff @@ -176,6 +176,7 @@ #include #include #include +#include #ifdef HAVE_CONFIG_H # include "config.h" @@ -192,6 +193,33 @@ #define DEFAULT_OFF_BRIGHTNESS 300 #define DEFAULT_ON_BRIGHTNESS 1000 +#define PLAYMODE_OFF 0 +#define PLAYMODE_PLAY 1 +#define PLAYMODE_PAUSE 2 +#define PLAYMODE_STOP 3 +#define PLAYMODE_FF 4 +#define PLAYMODE_REW 5 +#define PLAYMODE_HEART 6 +#define PLAYMODE_HEARTOUTLINE 7 + +#define RECORDING_OFF 0 +#define RECORDING_ON 1 + +#define MAIL_OFF 0 +#define MAIL_ENVELOPE 1 +#define MAIL_NEW 2 + +#define MEDIASRC_OFF 0 +#define MEDIASRC_HDD 1 +#define MEDIASRC_1394 2 +#define MEDIASRC_CD 3 +#define MEDIASRC_USB 4 +#define MEDIATYPE_OFF 0 +#define MEDIATYPE_MOVIE 1 +#define MEDIATYPE_TV 2 +#define MEDIATYPE_MUSIC 3 +#define MEDIATYPE_PHOTO 4 + /** private data for the \c MD8800 driver */ typedef struct MD8800_private_data { char device[200]; @@ -209,6 +237,12 @@ int hw_brightness; int last_command; int wifi_scan; + int playmode; + int recording; + int mediasrc; + int mediatype; + int volume; + int mail; char info[255]; } PrivateData; @@ -599,6 +633,510 @@ // Controls the custom icons. // // + +MODULE_EXPORT int +MD8800_namedicon_set (Driver *drvthis, const char *iconName) +{ + PrivateData *p = drvthis->private_data; + + char iconGroup[ICONGROUP_LEN+1]; + char iconGroupMember[ICONGROUPMEMBER_LEN+1]; + int i; + int l = 0; + int retval = 0; + int Switched = 0; + char *dest = iconGroup; + memset(iconGroup, 0, ICONGROUP_LEN+1); + memset(iconGroupMember, 0, ICONGROUPMEMBER_LEN+1); + if (iconName == NULL) + return -1; + for (i=0; iconName[i] != 0; i++) + { + if (!Switched && (iconName[i] == ICONGROUP_MEMBER_SEPARATOR)) + { + dest = iconGroupMember; + l = 0; + } + else + { + *dest++ = iconName[i]; + l++; + if ((!Switched && (l>ICONGROUP_LEN)) || (Switched && (l > ICONGROUPMEMBER_LEN))) + return -1; + } + } + if (strcmp(iconGroup,"PLAYMODE") == 0) + { + if (strcmp(iconGroupMember, "OFF") == 0) + { + p->playmode = PLAYMODE_OFF; + write(p->fd, "\x1B\x31\x00\x00\x00\x00\x00\x00\x00\x00\x00", 11); // turn off play icon + if (p->recording == RECORDING_OFF) + write(p->fd, "\x1B\x30\x1A\x01", 4); // turn off bounding box too + } + else if (strcmp(iconGroupMember, "PLAY") == 0) + { + p->playmode = PLAYMODE_PLAY; + write(p->fd, "\x1B\x30\x1A\x01", 4); // turn on bounding box + write(p->fd, "\x1B\x31\x00\x00\x08\x1C\x3E\x7F\x00\x00\x00", 11); + } + else if (strcmp(iconGroupMember, "STOP") == 0) + { + p->playmode = PLAYMODE_STOP; + write(p->fd, "\x1B\x30\x1A\x01", 4); // turn on bounding box + write(p->fd, "\x1B\x31\x00\x3E\x3E\x3E\x3E\x3E\x00\x00\x00", 11); + } + else if (strcmp(iconGroupMember, "PAUSE") == 0) + { + p->playmode = PLAYMODE_PAUSE; + write(p->fd, "\x1B\x30\x1A\x01", 4); // turn on bounding box + write(p->fd, "\x1B\x31\x00\x3E\x3E\x00\x3E\x3E\x00\x00\x00", 11); + } + else if (strcmp(iconGroupMember, "FF") == 0) + { + p->playmode = PLAYMODE_FF; + write(p->fd, "\x1B\x30\x1A\x01", 4); // turn on bounding box + write(p->fd, "\x1B\x31\x00\x08\x1C\x3E\x08\x1C\x3E\x00\x00", 11); + } + else if (strcmp(iconGroupMember, "REW") == 0) + { + p->playmode = PLAYMODE_REW; + write(p->fd, "\x1B\x30\x1A\x01", 4); // turn on bounding box + write(p->fd, "\x1B\x31\x00\x3E\x1C\x08\x3E\x1C\x08\x00\x00", 11); + } + else if (strcmp(iconGroupMember, "HEART") == 0) + { + p->playmode = PLAYMODE_HEART; + write(p->fd, "\x1B\x30\x1A\x01", 4); // turn on bounding box + write(p->fd, "\x1B\x31\x00\x0C\x1E\x3E\x7C\x3E\x1E\x0C\x00", 11); + } + else if (strcmp(iconGroupMember, "HEARTOUTLINE") == 0) + { + p->playmode = PLAYMODE_HEARTOUTLINE; + write(p->fd, "\x1B\x30\x1A\x01", 4); // turn on bounding box + write(p->fd, "\x1B\x31\x0C\x12\x21\x41\x02\x41\x21\x12\x0C", 11); + } + else + retval = -1; + } + else if (strcmp(iconGroup,"RECORDING") == 0) + { + if (strcmp(iconGroupMember, "ON") == 0) + { + p->recording = RECORDING_ON; + write(p->fd, "\x1B\x30\x1A\x01", 4); // turn on bounding box + write(p->fd, "\x1B\x30\x08", 3); // Turn on REC icon + write(p->fd, &p->hw_brightness, 1); // .. using right brightness level + + } + else if (strcmp(iconGroupMember, "OFF") == 0) + { + p->recording = RECORDING_OFF; + write(p->fd, "\x1B\x30\x08\x00", 4); // turn off rec icon + if (p->playmode == PLAYMODE_OFF) + write(p->fd, "\x1B\x30\x1A\x01", 4); // turn off bounding box too + } + else + retval = -1; + } + else if (strcmp(iconGroup, "VOLUME") == 0) + { + int volumeLevel = -1; + if (strcmp(iconGroupMember, "OFF") == 0) + volumeLevel = -1; + else if (isdigit(iconGroupMember[0])) + { + volumeLevel = iconGroupMember[0] - '0'; + if (isdigit(iconGroupMember[1])) + { + volumeLevel = 10 * volumeLevel + (iconGroupMember[1]-'0'); + if (isdigit(iconGroupMember[2])) + { + volumeLevel = 10 * volumeLevel + (iconGroupMember[2]-'0'); + if (iconGroupMember[3] != 0) + { + volumeLevel = -1; + retval = -1; + } + } + else if (iconGroupMember[2] != 0) + { + volumeLevel = -1; + retval = -1; + } + } + else if (iconGroupMember[1] != 0) + { + volumeLevel = -1; + retval = -1; + } + } + p->volume = volumeLevel; + if (volumeLevel > 100) + { + volumeLevel = -1; + retval = -1; + } + if (volumeLevel >= 0) + write(p->fd, "\x1B\x30\x1C\x01", 4); // bounding box + else + { + write(p->fd, "\x1B\x30\x1C\x00", 4); // bounding box + write(p->fd, "\x1B\x30\x13\x00", 4); // turn off speaker icon + write(p->fd, "\x1B\x30\x14\x00", 4); // turn on muted speaker icon + } + if (volumeLevel == 0) + { + write(p->fd, "\x1B\x30\x13\x00", 4); // turn off speaker icon + write(p->fd, "\x1B\x30\x14\x01", 4); // turn on muted speaker icon + } + if (volumeLevel > 0) + { + write(p->fd, "\x1B\x30\x13\x01", 4); // turn on speaker icon + write(p->fd, "\x1B\x30\x14\x00", 4); // turn off muted speaker icon + } + if (volumeLevel >= 12) + write(p->fd, "\x1B\x30\x0B\x01", 4); + else + write(p->fd, "\x1B\x30\x0B\x00", 4); + if (volumeLevel >= 25) + write(p->fd, "\x1B\x30\x0C\x01", 4); + else + write(p->fd, "\x1B\x30\x0C\x00", 4); + if (volumeLevel >= 37) + write(p->fd, "\x1B\x30\x0D\x01", 4); + else + write(p->fd, "\x1B\x30\x0D\x00", 4); + if (volumeLevel >= 50) + write(p->fd, "\x1B\x30\x0E\x01", 4); + else + write(p->fd, "\x1B\x30\x0E\x00", 4); + if (volumeLevel >= 62) + write(p->fd, "\x1B\x30\x0F\x01", 4); + else + write(p->fd, "\x1B\x30\x0F\x00", 4); + if (volumeLevel >= 75) + write(p->fd, "\x1B\x30\x10\x01", 4); + else + write(p->fd, "\x1B\x30\x10\x00", 4); + if (volumeLevel >= 87) + write(p->fd, "\x1B\x30\x11\x01", 4); + else + write(p->fd, "\x1B\x30\x11\x00", 4); + if (volumeLevel >= 100) + write(p->fd, "\x1B\x30\x12\x01", 4); + else + write(p->fd, "\x1B\x30\x12\x00", 4); + } + else if (strcmp(iconGroup, "MAIL") == 0) + { + if (strcmp(iconGroupMember, "ENVELOPE") == 0) + { + p->mail = MAIL_ENVELOPE; + write(p->fd, "\x1B\x30\x09\x01", 4); + write(p->fd, "\x1B\x30\x0A\x00", 4); + write(p->fd, "\x1B\x30\x1B\x01", 4); // turn on email boundingbox + } + else if (strcmp(iconGroupMember, "NEW") == 0) + { + p->mail = MAIL_NEW; + write(p->fd, "\x1B\x30\x09\x01", 4); + write(p->fd, "\x1B\x30\x0A\x01", 4); + write(p->fd, "\x1B\x30\x1B\x01", 4); // turn on email boundinbox + } + else if (strcmp(iconGroupMember, "OFF") == 0) + { + p->mail = MAIL_OFF; + write(p->fd, "\x1B\x30\x09\x00", 4); + write(p->fd, "\x1B\x30\x0A\x00", 4); + write(p->fd, "\x1B\x30\x1B\x00", 4); // turn off email boundingbox + } + else + { + retval = -1; + } + } + else if (strcmp(iconGroup, "MEDIASRC") == 0) + { + if (strcmp(iconGroupMember, "HDD") == 0) + { + p->mediasrc = MEDIASRC_HDD; + write(p->fd, "\x1B\x30\x00", 3); + write(p->fd, &p->hw_brightness, 1); + write(p->fd, "\x1B\x30\x01\x00", 4); + write(p->fd, "\x1B\x30\x02\x00", 4); + write(p->fd, "\x1B\x30\x03\x00", 4); + write(p->fd, "\x1B\x30\x18\x01", 4); + } + else if (strcmp(iconGroupMember, "1394") == 0) + { + p->mediasrc = MEDIASRC_1394; + write(p->fd, "\x1B\x30\x00\x00", 4); + write(p->fd, "\x1B\x30\x01", 3); + write(p->fd, &p->hw_brightness, 1); + write(p->fd, "\x1B\x30\x02\x00", 4); + write(p->fd, "\x1B\x30\x03\x00", 4); + write(p->fd, "\x1B\x30\x18\x01", 4); + } + else if (strcmp(iconGroupMember, "CD") == 0) + { + p->mediasrc = MEDIASRC_CD; + write(p->fd, "\x1B\x30\x00\x00", 4); + write(p->fd, "\x1B\x30\x01\x00", 4); + write(p->fd, "\x1B\x30\x02", 3); + write(p->fd, &p->hw_brightness, 1); + write(p->fd, "\x1B\x30\x03\x00", 4); + write(p->fd, "\x1B\x30\x18\x01", 4); + } + else if (strcmp(iconGroupMember, "USB") == 0) + { + p->mediasrc = MEDIASRC_USB; + write(p->fd, "\x1B\x30\x00\x00", 4); + write(p->fd, "\x1B\x30\x01\x00", 4); + write(p->fd, "\x1B\x30\x02\x00", 4); + write(p->fd, "\x1B\x30\x03", 3); + write(p->fd, &p->hw_brightness, 1); + write(p->fd, "\x1B\x30\x18\x01", 4); + } + else if (strcmp(iconGroupMember, "OFF") == 0) + { + p->mediasrc = MEDIASRC_OFF; + write(p->fd, "\x1B\x30\x00\x00", 4); + write(p->fd, "\x1B\x30\x01\x00", 4); + write(p->fd, "\x1B\x30\x02\x00", 4); + write(p->fd, "\x1B\x30\x03\x00", 4); + write(p->fd, "\x1B\x30\x18\x00", 4); + } + else + { + retval = -1; + } + } + else if (strcmp(iconGroup, "MEDIATYPE") == 0) + { + if (strcmp(iconGroupMember, "MOVIE") == 0) + { + p->mediatype = MEDIATYPE_MOVIE; + write(p->fd, "\x1B\x30\x04", 3); + write(p->fd, &p->hw_brightness, 1); + write(p->fd, "\x1B\x30\x05\x00", 4); + write(p->fd, "\x1B\x30\x06\x00", 4); + write(p->fd, "\x1B\x30\x07\x00", 4); + write(p->fd, "\x1B\x30\x19\x01", 4); + } + else if (strcmp(iconGroupMember, "TV") == 0) + { + p->mediatype = MEDIATYPE_TV; + write(p->fd, "\x1B\x30\x04\x00", 4); + write(p->fd, "\x1B\x30\x05", 3); + write(p->fd, &p->hw_brightness, 1); + write(p->fd, "\x1B\x30\x06\x00", 4); + write(p->fd, "\x1B\x30\x07\x00", 4); + write(p->fd, "\x1B\x30\x19\x01", 4); + } + else if (strcmp(iconGroupMember, "MUSIC") == 0) + { + p->mediatype = MEDIATYPE_MUSIC; + write(p->fd, "\x1B\x30\x04\x00", 4); + write(p->fd, "\x1B\x30\x05\x00", 4); + write(p->fd, "\x1B\x30\x06", 3); + write(p->fd, &p->hw_brightness, 1); + write(p->fd, "\x1B\x30\x07\x00", 4); + write(p->fd, "\x1B\x30\x19\x01", 4); + } + else if (strcmp(iconGroupMember, "PHOTO") == 0) + { + p->mediatype = MEDIATYPE_PHOTO; + write(p->fd, "\x1B\x30\x04\x00", 4); + write(p->fd, "\x1B\x30\x05\x00", 4); + write(p->fd, "\x1B\x30\x06\x00", 4); + write(p->fd, "\x1B\x30\x07", 3); + write(p->fd, &p->hw_brightness, 1); + write(p->fd, "\x1B\x30\x19\x01", 4); + } + else if (strcmp(iconGroupMember, "OFF") == 0) + { + p->mediatype = MEDIATYPE_OFF; + write(p->fd, "\x1B\x30\x04\x00", 4); + write(p->fd, "\x1B\x30\x05\x00", 4); + write(p->fd, "\x1B\x30\x06\x00", 4); + write(p->fd, "\x1B\x30\x07\x00", 4); + write(p->fd, "\x1B\x30\x19\x00", 4); + } + else + { + retval = -1; + } + } + else + { + retval = -1; + } + return retval; +} + +#define COPY_TO_RETVAL(string) { int temp=strlen(string); if (buflen > temp) { strcpy(dest, string); dest += temp; buflen -= temp; } } +MODULE_EXPORT const char* MD8800_namedicon_get (Driver *drvthis, const char* iconGroup) +{ + PrivateData *p = drvthis->private_data; + int All = 0; + char *retval; + char *dest = NULL; + int buflen; + if (iconGroup == NULL) + return NULL; + if (strcmp(iconGroup,"ALL") == 0) + { + All = 1; + buflen = 93; // maximum for all icongroups + } + else + buflen = 22; // maximum for one icongroup + + retval = malloc(buflen); + if (retval == NULL) + { + return NULL; + } + dest = retval; + + if ((strcmp(iconGroup,"PLAYMODE") == 0) || All) + { + COPY_TO_RETVAL("PLAYMODE:"); + switch(p->playmode) + { + default: + case PLAYMODE_OFF: + COPY_TO_RETVAL("OFF ") + break; + case PLAYMODE_PLAY: + COPY_TO_RETVAL("PLAY ") + break; + case PLAYMODE_STOP: + COPY_TO_RETVAL("STOP ") + break; + case PLAYMODE_PAUSE: + COPY_TO_RETVAL("PAUSE ") + break; + case PLAYMODE_FF: + COPY_TO_RETVAL("FF ") + break; + case PLAYMODE_REW: + COPY_TO_RETVAL("REW ") + break; + case PLAYMODE_HEART: + COPY_TO_RETVAL("HEART ") + break; + case PLAYMODE_HEARTOUTLINE: + COPY_TO_RETVAL("HEARTOUTLINE ") + break; + } + } + if ((strcmp(iconGroup,"RECORDING") == 0) || All) + { + COPY_TO_RETVAL("RECORDING:") + switch(p->playmode) + { + default: + case RECORDING_OFF: + COPY_TO_RETVAL("OFF ") + break; + case RECORDING_ON: + COPY_TO_RETVAL("ON ") + break; + } + } + if ((strcmp(iconGroup, "VOLUME") == 0) || All) + { + COPY_TO_RETVAL("VOLUME:") + if ((buflen > 4) && (p->volume >= 0) && (p->volume <= 100)) + { + int i = sprintf(dest, "%d ", p->volume); + dest += i; + buflen -= i; + } + else + COPY_TO_RETVAL("OFF "); + } + if ((strcmp(iconGroup, "MAIL") == 0) || All) + { + COPY_TO_RETVAL("MAIL:") + switch(p->mail) + { + default: + case MAIL_OFF: + COPY_TO_RETVAL("OFF ") + break; + case MAIL_ENVELOPE: + COPY_TO_RETVAL("ENVELOPE ") + break; + case MAIL_NEW: + COPY_TO_RETVAL("NEW ") + break; + } + } + if ((strcmp(iconGroup, "MEDIASRC") == 0) || All) + { + COPY_TO_RETVAL("MEDIASRC:") + switch(p->mediasrc) + { + default: + case MEDIASRC_OFF: + COPY_TO_RETVAL("OFF ") + break; + case MEDIASRC_HDD: + COPY_TO_RETVAL("HDD ") + break; + case MEDIASRC_1394: + COPY_TO_RETVAL("1394 ") + break; + case MEDIASRC_CD: + COPY_TO_RETVAL("CD ") + break; + case MEDIASRC_USB: + COPY_TO_RETVAL("USB ") + break; + } + } + if ((strcmp(iconGroup, "MEDIATYPE") == 0) || All) + { + COPY_TO_RETVAL("MEDIATYPE:") + switch(p->mediatype) + { + default: + case MEDIATYPE_OFF: + COPY_TO_RETVAL("OFF ") + break; + case MEDIATYPE_MOVIE: + COPY_TO_RETVAL("MOVIE ") + break; + case MEDIATYPE_TV: + COPY_TO_RETVAL("TV ") + break; + case MEDIATYPE_MUSIC: + COPY_TO_RETVAL("MUSIC ") + break; + case MEDIATYPE_PHOTO: + COPY_TO_RETVAL("PHOTO ") + break; + } + } + return retval; +} +MODULE_EXPORT const char* MD8800_namedicon_info (Driver *drvthis) +{ + static const char *template_string = "PLAYMODE:OFF|PLAY|STOP|PAUSE|FF|REW|HEART|HEARTOUTLINE " + "RECORDING:OFF|ON " + "VOLUME:|OFF " + "MAIL:OFF|ENVELOPE|NEW " + "MEDIASRC:OFF|HDD|1394|CD|USB " + "MEDIATYPE:OFF|MOVIE|TV|MUSIC|PHOTO"; + char *p = malloc(strlen(template_string)+1); + if (p != NULL) + strcpy(p, template_string); + return p; +} + MODULE_EXPORT void MD8800_output (Driver *drvthis, int on) { Index: server/drivers/MD8800.h =================================================================== RCS file: /cvsroot/lcdproc/lcdproc/server/drivers/MD8800.h,v retrieving revision 1.3 diff -w -u -r1.3 MD8800.h --- server/drivers/MD8800.h 2 Apr 2007 21:29:54 -0000 1.3 +++ server/drivers/MD8800.h 24 Dec 2008 00:03:00 -0000 @@ -1,6 +1,6 @@ /* This is the LCDproc driver for the VFD of the Medion MD8800 PC - Copyright (C) 2006 Stefan Herdler in collaboration with Martin M?. + Copyright (C) 2006 Stefan Herdler in collaboration with Martin M?ller. This source Code is based on the NoritakeVFD, the serialVFD and the CFontzPacket Driver of this package. @@ -45,7 +45,7 @@ MODULE_EXPORT void MD8800_backlight (Driver *drvthis, int on); MODULE_EXPORT void MD8800_set_brightness(Driver *drvthis, int state, int promille); MODULE_EXPORT int MD8800_get_brightness(Driver *drvthis, int state); -MODULE_EXPORT int MD8800_icon (Driver *drvthis, int x, int y, int icon); - - +MODULE_EXPORT int MD8800_namedicon_set (Driver *drvthis, const char* icon); +MODULE_EXPORT const char* MD8800_namedicon_get (Driver *drvthis, const char* icon); +MODULE_EXPORT const char* MD8800_namedicon_info (Driver *drvthis); #endif Index: server/drivers/lcd.h =================================================================== RCS file: /cvsroot/lcdproc/lcdproc/server/drivers/lcd.h,v retrieving revision 1.25 diff -w -u -r1.25 lcd.h --- server/drivers/lcd.h 2 Apr 2007 21:29:54 -0000 1.25 +++ server/drivers/lcd.h 24 Dec 2008 00:03:00 -0000 @@ -79,6 +79,11 @@ * lot of things in that area might need to be changed. */ +#define ICONGROUP_LEN 16 +#define ICONGROUPMEMBER_LEN 16 +#define ICONGROUP_MEMBER_SEPARATOR '.' + + /* Heartbeat data */ #define HEARTBEAT_OFF 0 #define HEARTBEAT_ON 1 @@ -147,6 +152,9 @@ void (*num) (struct lcd_logical_driver *drvthis, int x, int num); void (*heartbeat) (struct lcd_logical_driver *drvthis, int state); int (*icon) (struct lcd_logical_driver *drvthis, int x, int y, int icon); + int (*namedicon_set) (struct lcd_logical_driver *drvthis, const char *namedicon); + const char* (*namedicon_get) (struct lcd_logical_driver *drvthis, const char *namedicon); + const char* (*namedicon_info) (struct lcd_logical_driver *drvthis); void (*cursor) (struct lcd_logical_driver *drvthis, int x, int y, int type); /* user-defined character functions, are those still supported ? */ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From herdler at gmx.de Wed Dec 24 16:31:33 2008 From: herdler at gmx.de (Stefan Herdler) Date: Wed, 24 Dec 2008 17:31:33 +0100 Subject: [Lcdproc] How to handle separate icon area on LCD/VFD glass In-Reply-To: <1230047790.5274.17.camel@TangoLinux.lan> References: <1230047790.5274.17.camel@TangoLinux.lan> Message-ID: <495263E5.1020605@gmx.de> Hi, Arthur van Dongen wrote: > Hi Stefan and others on this list, > > Thanks for your reply. > -------- Forwarded Message -------- > >> From: Stefan Herdler >> To: Arthur van Dongen >> Cc: lcdproc at lists.omnipotent.net >> Subject: Re: [Lcdproc] How to handle separate icon area on LCD/VFD >> glass >> Date: Tue, 23 Dec 2008 03:46:39 +0100 >> >> Hi Arthur, >> >> Arthur van Dongen wrote: >> >>> Hi all, >>> >>> (I already sent a similar post to this list, but this one is further >>> developed. Please ignore the previous one.) >>> >>> I have both a Medion MD8800 VFD and a Shuttle with VFD. Drivers within >>> LCDproc exist for both displays. I want to control the icons from >>> mythtv. For a better understanding of what I mean with these icons, here >>> are two links to pages with photos of the displays in action: >>> http://jeremy.infogami.com/SetVFD >>> http://www.martinm-76.dk/md8800/LCD/md8800-lcd.jpg >>> >>> I searched the net for the best way to implement icons, but the >>> contributions are either focused on LEDs attached to a small number of >>> GPIO ports of the display, or drawing custom characters on the LCD dot >>> matrix. The current drivers for MD8800 and ShuttleVFD already attempt to >>> support the icons, but implement the other interface. >>> >>> >> Interface? >> I just (mis)used the output command to push the display specific >> commands trough the LCDd ;-) . >> >>> Currently both implementations do not fulfill the (my) requirements, and >>> I see the need for an extension to the protocols. Back to the drawing >>> table.... >>> >>> >>> >> While writing the MD8800 driver I thought about making a better and more >> generic solution for the Icons. >> But at that time it was the only display with such icons I've known, so >> I dropped that plan. >> >>> Requirements >>> ============ >>> * Device-independent interface from client to server. If a client wants >>> to light the "Play" light on the display, it does not need to know if it >>> is implemented by a GPIO output attached to a LED or by a triangular LCD >>> segment somewehere on the glass. >>> * Extensible. If a new LCD or VFD display appears that has a new set of >>> icons, it should not require much effort to add support. >>> * Special handling of grouped segments. For example, both VFDs have a >>> "Volume" region, with different number of bars. The client can be hidden >>> from this detail by allowing a "volume 50%" command. >>> * Queryable. A client can request whether an "Envelope" icon is >>> supported by the device, and decide to display a "New mail" text based >>> on the result of this request. >>> >>> >> The icon should indicate a event independent to the screen shown. >> Having a icon setup of every client doesn't make much sense to me. >> I think one global icon setting is enough too. >> >> Having only one (global) icon setup will make the implementation much >> easier. The LCDd just had to hand over the request to the displaydriver. >> The complete icon handling can be done in the driver that is most >> flexible and "future proof" way I think. >> >>> * Separate control of the icons. One client can control the "Play" icon, >>> and another can control the "Envelope" icon. >>> * Combined control of icons. Switching from "FF" to "Play" icon should >>> be possible in a single command. There is no sense in controlling these >>> from different clients. >>> * Efficiency. The list of all icon names can only grow, and searching >>> for an icon in the list should not take too long. Grouping? >>> * Flexibility in defining combined icons. For example an icon set for >>> the video source can contain "TV" and "Film" on one device and "DVB-T", >>> "Sat", "MPEG", "DivX", "unknown-codec-of-the-future" icons on another. >>> >>> Design outline >>> ============== >>> Client-Server interface >>> ----------------------- >>> Example: >>> screen_add scrn0 >>> widget_add scrn0 iconWidget icon >>> widget_set scrn0 iconWidget 0 0 PLAYMODE.FF >>> widget_set scrn0 iconWidget 0 0 MAIL.OFF >>> widget_set scrn0 iconWidget 0 0 VIDSRC.TV >>> widget_set scrn0 iconWidget 0 0 VIDSRC.TV_Sat >>> >>> Server-Device API >>> ----------------- >>> _icon(Driver *drvthis, const char iconDef[]); >>> >>> >> The client interface I had in mind has 3 functions: >> >> - icon_info >> shows the supported icons and their possible values. >> Example of the return value: >> "icons: DVD:on,off,animate Mail:on,off,animate Volume:percent,off >> State:stop,play,rec,ff,fr,pause ..." >> >> "DVD" and "Mail" are "normal" icons. "animate" means "blinking" or >> highlighting in a other way. >> "Volume" is an example of a bargraph and "State" of the playstate-indicator >> I think we should define some "standard" icons which should be preferred >> by client and driver, but individual icons could be defined as well. >> > To avoid a mess of similar but slightly different names, there should > indeed be a list of common names. The names should be descriptive, so > "State" is not a good candidate IMO. > What about the naming of the functions? The "DRIVER_icon()" function > name is already in use. Is DRIVER_namedicon_set() a good choice? Or use > "DRIVER_icon_info" like in your example and risk confusion with the > current DRIVER_icon() function? > The names should be seen as example to explain the basic concept what i had in mind. I haven't had elaborated details like naming functions so far. (... and it was late that night ;-)) The final instance in such things is anyway Peter the maintainer of the whole LCDproc project. >> -icon_set >> Sets the value of one or more icons. >> Example: >> icon_set DVD:on State:play Volume:57 >> >> -icon_get >> can be used to retrieve the state of a icon. >> Example: >> icon_get DVD Volume >> -> >> Icon_state: DVD:on Volume:57 >> >> All the icon states would be global, so there is no need to define a >> screen or position of the icon I think. >> Every client could change the state every icon. >> The allocation of the icons will be up to the configuration of clients. >> > I agree with your suggestion to make it global, instead of > screen-oriented. > What should happen if a client disconnects? Should the server remember > the icons that are set by this client, and clear them? > Is it -really- useful to clear the icon? I would say no. If a client is terminated normally it should clean up first and if a client crashes the on the screen remaining icon is the least critical problem. The disadvantages of clearing the Icons are: -We need a lot of code in the LCDd to remember the settings (I guess it won't be easy to write it flexible enough to cover all possibilities). -A client had to stay connected to show a icon. I don't think we should waste to much time with that. > And what if two clients set the same group? Group? You are talking about the "stop,play,rec,ff,fr,pause" icon(s)?! Setting more then one of this icons IMHO doesn't bring more Information on the display, it will be only confusing. I would handle this group like one one icon with different states. > The last one sets it and the > earlier setting is lost? > I guess that will happen. I don't have any real good idea how to prevent that. Allowing only foreground clients to change the icons? I don't think is what we want. Allowing the clients to lock an icon? The client had to unlock the icon when it is not in use. Wouldn't it be easier just stop modifying it? Users with more then one interactive client (like mythtv, freevo, vdr, ...) have to deal with that problem anyway even without icons. So I would let the clients handle that problem until anyone comes up with a better idea. Regards Stefan > >>> When using icon names of the form GROUP.SELECTION and passing this >>> unaltered to the driver, the driver can then decide what to do with it. >>> I do not know how the screen priorities affect this, when multiple >>> clients set icons on the same location. >>> The driver should split the GROUP from the SELECTION and parse these. If >>> they are known the driver can turn on the right segments in the group, >>> and otherwise revert to a default. Using partial matching, like the TV >>> and TV_SAT selection, the driver can revert to a more common icon. >>> >>> So what do you experts think? Am I heading in the right direction? >>> >>> >> Definitely the right direction, I think! >> >> Client programmer will appreciate a common way to control the icons. >> And the display owner would be happy if more clients would be able to >> control the Icons. >> >>> Thanks for any corrections, ideas, directions, eye openers and other >>> info ;-) >>> >>> Arthur >>> >>> ------------------------------------------------------------------------ >>> >>> _______________________________________________ >>> LCDproc mailing list >>> LCDproc at lists.omnipotent.net >>> http://lists.omnipotent.net/mailman/listinfo/lcdproc >>> >>> >> regards >> Stefan >> >> p.s. >> I don't own a display with icons, but if you need help modifying the >> MD8800 driver may contact me. >> It's a long time since I've written the driver, but I will see what I >> can do ;-) . >> From herdler at gmx.de Wed Dec 24 23:28:14 2008 From: herdler at gmx.de (Stefan Herdler) Date: Thu, 25 Dec 2008 00:28:14 +0100 Subject: [Lcdproc] [PATCH] Icon support on MD8800 VFD In-Reply-To: <1230077750.5274.29.camel@TangoLinux.lan> References: <1230077750.5274.29.camel@TangoLinux.lan> Message-ID: <4952C58E.4030309@gmx.de> Hi, Arthur van Dongen wrote: > Hi Stefan, hi all, > > I created a patch to support the icons on the MD8800 VFD, for more info > see earlier in the lcdproc mailing list. > The diff is based on the CVS trunk, synced last week. > > The icons can be controlled by issuing a > "namedicon_set . command, for example > "namedicon_set PLAYMODE.STOP". The current status can be queried by > issuing a "namedicon_get {ALL|}" command, the list of > possible values with "namedicon_info". > > Wow, you're fast! > Please have a look at the patch and send me any feedback. If all is OK, > I will implement the same functions for my ShuttleVFD display, and try > to control these icons from MythTV. > I haven't checked every detail, but in the main the driver side is looking good so far. My knowledge about the clients side is limited, so I can't much abut it. I noticed a few things we should may think about again. - You grouped "mediatype" and "mediasrc" icons. With that it isn't possible to light two "mediatype" or "mediasrc" icons at the same time. I can imagine applications where it would be useful to do that e.g. indicating mounted devices. - The "default:" statement, shouldn't it be always at the end of a switch case? - The names of the icons: They fit the MD8800 display, I think. But that is the only display with icons i had a closer look on. What is about other displays? Well, it might be helpful if someone with e.g. a Imon-LCD with icons tells his opinion. Regards Stefan > Best regards, > Arthur van Dongen > > > From peter at adpm.de Sat Dec 27 18:07:32 2008 From: peter at adpm.de (Peter Marschall) Date: Sat, 27 Dec 2008 19:07:32 +0100 Subject: [Lcdproc] Fwd: lcdproc mailing list malfunction? Message-ID: <200812271907.32425.peter@adpm.de> test -- Peter Marschall peter at adpm.de -------------- next part -------------- An embedded message was scrubbed... From: "Markus Dolze" Subject: lcdproc mailing list malfunction? Date: Tue, 23 Dec 2008 15:57:18 +0100 Size: 2284 URL: From bsdfan at nurfuerspam.de Sun Dec 28 11:45:17 2008 From: bsdfan at nurfuerspam.de (Markus Dolze) Date: Sun, 28 Dec 2008 12:45:17 +0100 Subject: [Lcdproc] Changed timing for lcd2usb Message-ID: <20081228114517.305550@gmx.net> Hello, I found that a lcd2usb device takes care of the communication timing itself. Attached is a patch that overwrites uPause() locally which speeds up writing to the display. I tested this myself and found no problems. Regards, Markus -------------- next part -------------- A non-text attachment was scrubbed... Name: patch-hd44780-lcd2usb.c Type: application/octet-stream Size: 1014 bytes Desc: not available URL: From TELarson at west.com Mon Dec 29 00:57:27 2008 From: TELarson at west.com (Larson, Timothy E.) Date: Sun, 28 Dec 2008 18:57:27 -0600 Subject: [Lcdproc] smoketest volunteer Message-ID: Someone add me to the developer list, please? SF username "christtrekker". Tim -- Tim Larson AMT2 Unix Systems Administrator InterCall, a division of West Corporation Eschew obfuscation! -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 9455 bytes Desc: not available URL: From gareth at omnipotent.net Mon Dec 29 03:14:12 2008 From: gareth at omnipotent.net (Gareth Watts) Date: Sun, 28 Dec 2008 19:14:12 -0800 Subject: [Lcdproc] List outage Message-ID: <85F38D6A-EAB0-4489-9CE0-E29753EB06C7@omnipotent.net> Hi All Apologies for the list being down this past week - The server was restarted last weekend and mailman didn't come up (fixed now). Thanks to Peter Marschall for the heads up about the problem. Gareth From junk_inbox at verizon.net Mon Dec 29 04:07:32 2008 From: junk_inbox at verizon.net (Jeff Artz) Date: Sun, 28 Dec 2008 23:07:32 -0500 Subject: [Lcdproc] LCDd daemon hangs with USB Crystalfontz 634 LCD Message-ID: <4345451E4BEF4958BD79FC703E4B780C@jartzhome> Ok, I've googled and found some references to this hang, and my new CF 634 display does the same, exactly as described in this thread from last year: http://lists.omnipotent.net/pipermail/lcdproc/2007-April/011646.html I'm running Fedora Core 8, kernel "2.6.26.6-49.fc8", current CVS LCDproc v0.5.2 Here's what happens: [mythtv at mythbackend etc]$ sudo /sbin/service LCDd start Starting up LCDd: ps ax of above hang scenerio: [root at mythbackend mythtv]# ps ax | grep LCDd 16361 pts/1 S+ 0:00 /bin/sh /sbin/service LCDd start 16368 pts/1 S+ 0:00 /bin/sh /etc/init.d/LCDd start 16373 pts/1 S+ 0:00 /bin/bash -c ulimit -S -c 0 >/dev/null 2>&1 ; /usr/local/sbin/LCDd -c /home/mythtv/lcd/LCDd.conf 16374 pts/1 S+ 0:00 /usr/local/sbin/LCDd -c /home/mythtv/lcd/LCDd.conf 16375 ? Ss 0:00 /usr/local/sbin/LCDd -c /home/mythtv/lcd/LCDd.conf 16381 pts/3 R+ 0:00 grep LCDd [root at mythbackend mythtv]# If I manually do a "kill -USR1 16374", "[ OK ]" is displayed and the prompt will come back and everything works fine. So, to help troubleshoot, I changed the ReportLevel to 5, and here's what I get to stdout: [mythtv at mythbackend etc]$ sudo /sbin/service LCDd start Starting up LCDd: LCDd version 0.5.2 starting Built on Dec 22 2008, protocol version 0.3, API version 0.5 Using Configuration File: /home/mythtv/lcd/LCDd.conf Set report level to 5, output to stderr Server forking to background Listening for queries on 127.0.0.1:13666 screenlist_init() driver_load(name="CFontz", filename="/home/mythtv/lcd/CFontz.so") CFontz: using Device /dev/lcd CFontz: init() done Key "Escape" is now reserved in exclusive mode by client [-1] Key "Enter" is now reserved in shared mode by client [-1] Key "Up" is now reserved in shared mode by client [-1] Key "Down" is now reserved in shared mode by client [-1] screenlist_process() screenlist_switch(s=[_server_screen]) screenlist_switch: switched to screen [_server_screen] screenlist_process() screenlist_process() screenlist_process() screenlist_process() screenlist_process() screenlist_process() screenlist_process() screenlist_process() screenlist_process() screenlist_process() (Which doesn't seem very helpful to me - perhaps it will to the developers) So for the moment I can't setup LCDd to start at boot time, or it will hang my system. I manually start it after booting. (Thankfully that's not very often, as it's my MythTV backend system) How can I help troubleshoot this further? (Suggestions of a debugger and/or the process, not quite step-by-step, but the more explict the better - ie please don't reply with simply "just debug the process"... I don't know how to do that [yet]!) Thanks! -------------- next part -------------- An HTML attachment was scrubbed... URL: From ethan.dicks at gmail.com Mon Dec 29 07:10:29 2008 From: ethan.dicks at gmail.com (Ethan Dicks) Date: Mon, 29 Dec 2008 02:10:29 -0500 Subject: [Lcdproc] Changed timing for lcd2usb In-Reply-To: <20081228114517.305550@gmx.net> References: <20081228114517.305550@gmx.net> Message-ID: On Sun, Dec 28, 2008 at 6:45 AM, Markus Dolze wrote: > Hello, > > I found that a lcd2usb device takes care of the communication timing itself. Attached is a patch that overwrites uPause() locally which speeds up writing to the display. > > I tested this myself and found no problems. I have an lcd2usb and can give this a test soon. I just got home from my year at Pole and I haven't quite got my development environment completely back up yet (right now, for reasons I don't yet fully understand, I'm having libusb issues under Mac OS 10.4 - I can't seem to to "find" a couple of functions used by the new 20x2 and 20x4 combined PicoLCD driver). Once I get things sorted out, I should be able to get back to testing. -ethan From juan.nm at vaelsys.com Mon Dec 29 11:42:35 2008 From: juan.nm at vaelsys.com (Juan Navarro) Date: Mon, 29 Dec 2008 12:42:35 +0100 Subject: [Lcdproc] cwlinux 12832 driver fix In-Reply-To: <200812061832.52654.peter@adpm.de> References: <49355139.9050402@vaelsys.com> <200812061832.52654.peter@adpm.de> Message-ID: Peter Marschall escribi?: > Hi, > > On Tuesday, 2. December 2008, Juanelo wrote: >> Hi, I have been playing with this LCD; to make it work with the current >> CVS driver, I had to edit the file CwLnx.c and add a condition to an if, >> so the following line: >> >> else if (p->model == 12232) { // the graphical model >> >> i propose to change it to something like: >> >> ... >> else if (p->model==12232 || p->model==12832) { >> ... >> } >> else { >> printf("CwLnx_set_char(): MODEL %d NOT SUPPORTED!\n", p->model); >> return; >> } >> >> in both CwLnx_set_char_unrestricted() and CwLnx_set_char() > > It is good to see some tests on my extensions that I did > with only the documentation, but with out the hardware. > > I added the first part of your patch. > The scond part (the "else { ..." part) is not necessary > as the driver's init function only allows the displays > tested in the "if" and "else if" branches. > > >> by the way, there is also a #define: >> #define LCD_OFF_CURSOR 72 /* is this correct?*/ >> >> that according to the documentation doesn't seem to apply to the 12832 >> model; in fact the value "72" has already been defined previously in >> the same file: >> #define LCD_INIT_INSERT 72 /* go to home */ > > I know; I wrote this comment as I saw the the collision in the > definition. > But without the hardware I wasn't able to test, so I left it in. > > Could you try to test with the line > CwLnx_hidecursor(p->fd); > commented, and report back whether it still works. > > Regards > Peter > I have tried commenting out the indicated line and it works correctly, so I would assume that this line can be deleted from the code. Documentation says that all the options related to cursor blinking are disabled by default, so it's not needed to disable them manually. Another topic I would like to speak about, is the initialization of the communication with the LCD. It seems to me a bit strange that we need to start the connection at the opposite of the desired speed, only to tell the LCD what's actually our desired baud rate, and then restart the connection at that speed. I think this *should* be not neccesary, because documentation says that the default baud rate for the device(s) is 19200 bps, so it *should* be safe to assume that speed is correct. I wrote *should* because I have been doing tests with a 1602 model, setting 19200 bps in the config file, and it shows a weird response: - direct "minicom" connection at 19200 baud works ok. letters are shown as they are typed in the keyboard. - my LCDd client has 2 screens; one of them only shows a pair of strings, and it shows up correctly, but the other one has a "title" widget, and it shows a lot of garbage. Actually, its not "garbage", I can see the labels that should be shown in the LCD, but they are moving fast from one side to another, mixed with real garbage. If I remove the title declaration from the source code, it seems to work as expected. In the other hand, setting the speed to 9200 in config file makes it work OK in all cases. So this seems to be a mix between port speed handling and (maybe?) a bug in the title widget... it's not clear to me :S I have even used my own serial port initialization code (used for other projects), which directly initializes the serial connection at the specified speed, and it also shows the same results: at 9600 the LCD works perfectly but at 19200 it shows the same wrong screens. I will continue playing with the source code. My original idea was connect to the LCD with the default speed specified in the docs (19200 baud) and then use the command named "Read Model Number (254 48 253)" in order to discover automatically the LCD model version when initializing the driver. This would allow to change between CwLinux LCDs without the need to edit the config file, just a restart of the LCDd server. In the meantime, have a very happy new year everyone ;) From avdongen at xs4all.nl Mon Dec 29 11:52:08 2008 From: avdongen at xs4all.nl (Arthur van Dongen) Date: Mon, 29 Dec 2008 12:52:08 +0100 Subject: [Lcdproc] [Fwd: Re: How to handle separate icon area on LCD/VFD glass] Message-ID: <1230551528.5196.44.camel@TangoLinux.lan> Hi Peter, -------- Forwarded Message -------- > From: Peter Marschall > To: lcdproc at lists.omnipotent.net > Subject: Re: [Lcdproc] How to handle separate icon area on LCD/VFD > glass > Date: Mon, 22 Dec 2008 13:05:47 +0100 > > Hi Arthur, > > On Thursday, 18. December 2008, Arthur van Dongen wrote: > > I searched the net for the best way to implement icons, but the > > contributions are either focused on LEDs attached to a small number of > > GPIO ports of the display, or drawing custom characters on the LCD dot > > matrix. The current drivers for MD8800 and ShuttleVFD already attempt to > > support the icons, but implement the other interface. > > LCDproc currently supports icon widgets. > These widgets can be placed on the display inside the "regular" > display area (i.e. at specific positions among the text). > > This is one of the core features of LCDproc, used by other features, > and cannot easily be replaced. > > So, the "icon" widget is out of reach for your ideas. > > > Currently both implementations do not fulfill the (my) requirements, and > > I see the need for an extension to the protocols. Back to the drawing > > table.... > > Let me play devil's advocate, and ask questions, bring > counter-arguments, ... ;-) > > > Requirements > > ============ > > * Device-independent interface from client to server. If a client wants > > to light the "Play" light on the display, it does not need to know if it > > is implemented by a GPIO output attached to a LED or by a triangular LCD > > segment somewehere on the glass. > > This is only true, if e.g. the PLAY icon is not required to be at a specific > position. You assume the icon is always context free. > > How can programmers of clients know what external icons are available and > where they are placed in relation to the regular text. The icons I'm referring to are located on a fixed position on the glass, outside the text (dot matrix/7 segment/11 segment) region. So the location does not matter from a client or driver point of view, it is fixed by the hardware. The client could request the available icons and get back a string list, but that is probably too hard to be commonly implemented. > > * Extensible. If a new LCD or VFD display appears that has a new set of > > icons, it should not require much effort to add support. > > What about displays that do not support such external icons ? > Shall the clients on those displays leave e.g. the last line empty ? Nope. Would make clients with 1 line useless ;-) I think the external icons can be considered "extra". > > * Special handling of grouped segments. For example, both VFDs have a > > "Volume" region, with different number of bars. The client can be hidden > > from this detail by allowing a "volume 50%" command. > > Hmm, this is much more than an a simple icon. > It > > > * Queryable. A client can request whether an "Envelope" icon is > > supported by the device, and decide to display a "New mail" text based > > on the result of this request. > > Here I concur in principle. > But to make the interface generic you need to standardize on names > and properties for these new icons/widgets. > > Only with a standardized set of these widgets and their properties clients > can be written that support more than one specific display. > > > * Separate control of the icons. One client can control the "Play" icon, > > and another can control the "Envelope" icon. > > * Combined control of icons. Switching from "FF" to "Play" icon should > > be possible in a single command. There is no sense in controlling these > > from different clients. > > * Efficiency. The list of all icon names can only grow, and searching > > for an icon in the list should not take too long. Grouping? > > * Flexibility in defining combined icons. For example an icon set for > > the video source can contain "TV" and "Film" on one device and "DVB-T", > > "Sat", "MPEG", "DivX", "unknown-codec-of-the-future" icons on another. > > > > Design outline > > ============== > > Client-Server interface > > ----------------------- > > Example: > > screen_add scrn0 > > widget_add scrn0 iconWidget icon > > widget_set scrn0 iconWidget 0 0 PLAYMODE.FF > > widget_set scrn0 iconWidget 0 0 MAIL.OFF > > widget_set scrn0 iconWidget 0 0 VIDSRC.TV > > widget_set scrn0 iconWidget 0 0 VIDSRC.TV_Sat > > > > Server-Device API > > ----------------- > > _icon(Driver *drvthis, const char iconDef[]); > > Please don't force the individual drivers to interpret text. > This is up to the server core so that it can be done once (and correctly). You've got a point here. But the alternative is using a set of predefined constants, and that is much less expandable. For now I vote for using strings. This can be reasonable efficient by doing a two-step comparison of the group ("PLAYMODE") and member ("FF") parts. > > What about the query function ? > > > When using icon names of the form GROUP.SELECTION and passing this > > unaltered to the driver, the driver can then decide what to do with it. > > I do not know how the screen priorities affect this, when multiple > > clients set icons on the same location. > > The driver should split the GROUP from the SELECTION and parse these. If > > they are known the driver can turn on the right segments in the group, > > and otherwise revert to a default. Using partial matching, like the TV > > and TV_SAT selection, the driver can revert to a more common icon. > > Drivers have no notion of clients & client screens, so > doing the grouping in the driver cannot work. > > BTW how do screen changes (every x seconds) interact with the > extended icons? Stefan Herdler already convinced me (see his reply on this list) to make the icons independent of screens and widgets, and to use them globally. If two clients set the same group, the last one just overwrites the first. > > > So what do you experts think? Am I heading in the right direction? > > > > Thanks for any corrections, ideas, directions, eye openers and other > > info ;-) > > As I wrote above, changing the icon widget is not possible. > Changing the protocol will also not happen inside the 0.5 series. I do not intend to remove or change the current icon widget, but add another optional function instead. The naming is TBD, and icon() would have been an option if it had not existed yet. Do you think that adding an optional function is OK, providing that it does not break existing clients and drivers? > > I can understand your pain, but from a "harmonization" point of > view, I consider the extended icons on the different displays > too different to be able to get a common system. > > So, for the short term I suggest using the output command > to get the icons. I have considered that, of course. But there are a few cons to this approach: - the current output() commands provides 32 bits, and my displays have 29 and 33 segments. Only 20 of them are common. Extending to 64 bits would only give some room for now but we would hit this limit sooner or later. - The clients can call the output functions, but only if they have knowledge about which bit means what. This is something only the driver can know, and sometimes not even at compile time. Consider the case if the GPIOs of a LCD display are connected to LEDs by an integrator, then this is something that could be specified in the driver config section. - I was looking for some mechanism that is future-proof and can be used by any client and any driver that supports this in any way. > > Regards > Peter > Thanks, Arthur -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From bsdfan at nurfuerspam.de Mon Dec 29 14:27:26 2008 From: bsdfan at nurfuerspam.de (Markus Dolze) Date: Mon, 29 Dec 2008 15:27:26 +0100 Subject: [Lcdproc] [Fwd: Re: How to handle separate icon area on LCD/VFD glass] In-Reply-To: <1230551528.5196.44.camel@TangoLinux.lan> References: <1230551528.5196.44.camel@TangoLinux.lan> Message-ID: <20081229142726.146010@gmx.net> Hello everyone, -------- Original-Nachricht -------- > Datum: Mon, 29 Dec 2008 12:52:08 +0100 > Von: Arthur van Dongen > An: Peter Marschall > CC: lcdproc mailing list > Betreff: [Lcdproc] [Fwd: Re: How to handle separate icon area on LCD/VFD glass] > Hi Peter, > > -------- Forwarded Message -------- > > From: Peter Marschall > > To: lcdproc at lists.omnipotent.net > > Subject: Re: [Lcdproc] How to handle separate icon area on LCD/VFD > > glass > > Date: Mon, 22 Dec 2008 13:05:47 +0100 > > > > Hi Arthur, > > ... > > > > As I wrote above, changing the icon widget is not possible. > > Changing the protocol will also not happen inside the 0.5 series. > I do not intend to remove or change the current icon widget, but add > another optional function instead. The naming is TBD, and icon() would > have been an option if it had not existed yet. Do you think that adding > an optional function is OK, providing that it does not break existing > clients and drivers? The patch sent in earlier removed the MD8800_icon() function. This was probably not on purpose. > > > > I can understand your pain, but from a "harmonization" point of > > view, I consider the extended icons on the different displays > > too different to be able to get a common system. > > > > So, for the short term I suggest using the output command > > to get the icons. Well, Arthur set a starting point, but I would appreciate it to be taken into account after a 0.5.3 release. Instead of using the output() function which is limited to send a single 'int' we could probably provide a more generic output function which passes commands transparently from the client to the display to drive those LEDs (and probably other functions). > I have considered that, of course. But there are a few cons to this > approach: > - the current output() commands provides 32 bits, and my displays have > 29 and 33 segments. Only 20 of them are common. Extending to 64 bits > would only give some room for now but we would hit this limit sooner or > later. The output command currently parses into a 'long' type value, but it is returned and passed to the drivers as 'int' type. We should look into this anyway. > - The clients can call the output functions, but only if they have > knowledge about which bit means what. This is something only the driver > can know, and sometimes not even at compile time. Consider the case if > the GPIOs of a LCD display are connected to LEDs by an integrator, then > this is something that could be specified in the driver config section. The result would be similar complex to the key input mechanism we currently have. > - I was looking for some mechanism that is future-proof and can be used > by any client and any driver that supports this in any way. > Thanks, > Arthur Regards Markus From divestoclimb at gmail.com Mon Dec 29 15:37:59 2008 From: divestoclimb at gmail.com (Benjamin Roberts) Date: Mon, 29 Dec 2008 10:37:59 -0500 Subject: [Lcdproc] MtxOrb hbars missing bottom row of pixels Message-ID: <251aaf6c0812290737j48f9087cw2bc26c46b7d8138@mail.gmail.com> I noticed this weekend that my Matrix Orbital LK202-USB display was only displaying seven vertical pixels of the last hbar cell in each bar, missing the bottom row. The cells to the left of the last one are fine because they are completely filled block characters, which makes the problem easy to notice on any hbar which consists of at least one completely filled cell and a partially filled final cell. The problematic code is in MtxOrb_hbar (this is also the code in CVS as of today): > for (i = 1; i <= p->cellwidth; i++) { > // fill pixel columns from left to right. > memset(hBar, 0xFF & ~((1 << (p->cellwidth - i)) - 1), sizeof(hBar)-1); > MtxOrb_set_char(drvthis, i, hBar); > } I changed the last argument of the memset line from "sizeof(hBar)-1" to "sizeof(hBar)" and it solved the problem. However, due to a charset incompatibility I have modified my copy of lcdproc to use a custom icon for ICON_BLOCK_FILLED (an 8x5 of 1's, as defined by the normally commented out block_filled[] array in MtxOrb_icon) so it's possible my icon does not represent the character that's on normal LCD character sets. Do other people see this problem or is it just my BLOCK_FILLED character? Ben From bsdfan at nurfuerspam.de Mon Dec 29 15:59:58 2008 From: bsdfan at nurfuerspam.de (Markus Dolze) Date: Mon, 29 Dec 2008 16:59:58 +0100 Subject: [Lcdproc] MtxOrb hbars missing bottom row of pixels In-Reply-To: <251aaf6c0812290737j48f9087cw2bc26c46b7d8138@mail.gmail.com> References: <251aaf6c0812290737j48f9087cw2bc26c46b7d8138@mail.gmail.com> Message-ID: <20081229155958.24920@gmx.net> -------- Original-Nachricht -------- > Datum: Mon, 29 Dec 2008 10:37:59 -0500 > Von: "Benjamin Roberts" > An: lcdproc at lists.omnipotent.net > Betreff: [Lcdproc] MtxOrb hbars missing bottom row of pixels > I noticed this weekend that my Matrix Orbital LK202-USB display was > only displaying seven vertical pixels of the last hbar cell in each > bar, missing the bottom row. The cells to the left of the last one are > fine because they are completely filled block characters, which makes > the problem easy to notice on any hbar which consists of at least one > completely filled cell and a partially filled final cell. > > The problematic code is in MtxOrb_hbar (this is also the code in CVS > as of today): > > > for (i = 1; i <= p->cellwidth; i++) { > > // fill pixel columns from left to right. > > memset(hBar, 0xFF & ~((1 << (p->cellwidth - i)) - 1), > sizeof(hBar)-1); > > MtxOrb_set_char(drvthis, i, hBar); > > } > > I changed the last argument of the memset line from "sizeof(hBar)-1" > to "sizeof(hBar)" and it solved the problem. However, due to a charset > incompatibility I have modified my copy of lcdproc to use a custom > icon for ICON_BLOCK_FILLED (an 8x5 of 1's, as defined by the normally > commented out block_filled[] array in MtxOrb_icon) so it's possible my > icon does not represent the character that's on normal LCD character > sets. Do other people see this problem or is it just my BLOCK_FILLED > character? > > Ben Hi, I have noticed the same some time ago with my old MtxOrb LK202-25 display. Regards, Markus From ethan.dicks at gmail.com Mon Dec 29 16:25:06 2008 From: ethan.dicks at gmail.com (Ethan Dicks) Date: Mon, 29 Dec 2008 11:25:06 -0500 Subject: [Lcdproc] MtxOrb hbars missing bottom row of pixels In-Reply-To: <20081229155958.24920@gmx.net> References: <251aaf6c0812290737j48f9087cw2bc26c46b7d8138@mail.gmail.com> <20081229155958.24920@gmx.net> Message-ID: On Mon, Dec 29, 2008 at 10:59 AM, Markus Dolze wrote: > -------- Original-Nachricht -------- >> Datum: Mon, 29 Dec 2008 10:37:59 -0500 >> Von: "Benjamin Roberts" > >> I noticed this weekend that my Matrix Orbital LK202-USB display was >> only displaying seven vertical pixels of the last hbar cell in each >> bar, missing the bottom row.... >> >> The problematic code is in MtxOrb_hbar (this is also the code in CVS >> as of today): >> >> > for (i = 1; i <= p->cellwidth; i++) { >> > // fill pixel columns from left to right. >> > memset(hBar, 0xFF & ~((1 << (p->cellwidth - i)) - 1), >> sizeof(hBar)-1); >> > MtxOrb_set_char(drvthis, i, hBar); >> > } >> >> I changed the last argument of the memset line from "sizeof(hBar)-1" >> to "sizeof(hBar)" and it solved the problem. Yes... I think I fixed the same thing in the older 20x2-only PicoLCD driver earlier this year. >> However, due to a charset >> incompatibility I have modified my copy of lcdproc to use a custom >> icon for ICON_BLOCK_FILLED (an 8x5 of 1's, as defined by the normally >> commented out block_filled[] array in MtxOrb_icon) so it's possible my >> icon does not represent the character that's on normal LCD character >> sets. Do other people see this problem or is it just my BLOCK_FILLED >> character? There are a few LCDs (and I know from helping others out that yours is one of them) that do _not_ have a filled or checkerboard character at 0xFF. I think I've run across about 4 dominant HD44780 character sets for LCDs and VFDs that mostly are different below 0x20 and above 0x80 (European accented chars vs Katakana, plus extra symbols and glyphs on the VFDs). With all the variations, I can't say it's true for every single display out there, but checking the Hitachi HD44780 datasheet, the filled-block char _is_ the ull height of the character cell. In fact, as rendered in the character set, the ROM image is *10x5*but the bottom two rows are in the "cursor" area and are not filled in on any other character. I'm guessing that matters more for 5x9 or other less-common LCD pixel geometries. This sounds like a good reason to dust off my "hbar" and "vbar" clients. I wrote a simple client in Perl to just tick up the bars and wait, specifically to find rendering and custom-character-setting issues. I need to do a little tidying up and finish the internal docs, but this is a good reason to do so. -ethan From bsdfan at nurfuerspam.de Mon Dec 29 19:02:01 2008 From: bsdfan at nurfuerspam.de (Markus Dolze) Date: Mon, 29 Dec 2008 20:02:01 +0100 Subject: [Lcdproc] Problem with backlight on old MtxOrb Message-ID: <20081229190201.24900@gmx.net> Hello, during my tests several weeks ago with my MtxOrb LK202-25 I found that my display's firmware is too old to have the adjustable backlight setting ('0x99'). Instead it only has 'B' (on) and 'F' (off) setting. Because of this garbage characters appear on the screen. The MtxOrb_backlight() did work with 'B' and 'F' previously, but got rewritten in 2006 to use '0x99'. Unfortunately the firmware is even too old to have the 'read module type' and 'read version number' commands. So there is no way to identify this device automatically by the driver. Would it be ok to add a configuration setting like 'AdjustableBacklight=true | false' and then make MtxOrb_backlight() use the old on/off method or the new On/OffBrightness values accordingly? Any other suggestions? Regards, Markus From ethan.dicks at gmail.com Mon Dec 29 19:40:14 2008 From: ethan.dicks at gmail.com (Ethan Dicks) Date: Mon, 29 Dec 2008 14:40:14 -0500 Subject: [Lcdproc] Problem with backlight on old MtxOrb In-Reply-To: <20081229190201.24900@gmx.net> References: <20081229190201.24900@gmx.net> Message-ID: On Mon, Dec 29, 2008 at 2:02 PM, Markus Dolze wrote: > Hello, > > during my tests several weeks ago with my MtxOrb LK202-25 I found that my display's firmware is too old to have the adjustable backlight setting ('0x99'). Instead it only has 'B' (on) and 'F' (off) setting. Because of this garbage characters appear on the screen. > > The MtxOrb_backlight() did work with 'B' and 'F' previously, but got rewritten in 2006 to use '0x99'. > > Unfortunately the firmware is even too old to have the 'read module type' and 'read version number' commands. So there is no way to identify this device automatically by the driver. > > Would it be ok to add a configuration setting like 'AdjustableBacklight=true | false' and then make MtxOrb_backlight() use the old on/off method or the new On/OffBrightness values accordingly? Markus, Are you using LCDproc code from a recent nightly tarball or the CVS tree? I ask because I've done a bit of work on the Matrix Orbital driver over the past year (May?), and have fixed a bug here and there _after_ the 0.5.2 release. I myself only have a MtxOrb VFD, not an LCD, so I can't personally check a variety of problems that have cropped up now and again. Looking at the code, I see where it got changed from the old "B" and "F" to the new 0x99. What we probably ought to do is create a new category (and keyword for LCDd.conf) for "old backlight" vs simply LCD vs VFD (and LKD and VKD). Unfortunately, the possible matrix of LCD commands sets is so extensive across all the Matrix Orbital products, that I don't think there is a way to automate it - we'll have to let the end user tell the server which kind he has. A year or so ago, I sat down with many MtxOrb manuals and tried to make some sense of the patterns, but I think there's been some ID-code reuse from older to newer revs of various modules such that the code just can't "know" the right thing to do. It needs a hint. I have a idea how to do this cleanly, but I still need to get my gear set up after my year away. This should be in CVS and tested before what I believe to be an impending 0.5.3 release. I won't be able to work on it this week, but hopefully with the new year, I can get my development environment back up and running smoothly. From bsdfan at nurfuerspam.de Mon Dec 29 20:32:03 2008 From: bsdfan at nurfuerspam.de (Markus Dolze) Date: Mon, 29 Dec 2008 21:32:03 +0100 Subject: [Lcdproc] Problem with backlight on old MtxOrb In-Reply-To: References: <20081229190201.24900@gmx.net> Message-ID: <20081229203203.24890@gmx.net> -------- Original-Nachricht -------- > Datum: Mon, 29 Dec 2008 14:40:14 -0500 > Von: "Ethan Dicks" > An: "Markus Dolze" > CC: "LCDproc Mailinglist" > Betreff: Re: [Lcdproc] Problem with backlight on old MtxOrb > On Mon, Dec 29, 2008 at 2:02 PM, Markus Dolze > wrote: > > Hello, > > > > during my tests several weeks ago with my MtxOrb LK202-25 I found that > my display's firmware is too old to have the adjustable backlight setting > ('0x99'). Instead it only has 'B' (on) and 'F' (off) setting. Because of this > garbage characters appear on the screen. > > > > The MtxOrb_backlight() did work with 'B' and 'F' previously, but got > rewritten in 2006 to use '0x99'. > > > > Unfortunately the firmware is even too old to have the 'read module > type' and 'read version number' commands. So there is no way to identify this > device automatically by the driver. > > > > Would it be ok to add a configuration setting like > 'AdjustableBacklight=true | false' and then make MtxOrb_backlight() use the old on/off method or > the new On/OffBrightness values accordingly? > > Markus, > > Are you using LCDproc code from a recent nightly tarball or the CVS > tree? I ask because I've done a bit of work on the Matrix Orbital > driver over the past year (May?), and have fixed a bug here and there > _after_ the 0.5.2 release. I myself only have a MtxOrb VFD, not an > LCD, so I can't personally check a variety of problems that have > cropped up now and again. I am working right from the CVS as I work on other things as well. > > Looking at the code, I see where it got changed from the old "B" and > "F" to the new 0x99. What we probably ought to do is create a new > category (and keyword for LCDd.conf) for "old backlight" vs simply LCD > vs VFD (and LKD and VKD). Unfortunately, the possible matrix of LCD > commands sets is so extensive across all the Matrix Orbital products, > that I don't think there is a way to automate it - we'll have to let > the end user tell the server which kind he has. A year or so ago, I > sat down with many MtxOrb manuals and tried to make some sense of the > patterns, but I think there's been some ID-code reuse from older to > newer revs of various modules such that the code just can't "know" the > right thing to do. It needs a hint. When I got my device it was accompanied with the CDROM and the manual on it. I found at least 4 other manual revisions for different versions of the PCB of the LK202-25. So yes, finding the right manual for one specific model is difficult. > > I have a idea how to do this cleanly, but I still need to get my gear > set up after my year away. This should be in CVS and tested before > what I believe to be an impending 0.5.3 release. I won't be able to > work on it this week, but hopefully with the new year, I can get my > development environment back up and running smoothly. The driver does currently use only a subset off all the commands available and distinguishes between the different models (lcd,lkd,...). The only issue I discovered was with the backlight and the 'identify' commands. Although I haven't tried any keys yet. So we probably do not need a big change. Regards Markus From bsdfan at nurfuerspam.de Tue Dec 30 09:48:06 2008 From: bsdfan at nurfuerspam.de (Markus Dolze) Date: Tue, 30 Dec 2008 10:48:06 +0100 Subject: [Lcdproc] hd44780 display update timing Message-ID: <20081230094806.311310@gmx.net> -------- Original-Nachricht -------- > Datum: Tue, 23 Dec 2008 15:49:38 +0100 > Von: "Markus Dolze" > An: "LCDproc Mailinglist" > Betreff: [Lcdproc] hd44780 display update timing > Hello, ... > > 1. A unmodified hd44780-winamp connected display with no extra delays: > ==== > HD44780: flushed 32 chars (4 moves) in 0.719918 sec ... > > It would be nice if someone with an hd44780-winamp connected display could > do the same test on a different OS to see if the slow timing is specific > to FreeBSD. > > Regards > Markus Hi, today I found the reason why the winamp wiring was so slow on my system: It was the kernel clockrate which I had reduced for some reason. Compare these: winamp (delay_nanosleep, kern.hz=100) HD44780: flushed 32 chars (4 moves) in 0.719908 sec senddata ~ 20 ms winamp (delay_gettimeofday, kern.hz=100) HD44780: flushed 32 chars (4 moves) in 0.002527 sec senddata ~ 0.060 ms winamp (delay_nanosleep, kern.hz=1000 (default)) HD44780: flushed 32 chars (4 moves) in 0.071929 sec sendata ~ 2.2 ms It is still slower than it could be as seen by switching to 'delay_gettimeofday, but it's fine for me now. Regards Markus From avdongen at xs4all.nl Tue Dec 30 12:53:42 2008 From: avdongen at xs4all.nl (Arthur van Dongen) Date: Tue, 30 Dec 2008 13:53:42 +0100 Subject: [Lcdproc] numeric priorities handling Message-ID: <1230641622.5640.31.camel@TangoLinux.lan> Hi all, I found some strange things in the priority handling. I don't know if it's a bug, a feature or maybe I just don't get things right. In the screen_commands.c source (current CVS head) numeric priorities are converted to the 0-7 range similar to the screen_pri_name_to_pri() function. But only PRI_FOREGROUND, PRI_INFO and PRI_BACKGROUND are handled for numeric input in the original code. <0 -> error 0 -> PRI_HIDDEN 1-64 -> PRI_FOREGROUND 65-192 -> PRI_INFO 192-maxint -> PRI_BACKGROUND Should they be added, like in the code pasted below? (I could not easily make a diff output, because I have made other changes in the file.) And it is confusing that the lower the number, the higher the priority but 0 is lowest priority. else if (strcmp(p, "priority") == 0) { if (argc > i + 1) { i++; debug(RPT_DEBUG, "screen_set: priority=\"%s\"", argv[i]); /* first try to interpret it as a number */ number = atoi(argv[i]); if (number > 0) { if (number <= 32) // added number = PRI_INPUT; // added else if (number <= 64) // added number = PRI_ALERT; // added else if (number <= 128) // constant changed from 64 to 128 number = PRI_FOREGROUND; else if (number <= 192) number = PRI_INFO; else number = PRI_BACKGROUND; } else { /* Try if it is a priority class */ number = screen_pri_name_to_pri(argv[i]); } if (number >= 0) { s->priority = number; sock_send_string(c->sock, "success\n"); } else { sock_send_error(c->sock, "invalid argument at -priority\n"); } } else { sock_send_error(c->sock, "-priority requires a parameter\n"); } } Second thing I could not explain is that in Mythtv priorities are differently assigned depending on the LCDproc version, see http://svn.mythtv.org/trac/browser/trunk/mythtv/programs/mythlcdserver/lcdprocclient.cpp#L663. As I read the code it could not have worked with the old lcdproc (ranges mismatch), nor with the new lcdproc (not all priorities available and numbers mismatch). How _should_ a client use the numeric values? _Should_ the client act differently depending on lcdproc server version?? Regards, Arthur -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From joris at robijn.net Tue Dec 30 14:07:20 2008 From: joris at robijn.net (Joris Robijn) Date: Tue, 30 Dec 2008 15:07:20 +0100 Subject: [Lcdproc] numeric priorities handling In-Reply-To: <1230641622.5640.31.camel@TangoLinux.lan> References: <1230641622.5640.31.camel@TangoLinux.lan> Message-ID: <495A3928.4604.4900EA4@joris.robijn.net> Hello Arthur, I have introduced the priority classes long ago because the numeric priorities did not make sense in an application. They were not useful in determining which screen should be displayed when, and I think at the time the numeric priorities did not actually change the way the screens were displayed. The priority classes are meant to indicate why the client application shows this screen. Or what it wants to do/mean with it. If you have an interactive application there can be different reasons for displaying a screen. If it's information only, it is not as important as a question. And a question is not as important as an alarm message. I think there are some examples in the documentation, but maybe you already read these. Maybe it needs more clarification. You can safely consider the numeric priorities obsolete. I am not actively developing anymore, so for improvements: go ahead. Regards, Joris On 30 Dec 2008 at 13:53, Arthur van Dongen wrote: > Hi all, > > I found some strange things in the priority handling. I don't know if it's > a bug, a feature or maybe I just don't get things right. > > In the screen_commands.c source (current CVS head) numeric priorities are > converted to the 0-7 range similar to the screen_pri_name_to_pri() > function. But only PRI_FOREGROUND, PRI_INFO and PRI_BACKGROUND are handled > for numeric input in the original code. <0 -> error 0 -> > PRI_HIDDEN 1-64 -> PRI_FOREGROUND 65-192 -> PRI_INFO 192-maxint > -> PRI_BACKGROUND > > Should they be added, like in the code pasted below? (I could not easily > make a diff output, because I have made other changes in the file.) And it > is confusing that the lower the number, the higher the priority but 0 is > lowest priority. > > > else if (strcmp(p, "priority") == 0) { > if (argc > i + 1) { > i++; > debug(RPT_DEBUG, "screen_set: priority=\"%s\"", argv[i]); > /* first try to interpret it as a number */ > number = atoi(argv[i]); > if (number > 0) { > if (number <= 32) // added > number = PRI_INPUT; // added > else if (number <= 64) // added > number = PRI_ALERT; // added > else if (number <= 128) // constant changed from 64 to 128 > number = PRI_FOREGROUND; > else if (number <= 192) > number = PRI_INFO; > else > number = PRI_BACKGROUND; > } > else { > /* Try if it is a priority class */ > number = screen_pri_name_to_pri(argv[i]); > } > if (number >= 0) { > s->priority = number; > sock_send_string(c->sock, "success\n"); > } > else { > sock_send_error(c->sock, "invalid argument at -priority\n"); > } > } > else { > sock_send_error(c->sock, "-priority requires a parameter\n"); > } > } > > > Second thing I could not explain is that in Mythtv priorities are > differently assigned depending on the LCDproc version, see > http://svn.mythtv.org/trac/browser/trunk/mythtv/programs/mythlcdserver/lcd > procclient.cpp#L663. As I read the code it could not have worked with the > old lcdproc (ranges mismatch), nor with the new lcdproc (not all > priorities available and numbers mismatch). How _should_ a client use the > numeric values? _Should_ the client act differently depending on lcdproc > server version?? > > Regards, > Arthur > -- Joris Robijn Mobile: +31 6 288 41 964 From michael at reinelt.co.at Tue Dec 30 17:36:01 2008 From: michael at reinelt.co.at (Michael Reinelt) Date: Tue, 30 Dec 2008 18:36:01 +0100 Subject: [Lcdproc] hd44780 display update timing In-Reply-To: <20081230094806.311310@gmx.net> References: <20081230094806.311310@gmx.net> Message-ID: <495A5C01.6080007@reinelt.co.at> > today I found the reason why the winamp wiring was so slow on my system: It was the kernel clockrate which I had reduced for some reason. > > Compare these: > > winamp (delay_nanosleep, kern.hz=100) > HD44780: flushed 32 chars (4 moves) in 0.719908 sec > senddata ~ 20 ms > > winamp (delay_gettimeofday, kern.hz=100) > HD44780: flushed 32 chars (4 moves) in 0.002527 sec > senddata ~ 0.060 ms > > winamp (delay_nanosleep, kern.hz=1000 (default)) > HD44780: flushed 32 chars (4 moves) in 0.071929 sec > sendata ~ 2.2 ms Well, the reason is simple (I got the same issues with lcd4linux): nansoleep delays *at least one tick*, which is 10 msec with a 100Hz kernel and 1 msec with a 1000Hz Kernel. Even if you do a nanosleep(2 nanoseconds) you will get a delay of at least 1 msec. If you do 2 nano-delays, you'll end up with 2 msec. your gettimeofday() delay works probably the same as in lcd4linux: it does busy-waiting.... nanosleep provides real nanosecond delays with SCHED_RT priority, but nobody wants to run a program like lcdproc or lcd4linux with SCHED_RT (think of a small bug resulting in a endless loop... you won't even be able to kill the process) -- Michael Reinelt http://home.pages.at/reinelt GPG-Key 0xDF13BA50 ICQ #288386781