LCDproc development and user support list

Text archives Help

[Lcdproc] Temperature or Fan Functions at the driver level

Chronological Thread 
  • From: dglaudemailing AT (David GLAUDE)
  • Subject: [Lcdproc] Temperature or Fan Functions at the driver level
  • Date: Thu Oct 21 19:24:01 2004

Stewart W. Putnam wrote:
>> 2) Implement hardware specific feature in the driver and "tunnel" the
>> new message to that driver inside the protocol.
>> Solution N°2 is possible and was discussed on this list. The main
>> problem is that a client will have to be aware of hardware specifics
>> feature and way to talk to it.
>> But a better "tunnel" can be build for any hardware specifics feature.
> This seems the more practicable. I'll search for it in the list
> archives, but oculd you send me a pointer to the relevant thread(s)?
> I'd feel out of place saying much without reading up first. Do I gather
> this 'tunnel' and a 'client will ... aware of hardware specifics feature
> and way to talk to it' idea is so far an idea: i.e. there is no example
> of this in existing code that I might study?

No, there is no code to study yet.

I think you will have to call to the background knownledge of this list.
It was part of 0.5 API discussion where we openend the door for that way
of doing things. I don't know if the door is open, in documentation or
only in our colective mind.

>> So maybe one can write an lm-sensor driver that export some FAN/TEMP
>> function. But first we need to brainstorm on how to best integrate
>> that in the protocol and in the API.
> I've only thought of this so far & read no lm-sensors code or
> development specs ... a lm-sensors 633 driver might handle all temp and
> fan functions via a 'real' connection to the 633 on /dev/ttySn, do
> nothing to the lcd screen, offer fan control and temp to any process (
> including lcd clients ) /proc-capable, and offer an emulated
> /dev/ttySn+1 (conforming to what the existing LCDproc driver expects) to
> LCDd for tunneled lcd display and keypress functions... All quite
> speculative for me ... high ovearhead on init and continuing realtime
> for both lm-sensors and lcdproc?

I was thinking about that, but expressing it was difficult.

Since the CF633 is packet based, it should be easy to have that kind of
"multiplexor" that talk to the device and provide filtred message to
LCDproc driver. If you "route" everything but FAN/TEMP related packet
(and acknowledgement) to the driver (be carefull in the initialisation
code we send command to disable every reporting). If you go for that
option, I would suggest you to put an option in CF633 to not treat or
generate FAN/TEMP related command.

If you get to build that piece of code, then we will have the begining
of a CF633 emulator (receiving command and sending acknoledgement). This
will be a very interesting piece of code. If they can do it in a small
"PIC-like" chip, we can do in in a small C program. ;-)

This might be the fastest path for you as it does not interract too much
with LCDproc code and it's arcane. Also if one day LCDproc support
lm-sensor, we will have two way to get the info... the multiplexor or
directly from the CF633 driver. ;-)


Don't let computer expert control election...
For Belgium:

Archive powered by MHonArc 2.6.18.

Top of page