LCDproc development and user support list

Text archives Help

[Lcdproc] Temperature or Fan Functions at the driver level

Chronological Thread 
  • From: joris AT (Joris Robijn)
  • Subject: [Lcdproc] Temperature or Fan Functions at the driver level
  • Date: Thu Oct 21 19:46:01 2004

On 21 Oct 2004 at 17:59, David GLAUDE wrote:

> We have some limits that are not break yet...
> 1) we don't do graphical LCD (yet) or only in TXT emulation.
...or if if fits right in the text-model.

> 2) we don't do user/client provided icon
...maybe we could support this partially. But it should also still fit in
the text-model.

> 3) we don't don FAN / TEMP
...because we don't know how to cleanly do it.

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

Nice pointer. I think we have enough drivers that lack maintenance
already ;)

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

Maybe it should be a command to get and set parameters. A simple
char* get_param( char* string )
void set_param( char* string, char *value )

If you would do get("parameters") you could get a ;-separated list of
available params.

No real parsing should be required in the the driver, because this can
open holes for exploits. So the LCDd core should make sure to have
filtered the requested parameter, should send it to the driver and should
verify the returned string. How this would be incorporated in the
protocol... Hmm you would first need to select a device to talk to.

Anyway it's just an idea... Shoot it if required.

> > If one were to put merely a 'MODULE_EXPORT void
> > CFontz633_send_bytes_message()' into the base driver for a 633 temp

I don't like this. You may get the device into a state that the driver
does not understand. I think the driver should be in control. With
parameters the driver is in control.

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

Yes that's a problem. How should the core know about all this...
It could ask reservable parameters from each device.

We could make "output" one of these parameters too... This way output
would also fall under the jurisdiction of the reservation engine. The
"output" function in the protocol could just link to the
set_param("output") function.

> 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 think it is the best if sensor stuff is handled in the sensor
program/lib. There could be a CF driver in the lmsensors package... Maybe
it requires a locking mechanism similar to the locking mechanism in the
HD44780, which was used to share the bargraph on the LPT port with a
program called portato. In this case access to the serial port should be

Joris Robijn
<joris AT>
Mobile: +31 6 288 41 964

// To understand recursion, we must first understand

Archive powered by MHonArc 2.6.18.

Top of page