Linux LCDproc CFA-63x Fan Temp & Enhancements Driver with Source

This is a driver module enabling the LCDproc package to read temperatures and drive fans by temperature on a CFA-633 or CFA-631 / CFA-635 + SCAB control module. It can do more, but reading & recording of temperatures and fan management is the core functionality that should be solid and stable and supported across distributions / compilers / hardware.
  • This is updated to work with the recently released lm-sensors-3.0.2 (& previous ver.).
  • Works with CFA-633 or CFA-631 / CFA-635 + SCAB.
  • Uses pthreads: should be machine independent.
  • Can read hddtemp, lmsensors data & drive CFA-63x fans based on that.
  • Can create screens about hddtemp, lmsensors & various proc / top / ps data beyond the normal lcdproc.
  • Can log all this in the *.csv file as well.
  • Includes html format documentation.
  • Deviates significantly from lcdproc base and might therefore never be included in a standard lcdproc release.
  • If you are accustomed to building your own kernels and Linux packages from source it should be quite easy to build and install.
I am cautious promoting my hobby project for thermal management. All the repetitions 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.

wouldn'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. Detailed feedback from testers would make me less timid.

More than thinking I've polished something off today, my latest spurt of creativity has run it's course.
Looking for additional LCD resources? Check out our LCD blog for the latest developments in LCD technology.


I see Lenny is released and from a blurb at phoronix there is a new version of lm-sensors on the way.

In trying out Lenny I found that my driver and patches were compiling on my old install because I had a messy collection of *.deb and source lm-sensors. It makes me think: wow, nobody ever PM'd me with any such problem.

I'll be putterring away making myself a fresh 64 bit Lenny install and playing catch up with the the new lm-sensors when it is released.

So it would be a great time for anyone using this to send feedback: from minor typos or unclear wording in the instructions to wished for features or show stopping bugs.



New member
Just noticed this upgrade to lcdproc, but I'm a complete n00b with linux. I'm running the latest version of 64-bit Ubuntu, and have lcdproc working with a CFA-635, although it just does some simple things like displays time, date, and uptime.

Can someone give a linux pedestrian, like me, a step-by-step guide into how to implement these seemingly great upgrades to lcdproc - without clobbering my OS? I'd certainly be most grateful to having my wonderful SCAB back again under linux.

I have a version that works for me on debian Lenny 64 bit 2.6.26 kernel.
I've been staring at an apparent bug for oh, ten months now. The bug might be something in the 2.2.26 kernel that makes it look like my LCDd driver is using 100 times more cpu than it did on a 2.6.18 32 bit kernel.
[ edit: fix <table> <\table> here>
<table border="0" width="100%" cellpadding="0" cellspacing="0" align="center">
top - 20:58:23 up 16 min, 2 users, load average: 0.11, 0.20, 0.14
Tasks: 111 total, 4 running, 107 sleeping, 0 stopped, 0 zombie
Cpu(s): 0.5%us, 0.5%sy, 0.0%ni, 99.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Mem: 2058716k total, 704112k used, 1354604k free, 17288k buffers
Swap: 3068372k total, 0k used, 3068372k free, 297220k cached

5000 root 20 0 56448 1596 1056 S 4 0.1 0:13.94 LCDd
5049 stew 20 0 527m 115m 26m S 3 5.7 0:30.55 firefox-bin
5304 root 20 0 18824 1268 944 R 1 0.1 0:00.04 top
4572 root 20 0 874m 34m 13m R 1 1.7 0:19.79 Xorg
4985 root 20 0 220m 17m 9.8m R 1 0.9 0:04.37 gnome-terminal
but if the system in 99% idle, how can LCDd be using 4% ? The top command is accurately reporting what the kernel tells it, so a bug in the kernel scheduler's record keeping? ... Look at the difference in man proc for /proc/[number]/stat between 2.618 and 2.6.26 kernels ... bug crept in there?

I've been thinking of packaging my latest nice and tidy, as simple as possible to install, with a nod to this bug.
But I'm not there.
For the moment, here is something packaged more sloppily.
If you have the last version of lcdproc + 63oddtf that built and ran for you, you should be able to drop in this server/drivers/CF63oddtf.[ch], rerun ./configure on a 64 bit os , and be up and running. ( For those that know more about patching, the & etc are against lcdproc 0.5.2 I think; sh & etc. )

The LCDd.conf entries have not changed.
lcdproc 0.5.3 is available from sourceforge but not last I checked, btw. Go figure ;)

For the time being, anyone trying to make this download work, please Private Message me & help keep this thread sparse and lean. Anything that gets figured out will go into instructions in a future download, thankyou.


Last edited:
Here is a patch to build oddtf with lcdproc 0.5.3 from sourceforge. See the readme.CF63oddtf in the download.

I'm going with the thought that the bug that has been bugging me is in the 2.6.26 kernel, not in CF63oddtf. A brief on how this bug would appear to a user is in the readme-CF63oddtf-bug.html file.



New member
Hey there,

I've just rigged this up with lm_sensors 3.0.3 and LCDproc 0.5.3 (since the apply-patches doesn't seem to like 0.5.4)
Although it's all working so far, would there possibly be an update for 0.5.4 in the future?
(does it matter?)

(have a 635 w/scab w/4 temp probes and would like to PWM control the 3 fans hooked to the SCAB based on temp)

Also, pardon my thickness, but is there a doc somewhere that describes better the syntax for the LCDd.conf section for the CF63oddtf driver?

Thanks a huge bunch,

This is what I've been using on Debian Squeeze. The patches applied and built cleanly for me against ( 5.4 today ). Only a few minor changes in the driver. (dpkg-query -W lm-sensors gives me : "lm-sensors 1:3.1.2-6" -- please report on any incompatibility.)
You can, for better documentation, build docs/lcdproc-user/lcdproc-user.html
cd docs/lcdproc-user
xmlto xhtml-nochunks lcdproc-user.docbook --skip-validation
The file LCDd.conf-oddtf-chunk is my current [63oddtf] section, and syslog.oddtf is the resulting startup on ReportLevel=4.


Last edited:
This applies to lcdproc-0.5.5 stable.
Adds several ways to use the left hand leds on a 635. Minor bug fixes & efficiency tunes. Updated doc/lcdproc-user html documentation.
I'm looking at how to best add a measure of dynamic cpu frequency scaling in the .csv log; another update soon perhaps.

[The lcdproc domains are down atm. I'll upload the 0.5.5 stable tarball here -- for now ... maybe that's innapropriate? ]


Last edited:
make install started reporting an error today:
/usr/bin/install: will not overwrite just-created `/usr/lib/lcdproc/' with `'
make[3]: *** [install-pkglibPROGRAMS] Error 1
I think now that install has been overwriting without complaining for four years+. Something changed in my build envrionment is now checking for and forbidding this overwriting.
The cause of this has been in my acinclude.m4 patch.
grep oddtf acinclude.m4 -n | grep DRIVERS
80:			DRIVERS="$DRIVERS CF63oddtf${SO}"
89:			  	DRIVERS="$DRIVERS CF63oddtf${SO}"
Edit acinclude.m4 and delete the second line completley.
Rerun and configure.
Last edited:


New member
Applies to 2013 02 12 nightly tarball. Bugfixes. One new option in [CF63oddtf] HeartBeat=0 disables the heartbeat on driver-client screens.
i'm having a little trouble here with building this. can you help?
[root@router1 lcdproc-0.5.5]# ./patch-apply
patching file server/drivers/
Hunk #1 FAILED at 23.
Hunk #2 FAILED at 37.
Hunk #3 succeeded at 80 with fuzz 2 (offset -4 lines).
2 out of 3 hunks FAILED -- saving rejects to file server/drivers/
patching file acinclude.m4
Hunk #1 FAILED at 8.
Hunk #2 FAILED at 22.
Hunk #3 succeeded at 76 (offset 9 lines).
Hunk #4 succeeded at 151 (offset 9 lines).
Hunk #5 succeeded at 517 (offset -34 lines).
2 out of 5 hunks FAILED -- saving rejects to file acinclude.m4.rej
patching file docs/
Hunk #1 succeeded at 93 with fuzz 2 (offset 3 lines).
patching file docs/lcdproc-user/drivers.docbook
Hunk #1 succeeded at 11 with fuzz 2 (offset 1 line).
patching file docs/lcdproc-user/lcdproc-user.docbook
Hunk #1 succeeded at 18 with fuzz 2 (offset 1 line).
Running aclocal ...
Running autoheader...
Running automake ...
server/drivers/ `pkglibdir' is not a legitimate directory for `PROGRAMS'
server/drivers/ variable `CF63oddtf_SOURCES' is defined but no program or
server/drivers/ library has `CF63oddtf' as canonical name (possible typo)
Running autoconf ...
[root@router1 lcdproc-0.5.5]# sh ./
Running aclocal ...
Running autoheader...
Running automake ...
server/drivers/ `pkglibdir' is not a legitimate directory for `PROGRAMS'
server/drivers/ variable `CF63oddtf_SOURCES' is defined but no program or
server/drivers/ library has `CF63oddtf' as canonical name (possible typo)
Running autoconf ...
[root@router1 lcdproc-0.5.5]# ./configure --enable-drivers=all --bindir=/usr --sbindir=/usr --libexecdir=/usr --sysconfdir=/etc --sharedstatedir=/usr/share --enable-debug
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... /bin/mkdir -p
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking build system type... x86_64-unknown-linux-gnu
checking host system type... x86_64-unknown-linux-gnu
checking whether to enable debugging... yes
checking for gcc... gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables...
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking for style of include used by make... GNU
checking dependency style of gcc... gcc3
checking how to run the C preprocessor... gcc -E
checking for ranlib... ranlib
checking whether gcc and cc understand -c and -o together... yes
checking for xmlto... no
checking CFLAGS for gcc -Wno-unused-function... -Wno-unused-function
checking CFLAGS for gcc -ftrampolines... no, unknown
checking for gethostbyname... yes
checking for connect... yes
checking for inet_aton... yes
checking for kstat_open in -lkstat... no
checking for nanosleep in -lposix4... no
checking for getloadavg... yes
checking for swapctl... no
checking for grep that handles long lines and -e... /bin/grep
checking for egrep... /bin/grep -E
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking procfs.h usability... no
checking procfs.h presence... no
checking for procfs.h... no
checking sys/procfs.h usability... yes
checking sys/procfs.h presence... yes
checking for sys/procfs.h... yes
checking sys/loadavg.h usability... no
checking sys/loadavg.h presence... no
checking for sys/loadavg.h... no
checking utmpx.h usability... yes
checking utmpx.h presence... yes
checking for utmpx.h... yes
checking for kvm_open in -lkvm... no
checking for kvm_open in -lkvm with -lelf... no
checking sched.h usability... yes
checking sched.h presence... yes
checking for sched.h... yes
checking for sys/types.h... (cached) yes
checking machine/pio.h usability... no
checking machine/pio.h presence... no
checking for machine/pio.h... no
checking machine/sysarch.h usability... no
checking machine/sysarch.h presence... no
checking for machine/sysarch.h... no
checking sys/cpuvar.h usability... no
checking sys/cpuvar.h presence... no
checking for sys/cpuvar.h... no
checking machine/apm_bios.h usability... no
checking machine/apm_bios.h presence... no
checking for machine/apm_bios.h... no
checking for System V IPC headers... yes
checking for union semun... no
checking for machine/cpufunc.h... no
checking for sched_setscheduler... yes
checking for sched_setscheduler in -lposix4... no
checking for sched_setscheduler in -lrt... yes
checking for i386_get_ioperm in -li386... no
checking for i386_get_ioperm in -lc... no
checking for iopl... yes
checking for ioperm... yes
checking sys/io.h usability... yes
checking sys/io.h presence... yes
checking for sys/io.h... yes
checking for a parallel port... yes
checking linux/i2c-dev.h usability... yes
checking linux/i2c-dev.h presence... yes
checking for linux/i2c-dev.h... yes
checking for dirent.h that defines DIR... yes
checking for library containing opendir... none required
checking for ANSI C header files... (cached) yes
checking fcntl.h usability... yes
checking fcntl.h presence... yes
checking for fcntl.h... yes
checking sys/ioctl.h usability... yes
checking sys/ioctl.h presence... yes
checking for sys/ioctl.h... yes
checking sys/time.h usability... yes
checking sys/time.h presence... yes
checking for sys/time.h... yes
checking for unistd.h... (cached) yes
checking for sys/io.h... (cached) yes
checking errno.h usability... yes
checking errno.h presence... yes
checking for errno.h... yes
checking limits.h usability... yes
checking limits.h presence... yes
checking for limits.h... yes
checking kvm.h usability... no
checking kvm.h presence... no
checking for kvm.h... no
checking sys/param.h usability... yes
checking sys/param.h presence... yes
checking for sys/param.h... yes
checking sys/dkstat.h usability... no
checking sys/dkstat.h presence... no
checking for sys/dkstat.h... no
checking for sys/sysctl.h... yes
checking for sys/pcpu.h... no
checking for SA_RESTART... yes
checking for an ANSI C-conforming const... yes
checking for inline... inline
checking for size_t... yes
checking whether time.h and sys/time.h may both be included... yes
checking whether struct tm is in sys/time.h or time.h... time.h
checking for uid_t in sys/types.h... yes
checking whether gcc needs -traditional... no
checking return type of signal handlers... void
checking for select... yes
checking for socket... yes
checking for strdup... yes
checking for strerror... yes
checking for strtol... yes
checking for uname... yes
checking for cfmakeraw... yes
checking for snprintf... yes
checking for getopt... yes
checking for your mounted filesystem table... /etc/mtab
checking for fcntl.h... (cached) yes
checking sys/dustat.h usability... no
checking sys/dustat.h presence... no
checking for sys/dustat.h... no
checking for sys/param.h... (cached) yes
checking sys/statfs.h usability... yes
checking sys/statfs.h presence... yes
checking for sys/statfs.h... yes
checking sys/fstyp.h usability... no
checking sys/fstyp.h presence... no
checking for sys/fstyp.h... no
checking mnttab.h usability... no
checking mnttab.h presence... no
checking for mnttab.h... no
checking mntent.h usability... yes
checking mntent.h presence... yes
checking for mntent.h... yes
checking utime.h usability... yes
checking utime.h presence... yes
checking for utime.h... yes
checking sys/statvfs.h usability... yes
checking sys/statvfs.h presence... yes
checking for sys/statvfs.h... yes
checking sys/vfs.h usability... yes
checking sys/vfs.h presence... yes
checking for sys/vfs.h... yes
checking sys/filsys.h usability... no
checking sys/filsys.h presence... no
checking for sys/filsys.h... no
checking sys/fs_types.h usability... no
checking sys/fs_types.h presence... no
checking for sys/fs_types.h... no
checking for sys/mount.h... yes
checking for getmntinfo... no
configure: checking how to get filesystem space usage...
checking for statvfs... yes
checking module extension... .so
checking for dlopen in -ldl... yes
checking for shl_load in -ldld... no
checking if libusb support has been enabled... yes
checking for pkg-config... /usr/bin/pkg-config
checking pkg-config is at least version 0.9.0... yes
checking for LIBUSB... no
checking if libftdi support has been enabled... yes
checking for LIBFTDI... no
checking if libhid support has been enabled... yes
checking for LIBHID... no
checking if ethlcd support has been enabled... yes
checking for doxygen... no
configure: checking which drivers to compile...
checking for select... (cached) yes
checking sys/select.h usability... yes
checking sys/select.h presence... yes
checking for sys/select.h... yes
checking for select... (cached) yes
checking for sys/select.h... (cached) yes
checking ncurses.h usability... yes
checking ncurses.h presence... yes
checking for ncurses.h... yes
checking curses.h usability... yes
checking curses.h presence... yes
checking for curses.h... yes
checking for main in -lncurses... yes
checking for ncurses.h... (cached) yes
checking for acs_map in curses.h... yes
checking for redrawwin() in curses... yes
checking for wcolor_set() in curses... yes
configure: error: Unknown driver ea65
[root@router1 lcdproc-0.5.5]# make
cd . && /bin/sh /tmp/lcdproc-0.5.5/missing --run automake-1.11 --foreign
server/drivers/ `pkglibdir' is not a legitimate directory for `PROGRAMS'
server/drivers/ variable `CF63oddtf_SOURCES' is defined but no program or
server/drivers/ library has `CF63oddtf' as canonical name (possible typo)
make: *** [] Error 1
[root@router1 lcdproc-0.5.5]#
The LCDproc source has changed since I made that patch set & the patch program can't see how to change the newer LCDproc code as requested. I'm posting my saved copy of the lcdproc nightly tarball for which the patch above was built. :)p I probably missnamed the save *2012* when I saved it on 20130212 ). I will also set to making a new patch.



New member
Hi, this doesn't work for me. :( Compiling is fine, but getting an segfault after replacing the driver. It works with CFontzPacket but not with CF63oddtf.

I'm running Gentoo with Kernel 3.15.3 and glibc 2.17

kernel: LCDd[9740]: segfault at e ip 00007f3c36ece5df sp 00007fff77161e00 error 4 in[7f3c36e80000+1a0000]
Tried your patches with lcdproc-0.5.7-pre1 and lcdproc-0.5.7 final.
Last edited:
I've not used gentoo. Send me your configure log and build log please. You can send it through the private messaging of the forums. You could also build LCDproc with --enable-debug and set ReportLevel=5 in LCDd.conf and send me that too; it's less precice than gdb but it would show what is working and roughly how far into loading or recursing the module gets.

You can turn off some driver functionality by undefining 14 CLIENT_CHILD , 19 TIMING_REPORT , 27 DO_ULT , 30 DO_LM , 32 DO_HDD , 37 PROTOCOL_CHEATING ( LINE #, BLOCK_NAME)

By process of elimination & minimal effort you might get a stripped down driver working.

With a segfault in glibc i would rebuild
from scratch for gdb & trap the sf that way most precisely. running gdb on a multithreaded & moduled app is complicated. There are notes in CFoddtf.Changelog: new configure options, & perhaps comment out dlclose() in server/main.c so the module's debug symbols do not get flushed on termination.

gentoo is a source based distro yes? you are accustomed to compiling with minor modifications?