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 16:00:02 2004

Stewart W. Putnam wrote:
> lcdproc drivers should provide a few hardware independent abstracted
> functions to the LCDd server: _init, _close, _get_key, _set_contrast,
> _backlight, _vbar & etc.

We have some limits that are not break yet...
1) we don't do graphical LCD (yet) or only in TXT emulation.
2) we don't do user/client provided icon
3) we don't don FAN / TEMP

1) We feel it is another project
2) There are too many issue with character size, number of custom
caracter... currently we stick (0.5) with a set of ICON to fit most
purpose. But it might be easy to change that limit.
3) We felt there were too few hardware with FAN / TEMP support and there
was no easy way to know how to best abstract something the seems to be
unique to a few device... the API=0.5 and protocol=0.3 need to be
changed to accomodate that.

> Anyone who want's to know why this is so, and
> why it makes sense to avoid elaborate temp or fan functions, could, say,
> read up on why Motherboard Monitor devolopment
> ( stopped.

This is not the same here:
1) We get all the info we want from vendor (or we don't even try)
2) We get sometime working driver code from vendor
3) We sometime get GPL code from vendor. ;-)
4) It is Free Software so source code is available and developer can
jump in or out of the development
5) We don't sign NDA !!!

> So it follows that a driver including such features should include
> them as wholly ignorable options that are turned off by default, and
> include these options without trampling on lcdproc's existing software
> architechture, client server model, & etc.

Not exactly.
There are two ways:
1) Change the API to include new command for that + add protocol command
to query or demand to display those information.
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.

> If one were to put merely a 'MODULE_EXPORT void
> CFontz633_send_bytes_message()' into the base driver for a 633 temp
> client to call, and allow a client to reserve the resulting fan and
> temperature response packets in the same way as clients can reserve
> keypad presses, one could build an elaborate fan / temp client with
> minimal modification to the base CF driver module, yes? Or is
> MODULE_EXPORT'ing a lower level multi-purpouse function like
> send_bytes_message() for a client's use impossible or a significant
> breach of lcdproc protocol / architechture?

It is possible... however it might not be "send bytes" but send "command".
The main issue is that the protocol is text based and sending bytes or
coding those byte to be printable is not very funny. The complexity and
the detail of managing the hardware should be left to the driver. The
client however knowlegable of the fact that there is a fan should not
know about the specific "bytes" to send.

There is already a breach for GPIO (General Purpose IO) that was first
for a single IO then for multiplie IO. However this is just a "byte"
value we set or get...

But a better "tunnel" can be build for any hardware specifics feature.
If we end with 3 or 4 hardware that support fan/temp, then maybe we will
find a way to use a common language to play with those concept and this
could be in the end added to the protocol.

Keypad was an issue because of the sharing of key...
Temperature is fine because any client could request any temperature
without disturbing the other.
Fan speed is the same, two client could read the fan speed simultaniously.
Fan control better be something exclusive that you reserve or two
clients might fight for controlling the speed (please notice that there
is no such mechanism for GPIO but we implemented something for key).

> For what I'm doing I'm thinking of whipping up a wholly standalone
> hack & mix of lm-sensors & the top utility to get a single logline with
> liquid flow rate, each cpu/mb/gpu temp, all the 633 temps before and
> after each water block, pump, filter, or radiator, and a short rank
> order listing of the top 3 or 4 cpu & memory & mb resource consumers at
> any given moment... A big project that might easily spin off an
> acceptable CF driver mod and client. Er..., why..., for making art out
> of waste heat of course... and fiendishly clever Rube Goldberg machines
> to get Batman once and for all...

LM-sensor has not been investigated yet...

But IRman and LIRC have been integrated as input (keypad) device.
It was rather easy, those driver only export the key function and
multiple input driver can be loaded simultaniously as one (currently
only one in most case) output driver.

One might imagin that there other "class" of "function" supported by
1) output=LCD
2) input=keypad
3) control=IO/FAN
4) Sensor=Temperature

Now some hardware do all those things.
Sometime you have to use IRman for input and LCD for output.

So now we get to the picture...
FAN and TEMP could be done by the LCD or by lm-sensor.

So this mean even if not all hardware support fan and temp, most mother
board can report something about CPU temperature.

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.

That must be done on the list.
But it will take time to convince, to see how to best integrate that
without slowing down 0.5 release, without breaking the protocol/API and
keep some backward compatibility...


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

Archive powered by MHonArc 2.6.18.

Top of page