LCDproc development and user support list

Text archives Help


[Lcdproc] CrystalFontz 633 Support?


Chronological Thread 
  • From: dglaudemailing AT gmx.net (David GLAUDE)
  • Subject: [Lcdproc] CrystalFontz 633 Support?
  • Date: Wed Oct 20 07:21:02 2004

Gary Buckmaster wrote:
> 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.

You might want to use 0.5 and the client side menu feature.

I think someone already explained on this list (or said how to or what
he did) how to input IP addresses. I think the trick is to permit only
"01234567890." in an "input menu". Then one can enter an IP address by
moving the arrow key.

The definitive expert on menu is Joris.

> 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.

Did I say that the lcdproc client is badly broken???
lcdproc client is THE test suite for LCDd and it's driver.
The only problematic feature of lcdproc client is BigNum usage in BigClock.

So if you have problem with lcdproc driving CF633... there is a problem
with the CF633 driver you use. You might want to try each featured
screen of lcdproc client one by one to see wich are failing (and compare
that to curses driver or an X emulation of Matrix Orbital [if you find
it] or VGAlib driver [if it still exist]). You might want to try two
screen simultaniously or two lcdproc client simulatiously to see if the
"badly broken" is due to interaction between different screen (could be
problem with custom char allocation algorithm or with framebuffer that
is only visible with some set of screen).

Please report witch screen (lcdproc option) does fail and relevant LCDd
configuration file for you CF633 and date of your CVS snapshoot and
branch. This will make your experience reproducable and the bug fixable.

> 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.

There is more than one way (and more than one language) to write client.
There are also library to simplify or abstract the protocol.
The use of those library should help change the protocol without
breaking existing client... however 0.5 server should be backward
compatible with client talking 0.4 protocol.

Only the API between server and driver is strongly changed in 0.5
compare to 0.4.

David GLAUDE

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





Archive powered by MHonArc 2.6.18.

Top of page