| | 31 | |
| | 32 | .SH SEMANTICS |
| | 33 | |
| | 34 | On a given system, there may be one or more hardware monitoring chips. |
| | 35 | Each chip may have several features. For example, the LM78 monitors 7 |
| | 36 | voltage inputs, 3 fans and one temperature. Feature names are |
| | 37 | standardized. Typical feature names are in0, in1, in2... for voltage |
| | 38 | inputs, fan1, fan2, fan3... for fans and temp1, temp2, temp3... for |
| | 39 | temperature inputs. |
| | 40 | |
| | 41 | Each feature may in turn have one or more sub\-features, each |
| | 42 | representing an attribute of the feature: input value, low limit, high |
| | 43 | limit, alarm, etc. Sub\-feature names are standardized as well. For |
| | 44 | example, the first voltage input (in0) would typically have |
| | 45 | sub\-features in0_input (measured value), in0_min (low limit), in0_max |
| | 46 | (high limit) and in0_alarm (alarm flag). Which sub\-features are |
| | 47 | actually present depend on the exact chip type. |
| | 48 | |
| | 49 | The |
| | 50 | .I sensors.conf |
| | 51 | configuration file will let you configure each chip, feature and |
| | 52 | sub\-feature in a way that makes sense for your system. |
| | 53 | |
| | 54 | The rest of this section describes the meaning of each configuration |
| | 55 | statement. |
| | 56 | |
| | 57 | .SS CHIP STATEMENT |
| | 58 | |
| | 59 | A |
| | 60 | .I chip |
| | 61 | statement selects for which chips all following |
| | 62 | .IR compute , |
| | 63 | .IR label , |
| | 64 | .I ignore |
| | 65 | and |
| | 66 | .I set |
| | 67 | statements are meant. A chip |
| | 68 | selection remains valid until the next |
| | 69 | .I chip |
| | 70 | statement. Example: |
| | 71 | |
| | 72 | .RS |
| | 73 | chip "lm78\-*" "lm79\-*" |
| | 74 | .RE |
| | 75 | |
| | 76 | If a chip matches at least one of the chip descriptions, the following |
| | 77 | configuration lines are examined for it, otherwise they are ignored. |
| | 78 | |
| | 79 | A chip description is built from several elements, separated by |
| | 80 | dashes. The first element is the chip type, the second element is |
| | 81 | the name of the bus, and the third element is the hexadecimal address |
| | 82 | of the chip. Such chip descriptions are printed by sensors(1) as the |
| | 83 | first line for every chip. |
| | 84 | |
| | 85 | The name of the bus is either |
| | 86 | .IR isa , |
| | 87 | .IR pci , |
| | 88 | .IR virtual , |
| | 89 | .I spi-* |
| | 90 | or |
| | 91 | .I i2c-N |
| | 92 | with |
| | 93 | .I N |
| | 94 | being a bus number as binded with a |
| | 95 | .I bus |
| | 96 | statement. This list isn't necessarily exhaustive as support for other |
| | 97 | bus types may be added in the future. |
| | 98 | |
| | 99 | You may substitute the wildcard operator |
| | 100 | .I * |
| | 101 | for every element. Note however that it wouldn't make any sense to specify |
| | 102 | the address without the bus type, so the address part is plain omitted |
| | 103 | when the bus type isn't specified. |
| | 104 | Here is how you would express the following matches: |
| | 105 | |
| | 106 | .TS |
| | 107 | l l. |
| | 108 | LM78 chip at address 0x2d on I2C bus 1 lm78\-i2c\-1\-2d |
| | 109 | LM78 chip at address 0x2d on any I2C bus lm78\-i2c\-*\-2d |
| | 110 | LM78 chip at address 0x290 on the ISA bus lm78\-isa\-0290 |
| | 111 | Any LM78 chip on I2C bus 1 lm78\-i2c\-1\-* |
| | 112 | Any LM78 on any I2C bus lm78\-i2c\-*\-* |
| | 113 | Any LM78 chip on the ISA bus lm78\-isa\-* |
| | 114 | Any LM78 chip lm78\-* |
| | 115 | Any chip at address 0x2d on I2C bus 1 *\-i2c\-1\-2d |
| | 116 | Any chip at address 0x290 on the ISA bus *\-isa\-0290 |
| | 117 | .TE |
| | 118 | |
| | 119 | If several chip statements match a specific chip, they are all considered. |
| | 120 | |
| | 121 | .SS LABEL STATEMENT |
| | 122 | |
| | 123 | A |
| | 124 | .I label |
| | 125 | statement describes how a feature should be called. Features without a |
| | 126 | .I label |
| | 127 | statement are just called by their feature name. Applications can use this |
| | 128 | to label the readings they present. Example: |
| | 129 | |
| | 130 | .RS |
| | 131 | label in3 "+5V" |
| | 132 | .RE |
| | 133 | |
| | 134 | The first argument is the feature name. The second argument is the feature |
| | 135 | description. |
| | 136 | |
| | 137 | .SS IGNORE STATEMENT |
| | 138 | |
| | 139 | An |
| | 140 | .I ignore |
| | 141 | statement is a hint that a specific feature should be ignored - probably |
| | 142 | because it returns bogus values (for example, because a fan or temperature |
| | 143 | sensor is not connected). Example: |
| | 144 | |
| | 145 | .RS |
| | 146 | ignore fan1 |
| | 147 | .RE |
| | 148 | |
| | 149 | The only argument is the feature name. Please note that this does not disable |
| | 150 | anything in the actual sensor chip; it simply hides the feature in question |
| | 151 | from libsensors users. |
| | 152 | |
| | 153 | .SS COMPUTE STATEMENT |
| | 154 | |
| | 155 | A |
| | 156 | .I compute |
| | 157 | statement describes how a feature's raw value should be translated to a |
| | 158 | real\-world value, and how a real\-world value should be translated back |
| | 159 | to a raw value again. This is most useful for voltage sensors, because |
| | 160 | in general sensor chips have a limited range and voltages outside this |
| | 161 | range must be divided (using resistors) before they can be monitored. |
| | 162 | Example: |
| | 163 | |
| | 164 | .RS |
| | 165 | compute in3 ((6.8/10)+1)*@, @/((6.8/10)+1) |
| | 166 | .RE |
| | 167 | |
| | 168 | The example above expresses the fact that the voltage input is divided |
| | 169 | using two resistors of values 6.8 Ohm and 10 Ohm, respectively. See the |
| | 170 | .B VOLTAGE COMPUTATION DETAILS |
| | 171 | section below for details. |
| | 172 | |
| | 173 | The first argument is the feature name. The second argument is an expression |
| | 174 | which specifies how a raw value must be translated to a real\-world value; |
| | 175 | `@' stands here for the raw value. This is the formula which will be applied |
| | 176 | when reading values from the chip. The third argument is an expression that |
| | 177 | specifies how a real\-world value should be translated back to a raw value; |
| | 178 | `@' stands here for the real\-world value. This is the formula which will be |
| | 179 | applied when writing values to the chip. The two formulas are obviously |
| | 180 | related, and are seperated by a comma. |
| | 181 | |
| | 182 | A |
| | 183 | .I compute |
| | 184 | statement applies to all sub\-features of the target feature for which |
| | 185 | it makes sense. For example, the above example would affect sub\-features |
| | 186 | in3_min and in3_max (which are voltage values) but not in3_alarm |
| | 187 | (which is a boolean flag.) |
| | 188 | |
| | 189 | The following operators are supported in |
| | 190 | .I compute |
| | 191 | statements: |
| | 192 | .RS |
| | 193 | + \- * / ( ) ^ ` |
| | 194 | .RE |
| | 195 | ^x means exp(x) and `x means ln(x). |
| | 196 | |
| | 197 | You may use the name of sub\-features in these expressions; current readings |
| | 198 | are substituted. You should be careful though to avoid circular references. |
| | 199 | |
| | 200 | If at any moment a translation between a raw and a real\-world value is |
| | 201 | called for, but no |
| | 202 | .I compute |
| | 203 | statement applies, a one\-on\-one translation is used instead. |
| | 204 | |
| | 205 | .SS SET STATEMENT |
| | 206 | |
| | 207 | A |
| | 208 | .I set |
| | 209 | statement is used to write a sub\-feature value to the chip. Of course not |
| | 210 | all sub\-feature values can be set that way, in particular input values |
| | 211 | and alarm flags can not. Valid sub\-features are usually min/max limits. |
| | 212 | Example: |
| | 213 | |
| | 214 | .RS |
| | 215 | set in3_min 5 * 0.95 |
| | 216 | .RE |
| | 217 | .RS |
| | 218 | set in3_max 5 * 1.05 |
| | 219 | .RE |
| | 220 | |
| | 221 | The example above basically configures the chip to allow a 5% deviance |
| | 222 | for the +5V power input. |
| | 223 | |
| | 224 | The first argument is the feature name. The second argument is an expression |
| | 225 | which determines the written value. If there is an applying |
| | 226 | .I compute |
| | 227 | statement, this value is fed to its third argument to translate it to a |
| | 228 | raw value. |
| | 229 | |
| | 230 | You may use the name of sub\-features in these expressions; current readings |
| | 231 | are substituted. You should be careful though to avoid circular references. |
| | 232 | |
| | 233 | Please note that |
| | 234 | .I set |
| | 235 | statements are only executed by sensors(1) when you use the |
| | 236 | .B \-s |
| | 237 | option. Typical graphical sensors applications do not care about these |
| | 238 | statements at all. |
| | 239 | |
| | 240 | .SS BUS STATEMENT |
| | 241 | |
| | 242 | A |
| | 243 | .I bus |
| | 244 | statement binds the description of an I2C or SMBus adapter to a bus number. |
| | 245 | This makes it possible to refer to an adapter in the configuration file, |
| | 246 | independent of the actual correspondence of bus numbers and actual |
| | 247 | adapters (which may change from moment to moment). Example: |
| | 248 | |
| | 249 | .RS |
| | 250 | bus "i2c\-0" "SMBus PIIX4 adapter at e800" |
| | 251 | .RE |
| | 252 | |
| | 253 | The first argument is the bus number. It is the literal text |
| | 254 | .IR i2c\- , |
| | 255 | followed by a number. As there is a dash in this argument, it must |
| | 256 | always be quoted. |
| | 257 | |
| | 258 | The second argument is the adapter name, it must match exactly the |
| | 259 | adapter name as it appears in |
| | 260 | .IR /sys/class/i2c\-adapter/i2c\-*/name . |
| | 261 | It should always be quoted as well as it will most certainly contain |
| | 262 | spaces or dashes. |
| | 263 | |
| | 264 | The |
| | 265 | .I bus |
| | 266 | statements may be scattered randomly throughout the configuration file; |
| | 267 | there is no need to place the bus line before the place where its binding |
| | 268 | is referred to. Still, as a matter of good style, we suggest you place |
| | 269 | all |
| | 270 | .I bus |
| | 271 | statements together at the top of your configuration file. |
| | 272 | |
| | 273 | Running |
| | 274 | .B sensors --bus-list |
| | 275 | will generate these lines for you. |
| | 276 | |
| | 277 | .SS STATEMENT ORDER |
| | 278 | |
| | 279 | Statements can go in any order, however it is recommended to put |
| | 280 | `set fanX_div' statements before `set fanX_min' statements, in case |
| | 281 | a driver doesn't preserve the fanX_min setting when the fanX_div |
| | 282 | value is changed. Even if the driver does, it's still better to put |
| | 283 | the statements in this order to avoid accuracy loss. |
| | 284 | |
| | 285 | .SH VOLTAGE COMPUTATION DETAILS |
| | 286 | |
| | 287 | Most voltage sensors in sensor chips have a range of 0 to 4.08 V. |
| | 288 | This is generally sufficient for the +3.3V and CPU supply voltages, so |
| | 289 | the sensor chip reading is the actual voltage. |
| | 290 | |
| | 291 | Other supply voltages must be scaled with an external resistor network. |
| | 292 | The driver reports the value at the chip's pin (0 \- 4.08 V), and the |
| | 293 | userspace application must convert this raw value to an actual voltage. |
| | 294 | The |
| | 295 | .I compute |
| | 296 | statements provide this facility. |
| | 297 | |
| | 298 | Unfortunately the resistor values vary among motherboard types. |
| | 299 | Therefore you have to figure out the correct resistor values for your |
| | 300 | own motherboard. |
| | 301 | |
| | 302 | For positive voltages (typically +5V and +12V), two resistors are used, |
| | 303 | with the following formula: |
| | 304 | R1 = R2 * (Vs/Vin \- 1) |
| | 305 | |
| | 306 | where: |
| | 307 | R1 and R2 are the resistor values |
| | 308 | Vs is the actual voltage being monitored |
| | 309 | Vin is the voltage at the pin |
| | 310 | |
| | 311 | This leads to the following compute formula: |
| | 312 | compute inX @*((R1/R2)+1), @/(((R1/R2)+1) |
| | 313 | |
| | 314 | Real\-world formula for +5V and +12V would look like: |
| | 315 | compute in3 @*((6.8/10)+1), @/((6.8/10)+1) |
| | 316 | compute in4 @*((28/10)+1), @/((28/10)+1) |
| | 317 | |
| | 318 | For negative voltages (typically \-5V and \-12V), two resistors are used |
| | 319 | as well, but different boards use different strategies to bring the |
| | 320 | voltage value into the 0 \- 4.08 V range. Some use an inverting |
| | 321 | amplifier, others use a positive reference voltage. This leads to |
| | 322 | different computation formulas. Note that most users won't have to care |
| | 323 | because most modern motherboards make little use of \-12V and no use of |
| | 324 | \-5V so they do not bother monitoring these voltage inputs. |
| | 325 | |
| | 326 | Real\-world examples for the inverting amplifier case: |
| | 327 | compute in5 \-@*(240/60), \-@/(240/60) |
| | 328 | compute in6 \-@*(100/60), \-@/(100/60) |
| | 329 | |
| | 330 | Real\-world examples for the positive voltage reference case: |
| | 331 | compute in5 @*(1+232/56) \- 4.096*232/56, (@ + 4.096*232/56)/(1+232/56) |
| | 332 | compute in6 @*(1+120/56) \- 4.096*120/56, (@ + 4.096*120/56)/(1+120/56) |
| | 333 | |
| | 334 | Many recent monitoring chips have a 0 \- 2.04 V range, so scaling resistors |
| | 335 | are even more needed, and resistor values are different. |
| | 336 | |
| | 337 | There are also a few chips out there which have internal scaling |
| | 338 | resistors, meaning that their value is known and doesn't change from |
| | 339 | one motherboard to the next. For these chips, the driver usually |
| | 340 | handles the scaling so it is transparent to the user and no |
| | 341 | .I compute |
| | 342 | statements are needed. |
| | 343 | |
| | 344 | .SH TEMPERATURE CONFIGURATION |
| | 345 | |
| | 346 | On top of the usual features, temperatures can have two specific |
| | 347 | sub\-features: temperature sensor type (tempX_type) and hysteresis |
| | 348 | values (tempX_max_hyst and tempX_crit_hyst). |
| | 349 | |
| | 350 | .SS THERMAL SENSOR TYPES |
| | 351 | |
| | 352 | Available thermal sensor types: |
| | 353 | .TS |
| | 354 | r l. |
| | 355 | 1 PII/Celeron Diode |
| | 356 | 2 3904 transistor |
| | 357 | 3 thermal diode |
| | 358 | 4 thermistor |
| | 359 | 5 AMD AMDSI |
| | 360 | 6 Intel PECI |
| | 361 | .TE |
| | 362 | |
| | 363 | For example, to set temp1 to thermistor type, use: |
| | 364 | |
| | 365 | .RS |
| | 366 | set temp1_type 4 |
| | 367 | .RE |
| | 368 | |
| | 369 | Only certain chips support thermal sensor type change, and even these |
| | 370 | usually only support some of the types above. Please refer to the |
| | 371 | specific driver documentation to find out which types are supported |
| | 372 | by your chip. |
| | 373 | |
| | 374 | In theory, the BIOS should have configured the sensor types correctly, |
| | 375 | so you shouldn't have to touch them, but sometimes it isn't the case. |
| | 376 | |
| | 377 | .SS THERMAL HYSTERESIS MECHANISM |
| | 378 | |
| | 379 | Many monitoring chips do not handle the high and critical temperature |
| | 380 | limits as simple limits. Instead, they have two values for each |
| | 381 | limit, one which triggers an alarm when the temperature rises and another |
| | 382 | one which clears the alarm when the temperature falls. The latter is |
| | 383 | typically a few degrees below the former. This mechanism is known as |
| | 384 | hysteresis. |
| | 385 | |
| | 386 | The reason for implementing things that way is that high temperature |
| | 387 | alarms typically trigger an action to attempt to cool the system down, |
| | 388 | either by scaling down the CPU frequency, or by kicking in an extra |
| | 389 | fan. This should normally let the temperature fall in a timely manner. |
| | 390 | If this was clearing the alarm immediately, then the system would be |
| | 391 | back to its original state where the temperature rises and the alarm |
| | 392 | would immediately trigger again, causing an undesirable tight fan on, |
| | 393 | fan off loop. The hysteresis mechanism ensures that the system is |
| | 394 | really cool before the fan stops, so that it will not have to kick in |
| | 395 | again immediately. |
| | 396 | |
| | 397 | So, in addition to tempX_max, many chips have a tempX_max_hyst |
| | 398 | sub-feature. Likewise, tempX_crit often comes with tempX_max_crit. |
| | 399 | Example: |
| | 400 | |
| | 401 | .RS |
| | 402 | set temp1_max 60 |
| | 403 | .RE |
| | 404 | .RS |
| | 405 | set temp1_max_hyst 56 |
| | 406 | .RE |
| | 407 | |
| | 408 | The hysteresis mechanism can be disabled by giving both limits the same |
| | 409 | value. |
| | 410 | |
| | 411 | .SH BEEPS |
| | 412 | |
| | 413 | Some chips support alarms with beep warnings. When an alarm is triggered |
| | 414 | you can be warned by a beeping signal through your computer speaker. On |
| | 415 | top of per\-feature beep flags, there is usually a master beep control |
| | 416 | switch to enable or disable beeping globally. Enable beeping using: |
| | 417 | |
| | 418 | .RS |
| | 419 | set beep_enable 1 |
| | 420 | .RE |
| | 421 | |
| | 422 | or disable it using: |
| | 423 | |
| | 424 | .RS |
| | 425 | set beep_enable 0 |
| | 426 | .RE |
| | 427 | |
| | 428 | .SH WHICH STATEMENT APPLIES |
| | 429 | |
| | 430 | If more than one statement of the same kind applies at a certain moment, |
| | 431 | the last one in the configuration file is used. So usually, you should |
| | 432 | put more general |
| | 433 | .I chip |
| | 434 | statements at the top, so you can overrule them below. |
| 118 | | |
| 119 | | .SH SEMANTICS |
| 120 | | |
| 121 | | This section describes the meaning of each statement. Each statement is |
| 122 | | accompanied by an example line. Please ignore line wrap\-arounds. |
| 123 | | |
| 124 | | .SS BUS STATEMENT |
| 125 | | |
| 126 | | .RS |
| 127 | | bus "i2c\-0" "SMBus PIIX4 adapter at e800" |
| 128 | | .RE |
| 129 | | |
| 130 | | A |
| 131 | | .I bus |
| 132 | | statement binds the description of an I2C or SMBus adapter to a bus number. |
| 133 | | This makes it possible to refer to an adapter in the configuration file, |
| 134 | | independent of the actual correspondence of bus numbers and actual |
| 135 | | adapters (which may change from moment to moment). |
| 136 | | |
| 137 | | The first argument is the bus number. It is the literal text |
| 138 | | .IR i2c\- , |
| 139 | | followed by a number. As there is a dash in this argument, it must |
| 140 | | always be quoted. |
| 141 | | |
| 142 | | The second argument is the adapter name, it must match exactly the |
| 143 | | adapter name as it appears in |
| 144 | | .IR /sys/class/i2c-adapter/i2c-*/name . |
| 145 | | It should always be quoted as well as it will most certainly contain |
| 146 | | spaces or dashes. |
| 147 | | |
| 148 | | The |
| 149 | | .I bus |
| 150 | | statements may be scattered randomly throughout the configuration file; |
| 151 | | there is no need to place the bus line before the place where its binding |
| 152 | | is referred to. Still, as a matter of good style, we suggest you place |
| 153 | | all |
| 154 | | .I bus |
| 155 | | statements together at the top of your configuration file. |
| 156 | | |
| 157 | | Running |
| 158 | | .B sensors --bus-list |
| 159 | | will generate these lines for you. |
| 160 | | |
| 161 | | .SS CHIP STATEMENT |
| 162 | | |
| 163 | | .RS |
| 164 | | chip "lm78\-*" "lm79\-*" |
| 165 | | .RE |
| 166 | | |
| 167 | | The |
| 168 | | .I chip |
| 169 | | statement selects for which chips all following configuration |
| 170 | | statements are meant. The chip selection remains valid until the next |
| 171 | | .I chip |
| 172 | | statement. It does not influence the operation of a |
| 173 | | .I bus |
| 174 | | statement. |
| 175 | | |
| 176 | | If a chip matches at least one of the chip descriptions, all following |
| 177 | | configuration lines are examined for it. If it matches none of the |
| 178 | | chip descriptions, every |
| 179 | | .RI non\- bus |
| 180 | | statement is ignored upto the next |
| 181 | | .I chip |
| 182 | | statement. |
| 183 | | |
| 184 | | A chip description is built from a couple of elements, separated by |
| 185 | | dashes. |
| 186 | | |
| 187 | | The first element is the name of the chip type. Sometimes a single driver |
| 188 | | implements several chip types, with several names. The driver documentation |
| 189 | | should tell you. You may substitute the wildcard operator |
| 190 | | .I * |
| 191 | | for this element. |
| 192 | | |
| 193 | | The second element is the name of the bus. This is either |
| 194 | | .IR isa , |
| 195 | | .I pci |
| 196 | | or |
| 197 | | .IR i2c-N , |
| 198 | | with |
| 199 | | .I N |
| 200 | | being any number as binded with a |
| 201 | | .I bus |
| 202 | | statement. You may substitute the wildcard operator |
| 203 | | .I * |
| 204 | | for this element, or only for the number of the I2C bus |
| 205 | | (which means 'any I2C bus'). |
| 206 | | |
| 207 | | The third element is the hexadecimal address of the chip. The valid range |
| 208 | | depends on the bus type. You may substitute |
| 209 | | the wildcard operator |
| 210 | | .I * |
| 211 | | for this element. |
| 212 | | |
| 213 | | Note that it wouldn't make any sense to specify the address without the |
| 214 | | bus type. For this reason, the address part is plain omitted when the bus |
| 215 | | type isn't specified. |
| 216 | | The following are all valid chip type specification based on |
| 217 | | .I lm78\-i2c\-1\-2d |
| 218 | | or |
| 219 | | .IR lm78\-isa\-0290 : |
| 220 | | |
| 221 | | .RS |
| 222 | | lm78\-i2c\-1\-2d |
| 223 | | .sp 0 |
| 224 | | lm78\-i2c\-1\-* |
| 225 | | .sp 0 |
| 226 | | lm78\-i2c\-*\-2d |
| 227 | | .sp 0 |
| 228 | | lm78\-i2c\-*\-* |
| 229 | | .sp 0 |
| 230 | | lm78\-isa\-0290 |
| 231 | | .sp 0 |
| 232 | | lm78\-isa\-* |
| 233 | | .sp 0 |
| 234 | | lm78\-* |
| 235 | | .sp 0 |
| 236 | | *\-i2c\-1\-2d |
| 237 | | .sp 0 |
| 238 | | *\-i2c\-1\-* |
| 239 | | .sp 0 |
| 240 | | *\-i2c\-*\-2d |
| 241 | | .sp 0 |
| 242 | | *\-i2c-*\-* |
| 243 | | .sp 0 |
| 244 | | *\-isa\-0290 |
| 245 | | .sp 0 |
| 246 | | *\-isa\-* |
| 247 | | .RE |
| 248 | | |
| 249 | | .SS COMPUTE STATEMENT |
| 250 | | .RS |
| 251 | | compute in3 ((6.8/10)+1)*@ , @/((6.8/10)+1) |
| 252 | | .RE |
| 253 | | |
| 254 | | The |
| 255 | | .I compute |
| 256 | | statement describes how you should translate a feature's raw value to a |
| 257 | | real\-world value, and how you should translate it back to a raw value again. |
| 258 | | |
| 259 | | The first argument is the feature name, which may be the name of a feature |
| 260 | | class (see below). The second is an expression which specifies how a |
| 261 | | raw value must be translated to a real\-world value; `@' stands here for |
| 262 | | the raw value. The third is an expression that specifies how a real\-world |
| 263 | | value should be translated back to a raw value; `@' stands here for the |
| 264 | | real\-world value. |
| 265 | | |
| 266 | | You may use the name of other features in these expressions; you should be |
| 267 | | careful though to avoid circular references, as this may hang the expression |
| 268 | | evaluator. |
| 269 | | |
| 270 | | If at any moment a translation between a raw and a real\-world value is |
| 271 | | called for, but no |
| 272 | | .I compute |
| 273 | | statement applies, a one\-on\-one translation is used instead. |
| 274 | | |
| 275 | | The comma is an unfortunate necessity to stop the statement from becoming |
| 276 | | ambiguous. |
| 277 | | |
| 278 | | .SS IGNORE STATEMENT |
| 279 | | .RS |
| 280 | | ignore fan1 |
| 281 | | .RE |
| 282 | | |
| 283 | | The |
| 284 | | .I ignore |
| 285 | | statement is a hint that a specific feature should be ignored - probably |
| 286 | | because it returns bogus values (for example, because a fan or temperature |
| 287 | | sensor is not connected). |
| 288 | | |
| 289 | | The only argument is the feature name, which may be a feature class; |
| 290 | | in that case the label class is used (see below). |
| 291 | | |
| 292 | | .SS LABEL STATEMENT |
| 293 | | .RS |
| 294 | | label in3 "+5V" |
| 295 | | .RE |
| 296 | | |
| 297 | | The |
| 298 | | .I label |
| 299 | | statement describes how a feature should be called. Features without a |
| 300 | | .I label |
| 301 | | statement are just called by their feature name. Applications can use this |
| 302 | | to label the readings they present (but they don't have to). |
| 303 | | |
| 304 | | The first argument is the feature name, which may be a feature class (see |
| 305 | | below). The second argument is the feature description. |
| 306 | | |
| 307 | | .SS SET STATEMENT |
| 308 | | .RS |
| 309 | | set in3_min 5 * 0.95 |
| 310 | | .RE |
| 311 | | |
| 312 | | The |
| 313 | | .I set |
| 314 | | statement gives an initial value for a feature. Not each feature can be |
| 315 | | given a sensible initial value; valid features are usually min/max limits. |
| 316 | | |
| 317 | | The first argument is the feature name. The second argument is an expression |
| 318 | | which determines the initial value. If there is an applying |
| 319 | | .I compute |
| 320 | | statement, this value is fed to its third argument to translate it to a |
| 321 | | raw value. |
| 322 | | |
| 323 | | You may use the name of other features in these expressions; current readings |
| 324 | | are substituted. You should be careful though to avoid circular references, |
| 325 | | as this may hang the expression evaluator. Also, you can't be sure in which |
| 326 | | order |
| 327 | | .I set |
| 328 | | statements are evaluated, so this can lead to nasty surprises. |
| 329 | | |
| 330 | | .SH FEATURE CLASSES |
| 331 | | |
| 332 | | There are two kinds of classes, here called |
| 333 | | .I compute |
| 334 | | and |
| 335 | | .I label |
| 336 | | classes, after the statements for which they are defined. Classes are |
| 337 | | defined over features: the kind of values that can be read from or set |
| 338 | | for a specific kind of chip. |
| 339 | | |
| 340 | | Each class has a class name, which is usually the same as its most |
| 341 | | prominent feature. A |
| 342 | | .I label |
| 343 | | or |
| 344 | | .I compute |
| 345 | | statement for the class name feature forces the same settings for all other |
| 346 | | class members. A specific statement for a class member feature always |
| 347 | | overrides the general class setting, though. This means that you can't |
| 348 | | override the class name feature explicitly. |
| 349 | | |
| 350 | | A simple example will explain this better. The |
| 351 | | .I fan1 |
| 352 | | label class of the |
| 353 | | .I lm78 |
| 354 | | chip contains three members: |
| 355 | | .I fan1 |
| 356 | | itself, |
| 357 | | .I fan1_min |
| 358 | | and |
| 359 | | .IR fan1_div . |
| 360 | | The last feature sets the number by which readings are divided (to give the |
| 361 | | fan less resolution, but a larger field of operation). The following |
| 362 | | line will set the name of all these features to describe the fan: |
| 363 | | .RS |
| 364 | | label fan1 "Processor 1 FAN" |
| 365 | | .RE |
| 366 | | Now we happen to know that, due to the type of fan we use, all readings |
| 367 | | are always off by a factor of two (some fans only return one 'tick' each |
| 368 | | rotation, others return two): |
| 369 | | .RS |
| 370 | | compute fan1 @/2 , @*2 |
| 371 | | .RE |
| 372 | | It will be clear that this should be done for the |
| 373 | | .I fan1_min |
| 374 | | feature too, but not for the |
| 375 | | .I fan1_div |
| 376 | | feature! Fortunately, the |
| 377 | | .I fan1 |
| 378 | | compute class contains |
| 379 | | .IR fan1_min , |
| 380 | | but not |
| 381 | | .IR fan1_div , |
| 382 | | so this works out right. |
| 383 | | |
| 384 | | .SH WHICH STATEMENT APPLIES |
| 385 | | |
| 386 | | If more than one statement of the same kind applies at a certain moment, |
| 387 | | the last one in the configuration file is used. So usually, you should |
| 388 | | put more general |
| 389 | | .I chip |
| 390 | | statements at the top, so you can overrule them below. |
| 391 | | |
| 392 | | There is one exception to this rule: if a statement only applies because |
| 393 | | the feature is in the same class as the feature the statement contains, |
| 394 | | and there is anywhere else a statement for this specific class member, |
| 395 | | that one takes always precedence. |
