From manio at skyboo.net Thu Oct 1 05:07:17 2009 From: manio at skyboo.net (Manio) Date: Thu, 01 Oct 2009 07:07:17 +0200 Subject: [Lcdproc] lcdproc.conf In-Reply-To: <4AC3CE7D.8090107@gmail.com> References: <4AC3CE7D.8090107@gmail.com> Message-ID: <4AC43905.6040803@skyboo.net> Pavel Mlc(och wrote: > But I'd like only simplier configuration, like BigTime and nothing > else. I tried read documentation but I cannot know how to do it. Can > someone helps me? The screen you mentioned is a main screen when no client is connected. The lcdproc project is client-server based so you need a client to display things like bigclock. AFAIR just need to run from console: $ lcdproc K > > Best regards, > Pavel Mlcoch regards, -- manio jabber/e-mail: manio at skyboo.net http://manio.skyboo.net From sebastien at requiem.fr Thu Oct 1 14:26:07 2009 From: sebastien at requiem.fr (sebastien requiem) Date: Thu, 01 Oct 2009 16:26:07 +0200 Subject: [Lcdproc] LCDProc and Terastation Message-ID: <4AC4BBFF.4030307@requiem.fr> Hey people, first of all, thanks to everyone who has contributed to this project, it looks awesome. I try to have it working with my hardware and may need a bit of your help that. I have a : Terastation Duo (http://www.buffalotech.com/products/network-storage/terastation/terastation-duo/) which has a "unknown" LCD display. I say unknow has I can't find any information on it. Here is what I know : = Hardware * There is a "NEC" chipset close to the cables on the board where the LCD is attached. * The LCD can handle 3 colors backlight (at least) Blue/Red/Orange * There is 4 buttons (Power, Func, Disp, Maintenance button) = Soft * The LCD is accessible at /dev/ttyS1 (don't know the serial speed though) * there is a proprietary soft that can drive it (miconapl) from Buffalo * Doing some strace on it shows clearly that /dev/ttyS1 is used. Anyone would have some clue about that LCD device ? About a possible working driver in LCDproc ? About reversing the protocol ? regards, From wyldfire00101010 at yahoo.com Fri Oct 2 21:16:15 2009 From: wyldfire00101010 at yahoo.com (Leif Hassell) Date: Fri, 2 Oct 2009 14:16:15 -0700 (PDT) Subject: [Lcdproc] Compile question Message-ID: <934359.71797.qm@web57705.mail.re3.yahoo.com> Wanting to do some modifications to lcdproc as a proof of concept. Is there any way to recompile *just* the lcdproc program itself? I've made the few changes I want to start with to the source code, and am not sure how to compile the new file. I want to compile it under a different name (lcdproc-custom), so that the original file is preserved. Any help appreciated. Thanks, Leif P.S. For those who may be curious, my LCD was damaged- that was the problem. Antec sent me a new one. Worked like a charm. -------------- next part -------------- An HTML attachment was scrubbed... URL: From joris at robijn.net Sat Oct 3 07:11:40 2009 From: joris at robijn.net (Joris Robijn) Date: Sat, 03 Oct 2009 09:11:40 +0200 Subject: [Lcdproc] Compile question In-Reply-To: <934359.71797.qm@web57705.mail.re3.yahoo.com> References: <934359.71797.qm@web57705.mail.re3.yahoo.com> Message-ID: <4AC7154C.742.9134D@joris.robijn.net> Hi Leif, Sure, just descend into the lcdproc directory and type make there. You will need to have performed the auto configure steps as described in the install and readme files. You could modify the Makefile so that it compiles for a differently named executable. Joris On 2 Oct 2009 at 14:16, Leif Hassell wrote: > Wanting to do some modifications to lcdproc as a proof of concept. Is > there any way to recompile *just* the lcdproc program itself? I've made > the few changes I want to start with to the source code, and am not sure > how to compile the new file. I want to compile it under a different name > (lcdproc-custom), so that the original file is preserved. > > Any help appreciated. > > Thanks, > Leif > > P.S. For those who may be curious, my LCD was damaged- that was the > problem. Antec sent me a new one. Worked like a charm. > > > > -- Joris Robijn Mobile: +31 6 288 41 964 From bsdfan at nurfuerspam.de Sat Oct 3 07:34:27 2009 From: bsdfan at nurfuerspam.de (Markus Dolze) Date: Sat, 03 Oct 2009 09:34:27 +0200 Subject: [Lcdproc] Submit nexcom lcm driver to lcdproc In-Reply-To: <41fde3420905052100y664c5b78wde1841c5d38b3537@mail.gmail.com> References: <41fde3420905052100y664c5b78wde1841c5d38b3537@mail.gmail.com> Message-ID: <4AC6FE83.4060102@nurfuerspam.de> Hello Mr. Tsou, I found some time to look at the driver you submitted. From the datasheet and the driver it looks like this is a HD44780-compatible device connected in 8bit-mode to a computer's parallel port. We already have a driver for such devices/connections: hd44780/winamp or hd44780/ext8bit. Although the wiring used by your device does not match the connections we already support you can easily adapt those drivers to match it. I will therefore not add the driver you submitted. If you still want to have support for your specific wiring, please use a hd44780 connection type - starting from hd44780-ext8bit.c will help you. Regards, Markus Vincente Tsou wrote: > Hi guys, > > I'm a nexcom stuff. > > I'd like to submit the nexcom lcm driver to lcdproc standard distribution. > > The attachment is a tar ball of nexcom lcm that include relational files. > > You could download the datasheet from here: > http://cid-e3c8d036c7b873cd.skydrive.live.com/self.aspx/%e5%85%ac%e9%96%8b/LCM%20Tech%20datasheet.PDF > > > > -- > Regards, > Vincente Tsou > > Senior Engineer > R/D, S/W Dept. > NEXCOM (8234) International Co. > Tel: 886-2-82280606 Ext. 3205 > Fax: 886-2-82280506 > E-mail: vincentetsou at nexcom.com.tw > Web: http://www.nexcom.com/ From 4freefinders at gmail.com Sat Oct 3 07:51:32 2009 From: 4freefinders at gmail.com (grant donald) Date: Sat, 3 Oct 2009 01:51:32 -0600 Subject: [Lcdproc] 1 ground wire Message-ID: Hello out there somewhere? I keep getting other peoples q's but no answers to mine. The wiring i'm using includes pins 18-25 as ground, because i'm trying to get this going with lcdsmartie as well. I got a parallel port adapter and i pushed one of the pins in too far, i could have left it but i tried to pull it back and it snapped off, There was no way it would come out. Now it still doesn't work, would that one ground wire be the cause? So i got myself a new display. When looking at the add i made sure it had a hd44780 chip with a backlight. Well if i would have read further i would have seen that it needs a 20.00 inverter for the "EL" backlight. Like what's that? That means it's not a lcd at all. Now i don't know if that matters either. Do you? I don't know anything, but the errors i'm getting suggest to me lcdproc is not at all compatible with Kubuntu, always says driver not found and it's right where it should be. or it really is a driver issue, thx Grant -------------- next part -------------- An HTML attachment was scrubbed... URL: From bsdfan at nurfuerspam.de Sat Oct 3 08:23:42 2009 From: bsdfan at nurfuerspam.de (Markus Dolze) Date: Sat, 03 Oct 2009 10:23:42 +0200 Subject: [Lcdproc] pyramid display timer/highres issue In-Reply-To: <4ABA0D59.80105@pyramid.de> References: <4ABA0D59.80105@pyramid.de> Message-ID: <4AC70A0E.3080002@nurfuerspam.de> J?rg Hohwieler wrote: > Dear all, > > Pyramid Computer ships an LCD display which is also supported by > LCDproc. The driver is called pyramid. > > The hardware consists of an FTDI chip, thus you've to use the ftdi_sio > kernel module to have an usb-to-serial converter. > > I have some customers that have problems with the display. The customers > said the display is very slow, so it doesn't really make fun using it. > > I also found out that the display doesn't work flawlessly with recent > kernels. It is very slow and it seems to be some kind of luck if the > server screen comes up. Also some screens won't be shown during rotation. > > The last kernel that worked perfect was 2.6.20. > > To get the display working properly with recent kernel I have to > > - make sure that timer freq. is < 1000 Hz - 100 Hz works best > > - disable high resolution timers by adding highres=off to kernel cmd > line if ACPI is activated in the kernel. Adding acpi=off would also help. > > Kernel 2.6.20 worked perfect because it doesn't have the high resolution > timers. They were added with kernel 2.6.21. > > Are there any know issues with lcdproc and this timer issue or is it > just related to the pyramid lcd? > > Is it possible to workaround this problem from within lcdproc? > > > Best regards > Joerg Hohwieler > Hi, LCDd accesses the pyramid device using a serial port without any special timings (unlike i.e. parallel port devices). However, there are two timing related parts: 1. The pyramid driver uses gettimeofday() to ensure that screen updates to not occur more often than 40 msec. 2. LCDd core uses gettimeofday() and usleep() to achieve a frame rate of 8Hz. I have not seen any reports about problems with newer kernel versions. You may try to use a different driver (e.g. curses) to see if it is a problem related to the server core (2 above). You may also try to remove the check mentioned in (1 above) - look at server/drivers/pylcd.c:pyramid_flush(). Regards Markus From bsdfan at nurfuerspam.de Sat Oct 3 15:02:39 2009 From: bsdfan at nurfuerspam.de (Markus Dolze) Date: Sat, 03 Oct 2009 17:02:39 +0200 Subject: [Lcdproc] Changed picoLCD IR handling In-Reply-To: <35687.88.159.85.214.1252165003.squirrel@webmail.onsneteindhoven.nl> References: <35687.88.159.85.214.1252165003.squirrel@webmail.onsneteindhoven.nl> Message-ID: <4AC7678F.3050904@nurfuerspam.de> A. van Schie wrote: > Oops: now with my patch. > > >> Hello LCDProc picoLCD users/developers, >> >> I have a picoLCD 2x20(M200) and my remote control (RC-5) doesn't work with >> the current CVS version. >> Because irrecord is also not working, I couldn't get a working >> configuration. >> >> More than a year ago I made my own implementation (also using >> lcdproc/picolcd and lirc/udp). >> I noticed that the main problem of the picoLCD was that the 'sync' SPACE >> is not send! >> My previous solution to this was to queue all the data, and by a timeout >> (or by a double PULSE), >> adding a 'sync' SPACE by calculating the duration between the current time >> and the time of the >> last message and send it. >> But the key presses where not always detected so I did not submitted my >> code (I know now why). >> >> >> Last weeks I had time to look at my problems with the current CVS version: >> 1. I found that there were still PULSEs without a space in between, when >> using my RC-5 remote. >> I didn't found a working parameter setting to get it working. >> (Maybe also because of the next issue) >> 2. I found out that there not all the IR data was received from the >> picoLCD and found out that >> the call to usb_clear_halt() prevents that the second part of the >> message read (why this call?) >> FIX: Removing this code fixed my problem but I don't know if it works on a >> picoLCD 4x20? >> The comment say something about that the data is send over and over >> again, >> but is it not normal RC key repeating? and will that stop when the >> button is released? >> This repeating should be handled by the lirc client in the ~/.lircrc >> with repeat and/or delay. >> Both issues explain why irrecord doesn't work! >> >> By running LIRC in debug I noticed: >> 3. LIRC gives a timeout when the data is not sent quick enhough LIRC >> timeouts and LIRC gets then >> out of sync and the key is losted. >> FIX: I solved this by queueing all data and send it when: >> - the last message ends with a pulse and the new message starts with a >> pulse. >> - I see a incomplete message (ending with a PULSE) >> Extra (should not happen, when everything goes ok): >> - The send buffer will become full (I check at the begin if there is >> still room to add all new samples) >> - I also added a LircFlushThreshold param, when I see a SPACE longer >> that that value I send it also >> (without the space, see 3). >> - Got a timeout (0.5s) >> 4. LIRC expects data to start with a SPACE, sending a the SPACE on the end >> of the message leads, >> to a timeout (on plead) and lirc is out of sync. >> FIX: So I did't send the SPACE at the end of the message, but I put it at >> the begin of the next message. >> I notices that LIRC doesn't need that SPACE at the end, because LIRC >> gets a timeout and assumes >> it as a SPACE. >> >> The LircSync and LircSyncLength parameter didn't make sense anymore so I >> removed those. >> >> (I also put the in lcd_packet keydata on the stack to prevent any possible >> memory leak there) >> >> These changes make that irrecord works again (without any complaining) for >> my RC-5 and >> my XCCube(SPACE_ENC|CONST_LENGTH encoding) remote. >> >> The only problem I had was that irw reported no key repeats (repeat >> counter stayed 00). >> But that was solved by changing the gap value (in lircd.conf) to the value >> irrecord reported. >> Now I can use repeat = 2 (or delay = 2) in ~/.lircrc to reduce repeating >> keys presses. >> >> Main advances: >> - The user now use irrecord again. >> - So he doesn't need to guess possible config values to make it work (most >> of the time). >> - The dynamic 'sync' should be flexible enhough to handle all type of >> remote control protocols, >> without extra configuration. >> >> Unknown: >> - Don't know if picoLCD 4x20 still works, because of the removed >> usb_clear_halt()? >> - Not sure that all remotes will work? >> >> I got it working now for a week (and had no key misses) so it's time to >> share code. >> >> Attached is the zipped patch agains the CVS MAIN (of 4 Sep 2009). >> >> I hope that everyone with a picoLCD likes this new way of handling IR >> data. >> >> Best regards, >> >> Andries van Schie. >> Hi, the patch compiles cleanly. For the docbook part a small change is needed to make it work. Before committing this, I'd like to hear from the PicoLCD guys whether it still works on 20x4 displays. Regards Markus From bsdfan at nurfuerspam.de Sat Oct 3 15:08:08 2009 From: bsdfan at nurfuerspam.de (Markus Dolze) Date: Sat, 03 Oct 2009 17:08:08 +0200 Subject: [Lcdproc] Driver for the SURE Electronics LCD device In-Reply-To: <200907312216.15507.laurent@latil.nom.fr> References: <200907312216.15507.laurent@latil.nom.fr> Message-ID: <4AC768D8.4070602@nurfuerspam.de> Laurent Latil wrote: > Hi, > > I recently bought a LCD device from the SURE electronics shop, in order to use > it through lcdproc. > > But it seemed that no drivers existed for this kind of devices (at least I > didn't find one after a quick glance at the sources, and some googling). > > Having read the (somewhat inaccurate) documentation of the device, and some > spying of exchange of the 'official' Windows program to control it I wrote a > dedicated LCDProc driver for the device. > > Patch is attached to this mail. (currently only tested with my 16x2 edition > II LCD device, of course) > > Please could you tell me if: > > - Suitable driver did actually not exist for this device > - This patch is fine otherwise > - This code works also for the 20x4 LCD available from same shop (if someone > owns one) > > Thanks. > Hi, the driver looks good and compiles cleanly. One comment says "this is an initial release". Do you consider the driver ready for inclusion? Regards, Markus From bsdfan at nurfuerspam.de Sat Oct 3 15:31:36 2009 From: bsdfan at nurfuerspam.de (Markus Dolze) Date: Sat, 03 Oct 2009 17:31:36 +0200 Subject: [Lcdproc] Removing win32 support Message-ID: <4AC76E58.9080401@nurfuerspam.de> Hi, when was the last time someone successfully compiled LCDproc natively for win32? There are several conditionals scattered across the code for win32, but I doubt anyone is using them. Note that I am talking about compiling it natively, not using Cygwin! For Windows there are far more advanced solutions available (i.e. LCDHype, LCD Smartie). Instead of trying to catch up on the latest Windows version I'd like to remove these parts from LCDproc. So - if nobody requires win32 support for LCDproc, I am going to remove it. Regards, Markus From bsdfan at nurfuerspam.de Sat Oct 3 15:46:17 2009 From: bsdfan at nurfuerspam.de (Markus Dolze) Date: Sat, 03 Oct 2009 17:46:17 +0200 Subject: [Lcdproc] hd44780 driver In-Reply-To: References: Message-ID: <4AC771C9.6080406@nurfuerspam.de> grant donald wrote: > Hello World, > > LCDd can't find the driver because i don't know where to point it. > Lcdproc is supposed to have it @/usr/bin/lcdproc but he don't got it. > Do you know where it is. Search don't find it. txs > > screenshot.png > > gdonald2007 Hi, LCDproc driver are usually located in %PREFIX%/lib/lcdproc/. You should find them under /usr/lib/lcdproc/ or /usr/local/lib/lcdproc/, depending on your system. Have you installed LCDproc from a package for your system or have you compiled / installed it yourself? Note that the hd44780 driver is not compiled by default. Just using ./configure will not build the hd44780 driver. You have to use './configure --enable-drivers=hd44780' or './configure --enable-drivers=all' if you build LCDproc yourself! Regards Markus From 4freefinders at gmail.com Sat Oct 3 21:19:37 2009 From: 4freefinders at gmail.com (grant donald) Date: Sat, 3 Oct 2009 15:19:37 -0600 Subject: [Lcdproc] Laurent driver Message-ID: Hi, I'd be interested in trying your driver for my odd ball HNQH204A, Looked for it and can't find any data on it but i know for sure it's not a hd44780 on the back. There's only one problem there is no link on the page. Grant -------------- next part -------------- An HTML attachment was scrubbed... URL: From satzklauer at googlemail.com Mon Oct 5 06:48:56 2009 From: satzklauer at googlemail.com (Satz Klauer) Date: Mon, 5 Oct 2009 08:48:56 +0200 Subject: [Lcdproc] Fwd: lcdproc ported for QNX In-Reply-To: <2c26506d0910042339n1a83a4c7v2b6f97e1cf45b803@mail.gmail.com> References: <2c26506d0910042339n1a83a4c7v2b6f97e1cf45b803@mail.gmail.com> Message-ID: <2c26506d0910042348x6040d55dk1c4660263cc90d2@mail.gmail.com> Hi, I ported the latest lcdproc release to work on the QNX realtime platform. This operating system is now available at no cost for non-commerical applications, so it is somehow a free operating system. Please find attached a tar.gz file that contains the diff-file for the changes and the new "machine_QNX.c" file for lcdproc. About the modifications: - it is tested on QNX 6.3.2 and should work with later versions too - I could not test all the different drivers because I do not have them here but I think they should work well, the only modification that was done here is for the serial interface configuration - the file machine_QNX.c is mainly identically with machine_Linux.c except the part where /etc/fstab is accessed, here I dropped the contents of the related function (because until now I never used the lcdproc client but I'll adapt it as soon as possible) Questions and comments are welcome! Elmi -------------- next part -------------- A non-text attachment was scrubbed... Name: lcdprocQNX.tar.gz Type: application/x-gzip Size: 6088 bytes Desc: not available URL: From ethan.dicks at gmail.com Mon Oct 5 14:35:06 2009 From: ethan.dicks at gmail.com (Ethan Dicks) Date: Mon, 5 Oct 2009 10:35:06 -0400 Subject: [Lcdproc] Fwd: lcdproc ported for QNX In-Reply-To: <2c26506d0910042348x6040d55dk1c4660263cc90d2@mail.gmail.com> References: <2c26506d0910042339n1a83a4c7v2b6f97e1cf45b803@mail.gmail.com> <2c26506d0910042348x6040d55dk1c4660263cc90d2@mail.gmail.com> Message-ID: On Mon, Oct 5, 2009 at 2:48 AM, Satz Klauer wrote: > Hi, > > I ported the latest lcdproc release to work on the QNX realtime > platform. This operating system is now available at no cost for > non-commerical applications, so it is somehow a free operating system. Interesting. QNX appears in some "interesting" places, like the 3Com Audrey - which also happens to have a serial port and a USB port, so it'd be easy to attach LCDs. > - it is tested on QNX 6.3.2 and should work with later versions too... Hmm... the Audrey uses something "earlier than 6.1" (using libc.so.1, apparently). I don't tend to use QNX often, but I would be interested in seeing LCDproc on an Audrey (since I have more than one of them). Thanks for taking time to do up this submission. I look forward to fiddling with it in the future. -ethan From satzklauer at googlemail.com Tue Oct 6 05:55:40 2009 From: satzklauer at googlemail.com (Satz Klauer) Date: Tue, 6 Oct 2009 07:55:40 +0200 Subject: [Lcdproc] lcdproc ported for QNX [update] Message-ID: <2c26506d0910052255o19a5a86gb176007a0db8508b@mail.gmail.com> > Interesting. QNX appears in some "interesting" places, like the 3Com > Audrey - which also happens to have a serial port and a USB port, so > it'd be easy to attach LCDs. Not only there: QNX is a realtime system and as such used widely in industrial applications. And that could be a big deal for LCDproc because there displays are used very often :-) Attached you can find a new patch, now with all drivers included (I forgot some). This patch also applies to version 0.5.2 because I do not have CVS access here. -------------- next part -------------- A non-text attachment was scrubbed... Name: lcdprocQNX2.tar.gz Type: application/x-gzip Size: 5799 bytes Desc: not available URL: From npavel at ituner.com Mon Oct 12 06:51:55 2009 From: npavel at ituner.com (Nicu Pavel) Date: Mon, 12 Oct 2009 09:51:55 +0300 Subject: [Lcdproc] Changed picoLCD IR handling In-Reply-To: <4AC7678F.3050904@nurfuerspam.de> References: <35687.88.159.85.214.1252165003.squirrel@webmail.onsneteindhoven.nl> <4AC7678F.3050904@nurfuerspam.de> Message-ID: <1255330315.17197.3.camel@droids> Hi, The 20x4 lcd will have a hardware review, maybe we can solve that usb_clear_halt when receiving packets with a firmware update. Till then the patch for 20x2 can be applied. Thanks, Nicu Pavel > the patch compiles cleanly. For the docbook part a small change is > needed to make it work. > > Before committing this, I'd like to hear from the PicoLCD guys whether > it still works on 20x4 displays. > > Regards > Markus > _______________________________________________ > LCDproc mailing list > LCDproc at lists.omnipotent.net > http://lists.omnipotent.net/mailman/listinfo/lcdproc > From bsdfan at nurfuerspam.de Tue Oct 13 03:48:12 2009 From: bsdfan at nurfuerspam.de (Markus Dolze) Date: Tue, 13 Oct 2009 05:48:12 +0200 Subject: [Lcdproc] lcdproc ported for QNX [update] In-Reply-To: <2c26506d0910052255o19a5a86gb176007a0db8508b@mail.gmail.com> References: <2c26506d0910052255o19a5a86gb176007a0db8508b@mail.gmail.com> Message-ID: <4AD3F87C.6070901@nurfuerspam.de> Satz Klauer wrote: >> Interesting. QNX appears in some "interesting" places, like the 3Com >> Audrey - which also happens to have a serial port and a USB port, so >> it'd be easy to attach LCDs. >> > > Not only there: QNX is a realtime system and as such used widely in > industrial applications. And that could be a big deal for LCDproc > because there displays are used very often :-) > > Attached you can find a new patch, now with all drivers included (I > forgot some). This patch also applies to version 0.5.2 because I do > not have CVS access here. > Hi, a patch against 0.5.3 has been submitted to https://sourceforge.net/tracker/?func=detail&atid=300119&aid=2876969&group_id=119. In its current form I am not happy with the patch. Scattering machine (or compiler dependend) #ifdef's accross our code is not what I would like to do. This is what the configure script is intended for. To proceed I will first take into account the improvements on C language, then see how to proceed with the system depended configure parts. Regards, Markus From satzklauer at googlemail.com Wed Oct 14 05:22:25 2009 From: satzklauer at googlemail.com (Satz Klauer) Date: Wed, 14 Oct 2009 07:22:25 +0200 Subject: [Lcdproc] lcdproc ported for QNX [update] In-Reply-To: <4AD3F87C.6070901@nurfuerspam.de> References: <2c26506d0910052255o19a5a86gb176007a0db8508b@mail.gmail.com> <4AD3F87C.6070901@nurfuerspam.de> Message-ID: <2c26506d0910132222g506877a6ga4a6f2e5683c24ad@mail.gmail.com> > In its current form I am not happy with the patch. Scattering machine > (or compiler dependend) #ifdef's accross our code is not what I would > like to do. This is what the configure script is intended for. The preprocessor conditionals I added to the code have been used for includes and constant definitions that are completely different for QNX. I cant imagine a way to handle them within configure or in an other, transparent way (except the method to redefine them somehow but that is not transparent for other developers). So what do you suggest how the constants and includes that are different to other operating systems can/should be handled? Beside of that: there are already different OS-dependent conditionals within the code, I only added them the same way because they have been there... Elmi From bsdfan at nurfuerspam.de Mon Oct 19 20:50:28 2009 From: bsdfan at nurfuerspam.de (Markus Dolze) Date: Mon, 19 Oct 2009 22:50:28 +0200 Subject: [Lcdproc] Problem with picoLCD keylights Message-ID: <4ADCD114.1030009@nurfuerspam.de> Hi, while preparing the commit for the picolcd IR handling patch I found that picoLCD_init () contains these lines (line 282 up): if (p->backlight) picoLCD_backlight(drvthis, 1); if (! p->keylights) set_key_lights(p->lcd, p->key_light, 0); else picoLCD_backlight(drvthis, 0); It looks like some braces are missing like this: if (p->backlight) { ... } else My question: 1. What is picoLCD_init supposed to do if the keylights are enabled? Should there be a set_key_lights(..., 1)? Can someone clearify to me how the keylights & backlight is supposed to work, please? Regards, Markus From bsdfan at nurfuerspam.de Mon Oct 19 21:12:55 2009 From: bsdfan at nurfuerspam.de (Markus Dolze) Date: Mon, 19 Oct 2009 23:12:55 +0200 Subject: [Lcdproc] lcdproc ported for QNX [update] In-Reply-To: <2c26506d0910132222g506877a6ga4a6f2e5683c24ad@mail.gmail.com> References: <2c26506d0910052255o19a5a86gb176007a0db8508b@mail.gmail.com> <4AD3F87C.6070901@nurfuerspam.de> <2c26506d0910132222g506877a6ga4a6f2e5683c24ad@mail.gmail.com> Message-ID: <4ADCD657.8000404@nurfuerspam.de> Satz Klauer wrote: >> In its current form I am not happy with the patch. Scattering machine >> (or compiler dependend) #ifdef's accross our code is not what I would >> like to do. This is what the configure script is intended for. > > The preprocessor conditionals I added to the code have been used for > includes and constant definitions that are completely different for > QNX. I cant imagine a way to handle them within configure or in an > other, transparent way (except the method to redefine them somehow but > that is not transparent for other developers). Including was incorrectly used in some files. While on most systems errno.h is just a symlink to sys/errno.h, including the latter is wrong. This has been fixed in CVS. > > So what do you suggest how the constants and includes that are > different to other operating systems can/should be handled? For the other differences I am looking for a way to get this handled by configure: - hardware control lines for serial ports - SA_RESTART for sigaction() > > Beside of that: there are already different OS-dependent conditionals > within the code, I only added them the same way because they have been > there... > Yes, currently OS-dependent part are used in the lcdproc client (machine_xyz.c) and server/drivers/port.h. Besides the discussion above you should note that LCDproc makes use of some C99 language features (the list may be incomplete): - inline functions - variable-length arrays - one-line comments beginning with // - long long int type - mixed declarations and code Thus, if you don't want to rewrite large portions of LCDproc you are required to use a compiler that has the above features. Most versions of GCC are fine. Regards, Markus