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 15:07:01 2004

David,

I apologize. My statements regarding lcdproc may be based on an incorrect
understanding of the system architecture. Using the 0.5 tree I have
successfully gotten the LCDd process running, and am able to see it
displaying a heartbeat indicator to the CF633. Running the lcdproc client
passing any single or combination of screen parameters has no effect other
than to cause the CF633 to dim during the duration of lcdproc's run,
otherwise I see no visible output from the lcdproc client. I see no
difference in performance if I run lcdproc as root or as a normal user,
there is still no output to the screen.

I'm sorry if I'm driving you guys nuts with newbie mistakes, I went as far
as I could with the available documentation.

-Gary

-----Original Message-----
From: David GLAUDE
[mailto:dglaudemailing AT gmx.net]
Sent: Wednesday, October 20, 2004 2:20 AM
To:
LCDproc AT lists.omnipotent.net
Cc: Gary Buckmaster
Subject: Re: [Lcdproc] CrystalFontz 633 Support?


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