LCDproc development and user support list

Text archives Help


[Lcdproc] CrystalFontz 633 Support?


Chronological Thread 
  • From: gary AT s4f.com (Gary Buckmaster)
  • Subject: [Lcdproc] CrystalFontz 633 Support?
  • Date: Wed Oct 20 00:32:02 2004

Although the temperature settings are kind of neat, ultimately my goal for
the CF633 is to use it as an interface to allow clients to set basic network
configurations for a server appliance. Once the appliance is up and online,
the CF633 will be used to display basic useful system stats like load,
memory useage, etc. I've gotten LCDd working properly from one of the
nightly builds, but as you pointed out David, the lcdproc client is badly
broken with regards to this device. As a result, I'm looking at the
possibility of using Wayne Wylupski's perl module to hack together a client
to fulfill these needs. Assuming that his module talks to the daemon
properly, I should (in theory) be able to hack together what I need.

Best,

Gary

-----Original Message-----
From:
lcdproc-admin AT lists.omnipotent.net
[mailto:lcdproc-admin AT lists.omnipotent.net]On
Behalf Of David GLAUDE
Sent: Tuesday, October 19, 2004 5:44 PM
To: Stewart W. Putnam
Cc: Gary Buckmaster;
LCDproc AT lists.omnipotent.net
Subject: Re: [Lcdproc] CrystalFontz 633 Support?


Status is that I think I wrote the initial code for CF633.
I guess both for 0.4.x and 0.5.x

Then there was an issue with copyright of the tiny part that
Crystal-Fontz wrote (mostly in the cfontz633IO files).

Then I wrote a IO file without any Crystal Fontz demo code (using
LCD4Linux code and credit where credit is due)

Then the problem with Crystal Fontz started to solve and using my
initial version was becoming OK.

Then there was the 631 that I received and some other developpers too...
but we failed to coordonate our effort to code the small differences
between 633 and 631.

So the code of 633 was to be modified to adapt for both 631 and 633.

Now because of the above copyright issue, none of the official release
contain the CF633 code... wich is still happily in CVS and more likely
working.

Then Stewart came with yet another fork of the original with temperature
feature.

I never wanted to do temperature monitoring (or fan) without the proper
support in the core of LCDd. Having hardware specific feature is not
really the goal of LCDproc... abstraction of commonly available feature
is what we try to accomplish.

So I understand that CF633 inside LCDproc is a total mess... and it is
partially my fault and I am ashamed of the result of my colaboration
with Crystal Fontz.

I have however consumed all the free-time I planned to dedicate to that
piece of code and real live did hurt with other priority (new baby, job
exam, ...).

There are however other developer with the necessary hardware (631 and
633) that might solve this mess... and I might free some time one day or
another (but not soon).

Anybody with coding skill and hardware, feel free to jump in and try to
fix this story. You will have my help (if I can help by email) for any
question on the historical code in CVS (assuming I don't need to setup
my LCDproc developement lab).

About Stewart Fan/Temperature feature-add, I did not understand
completely what was the point... but I think the code send to the log
what is reported by the hardware. If it is what I think, this break a
little bit the client server thing where LCDd and the client might be on
separte hardware. Also it mean temperature is not transported in the
protocol and everything. I believe it is a fast hack to get some support
for temperature support, but this might not be welcome in LCDproc since
it break so many concept already build in the architecture. It does not
mean it can not be a patch or in CVS as another driver or ... but I
don't see it fit completely with LCDproc.

You might want to have a look at LCD4Linux (as I did) to see how
Temperature and Fan are supported. For standalone application it might
be enough.

I hope it help and it is not too confuse.

David GLAUDE

Stewart W. Putnam wrote:
> I'm actively fishing for some feedback on my driver mod, though I'm
> kind of backed off active revision for the moment. ( I glance at the
> sceen to see that it has been up since boot & not crashed for a couple
> hours now...) My mod is expansive enough I think my next step would
> be to read up on how to use CVS and include my versian as a separate
> driver, say 'cd633+temps' or something because it is prabably still a
> lot buggier than the existing 633 driver...

--
Don't let computer expert control election...
Endorse: http://www.free-project.org/resolution/
For Belgium: http://www.poureva.be/

_______________________________________________
LCDproc mailing list
LCDproc AT lists.omnipotent.net
http://lists.omnipotent.net/mailman/listinfo/lcdproc





Archive powered by MHonArc 2.6.18.

Top of page