please verify that lcdproc is GPL

A

anonymous_putterer

New member
About a month ago I downloaded the lcdproc CVS tarball and started modifying it to use the 633's fan and sensor capabilities. I've brought my version to a point where I feel that I could share my work without writhing in embarassment... my 4 college credits in C from 14 years ago leaves me wondering...

The lcdproc site (www.lcdproc.org) says 2004-7-21:
"We have received a GPL'ed version of the interfacing code for the CF631/633 from Brent Crosby at Crystal Fontz. This means that all copyright issues have been resolved and we can continue working on the driver. Thanks a lot Brent!"

Being a stickler for dotting i's and crossing t's and what can be well said in a court of law, I just want to verify that I may share a modification under the GPL.

Thankyou.
Crystalfontz LCD Blog
Looking for additional LCD resources? Check out our LCD blog for the latest developments in LCD technology.
 
A

anonymous_putterer

New member
If you dowload thier
http://lcdproc.sourceforge.net/nightly/lcdproc-CVS-current.tar.bz2
and build that and it works for you, then you can unpack this zip, follow the iinstructions in its' README, and enjoy temperature monitoring, fan adjustment, and temperature controlled fans with lcdproc / linux.

10/12/04
-- I found some critical SEGFULT causing errors in lcd screen creation. Updated the .zip here. My appologies two of you who have downloaded this in the last week.

02 17 05
fixed crashing on long temp fan names and ReportLevel > 3
added one extra widget when odd nember of screens are generated
put commas in syslog reports so 'grep 633data /.../syslog' gives a *.csv -like file for OpenOffice.org Calc
todo: might be not starting regularly on boot with 25 + sensors attatched ?
 

Attachments

Last edited:
A

anonymous_putterer

New member
Error in my driver mod

I noticed yesterday that if I set
ReportLevel=4 or
ReportLevel=5
in LCDd.conf AND have temperature names longer than 6 characters my driver crashes on load.
It seems to not crash :with (ReportLevel <=3 ) && (long temperature names)
It seems to not crash :with (ReportLevel >=4 ) && ( short temperature names)
in my case:
633T13_Name=ca_air
works, while:
633T13_Name=case_air
crashes.
(replacing sprintf with snprintf is I think the solution when I have the time ...)

2/18/05 Fixed I hope, fresh dowload above.
 
Last edited:
A

anonymous_putterer

New member
So here's my latest.

Downlad the latest lcdproc and make sure that it is working without my modifications first please! LCDproc is under active development, so if it doesn't work one day, hang in and try the next.

quickie instructions:

Put my .zip in the lcdproc top dir.
Unzip it.
'make clean'
'make install'

( & by all means PM me or post here if that fails.)

To enable & control fan and temp functions, look over the new 'LCDd.conf-lines' files in the top of the lcdproc source directory. Cut and paste relevant lines into your LCDd.conf [cfontz633] section.

With this version, I advise setting reportlevel to 4 or 5 only for debugging. Level 5 might dump gigabytes / hour into syslog.
 

Attachments

C

CF Mark

Administrator
Well done.

Have you been in contact with the lcdproc guys about including your patch in the main lcdproc source?
 
A

anonymous_putterer

New member
Oh yes,
I'm no pro programmer, and it is a lot of code for anyone to have to double check. The whole CVS system is new to me as well, so my slowness in how to participate in that framework is also something.

There has been discussion on the lcdproc devel mailing list as to whether / and or how the fan and temp functionality of the 633 / SCAB enabled 63x's could / should / would integrate cleanly into the main focus of lcdproc or compliment it as an available option.

As a true hobbyist programmer with an unlimited licence in the 'Can't do that now, gotta go pcik fleas off my dog and scratch my butt' department, I find lcdproc quite alright.

Feedback welcome: nit picky word choice in configuration files & documentation to pointing out things that 'anyone whose taken a progamming class would know' to advanced issues in debugging cloned / forked / multithreaded applications ... mere mention that anyone actually installed it and made it work and thinks it is 'OK' or even maybe 'neat' ...
 
C

corvus

New member
latest CVS?

I am trying to get it to run but I had to add some stuff to the server/drivers/Makefile CFontz633_SOURCES line from your server/drivers/Makefile.am and then I still get:

Aug 9 01:18:32 dot LCDd: Could not open driver module /usr/local/lib/lcdproc/CFontz633.so: /usr/local/lib/lcdproc/CFontz633.so: undefined symbol: machine_init
Aug 9 01:18:32 dot LCDd: Driver [CFontz633] binding failed
Aug 9 01:18:32 dot LCDd: Could not load driver CFontz633

Lines added to CFontz633_SOURCES:

CFontz633_c.c CFontz633_c.h ../../clients/lcdproc/machine.h ../../clients/lcdproc/machine_Linux.c

Anyway...I'm in the process of getting it running and I sincerely appreciate the work you've done! Let me know if you've tried it on the latest CVS of lcdproc (later than Aug 9th) and I'll keep poking around with the Makefile until it works.
 
C

corvus

New member
It works!

Added a machine_Linux.o to the server/drivers/Makefile:

am_CFontz633_OBJECTS = CFontz633.$(OBJEXT) CFontz633io.$(OBJEXT) CFontz633_c.$(OBJEXT) ../../clients/lcdproc/machine_Linux.$(OBJEXT)

And unresolved symbols are resolved. I also had to set the Speed to 115200 to get LCDd to work with my USB 635.

Looks great!
 
A

anonymous_putterer

New member
Thankyou :)

LCDproc uses automake ( which I'm not particularly familiar with ) to generate the Makefile from a file Makefile.am. Modifying the Makefile directly is a round about fix; I'll have to read up a little to understand what's happening with this.

The machine*.h files are in the lcdproc/ clients/ lcdproc directory, and are used in reading the CPU and or memory usage info for the 'lcdproc C M X' I linked to them for that info and it looks like I didn't include them exactly properly.

Anyone with a similar symbols error might try a 'make clean' from the top lcdproc directory after applying my patch. This might rebuild the machine*.* along with my driver patch without having to edit the Makefile directly, perhaps.
 
C

corvus

New member
automake

Ah, I didn't rerun autogen/automake and went the long way instead.

This is OT I guess, but do you have any idea why when I run lcdproc the backlight always turns off on the lcdproc screen and then back on for the CFontz633 screen? I couldn't find a setting for lcdproc that kept the backlight on.
 
A

anonymous_putterer

New member
I've fixed several things in the "Why does it crash or hang on loading every once in a while," and "Wy does that line not update only some of the time" departments.

This version adds integrated support for lm-sensors, and will only build with the libsensors and libsensors-dev packages already installed.

There are also new LCDd.conf entries that permit you to track how much cpu any particular process is using. That is you could track mysqld or apache or XFree86 wheather or not they are at any moment one of the top cpu hoggs.

Make sure that your lcdproc-CVS-current-200ymmdd builds and installs as is. Copy the zip file into lcdproc-CVS-current-200ymmdd. Read the README.fan-temp.

This has been tested with scripts for a thousand start-stops on a 32bit single CPU Debian Sarge install with a 631 + SCAB. 633 & 635 + SCAB. ( Things may be different with multiple CPUs or cores or 64 bit, AFAIK. )
 

Attachments

A

anonymous_putterer

New member
I found a serious error that is in at least the last three versions that I posted.

Quick fix -- find the line in CFontz633.c, server/drivers/CFontz633.c :

if (p->q_depth < 64) usleep(20);

and replace it with

usleep(1000);

That is line 4360 in the full featured version from December 2005. Line 3297 in the lighter version of March 2006.

If you ran a lot of fast updating screens so that the que of packets to the display became deeper than 64, my driver would enter an unchecked full-throttle loop and attempt to use 100% CPU.

Or if you ran my driver on a machine already loaded to 100% CPU so the driver ran slow and the que reached over 64, then this bug would hit and attemt to take 100% CPU as well...
 
A

anonymous_putterer

New member
Lots of little fixes too.

Unzip this download in the top of a lcdproc nightly tarball tree that is already building, and installing and functioning for you. Then read the README.fan-temp.
 

Attachments

A

anonymous_putterer

New member
I am cautious promoting my hobby project for thermal management. All the repititons of :

This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.

woudn't make me feel much better if I heard my software failed and someone's PC overheated. I'm always finding bugs in my own work.

Lots of positive replies from testers would make me less timid. Annyway, in 4 months I've gotten -- is it 4 ? -- dowloads and no replies.

More than thinking I've polished something off today, my latest spurt of creativity for this seems spent.

This is updated to work with the recently released lm-sensors-3.0.2.
Works with 633 or 631/635 + SCAB.
Uses pthreads: should be march independent.
Can read hddtemp, lmsensors data & drive CF63[135] fans based on that.
Can create screens about hddtemp, lmsensors & various proc / top / ps data beyond the normal lcdproc.
Can log all this in a *.csv file.
Includes htm format documentation.
 

Attachments

CF Tech

CF Tech

Administrator
This thread title "please verify that lcdproc is GPL" probably is not helping!

I would suggest making a new thread in this "3rd Party Software" forum labeled something like "Enhanced thermal monitoring package for LCDproc", and duplicate your post with a good description of the capabilities and download link in it. It also might be good to include a short "how to get it working" section.

For my part, I'll make it a sticky for you so it will not get buried. :)
 
You must log in or register to reply here.
Top