diff options
Diffstat (limited to 'Documentation/laptops/thinkpad-acpi.txt')
| -rw-r--r-- | Documentation/laptops/thinkpad-acpi.txt | 1365 |
1 files changed, 1365 insertions, 0 deletions
diff --git a/Documentation/laptops/thinkpad-acpi.txt b/Documentation/laptops/thinkpad-acpi.txt new file mode 100644 index 000000000000..6c2477754a2a --- /dev/null +++ b/Documentation/laptops/thinkpad-acpi.txt | |||
| @@ -0,0 +1,1365 @@ | |||
| 1 | ThinkPad ACPI Extras Driver | ||
| 2 | |||
| 3 | Version 0.19 | ||
| 4 | January 06th, 2008 | ||
| 5 | |||
| 6 | Borislav Deianov <borislav@users.sf.net> | ||
| 7 | Henrique de Moraes Holschuh <hmh@hmh.eng.br> | ||
| 8 | http://ibm-acpi.sf.net/ | ||
| 9 | |||
| 10 | |||
| 11 | This is a Linux driver for the IBM and Lenovo ThinkPad laptops. It | ||
| 12 | supports various features of these laptops which are accessible | ||
| 13 | through the ACPI and ACPI EC framework, but not otherwise fully | ||
| 14 | supported by the generic Linux ACPI drivers. | ||
| 15 | |||
| 16 | This driver used to be named ibm-acpi until kernel 2.6.21 and release | ||
| 17 | 0.13-20070314. It used to be in the drivers/acpi tree, but it was | ||
| 18 | moved to the drivers/misc tree and renamed to thinkpad-acpi for kernel | ||
| 19 | 2.6.22, and release 0.14. | ||
| 20 | |||
| 21 | |||
| 22 | Status | ||
| 23 | ------ | ||
| 24 | |||
| 25 | The features currently supported are the following (see below for | ||
| 26 | detailed description): | ||
| 27 | |||
| 28 | - Fn key combinations | ||
| 29 | - Bluetooth enable and disable | ||
| 30 | - video output switching, expansion control | ||
| 31 | - ThinkLight on and off | ||
| 32 | - limited docking and undocking | ||
| 33 | - UltraBay eject | ||
| 34 | - CMOS control | ||
| 35 | - LED control | ||
| 36 | - ACPI sounds | ||
| 37 | - temperature sensors | ||
| 38 | - Experimental: embedded controller register dump | ||
| 39 | - LCD brightness control | ||
| 40 | - Volume control | ||
| 41 | - Fan control and monitoring: fan speed, fan enable/disable | ||
| 42 | - Experimental: WAN enable and disable | ||
| 43 | |||
| 44 | A compatibility table by model and feature is maintained on the web | ||
| 45 | site, http://ibm-acpi.sf.net/. I appreciate any success or failure | ||
| 46 | reports, especially if they add to or correct the compatibility table. | ||
| 47 | Please include the following information in your report: | ||
| 48 | |||
| 49 | - ThinkPad model name | ||
| 50 | - a copy of your DSDT, from /proc/acpi/dsdt | ||
| 51 | - a copy of the output of dmidecode, with serial numbers | ||
| 52 | and UUIDs masked off | ||
| 53 | - which driver features work and which don't | ||
| 54 | - the observed behavior of non-working features | ||
| 55 | |||
| 56 | Any other comments or patches are also more than welcome. | ||
| 57 | |||
| 58 | |||
| 59 | Installation | ||
| 60 | ------------ | ||
| 61 | |||
| 62 | If you are compiling this driver as included in the Linux kernel | ||
| 63 | sources, simply enable the CONFIG_THINKPAD_ACPI option, and optionally | ||
| 64 | enable the CONFIG_THINKPAD_ACPI_BAY option if you want the | ||
| 65 | thinkpad-specific bay functionality. | ||
| 66 | |||
| 67 | Features | ||
| 68 | -------- | ||
| 69 | |||
| 70 | The driver exports two different interfaces to userspace, which can be | ||
| 71 | used to access the features it provides. One is a legacy procfs-based | ||
| 72 | interface, which will be removed at some time in the distant future. | ||
| 73 | The other is a new sysfs-based interface which is not complete yet. | ||
| 74 | |||
| 75 | The procfs interface creates the /proc/acpi/ibm directory. There is a | ||
| 76 | file under that directory for each feature it supports. The procfs | ||
| 77 | interface is mostly frozen, and will change very little if at all: it | ||
| 78 | will not be extended to add any new functionality in the driver, instead | ||
| 79 | all new functionality will be implemented on the sysfs interface. | ||
| 80 | |||
| 81 | The sysfs interface tries to blend in the generic Linux sysfs subsystems | ||
| 82 | and classes as much as possible. Since some of these subsystems are not | ||
| 83 | yet ready or stabilized, it is expected that this interface will change, | ||
| 84 | and any and all userspace programs must deal with it. | ||
| 85 | |||
| 86 | |||
| 87 | Notes about the sysfs interface: | ||
| 88 | |||
| 89 | Unlike what was done with the procfs interface, correctness when talking | ||
| 90 | to the sysfs interfaces will be enforced, as will correctness in the | ||
| 91 | thinkpad-acpi's implementation of sysfs interfaces. | ||
| 92 | |||
| 93 | Also, any bugs in the thinkpad-acpi sysfs driver code or in the | ||
| 94 | thinkpad-acpi's implementation of the sysfs interfaces will be fixed for | ||
| 95 | maximum correctness, even if that means changing an interface in | ||
| 96 | non-compatible ways. As these interfaces mature both in the kernel and | ||
| 97 | in thinkpad-acpi, such changes should become quite rare. | ||
| 98 | |||
| 99 | Applications interfacing to the thinkpad-acpi sysfs interfaces must | ||
| 100 | follow all sysfs guidelines and correctly process all errors (the sysfs | ||
| 101 | interface makes extensive use of errors). File descriptors and open / | ||
| 102 | close operations to the sysfs inodes must also be properly implemented. | ||
| 103 | |||
| 104 | The version of thinkpad-acpi's sysfs interface is exported by the driver | ||
| 105 | as a driver attribute (see below). | ||
| 106 | |||
| 107 | Sysfs driver attributes are on the driver's sysfs attribute space, | ||
| 108 | for 2.6.23 this is /sys/bus/platform/drivers/thinkpad_acpi/ and | ||
| 109 | /sys/bus/platform/drivers/thinkpad_hwmon/ | ||
| 110 | |||
| 111 | Sysfs device attributes are on the thinkpad_acpi device sysfs attribute | ||
| 112 | space, for 2.6.23 this is /sys/devices/platform/thinkpad_acpi/. | ||
| 113 | |||
| 114 | Sysfs device attributes for the sensors and fan are on the | ||
| 115 | thinkpad_hwmon device's sysfs attribute space, but you should locate it | ||
| 116 | looking for a hwmon device with the name attribute of "thinkpad". | ||
| 117 | |||
| 118 | Driver version | ||
| 119 | -------------- | ||
| 120 | |||
| 121 | procfs: /proc/acpi/ibm/driver | ||
| 122 | sysfs driver attribute: version | ||
| 123 | |||
| 124 | The driver name and version. No commands can be written to this file. | ||
| 125 | |||
| 126 | Sysfs interface version | ||
| 127 | ----------------------- | ||
| 128 | |||
| 129 | sysfs driver attribute: interface_version | ||
| 130 | |||
| 131 | Version of the thinkpad-acpi sysfs interface, as an unsigned long | ||
| 132 | (output in hex format: 0xAAAABBCC), where: | ||
| 133 | AAAA - major revision | ||
| 134 | BB - minor revision | ||
| 135 | CC - bugfix revision | ||
| 136 | |||
| 137 | The sysfs interface version changelog for the driver can be found at the | ||
| 138 | end of this document. Changes to the sysfs interface done by the kernel | ||
| 139 | subsystems are not documented here, nor are they tracked by this | ||
| 140 | attribute. | ||
| 141 | |||
| 142 | Changes to the thinkpad-acpi sysfs interface are only considered | ||
| 143 | non-experimental when they are submitted to Linux mainline, at which | ||
| 144 | point the changes in this interface are documented and interface_version | ||
| 145 | may be updated. If you are using any thinkpad-acpi features not yet | ||
| 146 | sent to mainline for merging, you do so on your own risk: these features | ||
| 147 | may disappear, or be implemented in a different and incompatible way by | ||
| 148 | the time they are merged in Linux mainline. | ||
| 149 | |||
| 150 | Changes that are backwards-compatible by nature (e.g. the addition of | ||
| 151 | attributes that do not change the way the other attributes work) do not | ||
| 152 | always warrant an update of interface_version. Therefore, one must | ||
| 153 | expect that an attribute might not be there, and deal with it properly | ||
| 154 | (an attribute not being there *is* a valid way to make it clear that a | ||
| 155 | feature is not available in sysfs). | ||
| 156 | |||
| 157 | Hot keys | ||
| 158 | -------- | ||
| 159 | |||
| 160 | procfs: /proc/acpi/ibm/hotkey | ||
| 161 | sysfs device attribute: hotkey_* | ||
| 162 | |||
| 163 | In a ThinkPad, the ACPI HKEY handler is responsible for comunicating | ||
| 164 | some important events and also keyboard hot key presses to the operating | ||
| 165 | system. Enabling the hotkey functionality of thinkpad-acpi signals the | ||
| 166 | firmware that such a driver is present, and modifies how the ThinkPad | ||
| 167 | firmware will behave in many situations. | ||
| 168 | |||
| 169 | The driver enables the hot key feature automatically when loaded. The | ||
| 170 | feature can later be disabled and enabled back at runtime. The driver | ||
| 171 | will also restore the hot key feature to its previous state and mask | ||
| 172 | when it is unloaded. | ||
| 173 | |||
| 174 | When the hotkey feature is enabled and the hot key mask is set (see | ||
| 175 | below), the driver will report HKEY events in the following format: | ||
| 176 | |||
| 177 | ibm/hotkey HKEY 00000080 0000xxxx | ||
| 178 | |||
| 179 | Some of these events refer to hot key presses, but not all. | ||
| 180 | |||
| 181 | The driver will generate events over the input layer for hot keys and | ||
| 182 | radio switches, and over the ACPI netlink layer for other events. The | ||
| 183 | input layer support accepts the standard IOCTLs to remap the keycodes | ||
| 184 | assigned to each hot key. | ||
| 185 | |||
| 186 | The hot key bit mask allows some control over which hot keys generate | ||
| 187 | events. If a key is "masked" (bit set to 0 in the mask), the firmware | ||
| 188 | will handle it. If it is "unmasked", it signals the firmware that | ||
| 189 | thinkpad-acpi would prefer to handle it, if the firmware would be so | ||
| 190 | kind to allow it (and it often doesn't!). | ||
| 191 | |||
| 192 | Not all bits in the mask can be modified. Not all bits that can be | ||
| 193 | modified do anything. Not all hot keys can be individually controlled | ||
| 194 | by the mask. Some models do not support the mask at all, and in those | ||
| 195 | models, hot keys cannot be controlled individually. The behaviour of | ||
| 196 | the mask is, therefore, higly dependent on the ThinkPad model. | ||
| 197 | |||
| 198 | Note that unmasking some keys prevents their default behavior. For | ||
| 199 | example, if Fn+F5 is unmasked, that key will no longer enable/disable | ||
| 200 | Bluetooth by itself. | ||
| 201 | |||
| 202 | Note also that not all Fn key combinations are supported through ACPI. | ||
| 203 | For example, on the X40, the brightness, volume and "Access IBM" buttons | ||
| 204 | do not generate ACPI events even with this driver. They *can* be used | ||
| 205 | through the "ThinkPad Buttons" utility, see http://www.nongnu.org/tpb/ | ||
| 206 | |||
| 207 | procfs notes: | ||
| 208 | |||
| 209 | The following commands can be written to the /proc/acpi/ibm/hotkey file: | ||
| 210 | |||
| 211 | echo enable > /proc/acpi/ibm/hotkey -- enable the hot keys feature | ||
| 212 | echo disable > /proc/acpi/ibm/hotkey -- disable the hot keys feature | ||
| 213 | echo 0xffffffff > /proc/acpi/ibm/hotkey -- enable all hot keys | ||
| 214 | echo 0 > /proc/acpi/ibm/hotkey -- disable all possible hot keys | ||
| 215 | ... any other 8-hex-digit mask ... | ||
| 216 | echo reset > /proc/acpi/ibm/hotkey -- restore the original mask | ||
| 217 | |||
| 218 | The procfs interface does not support NVRAM polling control. So as to | ||
| 219 | maintain maximum bug-to-bug compatibility, it does not report any masks, | ||
| 220 | nor does it allow one to manipulate the hot key mask when the firmware | ||
| 221 | does not support masks at all, even if NVRAM polling is in use. | ||
| 222 | |||
| 223 | sysfs notes: | ||
| 224 | |||
| 225 | hotkey_bios_enabled: | ||
| 226 | Returns the status of the hot keys feature when | ||
| 227 | thinkpad-acpi was loaded. Upon module unload, the hot | ||
| 228 | key feature status will be restored to this value. | ||
| 229 | |||
| 230 | 0: hot keys were disabled | ||
| 231 | 1: hot keys were enabled (unusual) | ||
| 232 | |||
| 233 | hotkey_bios_mask: | ||
| 234 | Returns the hot keys mask when thinkpad-acpi was loaded. | ||
| 235 | Upon module unload, the hot keys mask will be restored | ||
| 236 | to this value. | ||
| 237 | |||
| 238 | hotkey_enable: | ||
| 239 | Enables/disables the hot keys feature in the ACPI | ||
| 240 | firmware, and reports current status of the hot keys | ||
| 241 | feature. Has no effect on the NVRAM hot key polling | ||
| 242 | functionality. | ||
| 243 | |||
| 244 | 0: disables the hot keys feature / feature disabled | ||
| 245 | 1: enables the hot keys feature / feature enabled | ||
| 246 | |||
| 247 | hotkey_mask: | ||
| 248 | bit mask to enable driver-handling (and depending on | ||
| 249 | the firmware, ACPI event generation) for each hot key | ||
| 250 | (see above). Returns the current status of the hot keys | ||
| 251 | mask, and allows one to modify it. | ||
| 252 | |||
| 253 | Note: when NVRAM polling is active, the firmware mask | ||
| 254 | will be different from the value returned by | ||
| 255 | hotkey_mask. The driver will retain enabled bits for | ||
| 256 | hotkeys that are under NVRAM polling even if the | ||
| 257 | firmware refuses them, and will not set these bits on | ||
| 258 | the firmware hot key mask. | ||
| 259 | |||
| 260 | hotkey_all_mask: | ||
| 261 | bit mask that should enable event reporting for all | ||
| 262 | supported hot keys, when echoed to hotkey_mask above. | ||
| 263 | Unless you know which events need to be handled | ||
| 264 | passively (because the firmware *will* handle them | ||
| 265 | anyway), do *not* use hotkey_all_mask. Use | ||
| 266 | hotkey_recommended_mask, instead. You have been warned. | ||
| 267 | |||
| 268 | hotkey_recommended_mask: | ||
| 269 | bit mask that should enable event reporting for all | ||
| 270 | supported hot keys, except those which are always | ||
| 271 | handled by the firmware anyway. Echo it to | ||
| 272 | hotkey_mask above, to use. | ||
| 273 | |||
| 274 | hotkey_source_mask: | ||
| 275 | bit mask that selects which hot keys will the driver | ||
| 276 | poll the NVRAM for. This is auto-detected by the driver | ||
| 277 | based on the capabilities reported by the ACPI firmware, | ||
| 278 | but it can be overridden at runtime. | ||
| 279 | |||
| 280 | Hot keys whose bits are set in both hotkey_source_mask | ||
| 281 | and also on hotkey_mask are polled for in NVRAM. Only a | ||
| 282 | few hot keys are available through CMOS NVRAM polling. | ||
| 283 | |||
| 284 | Warning: when in NVRAM mode, the volume up/down/mute | ||
| 285 | keys are synthesized according to changes in the mixer, | ||
| 286 | so you have to use volume up or volume down to unmute, | ||
| 287 | as per the ThinkPad volume mixer user interface. When | ||
| 288 | in ACPI event mode, volume up/down/mute are reported as | ||
| 289 | separate events, but this behaviour may be corrected in | ||
| 290 | future releases of this driver, in which case the | ||
| 291 | ThinkPad volume mixer user interface semanthics will be | ||
| 292 | enforced. | ||
| 293 | |||
| 294 | hotkey_poll_freq: | ||
| 295 | frequency in Hz for hot key polling. It must be between | ||
| 296 | 0 and 25 Hz. Polling is only carried out when strictly | ||
| 297 | needed. | ||
| 298 | |||
| 299 | Setting hotkey_poll_freq to zero disables polling, and | ||
| 300 | will cause hot key presses that require NVRAM polling | ||
| 301 | to never be reported. | ||
| 302 | |||
| 303 | Setting hotkey_poll_freq too low will cause repeated | ||
| 304 | pressings of the same hot key to be misreported as a | ||
| 305 | single key press, or to not even be detected at all. | ||
| 306 | The recommended polling frequency is 10Hz. | ||
| 307 | |||
| 308 | hotkey_radio_sw: | ||
| 309 | if the ThinkPad has a hardware radio switch, this | ||
| 310 | attribute will read 0 if the switch is in the "radios | ||
| 311 | disabled" postition, and 1 if the switch is in the | ||
| 312 | "radios enabled" position. | ||
| 313 | |||
| 314 | This attribute has poll()/select() support. | ||
| 315 | |||
| 316 | hotkey_report_mode: | ||
| 317 | Returns the state of the procfs ACPI event report mode | ||
| 318 | filter for hot keys. If it is set to 1 (the default), | ||
| 319 | all hot key presses are reported both through the input | ||
| 320 | layer and also as ACPI events through procfs (but not | ||
| 321 | through netlink). If it is set to 2, hot key presses | ||
| 322 | are reported only through the input layer. | ||
| 323 | |||
| 324 | This attribute is read-only in kernels 2.6.23 or later, | ||
| 325 | and read-write on earlier kernels. | ||
| 326 | |||
| 327 | May return -EPERM (write access locked out by module | ||
| 328 | parameter) or -EACCES (read-only). | ||
| 329 | |||
| 330 | wakeup_reason: | ||
| 331 | Set to 1 if the system is waking up because the user | ||
| 332 | requested a bay ejection. Set to 2 if the system is | ||
| 333 | waking up because the user requested the system to | ||
| 334 | undock. Set to zero for normal wake-ups or wake-ups | ||
| 335 | due to unknown reasons. | ||
| 336 | |||
| 337 | This attribute has poll()/select() support. | ||
| 338 | |||
| 339 | wakeup_hotunplug_complete: | ||
| 340 | Set to 1 if the system was waken up because of an | ||
| 341 | undock or bay ejection request, and that request | ||
| 342 | was sucessfully completed. At this point, it might | ||
| 343 | be useful to send the system back to sleep, at the | ||
| 344 | user's choice. Refer to HKEY events 0x4003 and | ||
| 345 | 0x3003, below. | ||
| 346 | |||
| 347 | This attribute has poll()/select() support. | ||
| 348 | |||
| 349 | input layer notes: | ||
| 350 | |||
| 351 | A Hot key is mapped to a single input layer EV_KEY event, possibly | ||
| 352 | followed by an EV_MSC MSC_SCAN event that shall contain that key's scan | ||
| 353 | code. An EV_SYN event will always be generated to mark the end of the | ||
| 354 | event block. | ||
| 355 | |||
| 356 | Do not use the EV_MSC MSC_SCAN events to process keys. They are to be | ||
| 357 | used as a helper to remap keys, only. They are particularly useful when | ||
| 358 | remapping KEY_UNKNOWN keys. | ||
| 359 | |||
| 360 | The events are available in an input device, with the following id: | ||
| 361 | |||
| 362 | Bus: BUS_HOST | ||
| 363 | vendor: 0x1014 (PCI_VENDOR_ID_IBM) or | ||
| 364 | 0x17aa (PCI_VENDOR_ID_LENOVO) | ||
| 365 | product: 0x5054 ("TP") | ||
| 366 | version: 0x4101 | ||
| 367 | |||
| 368 | The version will have its LSB incremented if the keymap changes in a | ||
| 369 | backwards-compatible way. The MSB shall always be 0x41 for this input | ||
| 370 | device. If the MSB is not 0x41, do not use the device as described in | ||
| 371 | this section, as it is either something else (e.g. another input device | ||
| 372 | exported by a thinkpad driver, such as HDAPS) or its functionality has | ||
| 373 | been changed in a non-backwards compatible way. | ||
| 374 | |||
| 375 | Adding other event types for other functionalities shall be considered a | ||
| 376 | backwards-compatible change for this input device. | ||
| 377 | |||
| 378 | Thinkpad-acpi Hot Key event map (version 0x4101): | ||
| 379 | |||
| 380 | ACPI Scan | ||
| 381 | event code Key Notes | ||
| 382 | |||
| 383 | 0x1001 0x00 FN+F1 - | ||
| 384 | 0x1002 0x01 FN+F2 IBM: battery (rare) | ||
| 385 | Lenovo: Screen lock | ||
| 386 | |||
| 387 | 0x1003 0x02 FN+F3 Many IBM models always report | ||
| 388 | this hot key, even with hot keys | ||
| 389 | disabled or with Fn+F3 masked | ||
| 390 | off | ||
| 391 | IBM: screen lock | ||
| 392 | Lenovo: battery | ||
| 393 | |||
| 394 | 0x1004 0x03 FN+F4 Sleep button (ACPI sleep button | ||
| 395 | semanthics, i.e. sleep-to-RAM). | ||
| 396 | It is always generate some kind | ||
| 397 | of event, either the hot key | ||
| 398 | event or a ACPI sleep button | ||
| 399 | event. The firmware may | ||
| 400 | refuse to generate further FN+F4 | ||
| 401 | key presses until a S3 or S4 ACPI | ||
| 402 | sleep cycle is performed or some | ||
| 403 | time passes. | ||
| 404 | |||
| 405 | 0x1005 0x04 FN+F5 Radio. Enables/disables | ||
| 406 | the internal BlueTooth hardware | ||
| 407 | and W-WAN card if left in control | ||
| 408 | of the firmware. Does not affect | ||
| 409 | the WLAN card. | ||
| 410 | Should be used to turn on/off all | ||
| 411 | radios (bluetooth+W-WAN+WLAN), | ||
| 412 | really. | ||
| 413 | |||
| 414 | 0x1006 0x05 FN+F6 - | ||
| 415 | |||
| 416 | 0x1007 0x06 FN+F7 Video output cycle. | ||
| 417 | Do you feel lucky today? | ||
| 418 | |||
| 419 | 0x1008 0x07 FN+F8 IBM: toggle screen expand | ||
| 420 | Lenovo: configure ultranav | ||
| 421 | |||
| 422 | 0x1009 0x08 FN+F9 - | ||
| 423 | .. .. .. | ||
| 424 | 0x100B 0x0A FN+F11 - | ||
| 425 | |||
| 426 | 0x100C 0x0B FN+F12 Sleep to disk. You are always | ||
| 427 | supposed to handle it yourself, | ||
| 428 | either through the ACPI event, | ||
| 429 | or through a hotkey event. | ||
| 430 | The firmware may refuse to | ||
| 431 | generate further FN+F4 key | ||
| 432 | press events until a S3 or S4 | ||
| 433 | ACPI sleep cycle is performed, | ||
| 434 | or some time passes. | ||
| 435 | |||
| 436 | 0x100D 0x0C FN+BACKSPACE - | ||
| 437 | 0x100E 0x0D FN+INSERT - | ||
| 438 | 0x100F 0x0E FN+DELETE - | ||
| 439 | |||
| 440 | 0x1010 0x0F FN+HOME Brightness up. This key is | ||
| 441 | always handled by the firmware | ||
| 442 | in IBM ThinkPads, even when | ||
| 443 | unmasked. Just leave it alone. | ||
| 444 | For Lenovo ThinkPads with a new | ||
| 445 | BIOS, it has to be handled either | ||
| 446 | by the ACPI OSI, or by userspace. | ||
| 447 | 0x1011 0x10 FN+END Brightness down. See brightness | ||
| 448 | up for details. | ||
| 449 | |||
| 450 | 0x1012 0x11 FN+PGUP Thinklight toggle. This key is | ||
| 451 | always handled by the firmware, | ||
| 452 | even when unmasked. | ||
| 453 | |||
| 454 | 0x1013 0x12 FN+PGDOWN - | ||
| 455 | |||
| 456 | 0x1014 0x13 FN+SPACE Zoom key | ||
| 457 | |||
| 458 | 0x1015 0x14 VOLUME UP Internal mixer volume up. This | ||
| 459 | key is always handled by the | ||
| 460 | firmware, even when unmasked. | ||
| 461 | NOTE: Lenovo seems to be changing | ||
| 462 | this. | ||
| 463 | 0x1016 0x15 VOLUME DOWN Internal mixer volume up. This | ||
| 464 | key is always handled by the | ||
| 465 | firmware, even when unmasked. | ||
| 466 | NOTE: Lenovo seems to be changing | ||
| 467 | this. | ||
| 468 | 0x1017 0x16 MUTE Mute internal mixer. This | ||
| 469 | key is always handled by the | ||
| 470 | firmware, even when unmasked. | ||
| 471 | |||
| 472 | 0x1018 0x17 THINKPAD Thinkpad/Access IBM/Lenovo key | ||
| 473 | |||
| 474 | 0x1019 0x18 unknown | ||
| 475 | .. .. .. | ||
| 476 | 0x1020 0x1F unknown | ||
| 477 | |||
| 478 | The ThinkPad firmware does not allow one to differentiate when most hot | ||
| 479 | keys are pressed or released (either that, or we don't know how to, yet). | ||
| 480 | For these keys, the driver generates a set of events for a key press and | ||
| 481 | immediately issues the same set of events for a key release. It is | ||
| 482 | unknown by the driver if the ThinkPad firmware triggered these events on | ||
| 483 | hot key press or release, but the firmware will do it for either one, not | ||
| 484 | both. | ||
| 485 | |||
| 486 | If a key is mapped to KEY_RESERVED, it generates no input events at all. | ||
| 487 | If a key is mapped to KEY_UNKNOWN, it generates an input event that | ||
| 488 | includes an scan code. If a key is mapped to anything else, it will | ||
| 489 | generate input device EV_KEY events. | ||
| 490 | |||
| 491 | Non hot-key ACPI HKEY event map: | ||
| 492 | 0x5001 Lid closed | ||
| 493 | 0x5002 Lid opened | ||
| 494 | 0x7000 Radio Switch may have changed state | ||
| 495 | |||
| 496 | The above events are not propagated by the driver, except for legacy | ||
| 497 | compatibility purposes when hotkey_report_mode is set to 1. | ||
| 498 | |||
| 499 | 0x2304 System is waking up from suspend to undock | ||
| 500 | 0x2305 System is waking up from suspend to eject bay | ||
| 501 | 0x2404 System is waking up from hibernation to undock | ||
| 502 | 0x2405 System is waking up from hibernation to eject bay | ||
| 503 | |||
| 504 | The above events are never propagated by the driver. | ||
| 505 | |||
| 506 | 0x3003 Bay ejection (see 0x2x05) complete, can sleep again | ||
| 507 | 0x4003 Undocked (see 0x2x04), can sleep again | ||
| 508 | 0x5009 Tablet swivel: switched to tablet mode | ||
| 509 | 0x500A Tablet swivel: switched to normal mode | ||
| 510 | 0x500B Tablet pen insterted into its storage bay | ||
| 511 | 0x500C Tablet pen removed from its storage bay | ||
| 512 | 0x5010 Brightness level changed (newer Lenovo BIOSes) | ||
| 513 | |||
| 514 | The above events are propagated by the driver. | ||
| 515 | |||
| 516 | Compatibility notes: | ||
| 517 | |||
| 518 | ibm-acpi and thinkpad-acpi 0.15 (mainline kernels before 2.6.23) never | ||
| 519 | supported the input layer, and sent events over the procfs ACPI event | ||
| 520 | interface. | ||
| 521 | |||
| 522 | To avoid sending duplicate events over the input layer and the ACPI | ||
| 523 | event interface, thinkpad-acpi 0.16 implements a module parameter | ||
| 524 | (hotkey_report_mode), and also a sysfs device attribute with the same | ||
| 525 | name. | ||
| 526 | |||
| 527 | Make no mistake here: userspace is expected to switch to using the input | ||
| 528 | layer interface of thinkpad-acpi, together with the ACPI netlink event | ||
| 529 | interface in kernels 2.6.23 and later, or with the ACPI procfs event | ||
| 530 | interface in kernels 2.6.22 and earlier. | ||
| 531 | |||
| 532 | If no hotkey_report_mode module parameter is specified (or it is set to | ||
| 533 | zero), the driver defaults to mode 1 (see below), and on kernels 2.6.22 | ||
| 534 | and earlier, also allows one to change the hotkey_report_mode through | ||
| 535 | sysfs. In kernels 2.6.23 and later, where the netlink ACPI event | ||
| 536 | interface is available, hotkey_report_mode cannot be changed through | ||
| 537 | sysfs (it is read-only). | ||
| 538 | |||
| 539 | If the hotkey_report_mode module parameter is set to 1 or 2, it cannot | ||
| 540 | be changed later through sysfs (any writes will return -EPERM to signal | ||
| 541 | that hotkey_report_mode was locked. On 2.6.23 and later, where | ||
| 542 | hotkey_report_mode cannot be changed at all, writes will return -EACES). | ||
| 543 | |||
| 544 | hotkey_report_mode set to 1 makes the driver export through the procfs | ||
| 545 | ACPI event interface all hot key presses (which are *also* sent to the | ||
| 546 | input layer). This is a legacy compatibility behaviour, and it is also | ||
| 547 | the default mode of operation for the driver. | ||
| 548 | |||
| 549 | hotkey_report_mode set to 2 makes the driver filter out the hot key | ||
| 550 | presses from the procfs ACPI event interface, so these events will only | ||
| 551 | be sent through the input layer. Userspace that has been updated to use | ||
| 552 | the thinkpad-acpi input layer interface should set hotkey_report_mode to | ||
| 553 | 2. | ||
| 554 | |||
| 555 | Hot key press events are never sent to the ACPI netlink event interface. | ||
| 556 | Really up-to-date userspace under kernel 2.6.23 and later is to use the | ||
| 557 | netlink interface and the input layer interface, and don't bother at all | ||
| 558 | with hotkey_report_mode. | ||
| 559 | |||
| 560 | |||
| 561 | Bluetooth | ||
| 562 | --------- | ||
| 563 | |||
| 564 | procfs: /proc/acpi/ibm/bluetooth | ||
| 565 | sysfs device attribute: bluetooth_enable | ||
| 566 | |||
| 567 | This feature shows the presence and current state of a ThinkPad | ||
| 568 | Bluetooth device in the internal ThinkPad CDC slot. | ||
| 569 | |||
| 570 | Procfs notes: | ||
| 571 | |||
| 572 | If Bluetooth is installed, the following commands can be used: | ||
| 573 | |||
| 574 | echo enable > /proc/acpi/ibm/bluetooth | ||
| 575 | echo disable > /proc/acpi/ibm/bluetooth | ||
| 576 | |||
| 577 | Sysfs notes: | ||
| 578 | |||
| 579 | If the Bluetooth CDC card is installed, it can be enabled / | ||
| 580 | disabled through the "bluetooth_enable" thinkpad-acpi device | ||
| 581 | attribute, and its current status can also be queried. | ||
| 582 | |||
| 583 | enable: | ||
| 584 | 0: disables Bluetooth / Bluetooth is disabled | ||
| 585 | 1: enables Bluetooth / Bluetooth is enabled. | ||
| 586 | |||
| 587 | Note: this interface will be probably be superseeded by the | ||
| 588 | generic rfkill class, so it is NOT to be considered stable yet. | ||
| 589 | |||
| 590 | Video output control -- /proc/acpi/ibm/video | ||
| 591 | -------------------------------------------- | ||
| 592 | |||
| 593 | This feature allows control over the devices used for video output - | ||
| 594 | LCD, CRT or DVI (if available). The following commands are available: | ||
| 595 | |||
| 596 | echo lcd_enable > /proc/acpi/ibm/video | ||
| 597 | echo lcd_disable > /proc/acpi/ibm/video | ||
| 598 | echo crt_enable > /proc/acpi/ibm/video | ||
| 599 | echo crt_disable > /proc/acpi/ibm/video | ||
| 600 | echo dvi_enable > /proc/acpi/ibm/video | ||
| 601 | echo dvi_disable > /proc/acpi/ibm/video | ||
| 602 | echo auto_enable > /proc/acpi/ibm/video | ||
| 603 | echo auto_disable > /proc/acpi/ibm/video | ||
| 604 | echo expand_toggle > /proc/acpi/ibm/video | ||
| 605 | echo video_switch > /proc/acpi/ibm/video | ||
| 606 | |||
| 607 | Each video output device can be enabled or disabled individually. | ||
| 608 | Reading /proc/acpi/ibm/video shows the status of each device. | ||
| 609 | |||
| 610 | Automatic video switching can be enabled or disabled. When automatic | ||
| 611 | video switching is enabled, certain events (e.g. opening the lid, | ||
| 612 | docking or undocking) cause the video output device to change | ||
| 613 | automatically. While this can be useful, it also causes flickering | ||
| 614 | and, on the X40, video corruption. By disabling automatic switching, | ||
| 615 | the flickering or video corruption can be avoided. | ||
| 616 | |||
| 617 | The video_switch command cycles through the available video outputs | ||
| 618 | (it simulates the behavior of Fn-F7). | ||
| 619 | |||
| 620 | Video expansion can be toggled through this feature. This controls | ||
| 621 | whether the display is expanded to fill the entire LCD screen when a | ||
| 622 | mode with less than full resolution is used. Note that the current | ||
| 623 | video expansion status cannot be determined through this feature. | ||
| 624 | |||
| 625 | Note that on many models (particularly those using Radeon graphics | ||
| 626 | chips) the X driver configures the video card in a way which prevents | ||
| 627 | Fn-F7 from working. This also disables the video output switching | ||
| 628 | features of this driver, as it uses the same ACPI methods as | ||
| 629 | Fn-F7. Video switching on the console should still work. | ||
| 630 | |||
| 631 | UPDATE: There's now a patch for the X.org Radeon driver which | ||
| 632 | addresses this issue. Some people are reporting success with the patch | ||
| 633 | while others are still having problems. For more information: | ||
| 634 | |||
| 635 | https://bugs.freedesktop.org/show_bug.cgi?id=2000 | ||
| 636 | |||
| 637 | ThinkLight control -- /proc/acpi/ibm/light | ||
| 638 | ------------------------------------------ | ||
| 639 | |||
| 640 | The current status of the ThinkLight can be found in this file. A few | ||
| 641 | models which do not make the status available will show it as | ||
| 642 | "unknown". The available commands are: | ||
| 643 | |||
| 644 | echo on > /proc/acpi/ibm/light | ||
| 645 | echo off > /proc/acpi/ibm/light | ||
| 646 | |||
| 647 | Docking / undocking -- /proc/acpi/ibm/dock | ||
| 648 | ------------------------------------------ | ||
| 649 | |||
| 650 | Docking and undocking (e.g. with the X4 UltraBase) requires some | ||
| 651 | actions to be taken by the operating system to safely make or break | ||
| 652 | the electrical connections with the dock. | ||
| 653 | |||
| 654 | The docking feature of this driver generates the following ACPI events: | ||
| 655 | |||
| 656 | ibm/dock GDCK 00000003 00000001 -- eject request | ||
| 657 | ibm/dock GDCK 00000003 00000002 -- undocked | ||
| 658 | ibm/dock GDCK 00000000 00000003 -- docked | ||
| 659 | |||
| 660 | NOTE: These events will only be generated if the laptop was docked | ||
| 661 | when originally booted. This is due to the current lack of support for | ||
| 662 | hot plugging of devices in the Linux ACPI framework. If the laptop was | ||
| 663 | booted while not in the dock, the following message is shown in the | ||
| 664 | logs: | ||
| 665 | |||
| 666 | Mar 17 01:42:34 aero kernel: thinkpad_acpi: dock device not present | ||
| 667 | |||
| 668 | In this case, no dock-related events are generated but the dock and | ||
| 669 | undock commands described below still work. They can be executed | ||
| 670 | manually or triggered by Fn key combinations (see the example acpid | ||
| 671 | configuration files included in the driver tarball package available | ||
| 672 | on the web site). | ||
| 673 | |||
| 674 | When the eject request button on the dock is pressed, the first event | ||
| 675 | above is generated. The handler for this event should issue the | ||
| 676 | following command: | ||
| 677 | |||
| 678 | echo undock > /proc/acpi/ibm/dock | ||
| 679 | |||
| 680 | After the LED on the dock goes off, it is safe to eject the laptop. | ||
| 681 | Note: if you pressed this key by mistake, go ahead and eject the | ||
| 682 | laptop, then dock it back in. Otherwise, the dock may not function as | ||
| 683 | expected. | ||
| 684 | |||
| 685 | When the laptop is docked, the third event above is generated. The | ||
| 686 | handler for this event should issue the following command to fully | ||
| 687 | enable the dock: | ||
| 688 | |||
| 689 | echo dock > /proc/acpi/ibm/dock | ||
| 690 | |||
| 691 | The contents of the /proc/acpi/ibm/dock file shows the current status | ||
| 692 | of the dock, as provided by the ACPI framework. | ||
| 693 | |||
| 694 | The docking support in this driver does not take care of enabling or | ||
| 695 | disabling any other devices you may have attached to the dock. For | ||
| 696 | example, a CD drive plugged into the UltraBase needs to be disabled or | ||
| 697 | enabled separately. See the provided example acpid configuration files | ||
| 698 | for how this can be accomplished. | ||
| 699 | |||
| 700 | There is no support yet for PCI devices that may be attached to a | ||
| 701 | docking station, e.g. in the ThinkPad Dock II. The driver currently | ||
| 702 | does not recognize, enable or disable such devices. This means that | ||
| 703 | the only docking stations currently supported are the X-series | ||
| 704 | UltraBase docks and "dumb" port replicators like the Mini Dock (the | ||
| 705 | latter don't need any ACPI support, actually). | ||
| 706 | |||
| 707 | UltraBay eject -- /proc/acpi/ibm/bay | ||
| 708 | ------------------------------------ | ||
| 709 | |||
| 710 | Inserting or ejecting an UltraBay device requires some actions to be | ||
| 711 | taken by the operating system to safely make or break the electrical | ||
| 712 | connections with the device. | ||
| 713 | |||
| 714 | This feature generates the following ACPI events: | ||
| 715 | |||
| 716 | ibm/bay MSTR 00000003 00000000 -- eject request | ||
| 717 | ibm/bay MSTR 00000001 00000000 -- eject lever inserted | ||
| 718 | |||
| 719 | NOTE: These events will only be generated if the UltraBay was present | ||
| 720 | when the laptop was originally booted (on the X series, the UltraBay | ||
| 721 | is in the dock, so it may not be present if the laptop was undocked). | ||
| 722 | This is due to the current lack of support for hot plugging of devices | ||
| 723 | in the Linux ACPI framework. If the laptop was booted without the | ||
| 724 | UltraBay, the following message is shown in the logs: | ||
| 725 | |||
| 726 | Mar 17 01:42:34 aero kernel: thinkpad_acpi: bay device not present | ||
| 727 | |||
| 728 | In this case, no bay-related events are generated but the eject | ||
| 729 | command described below still works. It can be executed manually or | ||
| 730 | triggered by a hot key combination. | ||
| 731 | |||
| 732 | Sliding the eject lever generates the first event shown above. The | ||
| 733 | handler for this event should take whatever actions are necessary to | ||
| 734 | shut down the device in the UltraBay (e.g. call idectl), then issue | ||
| 735 | the following command: | ||
| 736 | |||
| 737 | echo eject > /proc/acpi/ibm/bay | ||
| 738 | |||
| 739 | After the LED on the UltraBay goes off, it is safe to pull out the | ||
| 740 | device. | ||
| 741 | |||
| 742 | When the eject lever is inserted, the second event above is | ||
| 743 | generated. The handler for this event should take whatever actions are | ||
| 744 | necessary to enable the UltraBay device (e.g. call idectl). | ||
| 745 | |||
| 746 | The contents of the /proc/acpi/ibm/bay file shows the current status | ||
| 747 | of the UltraBay, as provided by the ACPI framework. | ||
| 748 | |||
| 749 | EXPERIMENTAL warm eject support on the 600e/x, A22p and A3x (To use | ||
| 750 | this feature, you need to supply the experimental=1 parameter when | ||
| 751 | loading the module): | ||
| 752 | |||
| 753 | These models do not have a button near the UltraBay device to request | ||
| 754 | a hot eject but rather require the laptop to be put to sleep | ||
| 755 | (suspend-to-ram) before the bay device is ejected or inserted). | ||
| 756 | The sequence of steps to eject the device is as follows: | ||
| 757 | |||
| 758 | echo eject > /proc/acpi/ibm/bay | ||
| 759 | put the ThinkPad to sleep | ||
| 760 | remove the drive | ||
| 761 | resume from sleep | ||
| 762 | cat /proc/acpi/ibm/bay should show that the drive was removed | ||
| 763 | |||
| 764 | On the A3x, both the UltraBay 2000 and UltraBay Plus devices are | ||
| 765 | supported. Use "eject2" instead of "eject" for the second bay. | ||
| 766 | |||
| 767 | Note: the UltraBay eject support on the 600e/x, A22p and A3x is | ||
| 768 | EXPERIMENTAL and may not work as expected. USE WITH CAUTION! | ||
| 769 | |||
| 770 | CMOS control | ||
| 771 | ------------ | ||
| 772 | |||
| 773 | procfs: /proc/acpi/ibm/cmos | ||
| 774 | sysfs device attribute: cmos_command | ||
| 775 | |||
| 776 | This feature is mostly used internally by the ACPI firmware to keep the legacy | ||
| 777 | CMOS NVRAM bits in sync with the current machine state, and to record this | ||
| 778 | state so that the ThinkPad will retain such settings across reboots. | ||
| 779 | |||
| 780 | Some of these commands actually perform actions in some ThinkPad models, but | ||
| 781 | this is expected to disappear more and more in newer models. As an example, in | ||
| 782 | a T43 and in a X40, commands 12 and 13 still control the ThinkLight state for | ||
| 783 | real, but commands 0 to 2 don't control the mixer anymore (they have been | ||
| 784 | phased out) and just update the NVRAM. | ||
| 785 | |||
| 786 | The range of valid cmos command numbers is 0 to 21, but not all have an | ||
| 787 | effect and the behavior varies from model to model. Here is the behavior | ||
| 788 | on the X40 (tpb is the ThinkPad Buttons utility): | ||
| 789 | |||
| 790 | 0 - Related to "Volume down" key press | ||
| 791 | 1 - Related to "Volume up" key press | ||
| 792 | 2 - Related to "Mute on" key press | ||
| 793 | 3 - Related to "Access IBM" key press | ||
| 794 | 4 - Related to "LCD brightness up" key pess | ||
| 795 | 5 - Related to "LCD brightness down" key press | ||
| 796 | 11 - Related to "toggle screen expansion" key press/function | ||
| 797 | 12 - Related to "ThinkLight on" | ||
| 798 | 13 - Related to "ThinkLight off" | ||
| 799 | 14 - Related to "ThinkLight" key press (toggle thinklight) | ||
| 800 | |||
| 801 | The cmos command interface is prone to firmware split-brain problems, as | ||
| 802 | in newer ThinkPads it is just a compatibility layer. Do not use it, it is | ||
| 803 | exported just as a debug tool. | ||
| 804 | |||
| 805 | LED control -- /proc/acpi/ibm/led | ||
| 806 | --------------------------------- | ||
| 807 | |||
| 808 | Some of the LED indicators can be controlled through this feature. The | ||
| 809 | available commands are: | ||
| 810 | |||
| 811 | echo '<led number> on' >/proc/acpi/ibm/led | ||
| 812 | echo '<led number> off' >/proc/acpi/ibm/led | ||
| 813 | echo '<led number> blink' >/proc/acpi/ibm/led | ||
| 814 | |||
| 815 | The <led number> range is 0 to 7. The set of LEDs that can be | ||
| 816 | controlled varies from model to model. Here is the mapping on the X40: | ||
| 817 | |||
| 818 | 0 - power | ||
| 819 | 1 - battery (orange) | ||
| 820 | 2 - battery (green) | ||
| 821 | 3 - UltraBase | ||
| 822 | 4 - UltraBay | ||
| 823 | 7 - standby | ||
| 824 | |||
| 825 | All of the above can be turned on and off and can be made to blink. | ||
| 826 | |||
| 827 | ACPI sounds -- /proc/acpi/ibm/beep | ||
| 828 | ---------------------------------- | ||
| 829 | |||
| 830 | The BEEP method is used internally by the ACPI firmware to provide | ||
| 831 | audible alerts in various situations. This feature allows the same | ||
| 832 | sounds to be triggered manually. | ||
| 833 | |||
| 834 | The commands are non-negative integer numbers: | ||
| 835 | |||
| 836 | echo <number> >/proc/acpi/ibm/beep | ||
| 837 | |||
| 838 | The valid <number> range is 0 to 17. Not all numbers trigger sounds | ||
| 839 | and the sounds vary from model to model. Here is the behavior on the | ||
| 840 | X40: | ||
| 841 | |||
| 842 | 0 - stop a sound in progress (but use 17 to stop 16) | ||
| 843 | 2 - two beeps, pause, third beep ("low battery") | ||
| 844 | 3 - single beep | ||
| 845 | 4 - high, followed by low-pitched beep ("unable") | ||
| 846 | 5 - single beep | ||
| 847 | 6 - very high, followed by high-pitched beep ("AC/DC") | ||
| 848 | 7 - high-pitched beep | ||
| 849 | 9 - three short beeps | ||
| 850 | 10 - very long beep | ||
| 851 | 12 - low-pitched beep | ||
| 852 | 15 - three high-pitched beeps repeating constantly, stop with 0 | ||
| 853 | 16 - one medium-pitched beep repeating constantly, stop with 17 | ||
| 854 | 17 - stop 16 | ||
| 855 | |||
| 856 | Temperature sensors | ||
| 857 | ------------------- | ||
| 858 | |||
| 859 | procfs: /proc/acpi/ibm/thermal | ||
| 860 | sysfs device attributes: (hwmon "thinkpad") temp*_input | ||
| 861 | |||
| 862 | Most ThinkPads include six or more separate temperature sensors but only | ||
| 863 | expose the CPU temperature through the standard ACPI methods. This | ||
| 864 | feature shows readings from up to eight different sensors on older | ||
| 865 | ThinkPads, and up to sixteen different sensors on newer ThinkPads. | ||
| 866 | |||
| 867 | For example, on the X40, a typical output may be: | ||
| 868 | temperatures: 42 42 45 41 36 -128 33 -128 | ||
| 869 | |||
| 870 | On the T43/p, a typical output may be: | ||
| 871 | temperatures: 48 48 36 52 38 -128 31 -128 48 52 48 -128 -128 -128 -128 -128 | ||
| 872 | |||
| 873 | The mapping of thermal sensors to physical locations varies depending on | ||
| 874 | system-board model (and thus, on ThinkPad model). | ||
| 875 | |||
| 876 | http://thinkwiki.org/wiki/Thermal_Sensors is a public wiki page that | ||
| 877 | tries to track down these locations for various models. | ||
| 878 | |||
| 879 | Most (newer?) models seem to follow this pattern: | ||
| 880 | |||
| 881 | 1: CPU | ||
| 882 | 2: (depends on model) | ||
| 883 | 3: (depends on model) | ||
| 884 | 4: GPU | ||
| 885 | 5: Main battery: main sensor | ||
| 886 | 6: Bay battery: main sensor | ||
| 887 | 7: Main battery: secondary sensor | ||
| 888 | 8: Bay battery: secondary sensor | ||
| 889 | 9-15: (depends on model) | ||
| 890 | |||
| 891 | For the R51 (source: Thomas Gruber): | ||
| 892 | 2: Mini-PCI | ||
| 893 | 3: Internal HDD | ||
| 894 | |||
| 895 | For the T43, T43/p (source: Shmidoax/Thinkwiki.org) | ||
| 896 | http://thinkwiki.org/wiki/Thermal_Sensors#ThinkPad_T43.2C_T43p | ||
| 897 | 2: System board, left side (near PCMCIA slot), reported as HDAPS temp | ||
| 898 | 3: PCMCIA slot | ||
| 899 | 9: MCH (northbridge) to DRAM Bus | ||
| 900 | 10: Clock-generator, mini-pci card and ICH (southbridge), under Mini-PCI | ||
| 901 | card, under touchpad | ||
| 902 | 11: Power regulator, underside of system board, below F2 key | ||
| 903 | |||
| 904 | The A31 has a very atypical layout for the thermal sensors | ||
| 905 | (source: Milos Popovic, http://thinkwiki.org/wiki/Thermal_Sensors#ThinkPad_A31) | ||
| 906 | 1: CPU | ||
| 907 | 2: Main Battery: main sensor | ||
| 908 | 3: Power Converter | ||
| 909 | 4: Bay Battery: main sensor | ||
| 910 | 5: MCH (northbridge) | ||
| 911 | 6: PCMCIA/ambient | ||
| 912 | 7: Main Battery: secondary sensor | ||
| 913 | 8: Bay Battery: secondary sensor | ||
| 914 | |||
| 915 | |||
| 916 | Procfs notes: | ||
| 917 | Readings from sensors that are not available return -128. | ||
| 918 | No commands can be written to this file. | ||
| 919 | |||
| 920 | Sysfs notes: | ||
| 921 | Sensors that are not available return the ENXIO error. This | ||
| 922 | status may change at runtime, as there are hotplug thermal | ||
| 923 | sensors, like those inside the batteries and docks. | ||
| 924 | |||
| 925 | thinkpad-acpi thermal sensors are reported through the hwmon | ||
| 926 | subsystem, and follow all of the hwmon guidelines at | ||
| 927 | Documentation/hwmon. | ||
| 928 | |||
| 929 | |||
| 930 | EXPERIMENTAL: Embedded controller register dump -- /proc/acpi/ibm/ecdump | ||
| 931 | ------------------------------------------------------------------------ | ||
| 932 | |||
| 933 | This feature is marked EXPERIMENTAL because the implementation | ||
| 934 | directly accesses hardware registers and may not work as expected. USE | ||
| 935 | WITH CAUTION! To use this feature, you need to supply the | ||
| 936 | experimental=1 parameter when loading the module. | ||
| 937 | |||
| 938 | This feature dumps the values of 256 embedded controller | ||
| 939 | registers. Values which have changed since the last time the registers | ||
| 940 | were dumped are marked with a star: | ||
| 941 | |||
| 942 | [root@x40 ibm-acpi]# cat /proc/acpi/ibm/ecdump | ||
| 943 | EC +00 +01 +02 +03 +04 +05 +06 +07 +08 +09 +0a +0b +0c +0d +0e +0f | ||
| 944 | EC 0x00: a7 47 87 01 fe 96 00 08 01 00 cb 00 00 00 40 00 | ||
| 945 | EC 0x10: 00 00 ff ff f4 3c 87 09 01 ff 42 01 ff ff 0d 00 | ||
| 946 | EC 0x20: 00 00 00 00 00 00 00 00 00 00 00 03 43 00 00 80 | ||
| 947 | EC 0x30: 01 07 1a 00 30 04 00 00 *85 00 00 10 00 50 00 00 | ||
| 948 | EC 0x40: 00 00 00 00 00 00 14 01 00 04 00 00 00 00 00 00 | ||
| 949 | EC 0x50: 00 c0 02 0d 00 01 01 02 02 03 03 03 03 *bc *02 *bc | ||
| 950 | EC 0x60: *02 *bc *02 00 00 00 00 00 00 00 00 00 00 00 00 00 | ||
| 951 | EC 0x70: 00 00 00 00 00 12 30 40 *24 *26 *2c *27 *20 80 *1f 80 | ||
| 952 | EC 0x80: 00 00 00 06 *37 *0e 03 00 00 00 0e 07 00 00 00 00 | ||
| 953 | EC 0x90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ||
| 954 | EC 0xa0: *ff 09 ff 09 ff ff *64 00 *00 *00 *a2 41 *ff *ff *e0 00 | ||
| 955 | EC 0xb0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ||
| 956 | EC 0xc0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ||
| 957 | EC 0xd0: 03 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ||
| 958 | EC 0xe0: 00 00 00 00 00 00 00 00 11 20 49 04 24 06 55 03 | ||
| 959 | EC 0xf0: 31 55 48 54 35 38 57 57 08 2f 45 73 07 65 6c 1a | ||
| 960 | |||
| 961 | This feature can be used to determine the register holding the fan | ||
| 962 | speed on some models. To do that, do the following: | ||
| 963 | |||
| 964 | - make sure the battery is fully charged | ||
| 965 | - make sure the fan is running | ||
| 966 | - run 'cat /proc/acpi/ibm/ecdump' several times, once per second or so | ||
| 967 | |||
| 968 | The first step makes sure various charging-related values don't | ||
| 969 | vary. The second ensures that the fan-related values do vary, since | ||
| 970 | the fan speed fluctuates a bit. The third will (hopefully) mark the | ||
| 971 | fan register with a star: | ||
| 972 | |||
| 973 | [root@x40 ibm-acpi]# cat /proc/acpi/ibm/ecdump | ||
| 974 | EC +00 +01 +02 +03 +04 +05 +06 +07 +08 +09 +0a +0b +0c +0d +0e +0f | ||
| 975 | EC 0x00: a7 47 87 01 fe 96 00 08 01 00 cb 00 00 00 40 00 | ||
| 976 | EC 0x10: 00 00 ff ff f4 3c 87 09 01 ff 42 01 ff ff 0d 00 | ||
| 977 | EC 0x20: 00 00 00 00 00 00 00 00 00 00 00 03 43 00 00 80 | ||
| 978 | EC 0x30: 01 07 1a 00 30 04 00 00 85 00 00 10 00 50 00 00 | ||
| 979 | EC 0x40: 00 00 00 00 00 00 14 01 00 04 00 00 00 00 00 00 | ||
| 980 | EC 0x50: 00 c0 02 0d 00 01 01 02 02 03 03 03 03 bc 02 bc | ||
| 981 | EC 0x60: 02 bc 02 00 00 00 00 00 00 00 00 00 00 00 00 00 | ||
| 982 | EC 0x70: 00 00 00 00 00 12 30 40 24 27 2c 27 21 80 1f 80 | ||
| 983 | EC 0x80: 00 00 00 06 *be 0d 03 00 00 00 0e 07 00 00 00 00 | ||
| 984 | EC 0x90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ||
| 985 | EC 0xa0: ff 09 ff 09 ff ff 64 00 00 00 a2 41 ff ff e0 00 | ||
| 986 | EC 0xb0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ||
| 987 | EC 0xc0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ||
| 988 | EC 0xd0: 03 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ||
| 989 | EC 0xe0: 00 00 00 00 00 00 00 00 11 20 49 04 24 06 55 03 | ||
| 990 | EC 0xf0: 31 55 48 54 35 38 57 57 08 2f 45 73 07 65 6c 1a | ||
| 991 | |||
| 992 | Another set of values that varies often is the temperature | ||
| 993 | readings. Since temperatures don't change vary fast, you can take | ||
| 994 | several quick dumps to eliminate them. | ||
| 995 | |||
| 996 | You can use a similar method to figure out the meaning of other | ||
| 997 | embedded controller registers - e.g. make sure nothing else changes | ||
| 998 | except the charging or discharging battery to determine which | ||
| 999 | registers contain the current battery capacity, etc. If you experiment | ||
| 1000 | with this, do send me your results (including some complete dumps with | ||
| 1001 | a description of the conditions when they were taken.) | ||
| 1002 | |||
| 1003 | LCD brightness control | ||
| 1004 | ---------------------- | ||
| 1005 | |||
| 1006 | procfs: /proc/acpi/ibm/brightness | ||
| 1007 | sysfs backlight device "thinkpad_screen" | ||
| 1008 | |||
| 1009 | This feature allows software control of the LCD brightness on ThinkPad | ||
| 1010 | models which don't have a hardware brightness slider. | ||
| 1011 | |||
| 1012 | It has some limitations: the LCD backlight cannot be actually turned on or | ||
| 1013 | off by this interface, and in many ThinkPad models, the "dim while on | ||
| 1014 | battery" functionality will be enabled by the BIOS when this interface is | ||
| 1015 | used, and cannot be controlled. | ||
| 1016 | |||
| 1017 | On IBM (and some of the earlier Lenovo) ThinkPads, the backlight control | ||
| 1018 | has eight brightness levels, ranging from 0 to 7. Some of the levels | ||
| 1019 | may not be distinct. Later Lenovo models that implement the ACPI | ||
| 1020 | display backlight brightness control methods have 16 levels, ranging | ||
| 1021 | from 0 to 15. | ||
| 1022 | |||
| 1023 | There are two interfaces to the firmware for direct brightness control, | ||
| 1024 | EC and CMOS. To select which one should be used, use the | ||
| 1025 | brightness_mode module parameter: brightness_mode=1 selects EC mode, | ||
| 1026 | brightness_mode=2 selects CMOS mode, brightness_mode=3 selects both EC | ||
| 1027 | and CMOS. The driver tries to autodetect which interface to use. | ||
| 1028 | |||
| 1029 | When display backlight brightness controls are available through the | ||
| 1030 | standard ACPI interface, it is best to use it instead of this direct | ||
| 1031 | ThinkPad-specific interface. The driver will disable its native | ||
| 1032 | backlight brightness control interface if it detects that the standard | ||
| 1033 | ACPI interface is available in the ThinkPad. | ||
| 1034 | |||
| 1035 | The brightness_enable module parameter can be used to control whether | ||
| 1036 | the LCD brightness control feature will be enabled when available. | ||
| 1037 | brightness_enable=0 forces it to be disabled. brightness_enable=1 | ||
| 1038 | forces it to be enabled when available, even if the standard ACPI | ||
| 1039 | interface is also available. | ||
| 1040 | |||
| 1041 | Procfs notes: | ||
| 1042 | |||
| 1043 | The available commands are: | ||
| 1044 | |||
| 1045 | echo up >/proc/acpi/ibm/brightness | ||
| 1046 | echo down >/proc/acpi/ibm/brightness | ||
| 1047 | echo 'level <level>' >/proc/acpi/ibm/brightness | ||
| 1048 | |||
| 1049 | Sysfs notes: | ||
| 1050 | |||
| 1051 | The interface is implemented through the backlight sysfs class, which is | ||
| 1052 | poorly documented at this time. | ||
| 1053 | |||
| 1054 | Locate the thinkpad_screen device under /sys/class/backlight, and inside | ||
| 1055 | it there will be the following attributes: | ||
| 1056 | |||
| 1057 | max_brightness: | ||
| 1058 | Reads the maximum brightness the hardware can be set to. | ||
| 1059 | The minimum is always zero. | ||
| 1060 | |||
| 1061 | actual_brightness: | ||
| 1062 | Reads what brightness the screen is set to at this instant. | ||
| 1063 | |||
| 1064 | brightness: | ||
| 1065 | Writes request the driver to change brightness to the | ||
| 1066 | given value. Reads will tell you what brightness the | ||
| 1067 | driver is trying to set the display to when "power" is set | ||
| 1068 | to zero and the display has not been dimmed by a kernel | ||
| 1069 | power management event. | ||
| 1070 | |||
| 1071 | power: | ||
| 1072 | power management mode, where 0 is "display on", and 1 to 3 | ||
| 1073 | will dim the display backlight to brightness level 0 | ||
| 1074 | because thinkpad-acpi cannot really turn the backlight | ||
| 1075 | off. Kernel power management events can temporarily | ||
| 1076 | increase the current power management level, i.e. they can | ||
| 1077 | dim the display. | ||
| 1078 | |||
| 1079 | |||
| 1080 | Volume control -- /proc/acpi/ibm/volume | ||
| 1081 | --------------------------------------- | ||
| 1082 | |||
| 1083 | This feature allows volume control on ThinkPad models which don't have | ||
| 1084 | a hardware volume knob. The available commands are: | ||
| 1085 | |||
| 1086 | echo up >/proc/acpi/ibm/volume | ||
| 1087 | echo down >/proc/acpi/ibm/volume | ||
| 1088 | echo mute >/proc/acpi/ibm/volume | ||
| 1089 | echo 'level <level>' >/proc/acpi/ibm/volume | ||
| 1090 | |||
| 1091 | The <level> number range is 0 to 15 although not all of them may be | ||
| 1092 | distinct. The unmute the volume after the mute command, use either the | ||
| 1093 | up or down command (the level command will not unmute the volume). | ||
| 1094 | The current volume level and mute state is shown in the file. | ||
| 1095 | |||
| 1096 | Fan control and monitoring: fan speed, fan enable/disable | ||
| 1097 | --------------------------------------------------------- | ||
| 1098 | |||
| 1099 | procfs: /proc/acpi/ibm/fan | ||
| 1100 | sysfs device attributes: (hwmon "thinkpad") fan1_input, pwm1, | ||
| 1101 | pwm1_enable | ||
| 1102 | sysfs hwmon driver attributes: fan_watchdog | ||
| 1103 | |||
| 1104 | NOTE NOTE NOTE: fan control operations are disabled by default for | ||
| 1105 | safety reasons. To enable them, the module parameter "fan_control=1" | ||
| 1106 | must be given to thinkpad-acpi. | ||
| 1107 | |||
| 1108 | This feature attempts to show the current fan speed, control mode and | ||
| 1109 | other fan data that might be available. The speed is read directly | ||
| 1110 | from the hardware registers of the embedded controller. This is known | ||
| 1111 | to work on later R, T, X and Z series ThinkPads but may show a bogus | ||
| 1112 | value on other models. | ||
| 1113 | |||
| 1114 | Fan levels: | ||
| 1115 | |||
| 1116 | Most ThinkPad fans work in "levels" at the firmware interface. Level 0 | ||
| 1117 | stops the fan. The higher the level, the higher the fan speed, although | ||
| 1118 | adjacent levels often map to the same fan speed. 7 is the highest | ||
| 1119 | level, where the fan reaches the maximum recommended speed. | ||
| 1120 | |||
| 1121 | Level "auto" means the EC changes the fan level according to some | ||
| 1122 | internal algorithm, usually based on readings from the thermal sensors. | ||
| 1123 | |||
| 1124 | There is also a "full-speed" level, also known as "disengaged" level. | ||
| 1125 | In this level, the EC disables the speed-locked closed-loop fan control, | ||
| 1126 | and drives the fan as fast as it can go, which might exceed hardware | ||
| 1127 | limits, so use this level with caution. | ||
| 1128 | |||
| 1129 | The fan usually ramps up or down slowly from one speed to another, and | ||
| 1130 | it is normal for the EC to take several seconds to react to fan | ||
| 1131 | commands. The full-speed level may take up to two minutes to ramp up to | ||
| 1132 | maximum speed, and in some ThinkPads, the tachometer readings go stale | ||
| 1133 | while the EC is transitioning to the full-speed level. | ||
| 1134 | |||
| 1135 | WARNING WARNING WARNING: do not leave the fan disabled unless you are | ||
| 1136 | monitoring all of the temperature sensor readings and you are ready to | ||
| 1137 | enable it if necessary to avoid overheating. | ||
| 1138 | |||
| 1139 | An enabled fan in level "auto" may stop spinning if the EC decides the | ||
| 1140 | ThinkPad is cool enough and doesn't need the extra airflow. This is | ||
| 1141 | normal, and the EC will spin the fan up if the various thermal readings | ||
| 1142 | rise too much. | ||
| 1143 | |||
| 1144 | On the X40, this seems to depend on the CPU and HDD temperatures. | ||
| 1145 | Specifically, the fan is turned on when either the CPU temperature | ||
| 1146 | climbs to 56 degrees or the HDD temperature climbs to 46 degrees. The | ||
| 1147 | fan is turned off when the CPU temperature drops to 49 degrees and the | ||
| 1148 | HDD temperature drops to 41 degrees. These thresholds cannot | ||
| 1149 | currently be controlled. | ||
| 1150 | |||
| 1151 | The ThinkPad's ACPI DSDT code will reprogram the fan on its own when | ||
| 1152 | certain conditions are met. It will override any fan programming done | ||
| 1153 | through thinkpad-acpi. | ||
| 1154 | |||
| 1155 | The thinkpad-acpi kernel driver can be programmed to revert the fan | ||
| 1156 | level to a safe setting if userspace does not issue one of the procfs | ||
| 1157 | fan commands: "enable", "disable", "level" or "watchdog", or if there | ||
| 1158 | are no writes to pwm1_enable (or to pwm1 *if and only if* pwm1_enable is | ||
| 1159 | set to 1, manual mode) within a configurable amount of time of up to | ||
| 1160 | 120 seconds. This functionality is called fan safety watchdog. | ||
| 1161 | |||
| 1162 | Note that the watchdog timer stops after it enables the fan. It will be | ||
| 1163 | rearmed again automatically (using the same interval) when one of the | ||
| 1164 | above mentioned fan commands is received. The fan watchdog is, | ||
| 1165 | therefore, not suitable to protect against fan mode changes made through | ||
| 1166 | means other than the "enable", "disable", and "level" procfs fan | ||
| 1167 | commands, or the hwmon fan control sysfs interface. | ||
| 1168 | |||
| 1169 | Procfs notes: | ||
| 1170 | |||
| 1171 | The fan may be enabled or disabled with the following commands: | ||
| 1172 | |||
| 1173 | echo enable >/proc/acpi/ibm/fan | ||
| 1174 | echo disable >/proc/acpi/ibm/fan | ||
| 1175 | |||
| 1176 | Placing a fan on level 0 is the same as disabling it. Enabling a fan | ||
| 1177 | will try to place it in a safe level if it is too slow or disabled. | ||
| 1178 | |||
| 1179 | The fan level can be controlled with the command: | ||
| 1180 | |||
| 1181 | echo 'level <level>' > /proc/acpi/ibm/fan | ||
| 1182 | |||
| 1183 | Where <level> is an integer from 0 to 7, or one of the words "auto" or | ||
| 1184 | "full-speed" (without the quotes). Not all ThinkPads support the "auto" | ||
| 1185 | and "full-speed" levels. The driver accepts "disengaged" as an alias for | ||
| 1186 | "full-speed", and reports it as "disengaged" for backwards | ||
| 1187 | compatibility. | ||
| 1188 | |||
| 1189 | On the X31 and X40 (and ONLY on those models), the fan speed can be | ||
| 1190 | controlled to a certain degree. Once the fan is running, it can be | ||
| 1191 | forced to run faster or slower with the following command: | ||
| 1192 | |||
| 1193 | echo 'speed <speed>' > /proc/acpi/ibm/fan | ||
| 1194 | |||
| 1195 | The sustainable range of fan speeds on the X40 appears to be from about | ||
| 1196 | 3700 to about 7350. Values outside this range either do not have any | ||
| 1197 | effect or the fan speed eventually settles somewhere in that range. The | ||
| 1198 | fan cannot be stopped or started with this command. This functionality | ||
| 1199 | is incomplete, and not available through the sysfs interface. | ||
| 1200 | |||
| 1201 | To program the safety watchdog, use the "watchdog" command. | ||
| 1202 | |||
| 1203 | echo 'watchdog <interval in seconds>' > /proc/acpi/ibm/fan | ||
| 1204 | |||
| 1205 | If you want to disable the watchdog, use 0 as the interval. | ||
| 1206 | |||
| 1207 | Sysfs notes: | ||
| 1208 | |||
| 1209 | The sysfs interface follows the hwmon subsystem guidelines for the most | ||
| 1210 | part, and the exception is the fan safety watchdog. | ||
| 1211 | |||
| 1212 | Writes to any of the sysfs attributes may return the EINVAL error if | ||
| 1213 | that operation is not supported in a given ThinkPad or if the parameter | ||
| 1214 | is out-of-bounds, and EPERM if it is forbidden. They may also return | ||
| 1215 | EINTR (interrupted system call), and EIO (I/O error while trying to talk | ||
| 1216 | to the firmware). | ||
| 1217 | |||
| 1218 | Features not yet implemented by the driver return ENOSYS. | ||
| 1219 | |||
| 1220 | hwmon device attribute pwm1_enable: | ||
| 1221 | 0: PWM offline (fan is set to full-speed mode) | ||
| 1222 | 1: Manual PWM control (use pwm1 to set fan level) | ||
| 1223 | 2: Hardware PWM control (EC "auto" mode) | ||
| 1224 | 3: reserved (Software PWM control, not implemented yet) | ||
| 1225 | |||
| 1226 | Modes 0 and 2 are not supported by all ThinkPads, and the | ||
| 1227 | driver is not always able to detect this. If it does know a | ||
| 1228 | mode is unsupported, it will return -EINVAL. | ||
| 1229 | |||
| 1230 | hwmon device attribute pwm1: | ||
| 1231 | Fan level, scaled from the firmware values of 0-7 to the hwmon | ||
| 1232 | scale of 0-255. 0 means fan stopped, 255 means highest normal | ||
| 1233 | speed (level 7). | ||
| 1234 | |||
| 1235 | This attribute only commands the fan if pmw1_enable is set to 1 | ||
| 1236 | (manual PWM control). | ||
| 1237 | |||
| 1238 | hwmon device attribute fan1_input: | ||
| 1239 | Fan tachometer reading, in RPM. May go stale on certain | ||
| 1240 | ThinkPads while the EC transitions the PWM to offline mode, | ||
| 1241 | which can take up to two minutes. May return rubbish on older | ||
| 1242 | ThinkPads. | ||
| 1243 | |||
| 1244 | hwmon driver attribute fan_watchdog: | ||
| 1245 | Fan safety watchdog timer interval, in seconds. Minimum is | ||
| 1246 | 1 second, maximum is 120 seconds. 0 disables the watchdog. | ||
| 1247 | |||
| 1248 | To stop the fan: set pwm1 to zero, and pwm1_enable to 1. | ||
| 1249 | |||
| 1250 | To start the fan in a safe mode: set pwm1_enable to 2. If that fails | ||
| 1251 | with EINVAL, try to set pwm1_enable to 1 and pwm1 to at least 128 (255 | ||
| 1252 | would be the safest choice, though). | ||
| 1253 | |||
| 1254 | |||
| 1255 | EXPERIMENTAL: WAN | ||
| 1256 | ----------------- | ||
| 1257 | |||
| 1258 | procfs: /proc/acpi/ibm/wan | ||
| 1259 | sysfs device attribute: wwan_enable | ||
| 1260 | |||
| 1261 | This feature is marked EXPERIMENTAL because the implementation | ||
| 1262 | directly accesses hardware registers and may not work as expected. USE | ||
| 1263 | WITH CAUTION! To use this feature, you need to supply the | ||
| 1264 | experimental=1 parameter when loading the module. | ||
| 1265 | |||
| 1266 | This feature shows the presence and current state of a W-WAN (Sierra | ||
| 1267 | Wireless EV-DO) device. | ||
| 1268 | |||
| 1269 | It was tested on a Lenovo Thinkpad X60. It should probably work on other | ||
| 1270 | Thinkpad models which come with this module installed. | ||
| 1271 | |||
| 1272 | Procfs notes: | ||
| 1273 | |||
| 1274 | If the W-WAN card is installed, the following commands can be used: | ||
| 1275 | |||
| 1276 | echo enable > /proc/acpi/ibm/wan | ||
| 1277 | echo disable > /proc/acpi/ibm/wan | ||
| 1278 | |||
| 1279 | Sysfs notes: | ||
| 1280 | |||
| 1281 | If the W-WAN card is installed, it can be enabled / | ||
| 1282 | disabled through the "wwan_enable" thinkpad-acpi device | ||
| 1283 | attribute, and its current status can also be queried. | ||
| 1284 | |||
| 1285 | enable: | ||
| 1286 | 0: disables WWAN card / WWAN card is disabled | ||
| 1287 | 1: enables WWAN card / WWAN card is enabled. | ||
| 1288 | |||
| 1289 | Note: this interface will be probably be superseeded by the | ||
| 1290 | generic rfkill class, so it is NOT to be considered stable yet. | ||
| 1291 | |||
| 1292 | Multiple Commands, Module Parameters | ||
| 1293 | ------------------------------------ | ||
| 1294 | |||
| 1295 | Multiple commands can be written to the proc files in one shot by | ||
| 1296 | separating them with commas, for example: | ||
| 1297 | |||
| 1298 | echo enable,0xffff > /proc/acpi/ibm/hotkey | ||
| 1299 | echo lcd_disable,crt_enable > /proc/acpi/ibm/video | ||
| 1300 | |||
| 1301 | Commands can also be specified when loading the thinkpad-acpi module, | ||
| 1302 | for example: | ||
| 1303 | |||
| 1304 | modprobe thinkpad_acpi hotkey=enable,0xffff video=auto_disable | ||
| 1305 | |||
| 1306 | Enabling debugging output | ||
| 1307 | ------------------------- | ||
| 1308 | |||
| 1309 | The module takes a debug parameter which can be used to selectively | ||
| 1310 | enable various classes of debugging output, for example: | ||
| 1311 | |||
| 1312 | modprobe ibm_acpi debug=0xffff | ||
| 1313 | |||
| 1314 | will enable all debugging output classes. It takes a bitmask, so | ||
| 1315 | to enable more than one output class, just add their values. | ||
| 1316 | |||
| 1317 | Debug bitmask Description | ||
| 1318 | 0x0001 Initialization and probing | ||
| 1319 | 0x0002 Removal | ||
| 1320 | |||
| 1321 | There is also a kernel build option to enable more debugging | ||
| 1322 | information, which may be necessary to debug driver problems. | ||
| 1323 | |||
| 1324 | The level of debugging information output by the driver can be changed | ||
| 1325 | at runtime through sysfs, using the driver attribute debug_level. The | ||
| 1326 | attribute takes the same bitmask as the debug module parameter above. | ||
| 1327 | |||
| 1328 | Force loading of module | ||
| 1329 | ----------------------- | ||
| 1330 | |||
| 1331 | If thinkpad-acpi refuses to detect your ThinkPad, you can try to specify | ||
| 1332 | the module parameter force_load=1. Regardless of whether this works or | ||
| 1333 | not, please contact ibm-acpi-devel@lists.sourceforge.net with a report. | ||
| 1334 | |||
| 1335 | |||
| 1336 | Sysfs interface changelog: | ||
| 1337 | |||
| 1338 | 0x000100: Initial sysfs support, as a single platform driver and | ||
| 1339 | device. | ||
| 1340 | 0x000200: Hot key support for 32 hot keys, and radio slider switch | ||
| 1341 | support. | ||
| 1342 | 0x010000: Hot keys are now handled by default over the input | ||
| 1343 | layer, the radio switch generates input event EV_RADIO, | ||
| 1344 | and the driver enables hot key handling by default in | ||
| 1345 | the firmware. | ||
| 1346 | |||
| 1347 | 0x020000: ABI fix: added a separate hwmon platform device and | ||
| 1348 | driver, which must be located by name (thinkpad) | ||
| 1349 | and the hwmon class for libsensors4 (lm-sensors 3) | ||
| 1350 | compatibility. Moved all hwmon attributes to this | ||
| 1351 | new platform device. | ||
| 1352 | |||
| 1353 | 0x020100: Marker for thinkpad-acpi with hot key NVRAM polling | ||
| 1354 | support. If you must, use it to know you should not | ||
| 1355 | start an userspace NVRAM poller (allows to detect when | ||
| 1356 | NVRAM is compiled out by the user because it is | ||
| 1357 | unneeded/undesired in the first place). | ||
| 1358 | 0x020101: Marker for thinkpad-acpi with hot key NVRAM polling | ||
| 1359 | and proper hotkey_mask semanthics (version 8 of the | ||
| 1360 | NVRAM polling patch). Some development snapshots of | ||
| 1361 | 0.18 had an earlier version that did strange things | ||
| 1362 | to hotkey_mask. | ||
| 1363 | |||
| 1364 | 0x020200: Add poll()/select() support to the following attributes: | ||
| 1365 | hotkey_radio_sw, wakeup_hotunplug_complete, wakeup_reason | ||