LCDproc development and user support list

Text archives Help


[Lcdproc] Temperature or Fan Functions at the driver level


Chronological Thread 
  • From: stewartputnam AT comcast.net (Stewart W. Putnam)
  • Subject: [Lcdproc] Temperature or Fan Functions at the driver level
  • Date: Thu Oct 21 19:03:02 2004

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

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




Archive powered by MHonArc 2.6.18.

Top of page