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