https://www.thinkwiki.org/w/api.php?action=feedcontributions&user=Denisq&feedformat=atomThinkWiki - User contributions [en]2024-03-29T08:44:05ZUser contributionsMediaWiki 1.31.12https://www.thinkwiki.org/w/index.php?title=Laptop-mode-tools&diff=51469Laptop-mode-tools2011-04-27T10:42:31Z<p>Denisq: /* Packages */</p>
<hr />
<div>__TOC__<br />
laptop-mode-tools is the userland component of [[Laptop-mode|laptop mode]], the Linux kernel mode that allows you to spin down your hard drives for longer periods of time. This package takes care of configuration and activation of laptop-mode, automatically remounting your filesystems with the appropriate options, and modifying the idle timeouts for your hard drives. Laptop mode tools integrate with power management daemons such as acpid, apmd and pbbuttonsd, so that laptop mode is started automatically when your laptop is running on batteries.<br />
<br />
=== Project Homepage / Availability ===<br />
http://www.samwel.tk/laptop_mode/<br />
<br />
=== Status ===<br />
*stable, active<br />
<br />
=== Packages ===<br />
* {{Debian}} packages are available: http://packages.debian.org/laptop-mode-tools . These packages are well-maintained, so you might just want to {{cmdroot|apt-get install laptop-mode-tools}} or {{cmdroot|aptitude install laptop-mode-tools}}<br />
* {{Fedora|Fedora Core}} 4 packages are available in the [http://dries.ulyssis.org/rpm/ Dries RPM repository].<br />
* {{OpenSUSE}} packages are available: http://software.opensuse.org/search?q=laptop-mode-tools&baseproject=ALL&lang=de&include_home=true&exclude_debug=true (latest version only provided by home projects, openSUSE 11.4 ships and old version of laptop-mode-tools).<br />
<br />
=== Documentation ===<br />
* The [http://www.samwel.tk/laptop_mode/ Project Home Page] holds installation instructions.<br />
* There is a [http://www.samwel.tk/laptop_mode/faq FAQ].<br />
* Read /lib/modules/`uname -r`/source/Documentation/laptop-mode.txt on your system.<br />
* The configuration file (/etc/laptop-mode/laptop-mode.conf) is well-commented, and a verbose manual page is available for it as well.<br />
<br />
<!--<br />
=== Sample configuration ===<br />
--><br />
<br />
<!--<br />
=== Contact ===<br />
Contact the author at [mailto:...].<br />
--><br />
<br />
<!--<br />
=== Related links === <br />
--><br />
<br />
[[Category:Tools]] [[Category:Debian]]</div>Denisqhttps://www.thinkwiki.org/w/index.php?title=How_to_reduce_power_consumption&diff=50757How to reduce power consumption2011-03-02T00:47:02Z<p>Denisq: forcing hpet adds "Clock Event Device: hpet" in /proc/timer_list</p>
<hr />
<div>Reducing system power consumption will extend battery life, reduce system<br />
temperature and (on some models) reduce system fan noise.<br />
Power consumption can be greatly improved from a stock distribution configuration<br />
to a fine tuned system. The general rules are :<br />
* Unload drivers for unused devices (ie. USB 1.1, Yenta/PCMCIA, Wireless, IRDA, Bluetooth, ...)<br />
* Reduce polling on devices (drives, USB subsystem, nvram, use SATA AN, ...)<br />
* Reduce hard drive activity<br />
* Reduce LCD brightness to the minimum you can stand<br />
* Reduce CPU wakeups, so it can stay longer in deep power saving c-states<br />
* Make use of every hardware devices availables power saving features (AHCI ALPM, USB autosuspend, Alsa and Wireless powersaving modes, HPET timers, ...)<br />
<br />
==Tools==<br />
Arjan van de Ven's [[PowerTOP]] utility<br />
is a gold mine to improve energy efficiency, but is almost only CPU-oriented. This tool helps to easily detect<br />
the top power offenders, both userland and kernel modules, which prevent the use of CPU power saving mechanisms and sometime suggest <br />
fixes accordingly.<br />
PowerTOP users collected some [http://www.lesswatts.org/projects/powertop/known.php tips & tricks]<br />
and an informative [http://www.lesswatts.org/projects/powertop/faq.php faq].<br />
<br />
Alternatively (or complementary) to PowerTOP, running <code>strace -p $(pidof yourapp)</code> <br />
for all your favorite or background running applications while they are expected to be <br />
idle, will show the misbehaviors.<br />
<br />
Beside CPU wakeups, disks spins are also power hungry. To detect what make your disk spinning,<br />
<br />
<code><br />
sysctl vm.block_dump=1<br />
</code><br />
<br />
will list all applications causing disks wakeups on the kernel's dmesg.<br />
Other useful tools for this purpose are blktrace, iostat and lm-profiler<br />
(from laptop-mode-tools suite).<br />
<br />
See also [[#Misbehaving Userland]].<br />
<br />
==BIOS settings==<br />
===Enabling Power Management===<br />
Some Thinkpad BIOS (like 2.08 BIOS on {{X40}}) offer two very lame options,<br />
with a very misleading online help (saying "Usually not needed"). That's<br />
<br />
<code><br />
CPU power management: (default disabled)<br />
PCI bus power management: (default disabled)<br />
</code><br />
<br />
You should indeed ''enable'' them, else the deepest C3 and C4 ACPI C-states<br />
are disabled.<br />
<br />
===Disabling I/O Ports===<br />
The BIOS (at least version 3.11 on {{X200}}) can also be used to disable I/O ports, like PCMCIA/CardBus. Although this requires a reboot to change settings, using the BIOS rather than a configuration file will survive distribution changes and may make it easier to remember how to re-enable a port. Disabling these devices can reduce power consumption by several watts.<br />
<br />
==CPU==<br />
Look at:<br />
* [[How to make use of Dynamic Frequency Scaling]]<br />
* [[Pentium M undervolting and underclocking]]<br />
<br />
A good thing to keep in mind is that every CPU wakeup, even if it's for<br />
a trivial light job, reduce the time the CPU stays on a deep power<br />
saving C-state (like C3 or C4). Therefore you should ensure your applications<br />
stay really idle when they meant to be idle (track shorts select timeouts<br />
in loop, etc. with [[PowerTOP]]).<br />
<br />
Also note that manually locking the CPU in the lowest P-state (frequency) <br />
available is '''not''' an efficient way to improve battery lifetime. This will<br />
cause the CPU to stay longer in C0 (power hungry C-state) doing hard work when <br />
there is something to do, while it could have done this work faster by augmenting<br />
the CPU freq, and returned back faster to a deeper, economic, C-state and to a<br />
lower frequency (P-state).<br />
The best is to let the kernel select the appropriates CPU frequencies by itself<br />
with the help of in kernel CPU governors.<br />
Have a look at [http://www.bughost.org/pipermail/power/2007-May/000166.html this explanation]<br />
from Intel's kernel developer Arjan van de Ven.<br />
<br />
==Kernel settings and patches==<br />
<br />
===General settings===<br />
The 2.6.21 kernel brought some very effective changes (like [[dynticks]]). <br />
Later, 2.6.24-rc2 brought a lot of other power efficiency improvements. <br />
If it's not already on your distribution and you value power efficiency, <br />
you may think about compiling a recent kernel yourself. <br />
<br />
Here are a few options (beside the ACPI and APM related one) that matter to <br />
reduce power consumption or to help diagnosing consumers:<br />
<br />
<code><br />
# From PowerTOP's FAQ:<br />
CONFIG_NO_HZ<br />
CONFIG_HIGH_RES_TIMERS<br />
CONFIG_HPET<br />
CONFIG_HPET_TIMER<br />
CONFIG_CPU_FREQ_GOV_ONDEMAND<br />
CONFIG_USB_SUSPEND<br />
CONFIG_SND_AC97_POWER_SAVE<br />
CONFIG_SND_HDA_POWER_SAVE<br />
CONFIG_SND_HDA_POWER_SAVE_DEFAULT=3<br />
CONFIG_TIMER_STATS<br />
CONFIG_ACPI_BATTERY<br />
CONFIG_CPU_FREQ_STAT<br />
CONFIG_INOTIFY<br />
<br />
# Not from the PowerTOP FAQ:<br />
CONFIG_BLK_DEV_IO_TRACE<br />
CONFIG_X86_ACPI_CPUFREQ<br />
CONFIG_X86_SPEEDSTEP_CENTRINO depreciated as of kernel 2.6.24, use CONFIG_X86_ACPI_CPUFREQ<br />
CONFIG_X86_SPEEDSTEP_ICH<br />
CONFIG_X86_SPEEDSTEP_SMI<br />
CONFIG_CPU_IDLE<br />
CONFIG_CPU_IDLE_GOV_LADDER<br />
CONFIG_CPU_IDLE_GOV_MENU<br />
</code><br />
<br />
Those options are already in Fedora Core 7 and Ubuntu Gutsy (not Feisty) default i686 kernels.<br />
PowerTOP FAQ also suggest to '''disable'''<br />
CONFIG_IRQBALANCE and CONFIG_ACPI_DEBUG.<br />
<br />
Also, you need to properly set APM and ACPI. Look at:<br />
* [[Power Management]]<br />
* [[How to make use of Power Management features]]<br />
<br />
=== Kernel boot and module loading options ===<br />
If you have an Intel chipset ICH5 or later (cf. lspci output), as in most modern Thinkpads, you should<br />
be using the integrated HPET timer (saves about 30 CPU wake ups per second). To see if<br />
hpet is enabled on your laptop:<br />
<br />
<code><br />
grep hpet /proc/timer_list<br />
</code><br />
<br />
If this does not display "Clock Event Device: hpet", then add <br />
<br />
<code><br />
hpet=force<br />
</code><br />
<br />
{{WARN|The ICH4 does have an HPET, but it is disabled for a good reason: Intel didn't test/validade it! Use of the ICH4 HPET is '''not''' recommended}}<br />
<br />
to your kernel boot options (usualy in /boot/grub/menu.lst or lilo.conf). <br />
Note that "hpet=force" is only available by default in 2.6.24-rc2 and above <br />
(or as a separated patch for 2.6.22 and 2.6.23, see below).<br />
<br />
On modern ThinkPads the HPET timer is automatically detected and enabled. On certain older machines hpet=force is required such as on the following machines:<br />
* {{T30}}, {{T40}}, {{T40p}}, {{T41}}, {{T41p}}, {{T42}}<br />
* {{X22}}, {{X23}}, {{X24}}, {{X30}}, {{X31}}, {{X40}}<br />
* {{A31}}<br />
* {{SL500}}<br />
<br />
{{HELP|please add your ThinkPad to the above list, if <nowiki>hpet=force</nowiki> was required}}<br />
<br />
===Useful Patches===<br />
<br />
Thomas Gleixner High Resolution Timers (hrt) patchset brings many improvements,<br />
like the cpuidle work and Udo A. Steinberg and Venki Pallipadi "force<br />
enable HPET" patches (non HPET timers causes about 20-40 CPU wakeups/second, but<br />
HPET is often hidden by the BIOS due to Windows XP deficiencies). Those are <br />
fully merged in 2.6.24-rc1 vanilla kernel.<br />
See http://www.tglx.de/projects/hrtimers/<br />
<br />
Kristen Carlson Accardi from Intel has a patchset to turn on "Aggressive<br />
Link Power Management" (ALPM) for the AHCI driver (for SATA bus). Also from<br />
Accardi, SATA Asynchronous Notification (SATA AN), alows SATA link to notify<br />
media insertions (thus avoid hal polling the cdrom). Those patches were merged <br />
in 2.6.24-rc2 kernel (AN needs also support in hal to be used).<br />
See: http://www.kernel.org/pub/linux/kernel/people/kristen/patches/SATA/alpm/<br />
<br />
As of now (2.6.24-rc8), the linux kernel doesn't support PCI Express power <br />
management (aka PCIe ASPM, aka PCIe LPM). Shaohua Li from Intel submited a <br />
patch on LKML (http://lkml.org/lkml/2008/1/17/544 ) though, and reported it <br />
to reduce power consumption by 1.3 watts for a system with three PCIe links.<br />
<br />
The [[HDAPS]] disk protection systems can reduce battery life. <br />
Matthew Garrett provides [http://www.linuxpowertop.org/patches/hdaps.patch a patch]<br />
that prevents hdaps kernel module to generate interrupts when<br />
this feature isn't used.<br />
<br />
===Useful sysctls===<br />
The meaning of those settings is explained case by case on the relevant <br />
sections of this document. But for convenience sake, we group them here too.<br />
<br />
Note that the "ondemand" scaling governor is recommended by Intel developers<br />
for energy efficiency: it's expected to be more efficient than the "powersave"<br />
governor, or than userspace daemons (like cpufreq-utils, cpufreqd, powernowd...).<br />
Look [http://www.bughost.org/pipermail/power/2007-May/000071.html here],<br />
[http://www.bughost.org/pipermail/power/2007-May/000073.html here], or<br />
[http://www.bughost.org/pipermail/power/2007-May/000166.html here] for a<br />
kernel developer explanation about "ondemand" being better on modern Intel CPUs.<br />
<br />
The "link_power_management_policy" tunable won't be available unless you<br />
run a 2.6.24-rc2 or more kernel, or applied Kirsten patchset, have an Intel <br />
AHCI compatible chipset, and use SATA drives.<br />
<br />
<code><br />
echo 5 > /proc/sys/vm/laptop_mode<br />
echo 0 > /proc/sys/kernel/nmi_watchdog<br />
echo Y > /sys/module/snd_ac97_codec/parameters/power_save<br />
echo 1 > /sys/devices/system/cpu/sched_mc_power_savings<br />
echo ondemand > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor<br />
echo 1500 > /proc/sys/vm/dirty_writeback_centisecs<br />
for i in /sys/bus/usb/devices/*/power/autosuspend; do echo 1 > $i; done<br />
# those sysctl's are only available if you have an AHCI compatible SATA <br />
# controler and use kernel > 2.6.24-rc2 (or use Kristen ALPM patchset) : <br />
echo min_power > /sys/class/scsi_host/host0/link_power_management_policy<br />
echo min_power > /sys/class/scsi_host/host1/link_power_management_policy<br />
</code><br />
<br />
If you're running a kernel older than 2.6.22 do this. Not needed for kernels 2.6.22 onward:<br />
<br />
<code><br />
cd /sys/devices/system/cpu/cpu0/cpufreq<br />
cat ondemand/sampling_rate_max > ondemand/sampling_rate<br />
</code><br />
<br />
==ATA drives==<br />
Hard drives and CDRom drives spinning is very costly. To improve battery<br />
lifetime, you should reduce disks access (or devices polling) the more you<br />
can. <br />
<br />
===Hard Drives===<br />
<br />
The files access time update, while mandated by POSIX, is causing lots of<br />
disk write access; even accessing files on disk cache may wake the ATA or USB<br />
bus. If you don't use this feature, disable it by adding the <tt>relatime</tt><br />
option to all relevant lines in the /etc/fstab, for example:<br />
/dev/sda1 / ext3 relatime,errors=remount-ro 0 1<br />
<br />
(On older kernels you may need to use <tt>noatime</tt> instead of <tt>relatime</tt>.)<br />
<br />
Also consider merely using a larger value for the <tt>commit</tt> option. This defines how often changed data is written to the disk (it is cached until then). The default value is 5 seconds.<br />
<br />
See man mount(8) for details on how the <tt>rel/noatime</tt> and <tt>commit</tt> options work.<br />
<br />
Use laptop_mode to reduce disk usage by delaying and grouping writes. You should enable<br />
it, at least while on battery. See [[Laptop-mode]] for more details:<br />
<br />
<code><br />
echo 5 > /proc/sys/vm/laptop_mode<br />
</code><br />
<br />
The default kernel dirty page writeback frequency is very conservative. On<br />
a laptop running on battery, one might find more appropriate to reduce it:<br />
<br />
<code><br />
echo 1500 > /proc/sys/vm/dirty_writeback_centisecs<br />
</code><br />
<br />
Some power saving hard drives features can be activated with hdparm (beware<br />
that "-B 1" may reduce your drive lifetime, if you have lot of intermittent<br />
disk activity causing lots of heads load/unloads: so reduce I/O activity first,<br />
as explained above, in order to get longer disks idling periods).<br />
For more details look at [[How to make use of Power Management features]] :<br />
<br />
<code> <br />
hdparm -B 1 -S 12 /dev/sda # and/or any other disk device<br />
</code><br />
<br />
====SATA Link Power Management====<br />
On kernels 2.6.24 and new this enables SATA Link Power Management:<br />
<code><br />
echo min_power > /sys/class/scsi_host/host0/link_power_management_policy<br />
echo min_power > /sys/class/scsi_host/host1/link_power_management_policy<br />
</code><br />
<br />
Disable it by replacing <code>min_power</code> with <code>max_performance</code>.<br />
<br />
On Ubuntu Hardy Heron with a 2.6.24-16 kernel, a suspend/resume cycle is much quicker if you disable SATA Link Power Management before initiating the suspend. As of Intrepid Ibex and kernel 2.6.27, this should be fixed. ([https://bugs.launchpad.net/linux/+bug/234047 Launchpad bug 234047], [http://bugzilla.kernel.org/show_bug.cgi?id=10817 Kernel bug 10817])<br />
<br />
====Laptop Mode Tools====<br />
<br />
The [http://samwel.tk/laptop_mode/ Laptop Mode Tools] utility implements many of the above power-saving measures from disks, and some others.<br />
<br />
===Optical drive===<br />
The optical drive is reported to consume power even when not accessed. See <br />
<br />
* [[How to hotswap UltraBay devices|Eject the UltraBay optical drive]], or just turn off its power supply (i.e., run the appropriate eject script but leave the drive inserted).<br />
* [[How to set optical drive speed|Reduce the spinning speed of the optical drive]].<br />
<br />
The hald daemon polling tends to maintain the ATA buses out of power saving<br />
modes, and to wakeup CDROM drive (except if you have a kernel >= 2.6.24, hal >= 0.5.10,<br />
and SATA AN compatible devices). If you have a recent hald version, you<br />
can stop this polling when on battery:<br />
<br />
<code><br />
hal-disable-polling --device /dev/scd0 # or whatever your CD drive is<br />
</code><br />
<br />
start polling again when on ac:<br />
<code><br />
hal-disable-polling --enable-polling --device /dev/scd0 # or whatever your CD drive is<br />
</code><br />
<br />
<br />
If your hald is not recent enough, consider suspending it when running on battery. Some moderns SATA buses and drivers supports a notification mechanism (SATA AN - Asynchronous Events Notifications) that obsolete the need for polling on modern hardware; support for this feature had been merged in Linux 2.6.24-rc1 and HAL 0.5.10.<br />
<br />
==LCD Backlight/Brightness==<br />
The LCD backlight is one of the very major power drain. <br />
Reducing brightness to the lowest readable<br />
level will save a lot of battery lifetime. Also, don't forget to configure<br />
your screen saver to shutdown the screen backlight (rather than displaying some<br />
eye candy), when no activity for a few minutes.<br />
<br />
You can also let the system [[automatically reduce brightness]] after a <br />
period of inactivity.<br />
<br />
If you're choosing your Thinkpad laptop model, keep in mind that the screen<br />
size affect the battery time greatly: more power needed for larger screens.<br />
<br />
The very recent, but xorg standard way to control backlight from CLI is<br />
using xbacklight. ie. to set backlight at half the brightness:<br />
<br />
<code><br />
xbacklight -set 50<br />
</code><br />
<br />
You should configure the DPMS to shutdown the screen when idle (rather than<br />
displaying a fancy but power consuming screensaver). ie. to turn off the<br />
display after 5 minutes of idling:<br />
<br />
<code><br />
xset +dpms<br />
xset dpms 0 0 300<br />
</code><br />
<br />
==Graphic controllers==<br />
All xorg Thinkpad graphics chipsets drivers (ati, radeon, fglrx, i810) have<br />
the same bug causing very frequent CPU wakeups when DRI is activated, even<br />
when you don't use any 3D application.<br />
This problem is partly fixed on xorg git tree but not released as of xorg<br />
7.2. If you value more battery than 3D, you should disable DRI: put this on<br />
the /etc/X11/xorg.conf "Device" of you graphic controller:<br />
<br />
<code><br />
Option "NoDRI"<br />
</code><br />
<br />
Also be sure that DPMS is working: <code>grep DPMS /var/log/Xorg.0.log</code><br />
should output "DPMS enabled". If not, put <code>Option "DPMS"</code> in your config.<br />
See the section above about how to enable dpms driven display power saving.<br />
<br />
On recent xrandr/xorg versions, you can disable the TV output (or any other detected<br />
as connected but not used outputs) when you're not using it: it's known to consume power. <br />
<br />
<code> <br />
xrandr # see all displays listed here, but that you don't actually use and disable them. <br />
xrandr --output TV --off # for instance (if "xrandr" above listed a connected output named "TV" that you don't use)<br />
</code><br />
<br />
When you don't have an external monitor plugged, disable CRT and DVI output <br />
(for some, this can make a difference in power usage) : <br />
<code> <br />
echo crt_disable > /proc/acpi/ibm/video<br />
echo dvi_disable > /proc/acpi/ibm/video<br />
</code> <br />
<br />
Some drivers have specials power saving mode, and/or allows underclocking the GPU. See also:<br />
* [[How to make use of Graphics Chips Power Management features]], or with [[Rovclock]] on ATI.<br />
* [[Problem with high power drain in ACPI sleep]]<br />
<br />
==USB Subsystem==<br />
The kernel support an efficient USB 2.0 power saving feature if you enabled<br />
CONFIG_USB_SUSPEND. This may not trigger in when you have an USB device<br />
plugged (and beside, USB devices tends to suck power on their own), so avoid<br />
using such devices when on battery. To enable it by default, you must add the line <br />
<code><br />
options usbcore autosuspend=1<br />
</code><br />
to your <tt>/etc/modprobe.conf</tt> or add it to (and create if necessary) the file <tt>/etc/modprobe.d/usbcore</tt> depending on how your distribution organises modprobe configuration. <br />
<br />
If on the other hand, you have <tt>usbcore</tt> built into your kernel, you can add this in the kernel boot options (ie. in grub's menu.lst):<br />
<br />
<code><br />
usbcore.autosuspend=1<br />
</code><br />
<br />
or at runtime, per device, with:<br />
<br />
<code><br />
for i in /sys/bus/usb/devices/*/power/autosuspend; do echo 1 > $i; done <br />
for i in /sys/bus/usb/devices/*/power/level; do echo auto > $i; done<br />
</code><br />
<br />
USB 1.1 is worst. It needs polling the bus frequently, hence can't really go<br />
in a low power mode when you enabled it, even if you don't have any device<br />
plugged. You'd better remove it when you don't use a 1.1 device:<br />
<br />
<code><br />
rmmod uhci_hcd<br />
</code><br />
<br />
If you don't intend to use any device needing USB 1.1 (unfortunately, the built-in bluetooth and fingerprint-reader are USB 1.1 devices), the USB 1.1 support can also be totally avoided. On Debian and derivatives, just do:<br />
<br />
<code><br />
echo "blacklist uhci_hcd" >> /etc/modprobe.d/blacklist<br />
</code><br />
<br />
==PCMCIA/CardBus==<br />
Same for PCMCIA/CardBus. Some users experiences interrupts clouds (sometime up to <br />
several thousands interrupts/second) causing CPU wakeups, thus totally preventing <br />
the CPU to reach lower C-states. <br />
If you don't use PCMCIA, you may disable it the same way (unloading seems insufficient<br />
to restore the system properly, you have to boot without it):<br />
<br />
<code><br />
echo "blacklist pcmcia" >> /etc/modprobe.d/blacklist<br />
echo "blacklist yenta_socket" >> /etc/modprobe.d/blacklist<br />
</code><br />
<br />
==Sound==<br />
<br />
ALSA has a power saving feature that should be enabled on your kernel<br />
(CONFIG_SND_AC97_POWER_SAVE). Note that this low power mode won't trigger in<br />
unless you muted all sound inputs (micro, line in etc.). This feature has<br />
to be activated with:<br />
<br />
<code><br />
amixer set Line mute nocap<br />
amixer set Mic mute nocap<br />
echo Y > /sys/module/snd_ac97_codec/parameters/power_save<br />
</code><br />
<br />
<br />
===Intel HD Audio===<br />
<br />
If you have Intel HD audio as your onboard sound controller, substitute the following for the last line in the above sequence:<br />
<br />
<code><br />
echo Y > /sys/module/snd_hda_intel/parameters/power_save_controller<br />
</code><br />
<br />
You also may wish to decrease the sound poweroff timeout to something shorter, like 1 second after last playback:<br />
<br />
<code><br />
echo 1 > /sys/module/snd_hda_intel/parameters/power_save<br />
</code><br />
<br />
===Additional Tweaks===<br />
<br />
You can unload all sound related modules when you are on <br />
battery, or mute the sound system (echo mute > /proc/acpi/ibm/volume).<br />
<br />
See also [[How to enable audio codec power saving]].<br />
<br />
==Wireless Interface==<br />
===intel wireless===<br />
Wireless network consume a lot of power.<br />
To save power, you can kill the Wi-Fi radio when it's not in use:<br />
<br />
<code><br />
echo 1 > /sys/bus/pci/devices/*/rf_kill<br />
</code><br />
<br />
If you need Wi-Fi, you can also reduce power consumption (at the price of<br />
performances) by activating the power saving modes:<br />
<br />
<code><br />
iwpriv eth1 set_power 5<br />
</code><br />
<br />
For drivers using the new Wi-Fi kernel framework (mac80211/cfg80211), <br />
the canonical way to do this is now:<br />
<br />
<code><br />
for i in /sys/bus/pci/devices/*/power_level ; do echo 5 > $i ; done<br />
</code><br />
<br />
Most drivers, like ipw2200, that don't use the new mac80211 framework place the<br />
interfaces in aggressive scanning mode when they are not associated with any <br />
Access Point, even when the interface is down (more info about this on Intel's<br />
[http://www.lesswatts.org/tips/wireless.php LessWatts] website).<br />
This behavior consumes a lot of power, even more than when the interface<br />
is plain active and in use. But this can disabled at module's load time :<br />
<br />
<code><br />
rmmod ipw2200<br />
modprobe ipw2200 associate=0<br />
</code><br />
<br />
You can fix this setting by placing the following in /etc/modprobe.d/options <br />
(Debian/Ubuntu) or in /etc/modprobe.conf (Red Hat/Fedora):<br />
<br />
<code><br />
options ipw2200 associate=0<br />
</code><br />
<br />
Reducing beacon intervals on your Access Point to 1 per second will also<br />
reduce network card interrupts, therefore power savings. This shouldn't have<br />
negatives side effects.<br />
<br />
In recent kernels, the powersaving on the intel ipw3945 has been disabled, as<br />
for some it is unstable. For others it worked just fine.<br />
<br />
See [http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.33.y.git;a=blobdiff;f=drivers/net/wireless/iwlwifi/iwl-3945.c;h=e413bd35bc411a1113177f1576538eb0ac26f00c;hp=4609323d8436dc9e22c74be2f1f3cf5e97785cb2;hb=bc45a67079c916a9bd0a95b0b879cc0f259bac6e;hpb=b7bb1756cb6a610cdbac8cfdad9e79bb5670b63b this patch]. You may wish to try changing '.broken_powersave=true' to false, in /usr/src/linux/drivers/net/wireless/iwlwifi/iwl-3945.c if you wish to enable powersave.<br />
<br />
See also, to activate power saving on the wireless network card:<br />
* For [[Intel PRO/Wireless 2200BG Mini-PCI Adapter]] and [[Intel PRO/Wireless 2915ABG Mini-PCI Adapter]], see instructions for the [[ipw2200]] driver.<br />
* For [[Intel PRO/Wireless 3945ABG Mini-PCI Express Adapter]], see the [http://ipw3945.sourceforge.net/README.ipw3945 ipw3945 driver README]<br />
<br />
==Ethernet Controler==<br />
If you don't use Wake-on-LAN, you should disable it for your network card,<br />
because it sucks a lot of power:<br />
<br />
<code><br />
ethtool -s eth0 wol d<br />
</code><br />
<br />
If you can, try to reduce useless network activity on your ethernet<br />
segment, coming to your NIC (ie. uneeded broadcasts), those cause <br />
interrupts and CPU wakeups.<br />
<br />
Forcing 100Mbps full-duplex speed on a gigabit ethernet NIC can also save a lot of power (~1W) on most network workloads. This also reduces components temperature (e.g., [[Thermal Sensors|thermal sensor]] 0xC0 on the {{T43}} cools down by 5 degree between 1000Mbps and 100Mbps, and another 1 degree for 10Mbps).<br />
<br />
<code><br />
ethtool -s eth0 autoneg off speed 100<br />
</code><br />
<br />
Note, however, that if the network device on the other side has auto-negotiation enabled (which is very common) and you turn auto-negotiation off, the other side will assume half-duplex mode and you will experience a significant loss of performance.<br />
<br />
==Bluetooth==<br />
When you don't need bluetooth, disable it. Because of its radio, <br />
bluetooth is not power friendly.<br />
<br />
<code><br />
hciconfig hci0 down ; rmmod hci_usb<br />
echo disable > /proc/acpi/ibm/bluetooth<br />
</code><br />
<br />
==Modem==<br />
When was the last time you used your analog modem? If you can't remember, you probably just don't need it. If it is on a separate module in your laptop, simply remove it. Store it in a ESD safe place (like the bag in which your last addon card or hard drive was packed), in case you should need it again. This won't save you a lot of power and weight, but why carry something around you never use.<br />
<br />
==System Fans==<br />
Fans consumes power when running, so you may look at the [[ACPI fan control script]].<br />
<br />
==Misbehaving Userland==<br />
You should avoid using Beagle, Compiz, Beryl, XMMS, gnome-power-manager<br />
and Evolution while on battery.<br />
Look at the PowerTOP's [http://www.linuxpowertop.org/known.php known problems]<br />
list.<br />
<br />
Deactivate desktop animations (blinking cursor on the terms, animated wallpapers, ...): they cause regular X (therefore kernel and CPU) wakeups.<br />
<br />
In short, while on battery, you should stop all applications that don't really stay idle when you're not using them. This means applications that:<br />
* Wakes up the CPU too often (by polling something, because of too short select() timeouts, ...)<br />
* Access the disks at regular intervals<br />
* Access an hardware bus (USB, ATA, ...) at regular intervals<br />
To find those offenders run:<br />
* <code>strace -p $(pidof yourapp)</code> # for all your running applications<br />
* <code>powertop</code><br />
* <code>dstat -t -c --power --top-cpu --top-io --top-bio --top-latency --top-cputime</code><br />
* <code>sysctl vm.block_dump=1</code> # and look at dmesg<br />
* <code>ps aux | awk '{print$10,$11}' | sort -n</code> # will list all running softs sorted by used cpu time<br />
Please, don't forget to fill a bug when you find such a misbehaving software.<br />
{{NOTE|Not all software is evil, buggy or badly written. Some produce regular activity because they have to, in order to provide their intented functionality. Think twice before filling bugs about this.}}<br />
<br />
==See Also==<br />
* [[How to measure power consumption]]<br />
* [[Script for monitoring power consumption]]<br />
* Battery [[maintenance]]<br />
<br />
==External resources==<br />
* [http://www.free-it.de/archiv/talks_2005/paper-11017/paper-11017.html ''Current trends in Linux Kernel Power Management''], Dominik Brodowski, 2005<br />
* [http://www.linuxpowertop.org PowerTOP] website<br />
* [http://www.gentoo.org/doc/en/power-management-guide.xml Power Management Guide] from the Gentoo Linux documentation<br />
* [http://mailman.linux-thinkpad.org/pipermail/linux-thinkpad/2005-November/030478.html When/where/what for low power consumption?] (thread on Linux-Thinkpad)<br />
* Intel's [http://www.lesswatts.org/ LessWatts] "''Saving power on Linux''" website<br />
* ''8 hours of battery life on your lap(top)'' ([http://atrey.karlin.mff.cuni.cz/~pavel/swsusp/8hours.odp ODP]/[http://atrey.karlin.mff.cuni.cz/~pavel/swsusp/8hours.pdf PDF]), a presentation by Pavel Machek<br />
<br />
<br />
[[Category:600X]] [[Category:A20m]] [[Category:A20p]] [[Category:A21e]] [[Category:A21m]] [[Category:A21p]] [[Category:A22e]] [[Category:A22m]] [[Category:A22p]] [[Category:A30]] [[Category:A30p]] [[Category:A31]] [[Category:A31p]] [[Category:i1200]] [[Category:i1300]] [[Category:i1620]] [[Category:G40]] [[Category:G41]] [[Category:R30]] [[Category:R31]] [[Category:R32]] [[Category:R40]] [[Category:R40e]] [[Category:R50]] [[Category:R50e]] [[Category:R50p]] [[Category:R51]] [[Category:R52]] [[Category:R60]] [[Category:R60e]] [[Category:T20]] [[Category:T21]] [[Category:T22]] [[Category:T23]] [[Category:T30]] [[Category:T40]] [[Category:T40p]] [[Category:T41]] [[Category:T41p]] [[Category:T42]] [[Category:T42p]] [[Category:T43]] [[Category:T43p]] [[Category:T60]] [[Category:T60p]] [[Category:T61]] [[Category:X20]] [[Category:X21]] [[Category:X22]] [[Category:X23]] [[Category:X24]] [[Category:X30]] [[Category:X31]] [[Category:X32]] [[Category:X40]] [[Category:X41]] [[Category:X41 Tablet]] [[Category:X60]] [[Category:X60s]] [[Category:X61]] [[Category:X61s]] [[Category:Z60m]] [[Category:Z60t]] [[Category:Z61t]] [[Category:Z61e]] [[Category:TransNote]]</div>Denisqhttps://www.thinkwiki.org/w/index.php?title=How_to_get_special_keys_to_work&diff=48701How to get special keys to work2010-06-04T14:28:29Z<p>Denisq: </p>
<hr />
<div>==Overview==<br />
The following table gives an overview over the special keys found on ThinkPads and what is needed to make them work.<br />
{| {{prettytable}}<br />
! key !! standard function{{footnote|1}} !! tools supporting key{{footnote|2}} !! configurability{{footnote|3}} !! remarks<br />
|-<br />
| {{key|Fn}} || - || [[#xmodmap configuration|xmodmap]], [[#tpb configuration|tpb]] || full || on release without completed key combination<br />
|-<br />
| {{key|Fn}}{{key|F1}} || - || [[thinkpad-acpi]] || full ||<br />
|-<br />
| {{key|Fn}}{{key|F2}} || lock screen || [[thinkpad-acpi]] || full || in models from T/X/Z 60 onwards<br />
|-<br />
| {{key|Fn}}{{key|F3}} || blank screen || [[thinkpad-acpi]] || full ||<br />
|-<br />
| {{key|Fn}}{{key|F4}} || suspend to ram || [[thinkpad-acpi]] || full || may generate ACPI event when not enabled in the thinkpad-acpi hotkey mask<br />
|-<br />
| {{key|Fn}}{{key|F5}} || switch bluetooth || [[thinkpad-acpi]] || full || in models starting from 2002<br />
|-<br />
| {{key|Fn}}{{key|F6}} || - || [[thinkpad-acpi]] || full ||<br />
|-<br />
| {{key|Fn}}{{key|F7}} || toggle display || [[thinkpad-acpi]], [[#tpb configuration|tpb]] || additional actions || [[Sample Fn-F7 script]]<br />
|-<br />
| {{key|Fn}}{{key|F8}} || toggle trackpoint/touchpad || [[thinkpad-acpi]], [[#tpb configuration|tpb]] || additional actions ||<br />
|-<br />
| {{key|Fn}}{{key|F9}} || eject from dock || [[thinkpad-acpi]] || full ||<br />
|-<br />
| {{key|Fn}}{{key|F10}} || - || [[thinkpad-acpi]] || full ||<br />
|-<br />
| {{key|Fn}}{{key|F11}} || - || [[thinkpad-acpi]] || full ||<br />
|-<br />
| {{key|Fn}}{{key|F12}} || hibernate || [[thinkpad-acpi]] || full || may generate ACPI event when not enabled in the thinkpad-acpi hotkey mask<br />
|-<br />
| {{key|Fn}}{{key|Home}} / {{key|Fn}}{{key|Pos1}} || brightness up || [[thinkpad-acpi]], [[#tpb configuration|tpb]], [[KMilo]] || additional actions ||<br />
|-<br />
| {{key|Fn}}{{key|End}} || brightness down || [[thinkpad-acpi]], [[#tpb configuration|tpb]], [[KMilo]] || additional actions ||<br />
|-<br />
| {{key|Fn}}{{key|PageUp}} || toggle thinklight || [[thinkpad-acpi]], [[#tpb configuration|tpb]], [[KMilo]] || additional actions ||<br />
|-<br />
| {{key|Fn}}{{key|Space}} || toggle zoom || [[thinkpad-acpi]], [[#tpb configuration|tpb]], [[KMilo]] || full ||<br />
|-<br />
| {{key|Fn}}{{key|Ins}} || - || [[thinkpad-acpi]]|| full ||<br />
|-<br />
| {{key|Fn}}{{key|Del}} || - || [[thinkpad-acpi]] || full ||<br />
|-<br />
| {{key|Fn}}{{key|Backspace}} || - || [[thinkpad-acpi]] || full ||<br />
|-<br />
| {{key|NumLock}} || - || [[#xmodmap configuration|xmodmap]] || make working ||<br />
|-<br />
| {{key|Windows}} || - || [[#xmodmap configuration|xmodmap]] || remapping ||<br />
|-<br />
| {{ibmkey|Access IBM|#495988}} or {{ibmkey|ThinkPad|#494949}} or {{ibmkey|ThinkVantage|#495988}} || help application || [[thinkpad-acpi]],[[#tpb configuration|tpb]], [[KMilo]] || full ||<br />
|-<br />
| {{ibmkey|Home|#494949}} || open web browser || [[#xmodmap configuration|xmodmap]], [[#tpb configuration|tpb]], [[KMilo]] || full || only {{A30}}, {{A30p}}, {{A31}}, {{A31p}} and ext. keyboards<br />
|-<br />
| {{ibmkey|Search|#494949}} || open search application || [[#xmodmap configuration|xmodmap]], [[#tpb configuration|tpb]], [[KMilo]] || full || only {{A30}}, {{A30p}}, {{A31}}, {{A31p}} and ext. keyboards<br />
|-<br />
| {{ibmkey|Mail|#494949}} || open mail application || [[#xmodmap configuration|xmodmap]], [[#tpb configuration|tpb]], [[KMilo]] || full || only {{A30}}, {{A30p}}, {{A31}}, {{A31p}} and ext. keyboards<br />
|-<br />
| {{ibmkey|Favorites|#494949}} || open favorites || [[#xmodmap configuration|xmodmap]], [[#tpb configuration|tpb]] || full || only {{A30}}, {{A30p}}, {{A31}}, {{A31p}} and ext. keyboards<br />
|-<br />
| {{ibmkey|Reload|#494949}} || reload web page || [[#xmodmap configuration|xmodmap]], [[#tpb configuration|tpb]] || full || only {{A30}}, {{A30p}}, {{A31}}, {{A31p}} and ext. keyboards<br />
|-<br />
| {{ibmkey|Abort|#494949}} || abort loading page || [[#xmodmap configuration|xmodmap]], [[#tpb configuration|tpb]] || full || only {{A30}}, {{A30p}}, {{A31}}, {{A31p}} and ext. keyboards<br />
|-<br />
| {{ibmkey|Backward|#494949}} || previous page || [[#xmodmap configuration|xmodmap]], [[#tpb configuration|tpb]] || full || ext. keyboards and ThinkPads starting from 2002<br />
|-<br />
| {{ibmkey|Forward|#494949}} || next page || [[#xmodmap configuration|xmodmap]], [[#tpb configuration|tpb]] || full || ext. keyboards and ThinkPads starting from 2002<br />
|-<br />
| {{ibmkey|Volume up|#494949}} || volume up || [[thinkpad-acpi]], [[#tpb configuration|tpb]], [[KMilo]] || additional actions ||<br />
|-<br />
| {{ibmkey|Volume down|#494949}} || volume down || [[thinkpad-acpi]], [[#tpb configuration|tpb]], [[KMilo]] || additional actions ||<br />
|-<br />
| {{ibmkey|Volume mute|#494949}} || mute volume || [[thinkpad-acpi]], [[#tpb configuration|tpb]], [[KMilo]] || additional actions ||<br />
|-<br />
| {{ibmkey|Play/Pause|#494949}} || start/pause playback || [[#xmodmap configuration|xmodmap]] || full || {{X60s}} (Fn+Arrow Down)<br />
|-<br />
| {{ibmkey|Stop|#494949}} || stop playback || [[#xmodmap configuration|xmodmap]] || full || {{X60s}} (Fn+Arrow Up)<br />
|-<br />
| {{ibmkey|Next|#494949}} || play next || [[#xmodmap configuration|xmodmap]] || full || {{X60s}} (Fn+Arrow Right)<br />
|-<br />
| {{ibmkey|Previous|#494949}} || play previous || [[#xmodmap configuration|xmodmap]] || full || {{X60s}} (Fn+Arrow Left)<br />
|-<br />
| {{ibmkey|Power|#494949}} || shutdown || [[thinkpad-acpi]] || full || triggered on pressing 3secs, but notebook goes off on 5sec press<br />
|-<br />
| Display lid || blank screen || acpi video || full ||<br />
|-<br />
| Ultrabay eject || announce ultrabay change || acpi bay || full ||<br />
|-<br />
| Dock eject || eject from dock || acpi dock || full ||<br />
|-<br />
| {{ibmkey|Tablet power|#494949}} || shutdown || [[thinkpad-acpi]] || full || triggered on pressing 3secs, but notebook goes off on 5sec press<br />
|-<br />
| {{ibmkey|Tablet orientation|#494949}} || rotates screen || [[#Mapping keys with setkeycodes|setkeycodes]] || full ||<br />
|-<br />
| {{ibmkey|Tablet shortcut|#494949}} || shortcut menu || [[#Mapping keys with setkeycodes|setkeycodes]] || full ||<br />
|-<br />
| {{ibmkey|Tablet Esc|#494949}} || esc key || [[#Mapping keys with setkeycodes|setkeycodes]] || full ||<br />
|-<br />
| {{ibmkey|Tablet Enter|#494949}} || enter key || [[#mapping keys with setkeycodes|setkeycodes]] || full ||<br />
|-<br />
| {{ibmkey|Tablet Up|#494949}} || up key || [[#Mapping keys with setkeycodes|setkeycodes]] || full ||<br />
|-<br />
| {{ibmkey|Tablet Down|#494949}} || down key || [[#Mapping keys with setkeycodes|setkeycodes]] || full ||<br />
|-<br />
| {{ibmkey|Tablet (unlabeled)|#494949}} || down key || [[#Mapping keys with setkeycodes|setkeycodes]] || full ||<br />
|}<br />
<br />
For completeness, note that the WiFi enable/disable switch is located (on the X61 and other models that have it) just under the front edge of the base of the machine. You should see a small horizontal slider switch. Enable by sliding it rightwards, disable by sliding it leftwards.<br />
<br />
Tablet buttons vary with model. See [[Tablet Hardware Buttons]].<br />
<br />
==Triggering key events==<br />
<br />
===thinkpad_acpi events===<br />
The thinkpad_acpi driver should automatically select an appropriate mask for your machine.<br />
But on a rare occasions you might need to change the hotkey mask for key events to happen. In that case,<br />
read the recommended hotkey_mask from hotkey_recommended_mask, set the extra bits you need, and write<br />
the result to hotkey_mask. These files (actually, "sysfs attributes") can be found on {{path|sys/devices/platform/thinkpad_acpi}}<br />
<br />
These events can be used to configure HAL or [[How to configure acpid|acpid]].<br />
<br />
{| {{prettytable}}<br />
|+ events triggered by [[thinkpad-acpi]]. May vary on different models.<br />
! key !! acpi event || IBM ThinkPad hal event || Lenovo ThinkPad hal event<br />
|-<br />
| {{key|Fn}}{{key|F1}} || ibm/hotkey HKEY 00000080 00001001 || ||<br />
|-<br />
| {{key|Fn}}{{key|F2}} || ibm/hotkey HKEY 00000080 00001002 || 0x01:battery || 0x01:screenlock<br />
|-<br />
| {{key|Fn}}{{key|F3}} || ibm/hotkey HKEY 00000080 00001003 || 0x02:screenlock || 0x02:battery<br />
|-<br />
| {{key|Fn}}{{key|F4}} || ibm/hotkey HKEY 00000080 00001004 || 0x03:sleep || 0x03:sleep<br />
|-<br />
| {{key|Fn}}{{key|F5}} || ibm/hotkey HKEY 00000080 00001005 || 0x04:radio || 0x04:radio<br />
|- <br />
| {{key|Fn}}{{key|F6}} || ibm/hotkey HKEY 00000080 00001006 || ||<br />
|-<br />
| {{key|Fn}}{{key|F7}} || ibm/hotkey HKEY 00000080 00001007 || 0x06:switchvideomode || 0x06:switchvideomode<br />
|-<br />
| {{key|Fn}}{{key|F8}} || ibm/hotkey HKEY 00000080 00001008 || 0x07:zoom || 0x07:f22<br />
|- <br />
| {{key|Fn}}{{key|F9}} || ibm/hotkey HKEY 00000080 00001009 || 0x08:f24 || 0x08:f24<br />
|-<br />
| {{key|Fn}}{{key|F10}} || ibm/hotkey HKEY 00000080 0000100a || ||<br />
|-<br />
| {{key|Fn}}{{key|F11}} || ibm/hotkey HKEY 00000080 0000100b || ||<br />
|-<br />
| {{key|Fn}}{{key|F12}} || ibm/hotkey HKEY 00000080 0000100c || 0x0b:suspend || 0x0b:suspend<br />
|-<br />
| {{key|Fn}}{{key|Backspace}} || ibm/hotkey HKEY 00000080 0000100d || ||<br />
|-<br />
| {{key|Fn}}{{key|Ins}} || ibm/hotkey HKEY 00000080 0000100e || ||<br />
|-<br />
| {{key|Fn}}{{key|Del}} || ibm/hotkey HKEY 00000080 0000100f || ||<br />
|-<br />
| {{key|Fn}}{{key|Home}}/{{key|Fn}}{{key|Pos1}} || ibm/hotkey HKEY 00000080 00001010 || 0x0f:brightnessup || 0x0f:brightnessup<br />
|-<br />
| {{key|Fn}}{{key|End}} || ibm/hotkey HKEY 00000080 00001011 || 0x10:brightnessdown || 0x10:brightnessdown<br />
|-<br />
| {{key|Fn}}{{key|PgUp}} || ibm/hotkey HKEY 00000080 00001012 || 0x11:kbdillumtoggle || 0x11:kbdillumtoggle<br />
|-<br />
| {{key|Fn}}{{key|Space}} || ibm/hotkey HKEY 00000080 00001014 || 0x13:zoom || 0x13:zoom<br />
|-<br />
| {{ibmkey|Volume up|#494949}}|| ibm/hotkey HKEY 00000080 00001015 || 0x14:volumeup || 0x14:volumeup<br />
|-<br />
| {{ibmkey|Volume down|#494949}} || ibm/hotkey HKEY 00000080 00001016 || 0x15:volumedown || 0x15:volumedown<br />
|-<br />
| {{ibmkey|Volume mute|#494949}} || ibm/hotkey HKEY 00000080 00001017 || 0x16:mute || 0x16:mute<br />
|-<br />
| {{ibmkey|Access IBM|#495988}} or {{ibmkey|ThinkPad|#494949}} or {{ibmkey|ThinkVantage|#495988}} || ibm/hotkey HKEY 00000080 00001018 || 0x17:prog1 || 0x17:prog1<br />
|-<br />
| Ultrabay eject || ibm/bay MSTR 00000003 00000000 || ||<br />
|-<br />
| Ultrabay inserted || ibm/bay MSTR 00000001 00000000 || ||<br />
|-<br />
| Dock eject || ibm/dock GDCK 00000003 00000001 || ||<br />
|-<br />
| Wireless switch || ibm/hotkey HKEY 00000080 00007000 || ||<br />
|}<br />
<br />
By disassembling and editing the DSDT, more events can be added. HKEY events are triggered by calls to the MKHQ function, e.g. <tt>\_SB.PCI0.LPC.EC.HKEY.MHKQ(0×1007)</tt> will trigger "ibm/hotkey HKEY 00000080 00001007". Most of these can be found in <tt>_Qxx</tt> methods within the DSDT, which are executed on embedded controller events, e.g. _Q10 is triggered by pressing Fn-F7. You can add a call to MKHQ into an existing <tt>_Qxx</tt> method to get it recognized by thinkpad-acpi as well as creating new <tt>_Qxx</tt> methods, which if you're lucky will correspond to an EC event that IBM never used (e.g. A 770 will send Fn-Home/End/PgUp/PgDn to thinkpad-acpi if hacked in this fashion). For example, [http://www.wormnet.eu/ibm-g40/morebuttons.dsl this is a modified block of DSDT for a G40].<br />
<br />
=== ACPI events from the <tt>button</tt> module===<br />
<br />
A few keys can generate ACPI events that result from the <tt>button</tt> kernel module, as long as they are masked off in the <tt>thinkpad-acpi</tt> hotkey's mask or the hotkey function of the latter module is disabled.<br />
<br />
If you want the ThinkPad's BIOS and ACPI methods to know about these keys being pressed, you probably want to leave them masked out from thinkpad-acpi, and use their non-HKEY events listed below, instead.<br />
<br />
{| {{prettytable}}<br />
|+ events triggered by ACPI when hotkey is masked out or disabled. <br />
! key !! event !! T60 event<br />
|-<br />
| {{ibmkey|Power|#494949}} || button/power PWRF 00000080 xxxxxxxx || button/power PWRF 00000080 00000001<br />
|-<br />
| {{key|Fn}}{{key|F4}} || button/sleep SLPB 00000080 00000001 || button/sleep SLPB 00000080 00000001<br />
|-<br />
| Display lid || button/lid LID 00000080 xxxxxxxx || button/lid LID 00000080 00000001<br />
|}<br />
<br />
===Configuration using HAL===<br />
<br />
Modern distributions like Ubuntu 8.10 and Fedora 10 use HAL to configure the kernel input devices. Xorg in turn gets these key events through the evdev driver and will no longer try to take control of the input devices away from the kernel.<br />
<br />
But before you get started on this you should make sure you have all the updates applied from your distro vendor as both Ubuntu 8.10 and Fedora 10 require some additional fixes that you might need.<br />
====Xorg problems====<br />
You may find that by default some buttons will work in Xorg and others will not (e.g. Fn-Space). The reason for this is that Xorg is limited to 255 different key codes, and some keys are mapped to key codes that are out of range for Xorg. The Xorg developers are aware of this issue and plan to fix it in XKB2. Unfortunately support for XKB2 has slipped and is now planned for Xorg 1.8, sometime in 2010.<br />
<br />
{{HINT|You can get Fn-Space working via ACPI events. Here is a practical [http://www.thinkwiki.org/wiki/Installing_Ubuntu_10.04_(Lucid_Lynx)_on_a_ThinkPad_Z61m#Make_Fn-Space_.28Screen_Magnify.29_work HOWTO] for Ubuntu 10.04 Lucid}} <br />
<br />
Default HAL config files are located in {{path|/usr/share/hal/fdi}}. If you create any custom files you should instead place them in {{path|/etc/hal/fdi}} to prevent them from getting overwritten by the next hal-info package update of your distribution.<br />
<br />
You can see for instance the mapping between {{path|/usr/share/hal/fdi/information/10freedesktop/30-keymap-module-thinkpad-acpi.fdi}} and that of the kernel [http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob_plain;f=include/linux/input.h;hb=HEAD input.h] header file.<br />
<br />
keyboard events defined in input.h in the 0x100 range and above will be ignored by current Xorg. If you want to work around this you can change the hal config file such that for instance the Fn-F5 key no longer maps to '''radio''' (0x181) but to '''wlan''' (238) or '''bluetooth''' (237).<br />
<br />
Have a look at the HAL documentation for samples on how to configure your own events [http://hal.freedesktop.org/quirk/quirk-keymap-index.html].<br />
<br />
To check if a key is being handled by Xorg, start xev and press the key. If you do not see any output from the keypress it is not handled. If it is handled you can configure the key in Gnome with gnome-keybinding-properties (kde??).<br />
<br />
====bypassing Xorg====<br />
Since the keys are handled by the kernel and passed through hal, we can bypass Xorg and have a key run a specific task.<br />
This is useful if Xorg cannot handle the key (out of range, or X doesn't<br />
matter this input key), or if your not running X. This can be done with the<br />
'''halevt''' program (located at [http://www.nongnu.org/halevt|http://www.nongnu.org/halevt] ; for Debian systems, use a version >= 0.1.5-1). This program can react to some events detected by HAL such a special key press. For example, to run a custom script when Fn-F5 (Radio toggle) is pressed, you could put a stanza in halevt's configuration file ('''/etc/halevt/halevt.xml''', in XML format) :<br />
<br />
<nowiki><br />
<halevt:Device match="hal.info.category = input"><br />
<!-- Warning: /etc/sudoers must be configured to let 'halevt' user<br />
runs the given command ! --><br />
<halevt:Condition name="ButtonPressed" detail="wlan" exec="sudo /usr/local/sbin/toggle_wlan"/><br />
</halevt:Device><br />
</nowiki><br />
<br />
Here, '''sudo''' is used as the halevt daemon runs with its own user, which don't have required rights to do the work in the custom script ''/usr/local/sbin/toggle_wlan'', so in ''/etc/sudoers'', we have :<br />
<br />
halevt ALL = NOPASSWD: /usr/local/sbin/toggle_wlan<br />
<br />
Be careful when writing halevt configuration, as the daemon isn't very verbose about what it does or not : you don't get error messages when command run fails…<br />
<br />
===inputlirc configuration===<br />
<br />
An alternative to halevt is inputlirc [http://ajoute.org/wiki/doc/linux/inputlirc]. After installation of the packages inputlirc [http://packages.debian.org/search?keywords=inputlirc] and lirc, you can test it with the irw command. To run custom scripts you need a configuration for the irexec daemon ('''/etc/lirc/lircrc''') :<br />
<br />
<nowiki><br />
begin<br />
prog = irexec<br />
button = KEY_RADIO<br />
config = /etc/acpi/wireless.sh<br />
end<br />
<br />
begin<br />
prog = irexec<br />
button = KEY_SCREENLOCK<br />
config = /etc/acpi/thinkpad-lockorbattery.sh<br />
end<br />
</nowiki><br />
<br />
===tpb configuration===<br />
{| {{prettytable}}<br />
|+ configuration keywords for [[tpb]] (to put in {{path|/etc/tpbrc}})<br />
! key !! config keyword<br />
|-<br />
| {{ibmkey|Access IBM|#495988}} or {{ibmkey|ThinkPad|#494949}} || THINKPAD<br />
|-<br />
| {{ibmkey|Home|#494949}} || HOME<br />
|-<br />
| {{ibmkey|Search|#494949}} || SEARCH<br />
|-<br />
| {{ibmkey|Mail|#494949}} || MAIL<br />
|-<br />
| {{ibmkey|Favorites|#494949}} || FAVORITES<br />
|-<br />
| {{ibmkey|Reload|#494949}} || RELOAD<br />
|-<br />
| {{ibmkey|Abort|#494949}} || ABORT<br />
|-<br />
| {{ibmkey|Backward|#494949}} || BACKWARD<br />
|-<br />
| {{ibmkey|Forward|#494949}} || FORWARD<br />
|-<br />
| {{key|Fn}} || FN<br />
|-<br />
| {{key|Fn}}{{key|Space}} || CALLBACK (zoom on/off)<br />
|-<br />
| {{key|Fn}}{{key|PageUp}} || CALLBACK (thinklight on/off)<br />
|-<br />
| {{key|Fn}}{{key|F7}} || CALLBACK (display lcd/crt/both)<br />
|-<br />
| {{key|Fn}}{{key|F8}} || CALLBACK (expand on/off)<br />
|-<br />
| {{key|Fn}}{{key|Home}} / {{key|Fn}}{{key|Pos1}} || CALLBACK (brightness <percent>)<br />
|-<br />
| {{key|Fn}}{{key|End}} || CALLBACK (brightness <percent>)<br />
|-<br />
| {{ibmkey|Volume up|#494949}} || CALLBACK (volume <percent>)<br />
|-<br />
| {{ibmkey|Volume down|#494949}} || CALLBACK (volume <percent>)<br />
|-<br />
| {{ibmkey|Volume mute|#494949}} || CALLBACK (mute on/off)<br />
|}<br />
<br />
To all parameter keywords should be assigned the full path to the executables supposed to be started on key press.<br />
The exectable provided for the CALLBACK keyword should take the parameters given in parentheses and act according to them.<br />
If you want to use xmodmap for the HOME, SEARCH, MAIL, FAVORITES, RELOAD, ABORT, BACKWARD, FORWARD and FN keys you should<br />
provide a <tt>XEVENTS OFF</tt> in your {{path|/etc/tpbrc}}. <br />
You can use an appropriate executable to [[How to inject fake keystrokes|inject fake keystrokes]].<br />
<br />
For Debian users, tpb is started from {{path|/etc/X11/Xsession.d/90tpb}}.<br />
<br />
'''Sound Button configuration'''<br />
<br />
''Note: Tested on T60p with Ubuntu 6.06 LTS''<br />
<br />
Most Thinkpads have a hardware sound mixer, thus the volumes buttons should work without configuration. However, this change is not reflected in the software mixer. tpb has a switch to enable software mixer support via OSS. The manual recommends this only for devices without a hardware mixer, but it also works for other hadware mixer enabled devices, even with the ALSA system. Just put MIXER ON in your {{path|/etc/tpbrc}} file and you can see the effect immediately in any ALSA mixer (e.g. kmix). For this to work you need write permissions to {{path|/dev/nvram}}.<br />
<br />
''Note: Tested on X21 with Ubuntu 6.06 LTS''<br />
<br />
On the ThinkPad X21 (and maybe some other older models) ACPI causes problems with tpb. On an X21 using acpi the volume buttons would work occasionally, and the OSD for tpb functions would rarely work. If a volume buttons was pressed too often, sometimes the computer would enter a low power (unplugged state) and would require a reboot. The solution is to use APM instead of ACPI. Instructions can be found in [[How_to_make_APM_work]].<br />
<br />
===KMilo configuration===<br />
The programs to be executed by [[KMilo]] are configured via the KDE Control Center (<tt>kcontrol</tt>), under <tt>System Administration --> IBM Thinkpad Laptop</tt>. Note that you can use appropriate commands to [[How to inject fake keystrokes|inject fake keystrokes]].<br />
<br />
===xmodmap configuration===<br />
xmodmap enables you to edit the modifier map and keymap tables that are used to translate keycodes into keysyms.<br />
Understood? Well, basically it allows you to give the X server a dictionary for the translation of keycodes like "97" into more human readable synonyms like "Home". This way xmodmap allows you to make the special keys of your keyboard known to X applications.<br />
<br />
To discover the keycode that a certain keypress produces, use the tool {{cmduser|xev}} <br />
<br />
Usually you should write your keycode-keysym associations into the file {{path|~/.Xmodmap}}. This file is usually read by the X session startup scripts of your system, so that the mappings automatically get included everytime you run the X server.<br />
<br />
The {{path|~/.Xmodmap}} lines for our purpose are in the form of<br />
keycode <keycode> = <keysym><br />
<br />
Load the assocation using the command<br />
<br />
{{cmduser|xmodmap ~/.Xmodmap}} <br />
<br />
(some configurations do this automatically upon X startup). <br />
<br />
The following table shows the keycodes generated by the ThinkPad special keys and sensible keysyms to assign them to.<br />
{| {{prettytable}}<br />
|+ keycodes and recommended keysyms<br />
! key !! keycode !! keysym<br />
|-<br />
| {{ibmkey|Access IBM|#495988}} or {{ibmkey|ThinkPad|#494949}} || 159 || XF86LaunchA<br />
|-<br />
| {{ibmkey|Backward|#494949}} || 234 || XF86Back or F19<br />
|-<br />
| {{ibmkey|Forward|#494949}} || 233 || XF86Forward or F20<br />
|-<br />
| {{ibmkey|Play/Pause|#494949}} || 162 || XF86AudioPlay<br />
|-<br />
| {{ibmkey|Stop|#494949}} || 164 || XF86AudioStop<br />
|-<br />
| {{ibmkey|Next|#494949}} || 153 || XF86AudioNext<br />
|-<br />
| {{ibmkey|Previous|#494949}} || 144 || XF86AudioPrev<br />
|-<br />
<br />
<br />
| {{ibmkey|Home|#494949}} || 178 || XF86HomePage<br />
|-<br />
| {{ibmkey|Search|#494949}} || 229 || XF86Search<br />
|-<br />
| {{ibmkey|Mail|#494949}} || 236 || XF86Mail<br />
|-<br />
| {{ibmkey|Favorites|#494949}} || 230 || XF86AddFavorite or XF86Favorites<br />
|-<br />
| {{ibmkey|Reload|#494949}} || 231 || XF86Reload<br />
|-<br />
| {{ibmkey|Abort|#494949}} || 232 || XF86Stop<br />
|-<br />
| {{key|Fn}} || 227 || F35<br />
|}<br />
<br />
Note: You can also use xkeycaps (an X tool to display and edit the X keyboard mapping) to generate proper .Xmodmap.<br />
<br />
Note: if you are running [[tpb]] you might need to add the line <tt>XEVENTS=off</tt> into your tpbrc to stop it from grabbing the key events and allow them to get through to X instead. See [[http://www.thinkwiki.org/wiki/Tpb]] for more detailed instruction on how to use tpb and xmodmap.<br />
<br />
Note: XF86Forward and XF86Back do not work correctly in Firefox. You may want to map them to F19 and F20 instead if you use Firefox.<br />
<br />
Note: The "XF86AudioPlay" etc. just works with a few programs. To make it work with more multimedia programs you have map the key to use something like [http://www.kde-apps.org/content/show.php/ReMoot?content=63140 ReMoot]. ReMoot is a command line wrapper that control 18 of the most common multimedia applications. <br />
<br />
=====Enabling the Windows and Menu Keys=====<br />
On some systems the Windows and Menu keys may not be recognized. You can enable then by<br />
making the following changes:<br />
<br />
keycode 115 = F13<br />
keycode 227 = F35<br />
<br />
F13 and F35 are used for the Windows and and Menu keys respectively. Labelling keycpode 227 as "Menu" may conflict with the right-mouse-click event.<br />
<br />
=====Using Caps Lock as Super L (Windows key)=====<br />
You can easily use Caps Lock as Win key by adding the following in your ~/.Xmodmap:<br />
! No Caps Lock<br />
clear lock<br />
! Caps Lock as Win key<br />
add mod4 = Caps_Lock<br />
=====NumLock=====<br />
On the ThinkPad {{600}}, {{T20}}, {{T21}}, {{T22}}, {{T30}}, {{X20}}, {{X21}}, {{X31}}, {{X40}}, {{T42p}}, {{T43}}, {{R51}}, {{R52}} and possibly other models, X does not recognize the keycode for {{key|NumLk}} = {{key|Shift}}+{{key|ScrLk}}. To fix this, add the following to {{path|~/.Xmodmap}} in your home directory or {{path|/etc/X11/Xmodmap}} and run <tt>xmodmap</tt>, ex: <tt>xmodmap ~/.Xmodmap</tt>:<br />
keycode 77 = Num_Lock<br />
<br />
The following might work better for you:<br />
keycode 77 = Num_Lock Num_Lock<br />
because you will only get keycode 77 together with Shift (at least on the {{T43}})<br />
<br />
This configuration also enables the respective LED.<br />
<br />
Please note, pressing the {{key|Shift}}+{{key|ScrLk}} key combination, without first following the above configuration, will start an accessibility feature, which will allow the numeric keypad to maneuver the mouse pointer. Starting this accessibility feature and subsequently running xmodmap, as described above, results in the accessibility feature and the numeric lock LED functioning simultaneously. As such, the above configuration should be completed before the accessibility feature is started in order to produce numbers.<br />
======T60 (and possibly others)======<br />
It seems that on the T60, PrtSc, ScrLk and Pause all generate the correct keycodes, however Fn-PrtSc (labelled as SysRq) generates keycode 64 (Alt_L) followed by the expected 111 (Sys_Req) on down and the same thing in the opposite order on release. Fn-ScrLk (labelled as NmLk) does indeed toggle the Numlock, but only seems to register as an X event the first time it is engaged. The above solution does not appear to work. This is perhaps because the Numlock toggle is built into the firmware rather than controlled by the kernel. Finally, Fn-Pause (labelled as Break) generates keycode 37 (Control_L) followed by the expected keycode 110 (Break) on down and the same thing in reverse order on release.<br />
<br />
=====NumPad (KeyPad) keys access by a key combination=====<br />
The current state is that you have to switch NumLock '''on''' via {{key|Fn}}+{{key|ScrLk}} and then e.g. type {{key|u}} to get a {{key|KP_4}} (NumPad 4). To get back to normal keyboard, you have to type {{key|Fn}}+{{key|ScrLk}} again.<br />
<br />
Some people (including me) are missing on recent Thinkpads the option to have Fn as a modifier key to access the NumPad instead, i.e. and e.g. {{key|Fn}}+{{key|u}} gives you {{key|KP_4}}.<br />
<br />
There is currently no way to make this work in a simple way (pleeeease correct me if I am wrong!), though there is a work-around. Instead of using {{key|Fn}} for accessing the NumPad, {{key|CapsLock}} can get this function by being mapped as Mode_switch (the {{key|AltGr}} on international keyboards). The {{key|Fn}} can be remapped to be Caps_Lock - while at the same time retaining its function to access the special laptop functions (e.g. {{key|Fn}}+{{key|F4}} for sleep}}, by using .Xmodmap.<br />
<br />
So on my {{R60}} running fvwm@{{Slackware}} 12.1 the .Xmodmap would look like this:<br />
<br />
! Make the forward and back buttons work<br />
keycode 233 = XF86Forward<br />
keycode 234 = XF86Back<br />
! Make the WIN key to Super modifier<br />
keycode 115 = Super_L<br />
! Set the Caps_Lock physical key to Mode_switch (like AltGr on intl. keyboards)<br />
keycode 66 = Mode_switch<br />
! Set the Fn key to work as Caps_Lock now. The special key combos like Fn-F4 for "sleep" still work then<br />
keycode 227 = Caps_Lock<br />
clear lock<br />
add lock = Caps_Lock<br />
! Now we activate those new keys. Find some free mod slots (xmodmap) and put them there.<br />
clear mod4<br />
clear mod5<br />
add mod4 = Super_L<br />
add mod3 = Mode_switch<br />
! It's time to add the keypad keys to the third position of the key definition (pure shift mode_switch shift+mode_switch)<br />
keycode 16 = 7 ampersand KP_7<br />
keycode 17 = 8 asterisk KP_8<br />
keycode 18 = 9 parenleft KP_9<br />
keycode 19 = 0 parenright KP_Divide<br />
keycode 30 = u U KP_4<br />
keycode 31 = i I KP_5<br />
keycode 32 = o O KP_6<br />
keycode 33 = p P KP_Multiply<br />
keycode 44 = j J KP_1<br />
keycode 45 = k K KP_2<br />
keycode 46 = l L KP_3<br />
keycode 47 = semicolon colon KP_Subtract<br />
keycode 58 = m M KP_0<br />
! ... I have to use the coma key, too, on the keypad...so I set it to be F20 (which is not existing on normal keyboards and thus is free... check for side effects in programmes accepting F12+ keys!)<br />
keycode 59 = comma less F20 <br />
keycode 60 = period greater KP_Decimal <br />
keycode 61 = slash question KP_Add<br />
<br />
{{WARN|Your keycodes might be different as well as your '''mod''#''''' settings.}}<br />
Use {{cmduser|xmodmap}} and {{cmduser|xmodmap -pke}} to check your ModMap, and the tool {{cmduser|xev}} to obtain your exact key codes.<br />
<br />
===Mapping keys with setkeycodes===<br />
You can use the setkeycodes command to remap certain keys. I.e. you can use {{cmdroot|setkeycodes 6e 109 6d 104 69 28 6b 1}} to map the Tablets Up and Down keys to the standard PageUp and PageDown keys and Tablet Escape and Enter to their respective keys.<br />
<br />
The following table shows the scancodes generated by the ThinkPad keys. They vary with model - see [[Tablet Hardware Buttons]].<br />
{| {{prettytable}}<br />
|+ scancodes<br />
! key !! scancode<br />
|-<br />
| {{ibmkey|Tablet orientation|#494949}} || 0x6c<br />
|-<br />
| {{ibmkey|Tablet Shortcut|#494949}} || 0x68<br />
|-<br />
| {{ibmkey|Tablet Esc|#494949}} || 0x6b<br />
|-<br />
| {{ibmkey|Tablet Enter|#494949}} || 0x69<br />
|-<br />
| {{ibmkey|Tablet Up|#494949}} || 0x6d<br />
|-<br />
| {{ibmkey|Tablet Down|#494949}} || 0x6e<br />
|-<br />
| {{ibmkey|Tablet (unlabeled)|#494949}} || 0x67<br />
|}<br />
<br />
===acpi_fakekey===<br />
You can turn acpi events into user-level xevents by putting <tt>acpi_fakekey</tt> commands into the acpi action scripts. There are several layers involved in using acpi keys in this way, so I'll go through the example of using the ThinkVantage button to open xmms.<br />
<br />
My ThinkVantage button generates an '''acpi event''' "ibm/hotkey HKEY 00000080 00001018", so we have the event file <tt>/etc/acpi/events/ThinkVantage</tt> for it which executes the script <tt>/etc/acpi/actions/fakekey-macro.sh</tt>. <br />
<pre><br />
event=ibm/hotkey HKEY 00000080 00001018<br />
action=/etc/acpi/actions/fakekey-macro.sh<br />
</pre><br />
In turn, the executable <tt>/etc/acpi/actions/fakekey-macro.sh</tt> script calls acpi_fakekey with the '''key number''' defined in <tt>/usr/share/acpi-support/key-constants</tt> as $KEY_MACRO which is 112 (you could just as well choose an other key number, just make sure that it doesn't belong to something else like the "j" key or something). <br />
<pre><br />
#!/bin/sh<br />
. /usr/share/acpi-support/key-constants<br />
acpi_fakekey $KEY_MACRO <br />
</pre><br />
I have no idea how this actually corresponds to which xevent is generated, so I can find out out by running the program <tt>xev</tt> and hitting the ThinkVantage button while the mouse is in the <tt>xev</tt> window (remember to <tt>/etc/init.d/acpid restart</tt> first if you just created the <tt>/etc/acpi/events/ThinkVantage</tt> file). I get something popping up in the terminal where I ran xev that looks like this:<br />
<pre><br />
KeyPress event, serial 30, synthetic NO, window 0x2800001,<br />
root 0x6a, subw 0x0, time 2000522842, (138,83), root:(781,500),<br />
state 0x0, keycode 239 (keysym 0x0, NoSymbol), same_screen YES,<br />
XLookupString gives 0 bytes: <br />
XmbLookupString gives 0 bytes: <br />
XFilterEvent returns: False<br />
<br />
KeyRelease event, serial 30, synthetic NO, window 0x2800001,<br />
root 0x6a, subw 0x0, time 2000522842, (138,83), root:(781,500),<br />
state 0x0, keycode 239 (keysym 0x0, NoSymbol), same_screen YES,<br />
XLookupString gives 0 bytes: <br />
XFilterEvent returns: False<br />
</pre><br />
This tells me that the <tt>acpi_fakekey 112</tt> as executed by hitting the ThinkVantage button generates KeyPress event followed by a KeyRelease event with '''keycode''' 239 and that this keycode has been assigned no corresponding '''keysym'''. Thus, I am free to assign the keycode to any keysym I want. You can find a list of available keysyms in <tt>/usr/share/X11/XKeysymDB</tt>. Again try and pick one that is not likely to have already been taken by something, such as <tt>XF86LaunchA</tt>. To assign this keysym to keycode 239, you can either edit ~/.Xmodmap on an individual user basis, or edit the systemwide <tt>/etc/X11/Xmodmap</tt> file to contain the line<br />
<pre><br />
keycode 239 = XF86LaunchA<br />
</pre><br />
If you choose to go with the former, you may need to run <tt>xmodmap ~/.Xmodmap</tt> for every login session in order to read in your ~/.Xmodmap file if your window manager does not do it for you. Regardless of which option you choose, you can run <tt>xmodmap <file></tt> to read in the updated Xmodmap file without logging out and logging back in.<br />
<br />
You should now find that hitting the ThinkVantage button creates the following output from <tt>xev</tt>:<br />
<pre><br />
KeyPress event, serial 55, synthetic NO, window 0x2800001,<br />
root 0x6a, subw 0x0, time 2001286078, (0,106), root:(643,523),<br />
state 0x0, keycode 239 (keysym 0x1008ff4a, XF86LaunchA), same_screen YES,<br />
XLookupString gives 0 bytes: <br />
XmbLookupString gives 0 bytes: <br />
XFilterEvent returns: False<br />
<br />
KeyRelease event, serial 55, synthetic NO, window 0x2800001,<br />
root 0x6a, subw 0x0, time 2001286078, (0,106), root:(643,523),<br />
state 0x0, keycode 239 (keysym 0x1008ff4a, XF86LaunchA), same_screen YES,<br />
XLookupString gives 0 bytes: <br />
XFilterEvent returns: False<br />
</pre><br />
Note the change of <tt>(keysym 0x0, NoSymbol)</tt> to <tt>(keysym 0x1008ff4a, XF86LaunchA)</tt>.<br />
<br />
You're now ready to map <tt>XF86LaunchA</tt> to executing xmms. This is highly dependent on what keygrabber you decide to use. For openbox, I edit my <tt>~/.config/openbox/rc.xml</tt> file and add the following entry in the <keyboard> section:<br />
<pre><br />
<keybind key="XF86LaunchA"><br />
<action name="Execute"><br />
<startupnotify><br />
<enabled>true</enabled><br />
</startupnotify><br />
<command><br />
xmms<br />
</command><br />
</action><br />
</keybind><br />
</pre><br />
After, right clicking on the desktop and selecting the "Reconfigure" menu option, you should then have xmms pop up when you hit the ThinkVantage key.<br />
<br />
==Example Applications==<br />
===Web Browsers===<br />
====Firefox (<3.0)====<br />
<br />
There are various ways to assign actions to the browser keys. The easiest way is to install [http://mozilla.dorando.at/keyconfig.xpi keyconfig.xpi] from http://mozilla.dorando.at, which adds a menu entry Tools->Keyconfig. Then you can assign any action you want to the F19/F20 keys (you still need to create {{path|~/.Xmodmap}} as explained above).<br />
<br />
<br />
The remaining discussion gives you various more complicated ways to achieve the same thing. <br />
To have firefox make use of the browser keys you need to modify one of its files{{footnote|4}}.<br />
To do this you will first need to extract it from the {{path|browser.jar}} archive. Do...<br />
<br />
Step 1: Edit .Xmodmap and add entries for F19 and F20 as explained above.<br />
<br />
Step 2:<br />
<br />
Note: <firefox-directory> is probably /usr/lib/firefox. Use your version so, if you have 3.0.1 or 3.0.2 use /usr/lib/firefox-3.0.1<br />
<br />
:{{cmdroot|cd <firefox-directory>/chrome}}<br /><br />
:{{cmdroot|unzip browser.jar}}<br />
<br />
The file of interest is {{path|content/browser/browser.xul}}. Edit it {and don't forget to make a backup copy first}...<br />
:{{cmdroot|vi content/browser/browser.xul}}<br />
<br />
Look for the '''<keyset id="mainKeyset">''' section and add the following lines within...<br />
<key id="goBackKb" keycode="VK_F19" command="Browser:Back" /><br />
<key id="goForwardKb" keycode="VK_F20" command="Browser:Forward" /><br />
<br />
The Command you need for Next Tab <br />
<key id="goBackTabKb" keycode="VK_F19" oncommand="gBrowser.mTabContainer.advanceSelectedTab(-1)" /><br />
For the Previous Tab <br />
<key id="goForwardTabKb" keycode="VK_F20" oncommand="gBrowser.mTabContainer.advanceSelectedTab(1)" /><br />
<br />
Now save the file and repackage the {{path|browser.jar}} archive...<br />
:{{cmdroot|zip -rD0 browser.jar content/browser/}}<br />
<br />
That's it.<br />
<br />
Step 3: Restart Firefox.<br />
<br />
{{HINT|Outdated: Another interesting Page on Firefox is http://dqd.com/~mayoff/notes/thinkpad/dqdnavkeys/ It uses different key mappings (F19 resp. F20) but a ready [http://dqd.com/~mayoff/notes/thinkpad/dqdnavkeys/dqdnavkeys-1.2.xpi .xpi] is provided which is pretty comfortable. However, this xpi file does not install on Firefox 1.5. or later.}}<br />
<br />
{{HINT| You can also use the [http://extensionroom.mozdev.org/more-info/keyconfig keyconfig] extension to configure custom keys. This extension works with Firefox 1.5 and also with Firefox 2.0. The Command you need for Next Tab is gBrowser.mTabContainer.advanceSelectedTab(1,true); For Previous Tab its gBrowser.mTabContainer.advanceSelectedTab(-1,true); You can alternatively install the [http://www.pqrs.org/~tekezo/firefox/extensions/functions_for_keyconfig/index.html functions for keyconfig] and set the variable f4kc_NextTab to F20 and f4kc_PrevTab to F19.}}.<br />
<br />
====Firefox 3.0====<br />
Thankfully the people at Mozilla decided to include the expected functionality for the XF86Back and XF86Forward keysyms in the new release so all you need to do is<br />
<br><code># printf 'keycode 234 = XF86Back\nkeycode 233 = XF86Forward' >> /etc/X11/Xmodmap</code><br><br />
And to make this take effect immediately (i.e., without having to log out and log in again), as a regular user run:<br />
<br><code>{{cmduser|Xmodmap /etc/X11/Xmodmap}}</code><br />
<br />
For Hardy Heron, the xmodmap command is all lowercase. Also, the /etc/X11/Xmodmap file is not being read on boot. I've added the command to my .bashrc to have it called on startup.<br />
<br />
====Konqueror====<br />
KDE allows you set key mappings for KDE applications (Go to KMenu > System > Control Center > Regional & Accessibility > Keyboard Shortcuts). By default (at least in KDE 3.5), XF86Back and XF86Forward are set as alternatives to Alt-Left and Alt-Right, and are mapped to KDE Back and Forward navigation actions. <br />
<br />
If you use Konqueror as your only browser, you only need to set up {{path|~/.Xmodmap}} as described [[#xmodmap configuration|above]] to assign ThinkPad back/forward keys to the symbols XF86Back/XF86Forward. This also make these keys work for other KDE applications such as Quanta Plus, KPackage and so on (not all KDE applications honor this setting, e.g. KDE help system doesn't).<br />
<br />
If you want to use Firefox, however, the above settings do not work. You will have to map ThinkPad back/forward keys to F19/F20 as described [[#Firefox|above]], and change KDE navigation key settings to use F19/F20 instead of the default.<br />
<br />
====Opera====<br />
However this isn't a simple configration file, you can set your browser manually.<br /><br />
Go to <i>Tool > Settings > Mouse and keyboard > Keyboard settings > Edit > Browser Window</i>. There add F19 - Back and F20 - Forward. Now you can surf using your TP keys ;-)<br />
<br />
====Epiphany====<br />
By default, the back/forward keys, when bound to XF86Back/XF86Forward, successfully navigate through the history.<br />
<br />
To get them switch through your tabs, you could use the extension from [http://crashman.homelinux.org/~andre/public/epiphany%20extensions/thinkpad%20browserkeys/ here]<br />
You just need to edit your Xmodmap like described for Firefox < 3.0 (bind the keys on F19 and F20)<br />
<br />
===Open an application===<br />
<br />
To configure the ThinkVantage button to open a terminal window in Gnome:<br />
<br />
Step 1:<br />
Use xev to find the keycode generated by the button on your machine. In my case is is 159.<br />
<br />
Step 2:<br />
Create an entry in .Xmodmap like so<br />
<br />
keycode 159 = XF86LaunchA<br />
<br />
replacing 159 by the keycode found in step 1. Load the map using<br />
<br />
:{{cmd|xmodmap ~/.Xmodmap}}<br />
<br />
Step 3:<br />
Configure the required function (e.g. open terminal window) in System->Preferences->Keyboard shortcuts<br />
<br />
===Window Managers===<br />
====fvwm====<br />
To get the {{ibmkey|Forward|#494949}} and {{ibmkey|Backward|#494949}} keys to cycle through pages in the virtual desktop, add this to your {{path|~/.fvwmrc}}:<br />
Key XF86Back A A Scroll -100000 0<br />
Key XF86Forward A A Scroll +100000 0<br />
If you use multiple virtual desktops, you could instead use the keys to flip between them by using GotoDesk.<br />
<br />
====fluxbox====<br />
To get the keys to cycle through pages in the virtual desktop, add this to your {{path|~/.fluxbox/keys}}:<br />
None F19 :PrevWorkspace<br />
None F20 :NextWorkspace<br />
<br />
====pekwm configuration====<br />
You can make the two browser keys switch workspaces in pekwm, by adding the following two lines to the {{path|~/.pekwm/keys}} file:<br />
KeyPress = "Mod1 XF86Back" { Actions = "GoToWorkspace prev" }<br />
KeyPress = "Mod1 XF86Forward" { Actions = "GoToWorkspace next" }<br />
<br />
====pwm====<br />
Another example how to use these two keys to switch between pwm tabs. These two lines should be added to {{path|~/.pwm/keys-default.conf}} or {{path|/etc/pwm/keys-default.conf}}:<br />
kbind "Back", "switch_rot", -1<br />
kbind "Forward", "switch_rot", 1<br />
<br />
====IceWM====<br />
To make IceWM cycle workspaces using the {{ibmkey|Forward|#494949}} and {{ibmkey|Backward|#494949}} keys, change these two options in {{path|~/.icewm/preferences}} (Provided you assigned keysyms F19 and F20 with xmodmap):<br />
# "Previous workspace" shortcut<br />
KeySysWorkspacePrev="F19"<br />
# "Next workspace" shortcut<br />
KeySysWorkspaceNext="F20"<br />
<br />
==== Gnome/metacity ====<br />
<br />
On {{Debian}} Lenny, using Gnome 2.22.2, once the acpid and acpi-support packages are installed, most Fn keys do the right thing out of the box.<br />
<br />
For more advanced configuration, follow the [https://wiki.ubuntu.com/Keybindings Ubuntu guide].<br />
<br />
===Other Uses===<br />
====Console tools configuraton====<br />
To make the {{ibmkey|Forward|#494949}} and {{ibmkey|Backward|#494949}} keys useful in console, add this to your keymap ({{path|/etc/console/boottime.kmap.gz}} in {{Debian}}):<br />
keycode 158 = Decr_Console<br />
keycode 159 = Incr_Console<br />
<br />
Alternatively you can load this script (perhaps on system startup) to enable Backward/Forward button console (VT) switch:<br />
<br />
#!/bin/sh<br />
echo keycode 158 = Decr_Console | loadkeys<br />
echo keycode 159 = Incr_Console | loadkeys<br />
<br />
It should work with any distro.<br />
<br />
====Cycling through tabs====<br />
In Gnome and Xfce4, Ctrl-PageUp/Ctrl-PageDown move to the previous/following open tab in all applications that have tabbed user interfaces (terminal emulator, web browser, ...). To make use of the {{ibmkey|Forward|#494949}} and {{ibmkey|Backward|#494949}} keys for this task, there're two possibilities.<br />
<br />
For both ways, you should map the keycodes 233 and 234 to XF86Back and XF86Forward as described in [[#xmodmap_configuration|xmodmap configuration]].<br />
<br />
=====Using xautomation=====<br />
xautomation can be found [http://hoopajoo.net/projects/xautomation.html here].<br />
<br />
Create two files with permissions 755:<br />
<br />
{{path|/usr/local/bin/tp_back}}:<br />
<bash><br />
#!/bin/bash<br />
/usr/bin/xte 'keydown Control_L' 'keydown Page_Up' 'keyup Page_Up' 'keyup Control_L'<br />
</bash><br />
<br />
{{path|/usr/local/bin/tp_forward}}:<br />
<bash><br />
#!/bin/bash<br />
/usr/bin/xte 'keydown Control_L' 'keydown Page_Down' 'keyup Page_Down' 'keyup Control_L'<br />
</bash><br />
<br />
Use your desktop's keyboard shortcut editor to assign XF86Back as a shortcut for tp_back and XF86Forward as a shortcut for tp_forward.<br />
<br />
This should work in all distros and with all window managers (you might have to use other key combinations than Ctrl-PageUp and Ctrl-PageDown).<br />
<br />
=====Redirecting XF86Back/XF86Forward=====<br />
Create {{path|/etc/X11/xkb/compat/thinkpad}}:<br />
<pre><br />
// $XFree86$<br />
// XFree86 special keysyms<br />
default partial xkb_compatibility "basic" {<br />
interpret.repeat= True;<br />
<br />
interpret XF86Back {<br />
action = Redirect(Key=<PGUP>, modifiers=Control);<br />
};<br />
interpret XF86Forward {<br />
action = Redirect(Key=<PGDN>, modifiers=Control);<br />
};<br />
};<br />
</pre><br />
<br />
Edit {{path|/etc/X11/xkb/compat/complete}} and add <tt>'''augment "thinkpad"'''</tt> so that it looks similar to the following:<br />
<pre><br />
// $XKeyboardConfig: xkbdesc/compat/complete,v 1.3 2005/10/17 00:42:11 svu Exp $<br />
// $Xorg: complete,v 1.3 2000/08/17 19:54:34 cpqbld Exp $<br />
default xkb_compatibility "complete" {<br />
include "basic"<br />
augment "iso9995"<br />
augment "mousekeys"<br />
augment "accessx(full)"<br />
augment "misc"<br />
augment "xfree86"<br />
augment "level5"<br />
augment "thinkpad"<br />
};<br />
</pre><br />
<br />
==External Sources==<br />
*[http://www-307.ibm.com/pc/support/site.wss/document.do?lndocid=MIGR-51537 IBMs page on configuring the ThinkPad buttons (ThinkPad, Access IBM, Mail, Search, and Home buttons) under Linux]<br />
*[http://dqd.com/~mayoff/notes/thinkpad/dqdnavkeys/ Rob Mayoffs page on using IBM Keyboard Navigation Keys in Linux Mozilla and Firefox]<br />
*[http://snarfed.org/space/thinkpad+keys+in+firefox Ryan Barretts blog article about using the browser keys in Firefox]<br />
*[http://chaotika.org/~bluesceada/?page=soft&sub=thinkpad#acpibutn DennisG's help to get the ibm-acpi buttons do useful things] on a {{Z61e}} and possibly {{Z61m}}, {{Z61t}} and {{Z61p}}<br />
*[https://help.ubuntu.com/community/KeyboardShortcuts/#Replacing%20keys%20with%20other%20keys using xbindkeys and xmacro to override key bindings]<br />
{{footnotes|<br />
#Note that the associated functionality for Fn-F* key combinations is not consistent amongst all ThinkPads. We are maintaining [[Default meanings of special keys|a table of associated meanings]].<br />
#if there are more than one tool listed, one is sufficient<br />
#'full' means you can completely reassign any action to be triggered by the key, 'additional actions' means you can trigger actions in addition to the standard function of the key, which can not be changed.<br />
#Thanks go to Ryan Barrett for writing the [http://snarfed.org/space/thinkpad+keys+in+firefox little howto] on [http://snarfed.org/space/start his blog].<br />
}}</div>Denisqhttps://www.thinkwiki.org/w/index.php?title=Talk:Tp_smapi&diff=48641Talk:Tp smapi2010-05-25T08:20:13Z<p>Denisq: /* SL Series */</p>
<hr />
<div>== Feedback ==<br />
<br />
Great, great work! Really! This completely rocks. I just stopped my battery from charging at 77% and restarted charging a bit later, no problems whatsoever. BTW, this is on kernel 2.6.14.3.<br />
<br />
--[[User:Spiney|spiney]] 21:25, 5 Dec 2005 (CET)<br />
----<br />
None of the fuctions is working on my T40, kernel 2.6.14-mm2.<br />
<br />
--[[User:Lammic|lammic]], 2005.12.05<br />
<br />
Works for me on a T41 running 2.6.12-10-686 (Ubuntu 5.10).<br />
<br />
--[[User:berndtnm|berndtnm]], 2005.12.06<br />
<br />
Including stop_charge_thresh? That one seems to be missing on the T42p.<br />
<br />
--[[User:Thinker|Thinker]] 00:46, 7 Dec 2005 (CET)<br />
----<br />
<br />
tp_smapi works just fine on an R52 with Ubuntu Breezy stock kernel.<br />
<br />
--[[User:Micampe|Micampe]] 12:52, 7 Dec 2005 (CET)<br />
<br />
----<br />
<br />
''To set the thresholds for starting and stopping battery charging (in percent of current capacity):''<br />
<br />
'''current''' really? That'd be weird, I'd expect it to be percent of '''total''' capacity.<br />
<br />
--[[User:Micampe|Micampe]] 14:39, 7 Dec 2005 (CET)<br />
<br />
"Current full charge capacity", as opposed to "current remaining capacity" or "designed full charge capacity"...<br />
<br />
--[[User:Thinker|Thinker]] 15:05, 7 Dec 2005 (CET)<br />
----<br />
<br />
Battery features don't work with my T41p. I can't check this with windows. Can anybody try these features?<br />
<br />
-- Nils, 7 Dec 2005<br />
----<br />
<br />
Nils, does cdrom_speed work for you on the T41p? Could you provide the details requested in the README (dmesg etc.)?<br />
<br />
--[[User:Thinker|Thinker]] 21:57, 7 Dec 2005 (CET)<br />
----<br />
<br />
CDRom Speed seems to work. (I see no warnings, but I have to do a speed test.) Now, I've send all outputs to the email-address in the readme.<br />
<br />
-- Nils, 8 Dec 2005<br />
----<br />
<br />
All the features except the stop_charge_thresh seem to work here on a t42p. <br />
One note, the start_charge_thresh seems to really be stop_charge_thresh. Ie, If I set that to lower than my current battery %, it will never charge, <br />
and if I set it to 100 the battery charges all the way. <br />
<br />
--[[User:Nirik|Nirik]] 16 Dec 2005<br />
----<br />
<br />
Nirik, "all the features" as of which version? For example, do the force_discharge{1,2} in tp_smapi 0.12 also work for you? See the table in the article page. About start_charge, that's odd. Can you send me a log of what you did, what was the result a what was the dmesg output for each operation?<br />
<br />
--[[User:Thinker|Thinker]] 14:16, 16 Dec 2005 (CET)<br />
----<br />
<br />
System T40p:<br />
<br />
<pre><br />
fairlight:/sys/devices/platform/smapi/BAT0# echo 1 > /sys/devices/platform/smapi/BAT0/force_discharge1<br />
fairlight:/sys/devices/platform/smapi/BAT0# echo 1 > /sys/devices/platform/smapi/BAT0/force_discharge2<br />
fairlight:/sys/devices/platform/smapi/BAT0# dmesg <br />
tp_smapi: req_in: BX=2118 CX=100 DI=0 SI=0<br />
tp_smapi: req_out: AX=8680 BX=2118 CX=100 DX=b2 DI=0 SI=0 ret=-38<br />
tp_smapi: SMAPI error: Function is not supported by SMAPI BIOS (func=2118)<br />
tp_smapi: cannot get force_discharge1 of battery 0: Function is not supported by SMAPI BIOS<br />
tp_smapi: req_in: BX=2104 CX=100 DI=0 SI=0<br />
tp_smapi: req_out: AX=80 BX=2103 CX=100 DX=78 DI=0 SI=0 ret=0<br />
tp_smapi: cannot get force_discharge2 of battery 0: bx=2103<br />
</pre><br />
<br />
So it seems force_discharge1 is not supported at all. But force_discharge2? By the way, i think wiki is a _very_ good idea for collecting information, but not for discussion. I would prefer a maillinglist. We can use sourceforge.<br />
<br />
--[[User|StefanSchmidt]]<br />
<br />
force_discharge2 is indicating a real error condition (bx=2103 which has bit 0x02 on), but I have no idea what the error is or how to fix it. Sorry. If you can trigger this function under Windows and have SoftICE or equivalent, maybe it can be worked out.<br />
<br />
About the Wiki discussion, I'm not sure a mailing list is justified yet, but you can use the linux-thinkpad list or the e-mail address in the README. <br />
<br />
--[[User:Thinker|Thinker]] 21:42, 16 Dec 2005 (CET)<br />
<br />
OK, then i use linux-thinkpad to get more people involved. I'am away the next weeks, but i hope to find some time to hacking on tp_smapi.<br />
<br />
--[[User:StefanSchmidt]]<br />
----<br />
<br />
Someone reported cd_speed works on T42 but on mine, it doesn't: this is 2378DXU<br />
<br />
--[[User:eBug]] 22:55, 17 Dec 2005 (CET)<br />
----<br />
<br />
eBug, how does it fail? If the file doesn't exist, it means you didn't enable PROVIDE_CD_SPEED (see the README). If it does exist, can you provide the dmesg output when you read an write to the file?<br />
<br />
--[[User:Thinker|Thinker]] 11:53, 18 Dec 2005 (CET)<br />
----<br />
<br />
To confirm:<br />
tp_smapi 0.13 works with hdaps module loaded on T41 (2373-8RG). However, force_discharge*, inhibit_charge_minutes, start_charge_thresh, stop_charge_thresh don't seem to be implemented on this model.<br />
<br />
--[[User:LJSBRokken|LJSBrokken]] 21 Dec 2005<br />
----<br />
<br />
tp_smapi version 0.13 with T23 (2647-3QG) (I have dual batteries)...<br />
<br />
None of the functions which make any changes work...<br />
<br />
<pre># cd /sys/devices/platform/smapi && cat BAT*/* > /dev/null<br />
cat: BAT0/force_discharge1: Function not implemented<br />
cat: BAT0/force_discharge2: Input/output error<br />
cat: BAT0/inhibit_charge_minutes: Function not implemented<br />
cat: BAT0/start_charge_thresh: Function not implemented<br />
cat: BAT0/stop_charge_thresh: Function not implemented<br />
cat: BAT1/force_discharge1: Function not implemented<br />
cat: BAT1/force_discharge2: Input/output error<br />
cat: BAT1/inhibit_charge_minutes: Function not implemented<br />
cat: BAT1/start_charge_thresh: Function not implemented<br />
cat: BAT1/stop_charge_thresh: Function not implemented</pre><br />
<br />
However, all the battery status information is available, and functions appear for both BAT0 and BAT1, regardless of when the UltraBay battery was inserted or ejected- this is very useful, it is the only way I can monitor my UltraBay battery unless it was present on boot.<br />
<br />
--[[User:SystemParadox|SystemParadox]] 21:51, 4 Jan 2006 (CET)<br />
----<br />
<br />
SystemParadox, what's the dmesg output produced by "cat BAT0/force_discharge2"?<br />
<br />
--[[User:Thinker|Thinker]] 22:02, 4 Jan 2006 (CET)<br />
----<br />
<br />
After the upgrade to 0.14 (with kernel 2.6.15, using the patch) I can't use inhibit_charge and start/stop_charge_thresh any longer (getting an input/output error), the dmesg debug output when {{cmd|cat|}}-ing those three files:<br />
<br />
<pre><br />
tp_smapi: tp_smapi 0.14 loading...<br />
tp_smapi: successfully loaded (smapi_port=0xb2).<br />
tp_smapi: req_in: BX=2114 CX=100 DI=0 SI=0<br />
tp_smapi: req_out: AX=ea210080 BX=ec192114 CX=c18d0700 DX=f7cc00b2 DI=f7f50000 SI=c18d0000 ret=-5<br />
tp_smapi: SMAPI error: Unknown error code (func=2114)<br />
tp_smapi: cannot get inhibit charge of battery 0: Unknown error code<br />
tp_smapi: req_in: BX=2116 CX=100 DI=0 SI=0<br />
tp_smapi: req_out: AX=c03b0080 BX=c18d2116 CX=c0160328 DX=ec7600b2 DI=ec760000 SI=a0810000 ret=-5<br />
tp_smapi: SMAPI error: Unknown error code (func=2116)<br />
tp_smapi: cannot get start thresh of battery 0: Unknown error code<br />
tp_smapi: req_in: BX=211a CX=100 DI=0 SI=0<br />
tp_smapi: req_out: AX=c03b0080 BX=c18d211a CX=c016032c DX=eb4500b2 DI=eb450000 SI=241e0000 ret=-5<br />
tp_smapi: SMAPI error: Unknown error code (func=211a)<br />
tp_smapi: cannot get stop thresh of battery 0: Unknown error code<br />
</pre><br />
<br />
--[[User:Spiney|spiney]] 08:12, 10 Jan 2006 (CET)<br />
----<br />
<br />
Oops, the transition to 32-bit SMAPI calls was broken. Fixed in 0.15. Thanks for the quick report!<br />
<br />
--[[User:Thinker|Thinker]] 12:10, 10 Jan 2006 (CET)<br />
----<br />
<br />
Yep, 0.15 works again. Quick response, bravo! :)<br />
<br />
--[[User:Spiney|spiney]] 12:23, 10 Jan 2006 (CET)<br />
----<br />
<br />
On a T22, nothing seems to work with 0.16.<br />
<br />
[[http://www.rafb.net/paste/results/fcUUDs49.html|dmesg output]] when doing cat *<br />
<br />
I am using an Ultrabay2000 battery, so it would be really usefull to be able to control that<br />
<br />
--[[User:nusse|nusse]]<br />
----<br />
<br />
Nusse: Not even the extended battery status? That does work on T23. About the control features, I believe they're not available on the T23; did you have any kind of (dis)charge control under WindowS?<br />
<br />
--[[User:Thinker|Thinker]] 20:59, 11 Jan 2006 (CET)<br />
----<br />
<br />
I don't really know what 'extended battery' status means, but here an example:<br />
<pre><br />
$ cat current_* /sys/devices/platform/smapi/BAT1<br />
cat: current_avg: Input/output error<br />
cat: current_now: Input/output error<br />
</pre><br />
This is what happens when i cat any file in this directory and also in ../BAT1 :(<br />
<br />
--[[User:nusse|nusse]] Thu Jan 12 22:07:26 CET 2006<br />
----<br />
<br />
Nusse: Yes, that's what I meant. What's the {{cmdroot|dmesg}} output generated by these commands?<br />
<br />
--[[User:Thinker|Thinker]] 00:27, 13 Jan 2006 (CET)<br />
----<br />
<br />
<br />
Thinker: I attached some link to my first comment but it seems to be down and the link was wrong anyway.<br />
<pre><br />
thinkpad controller read(%hx,%hx): failed writing to 0x1610<br />
thinkpad controller read(%hx,%hx): failed writing to 0x1610<br />
thinkpad controller read(%hx,%hx): failed writing to 0x1610<br />
thinkpad controller read(%hx,%hx): failed writing to 0x1610<br />
thinkpad controller read(%hx,%hx): failed writing to 0x1610<br />
thinkpad controller read(%hx,%hx): failed writing to 0x1610<br />
thinkpad controller read(%hx,%hx): failed writing to 0x1610<br />
thinkpad controller read(%hx,%hx): failed writing to 0x1610<br />
thinkpad controller read(%hx,%hx): failed writing to 0x1610<br />
thinkpad controller read(%hx,%hx): failed writing to 0x1610<br />
thinkpad controller read(%hx,%hx): failed writing to 0x1610<br />
thinkpad controller read(%hx,%hx): failed writing to 0x1610<br />
thinkpad controller read(%hx,%hx): failed writing to 0x1610<br />
thinkpad controller read(%hx,%hx): failed writing to 0x1610<br />
thinkpad controller read(%hx,%hx): failed writing to 0x1610<br />
tp_smapi: SMAPI error: Function is not supported by SMAPI BIOS (func=2118)<br />
tp_smapi: cannot get force_discharge of battery 0: Function is not supported by SMAPI BIOS<br />
tp_smapi: SMAPI error: Function is not supported by SMAPI BIOS (func=2114)<br />
tp_smapi: cannot get inhibit charge of battery 0: Function is not supported by SMAPI BIOS<br />
thinkpad controller read(%hx,%hx): failed writing to 0x1610<br />
thinkpad controller read(%hx,%hx): failed writing to 0x1610<br />
thinkpad controller read(%hx,%hx): failed writing to 0x1610<br />
thinkpad controller read(%hx,%hx): failed writing to 0x1610<br />
thinkpad controller read(%hx,%hx): failed writing to 0x1610<br />
thinkpad controller read(%hx,%hx): failed writing to 0x1610<br />
thinkpad controller read(%hx,%hx): failed writing to 0x1610<br />
thinkpad controller read(%hx,%hx): failed writing to 0x1610<br />
thinkpad controller read(%hx,%hx): failed writing to 0x1610<br />
thinkpad controller read(%hx,%hx): failed writing to 0x1610<br />
thinkpad controller read(%hx,%hx): failed writing to 0x1610<br />
thinkpad controller read(%hx,%hx): failed writing to 0x1610<br />
thinkpad controller read(%hx,%hx): failed writing to 0x1610<br />
thinkpad controller read(%hx,%hx): failed writing to 0x1610<br />
thinkpad controller read(%hx,%hx): failed writing to 0x1610<br />
tp_smapi: SMAPI error: Function is not supported by SMAPI BIOS (func=2116)<br />
tp_smapi: cannot get start thresh of battery 0: Function is not supported by SMAPI BIOS<br />
thinkpad controller read(%hx,%hx): failed writing to 0x1610<br />
thinkpad controller read(%hx,%hx): failed writing to 0x1610<br />
tp_smapi: SMAPI error: Function is not supported by SMAPI BIOS (func=211a)<br />
tp_smapi: cannot get stop thresh of battery 0: Function is not supported by SMAPI BIOS<br />
thinkpad controller read(%hx,%hx): failed writing to 0x1610<br />
thinkpad controller read(%hx,%hx): failed writing to 0x1610<br />
</pre><br />
<br />
--[[User:nusse|nusse]] Fri Jan 13 14:35:57 CET 2006<br />
----<br />
<br />
Nusse: Thanks; but there's not much we can do. Maybe the T22 uses a different interface, or doesn't have that feature.<br />
<br />
--[[User:Thinker|Thinker]] 23:23, 15 January 2006 (CET)<br />
----<br />
<br />
Thinker: Is there anything I can do to check if the interface is different? Changing 0x1610 to some random number?<br />
<br />
Is there a chance to get it by try and error?<br />
<br />
--[[User:nusse|nusse]] Mon Jan 16 19:10:12 CET 2006<br />
----<br />
<br />
0x1610 is the number of an IO port it writes to, so changing it to a random number will pretty much guarantee a system crash...<br />
<br />
The only way I can think of for figuring out the T22 interface is to see what the Windows software does.<br />
<br />
--[[User:Thinker|Thinker]] 19:47, 16 January 2006 (CET)<br />
----<br />
<br />
I have a R40 (2722-B3G), and several things don't work with 0.16 on linux 2.6.15.1:<br />
<br />
<pre><br />
tp_smapi: SMAPI error: Function is not supported by SMAPI BIOS (func=2118)<br />
tp_smapi: cannot get force_discharge of battery 0: Function is not supported by SMAPI BIOS<br />
tp_smapi: SMAPI error: Function is not supported by SMAPI BIOS (func=2114)<br />
tp_smapi: cannot get inhibit charge of battery 0: Function is not supported by SMAPI BIOS<br />
tp_smapi: SMAPI error: Function is not supported by SMAPI BIOS (func=2116)<br />
tp_smapi: cannot get start thresh of battery 0: Function is not supported by SMAPI BIOS<br />
tp_smapi: SMAPI error: Function is not supported by SMAPI BIOS (func=211a)<br />
tp_smapi: cannot get stop thresh of battery 0: Function is not supported by SMAPI BIOS<br />
</pre><br />
<br />
Don't know about Windows, haven't booted it for weeks nor used it for years...<br />
<br />
--[[User:Wonka|Wonka]] 19:00, 19 January 2006 (CET)<br />
----<br />
<br />
Wonka: do the other features (i.e., extended battery status) work on your R40?<br />
<br />
--[[User:Thinker|Thinker]] 20:30, 20 January 2006 (CET)<br />
----<br />
<br />
--[[User:lisch|lisch]] 16:14, 11 April 2006 (CDT)<br />
<br />
On my X32, with two batteries, I get just what I expect. Looks good:<br />
<pre>$ cat BAT?/* > /dev/null<br />
cat: BAT0/force_discharge: Function not implemented<br />
cat: BAT0/inhibit_charge_minutes: Function not implemented<br />
cat: BAT0/start_charge_thresh: Function not implemented<br />
cat: BAT0/stop_charge_thresh: Function not implemented<br />
cat: BAT1/force_discharge: Function not implemented<br />
cat: BAT1/inhibit_charge_minutes: Function not implemented<br />
cat: BAT1/start_charge_thresh: Function not implemented<br />
cat: BAT1/stop_charge_thresh: Function not implemented<br />
$<br />
</pre><br />
==Changing the CD speed when the CD is being accessed will hang your computer==<br />
<br />
I don't have this problem on my T40p. CDROM is mounted and file on CD is opened. Change speed do '''not''' hang my system.<br />
<br />
-- Stefan Schmidt<br />
----<br />
<br />
An open file looks fine if you're not reading/writing at that point. But my T43 does hangs on this:<br />
# dd if=/dev/scd0 of=/dev/null &<br />
# echo 1 > /sys/devices/platform/smapi/cdrom_speed<br />
<br />
--[[User:Thinker|Thinker]] 16:41, 7 Dec 2005 (CET)<br />
----<br />
<br />
OK, sorry. I was to fast. My system hangs on this commands, too. :(<br />
<br />
-- Stefan Schmidt<br />
<br />
Works well. Great.<br />
<br />
T42 2373-8zh. Working :cdrom_speed and start_charge_thresh. Untest : inhibit_charge_minutes.<br />
<br />
-- Haifeng Chen<br />
<br />
cdrom_speed works on my T40.<br />
<br />
-- [[User:Lammic|lammic]], 2005.12.09<br />
<br />
== Kernel Patch? ==<br />
<br />
Hello Thinker,<br />
<br />
would it be possible to provide the SMAPI support as kernel patch as well? Something along the lines of: (0.12 against 2.6.15-rc5)<br />
<br />
''(deleted, see below for how to create a patch file)''<br />
<br />
Deleted the tp_smapi.c file at the end, out of obvious reasons, and I'm not sure about the placement in the ACPI section, OTOH there it would be found easily next to ibm_acpi.<br />
<br />
Providing a patch would help when recompiling the kernel often, I hate recompiling external modules every time (even got me a kernel-upgrade script to do most of it automatically). But of course it's up to you. :)<br />
<br />
--[[User:Spiney|spiney]] 09:52, 16 Dec 2005 (CET)<br />
----<br />
<br />
I'll be glad to add this, but I don't want to go through additional manual steps in the release process (there are already quite a few). Can you add a "make patch" functionality to the Makefile, or something of the sort, to automatically generate a full patch (including tp_smapi.c) against current kernel sources?<br />
<br />
Also, this shouldn't be under drivers/acpi, since it doesn't use ACPI at all (that's why I didn't make it a patch to ibm_acpi). I think the right place is drivers/firmware, like the dell_rbu driver for Dell laptops.<br />
<br />
BTW, the convention for kernel patches is to start them once level higher:<br />
diff -Nurp kernel-2.6.14-vanilla kernel-2.6.14-patched<br />
<br />
--[[User:Thinker|Thinker]] 17:12, 16 Dec 2005 (CET)<br />
----<br />
<br />
Of course it's from the wrong level, as usual I was just lazy/inattentive. And at one point I'll remember who likes what patch format, promise. ;)<br />
<br />
A patch target as in "create a new file holding a correct diff to current kernel source" would be rather difficult, since line numbers might change etc., but applying the patch should be straighforward with a bit of sed. Of course I could just do that, create a patch with the diff command and then apply the new patch file in reverse. ;)<br />
<br />
--[[User:Spiney|spiney]] 18:36, 16 Dec 2005 (CET)<br />
----<br />
<br />
If it does that on a local copy (no changes the original kernel tree) and cleans up after itself, that's fine with me. :-)<br />
<br />
--[[User:Thinker|Thinker]] 18:50, 16 Dec 2005 (CET)<br />
----<br />
<br />
Ok, here's a shell script that creates the patch, feel free to use it under the terms of the GPL. For example call it from your Makefile with the patch target: (I didn't want to put all the script into the Makefile, since the rules about escaping in Makefiles, well, escape me ;)<br />
<br />
<pre><br />
#!/bin/bash<br />
<br />
KDIR=/lib/modules/$(uname -r)/build<br />
FDIR=drivers/firmware<br />
OPWD=$(pwd)<br />
<br />
TMPDIR=$(mktemp -d)<br />
cd $TMPDIR<br />
<br />
mkdir -p a/$FDIR<br />
cp $KDIR/$FDIR/{Kconfig,Makefile} a/$FDIR<br />
cp -r a b<br />
sed -i -e '/endmenu/i\<br />
config IBM_SMAPI\<br />
tristate "IBM ThinkPad SMAPI Support"\<br />
depends on X86\<br />
---help---\<br />
This adds SMAPI support on IBM ThinkPads, mostly used for battery\<br />
charge control. For more information about this driver see\<br />
<http://www.thinkwiki.org/wiki/SMAPI_support_for_Linux> .\<br />
\<br />
If you have an IBM ThinkPad laptop, say Y or M here.\<br />
' b/$FDIR/Kconfig<br />
sed -i -e '$a\<br />
obj-$(CONFIG_IBM_SMAPI) += tp_smapi.o' b/$FDIR/Makefile<br />
cp $OPWD/tp_smapi.c b/$FDIR<br />
diff -Nurp a b > $OPWD/tp_smapi-$(uname -r).patch<br />
rm -r a b<br />
cd $OPWD<br />
</pre><br />
<br />
BTW, [http://qbnz.com/highlighter/ GeSHi]-based syntax-highlighting would be great...<br />
<br />
--[[User:Spiney|spiney]] 19:28, 16 Dec 2005 (CET)<br />
----<br />
<br />
Ah, neat sed foo. How about [http://tpctl.sourceforge.net/tmp/Makefile this] escapade, then? <br />
<br />
What's the sed spell needed to replace the Makefile's<br />
VER := 0.13<br />
with auto-parsing of<br />
#define TP_VERSION "0.13"<br />
from tp_smapi.c?<br />
<br />
--[[User:Thinker|Thinker]] 20:37, 16 Dec 2005 (CET)<br />
----<br />
<br />
Hmm, something like<br />
VERFROMC=$(sed -ne 's/^#define TP_VERSION "\(.*\)"/\1/gp' tp_smapi.c)<br />
sed -i -e "s/^VER := .*$/VER := $VERFROMC/" Makefile<br />
should do (untested, from the top of my head, maybe the temporary variable isn't even necessary?). And neat Makefile wizardry, at one point I'll learn the syntax.<br />
<br />
--[[User:Spiney|spiney]] 20:44, 16 Dec 2005 (CET)<br />
----<br />
<br />
Makefile escaping is horrible, keep avoiding it... Anyway, the updated [http://tpctl.sourceforge.net/tmp/Makefile make patch] seems to do the right thing.<br />
<br />
--[[User:Thinker|Thinker]] 21:36, 16 Dec 2005 (CET)<br />
----<br />
<br />
Small documentation request: just needed to create a patch for the not-yet-installed 2.6.16-rc2, which is no problem with<br />
make KSRC=/path/to/linux-2.6.16-rc2 KVER=2.6.16-rc2 patch<br />
but I guess it would be a good addition to the README file. :)<br />
<br />
--[[User:Spiney|spiney]] 10:48, 8 February 2006 (CET)<br />
----<br />
<br />
Right, added (to next release).<br />
<br />
--[[User:Thinker|Thinker]] 13:40, 8 February 2006 (CET)<br />
----<br />
<br />
==Installation questions==<br />
Amazing! I've loaded this module in my T43 which is running SuSE 10 with the kernel of 2.6.13-15. I have three points to share:<br />
<br />
1. The battery control part seems to work but has a minor problem. I set the stop_charge_threshold to 70, but the battery stops charging at 55%. Don't know why and how to fix it. :P<br />
<br />
2. I don't have the cd speed control function. Here is what I have under /sys/devices/platform/smapi/:<br />
<br />
./ ../ ac_connected BAT0/ BAT1/ bus@ driver@ power/<br />
<br />
3. SuSE 10 doesn't have the necessary C files under .../drivers/hwmon/, I copied them from a 2.6.14.5 kernel source. Maybe it causes the two problems above. :(<br />
<br />
When I have time, I'll install the new kernel to see if the problems are gone and report the result.<br />
<br />
--[[User:68.51.153.96|68.51.153.96]] 04:31, 2 Jan 2006 (CET)<br />
----<br />
<br />
1. It should stop charging at 70, but will only ''start'' charging when remaining capacity has dipped below <tt>start_charge_thresh</tt>.<br />
<br />
2. See the note about PROVIDE_CD_SPEED.<br />
<br />
3. That's should be needed only for patching the HDAPS driver in order to make it compatible with tp_smapi. If your kernel (which version is it?) doens't inlude the HDAPS driver anyway, you don't need to patch....<br />
<br />
--[[User:Thinker|Thinker]] 09:28, 2 Jan 2006 (CET)<br />
----<br />
<br />
Thanks Thinker.<br />
<br />
1. I discharged and recharged the battery again. This time, it stops at 68% percent, which is pretty good.<br />
<br />
2. I missed the NOTE in README, for I just followed this wiki. :P<br />
<br />
3. My kernel version is 2.6.13-15.<br />
<br />
By the way, I just got this T43 whose model number is 266896U. I feel that the noise of the fan is much louder than my previous T21. I think it is so since it has a CPU with bigger power but am wondering if other T43 has the same big noise?<br />
<br />
--[[User:Tyne|Tyne]] 00:14, 3 Jan 2006 (CET)<br />
----<br />
<br />
The note about PROVIDE_CD_SPEED is also in the Wiki...<br />
<br />
About the T43 fan noise: yes, this is a very common (and annoying) problem. See [[Problem_with_fan_noise]] and our [[ACPI fan control script]], and send Lenovo a complaint in hope they'll fix this at the firmware level.<br />
<br />
--[[User:Thinker|Thinker]] 08:48, 3 Jan 2006 (CET)<br />
----<br />
I spent hours, trying to compile this on ubuntu edgy without success. It starts with warnings about missing files:<br />
<br />
<pre><br />
root@t40:/home/bernd/Desktop/tp_smapi-0.31/tp_smapi-0.31# make install<br />
make -C /lib/modules/2.6.17-11-386/source M=/home/bernd/Desktop/tp_smapi-0.31/tp_smapi-0.31 O=/lib/modules/2.6.17-11-386/build modules<br />
make[1]: Betrete Verzeichnis '/usr/src/linux-source-2.6.17'<br />
/usr/src/linux-source-2.6.17/Makefile:450: .config: No such file or directory<br />
<br />
WARNING: Symbol version dump /lib/modules/2.6.17-11-386/build/Module.symvers<br />
is missing; modules will have no dependencies and modversions.<br />
<br />
CC [M] /home/bernd/Desktop/tp_smapi-0.31/tp_smapi-0.31/thinkpad_ec.o<br />
cc1: error: include/linux/autoconf.h: No such file or directory<br />
[...]<br />
</pre><br />
and then many thousand lines later it finally stops:<br />
<pre><br />
[...]<br />
/home/bernd/Desktop/tp_smapi-0.31/tp_smapi-0.31/thinkpad_ec.c:357: error: ‘CONFIG_HZ’ undeclared (first use in this function)<br />
/home/bernd/Desktop/tp_smapi-0.31/tp_smapi-0.31/thinkpad_ec.c: In function ‘thinkpad_ec_invalidate’:<br />
/home/bernd/Desktop/tp_smapi-0.31/tp_smapi-0.31/thinkpad_ec.c:378: error: ‘CONFIG_HZ’ undeclared (first use in this function)<br />
/home/bernd/Desktop/tp_smapi-0.31/tp_smapi-0.31/thinkpad_ec.c: In function ‘thinkpad_ec_init’:<br />
/home/bernd/Desktop/tp_smapi-0.31/tp_smapi-0.31/thinkpad_ec.c:460: error: ‘CONFIG_HZ’ undeclared (first use in this function)<br />
make[3]: *** [/home/bernd/Desktop/tp_smapi-0.31/tp_smapi-0.31/thinkpad_ec.o] Fehler 1<br />
make[2]: *** [_module_/home/bernd/Desktop/tp_smapi-0.31/tp_smapi-0.31] Fehler 2<br />
make[1]: *** [modules] Fehler 2<br />
make[1]: Verlasse Verzeichnis '/usr/src/linux-source-2.6.17'<br />
make: *** [modules] Fehler 2<br />
</pre><br />
<br />
There must be something fundamentally wrong with the makefile. I have for example never seen that a symlink has to point from /lib/modules/someversion/somewhere to /usr/src/linux. I have installed other modules in the past and they all worked with installed linux-headers package. I didn't ever have to download 40MB kernel source, unpack it, configure it to have a .config and compile the whole kernel just to have 2 or three of the other files needed. This cannot be the correct way to install a driver.<br />
<br />
[[User:7bit|7bit]] 07:42, 27 March 2007 (CEST)<br />
----<br />
<br />
I tried compiling tp_smapi with the module-assistant . However, I cannot see how to add the option HDAPS=1. I edited the Makefile in the source archive of tp_smapi by adding HDAPS:=1 in the beginning of the file, but that didn't work. I get accelerometer readings but hdapsd gives back "open(protect_file): No such file or directory". I'm using ubuntu 9.04 beta, with kernel 2.6.28-11.<br />
<br />
--[[User:Sv3t|Sv3t]] 18:52, 9 April 2009 (UTC)<br />
<br />
== Formatting ==<br />
<br />
Wyrfel, that was some heavy editing you did... I agree with most changes (including the saner color choice). I did like those HINT floats, though - they keep the hints from interrupting the flow of text too much, and this particular text needs any help it can get.<br />
<br />
--[[User:Thinker|Thinker]] 17:04, 3 Jan 2006 (CET)<br />
----<br />
Hei Thinker,<br />
<br />
I'll look into it again. I felt that the floating HINTs were tearing the text apart too much. Maybe we could fix it by placing the clear marks somewhere else.<br />
<br />
[[User:Wyrfel|Wyrfel]] 18:46, 3 Jan 2006 (CET)<br />
----<br />
<br />
== Dual battery operation with tp_smapi ==<br />
<br />
It looks like it is working quite fine with tp_smapi-0.13 and 2.6.15 (it may also work with other versions, but those are the ones I have running right now).<br />
<br />
The juicy details:<br />
<br />
{{cmdroot|cd /sys/devices/platform/smapi/}}<br />
{{cmdroot|cat ac_connected}}<br />
<br />
{{cmdresult|0}}<br />
{{cmdroot|cat BAT{0,1}/state}}<br />
{{cmdresult|discharging}}<br />
{{cmdresult|idle}}<br />
<br />
{{cmdroot|echo 1 > BAT1/force_discharge1}}<br />
{{cmdroot|cat BAT{0,1}/state}}<br />
{{cmdresult|idle}}<br />
{{cmdresult|discharging}}<br />
<br />
Checking capacity values shows that the corrent battery is being depleted.<br />
<br />
And remember, before you yank the CD/DVD drive out, issue:<br />
<br />
{{cmdroot|cat eject > /proc/acpi/ibm/bay}}<br />
<br />
----<br />
<br />
Great! Which ThinkPad model is it? Could you also {{cmdroot|cat /sys/devices/platform/smapi/BAT{0,1}/force_discharge2}} and report the dmesg output (after {{cmdroot|make load}} or {{cmdroot|1=modprobe tp_smapi debug=1}})?<br />
<br />
About the eject command, I think it should be possible to do that automatically when the Ultrabay handle is ejected, via <tt>acpid</tt>.<br />
<br />
--[[User:Thinker|Thinker]] 15:45, 10 Jan 2006 (CET)<br />
----<br />
<br />
It's a T43 (2669). cat'ing force_discharge2 gives me an I/O error and I see<br />
<br />
tp_smapi: cannot get force_discharge2 of battery 0: bx=2103<br />
<br />
tp_smapi: cannot get force_discharge2 of battery 1: bx=2103<br />
<br />
I find these errors irrelevant from the user's point of view, though. <br />
<br />
Indeed, it should be possible to automatise the "eject" command. I should also be noted that once a force_discharge1 is set, it will NOT unset automatically, event when the AC is plugged back in. An obvious fix is to fiddle with the appropriate ACPI event to force_discharge1 back to 0 for all batteries once the AC is attached.<br />
<br />
----<br />
<br />
Thanks, this eliminates the last situation I imagined <tt>force_discharge2</tt> might work. The next tp_smapi version will remove <tt>force_discharge2</tt> and rename <tt>force_discharge1</tt> to <tt>force_discharge</tt>.<br />
<br />
If you write those ACPI scripts, it would be great if you put them on the Wiki.<br />
<br />
--[[User:Thinker|Thinker]] 16:31, 10 Jan 2006 (CET)<br />
----<br />
<br />
Well, I still do not preclude the fact that <tt>force_discharge2</tt> may be useful for something else on other models.<br />
<br />
The ACPI scripts (as well as an installation guide) is underway. It may take a while, though.<br />
<br />
----<br />
<br />
See the new article: [[Using an Ultrabay battery]].<br />
<br />
--[[User:Thinker|Thinker]] 17:05, 10 Jan 2006 (CET)<br />
----<br />
<br />
Hei Thinker,<br />
<br />
i just renamed the new page. Will adjust your links later on. Keeping the redirect page until that's done. Please set any new links you create to the new page (the pages of the individual UltraBay batteries should contain a pointer).<br />
<br />
On a sidenote: I would like to split the SMAPI support under Linux page into a tp_smapi driver page, just listing the features, and a "How to use tp_smapi" page. I would also split the thinkpad/tpctl page off that again. Any objections?<br />
<br />
[[User:Wyrfel|Wyrfel]] 20:42, 10 Jan 2006 (CET)<br />
----<br />
<br />
ACK about the page rename (the old one did sound a bit out of line to my ear, but I couldn't spot why...).<br />
<br />
About the splitting tp_smapi vs. thinkpad/tpctl, no objection.<br />
<br />
About splitting tp_smapi: currently most of that section doubles as both a spec and a HOWTO, which I think is a convenient and concise way to describe things (hey, it must be right, the Perl docs do it!). I'm not sure there's much benefit in duplicating that. Perhaps we should wait for a critical mass of additional lore to accumulate?<br />
<br />
--[[User:Thinker|Thinker]] 21:04, 10 Jan 2006 (CET)<br />
----<br />
Ok, i agree on the latter.<br />
<br />
[[User:Wyrfel|Wyrfel]] 00:57, 11 Jan 2006 (CET)<br />
----<br />
<br />
==Article name capitalization== <br />
<br />
Wikimedia autocapitalizes the article name upon submit. How do I concince Wikimedia that I really want a lowercase "t"? The underline is probably too much too ask...<br />
<br />
--[[User:Thinker|Thinker]] 11:03, 11 Jan 2006 (CET)<br />
----<br />
<br />
Impossible, according to [http://en.wikipedia.org/wiki/Wikipedia:Canonicalization Wikipedia:Canonicalization].<br />
<br />
--[[User:Thinker|Thinker]] 12:04, 11 Jan 2006 (CET)<br />
----<br />
<br />
Look at how Mozilla folks took care of it: http://kb.mozillazine.org/About:config<br />
<br />
--[[User:Domicius|domicius]] 00:33, 29 Sep 2008 (CET)<br />
----<br />
<br />
==Status Table==<br />
For at least the T series i think that charge control was not supported prior to the T42, hardware/BIOS side. Perhaps "N/A" flags would be better here?<br />
<br />
I also created <nowiki>{{Isup}}</nowiki> style templates for status, they just include images, like {{Isup}}.<br />
Not emotional about it, just wanted to let you know in case you want to use them.<br />
<br />
Third and last...would it possibly be better to make the table headers more human readable like i.e. "lower charge threshold" or something like that instead of "start_charge_thresh"?<br />
<br />
[[User:Wyrfel|Wyrfel]] 19:21, 11 Jan 2006 (CET)<br />
----<br />
<br />
About "N/A", sure, if we get reliable data about the hardware capabilities. Alas, most negative reports were just "it doesn't work", and in some cases gave contradictory information (SMAPI interface says a function is unsupported but user says it works under Windows).<br />
<br />
About {{Iyes}} and friends, they're very cute, but I think think they're harder to parse visually and would add some clutter to an already dense table.<br />
<br />
The table headers are just the names of the control files - that's important to keep, sine it's the most natural lookup key. Adding friendly description would be great, if we can fit them in (not everyone has an SXGA+ display...). I tried and failed.<br />
<br />
--[[User:Thinker|Thinker]] 20:38, 11 Jan 2006 (CET)<br />
----<br />
<br />
I have a T41p and the windows tools still don't offer me battery management, even though it's quite a while since the T42 came out.<br />
<br />
I'm ok with the rest.<br />
<br />
[[User:Wyrfel|Wyrfel]] 22:35, 11 Jan 2006 (CET)<br />
----<br />
<br />
For the {{X40}}, I can report success using the stop_charge_thresh feature with BIOS v2.03 (1UETC8WW) and Embedded Controller Program v1.60 (1UHTB0WW).<br />
<br />
[[User:Peterco|Peterco]] 12:07, 28 February 2006 (CET)<br />
----<br />
<br />
[[User:roam|roam]] 13:43, 11 January 2008 (CET)<br />
<br />
I need invert=1 for hdaps. The additional invert parameters (2-7) didn't work for me with tp_smapi 0.33. They work with 0.34.<br />
<br />
== Z60t ==<br />
<br />
Tested on Z60t. No errors using cat. Setting thresholds works. Status and capacity queries work. --[[User:Alon|Alon]] 21:44, 4 May 2006 (CEST)<br />
<br />
== Problem setting thresholds with X40 ==<br />
<br />
My X40, kernel 2.6.16 and tp_smapi 0.20. I try to set the thresholds to 40% and 90% using:<br />
<pre><br />
# echo 90 > stop_charge_thresh<br />
# echo 40 > start_charge_thresh<br />
</pre><br />
which should work, and the kernel reports from dmesg:<br />
<pre><br />
tp_smapi: successfully loaded (smapi_port=0xb2).<br />
tp_smapi: battery 0: changed start threshold to 85(+1)<br />
tp_smapi: battery 0: changed stop threshold to 90<br />
tp_smapi: battery 0: changed start threshold to 39(+1)<br />
</pre><br />
but, on confirmation here is what happens:<br />
<pre><br />
# cat stop_charge_thresh<br />
90<br />
# cat start_charge_thresh<br />
91<br />
</pre><br />
Any clues as to why start doesn't keep? Or why its always at 1 above stop_charge_thresh?<br />
<br />
--[[User:Xmm0|Xmm0]] 15:01, 17 May 2006 (CEST)<br />
----<br />
<br />
Is it any different if you first set start_charge_thresh and then stop_charge_thresh? <br />
<br />
Can you please load tp_smapi with module option "debug=1" and report the dmesg output genereated by each command?<br />
<br />
--[[User:Thinker|Thinker]] 16:31, 17 May 2006 (CEST)<br />
----<br />
<br />
== Battery daemon feedback requested ==<br />
<br />
I am writing a battery-management daemon to control charging and discharging BAT0 and BAT1 in accordance with usage patterns that extend Li-Ion and Li-Py battery life.<br />
<br />
By default, the machine fully discharges BAT1 first, and it is said that deep-cycling all the time dramatically shortens their lifetime.<br />
<br />
My Z61t is the test machine, and it is configured with two batteries, the stock 4-cell, and an "Advanced Ultrabay", which about doubles the runtime of the machine.<br />
<br />
Currently there are two "modes" of the daemon:<br />
<br />
Discharging mode.<br />
<pre><br />
* look at the "remaining_percent" values for both batteries<br />
* if one is more than THRESHOLD percent less than the other one, <br />
force discharge from the battery with more capacity left<br />
(the current value for THRESHOLD is 10%)<br />
</pre><br />
I believe the preceeding will prevent either battery from being deep-cycled disproportionately.<br />
<br />
Charging mode. I am less sure what the "right" algorithm is here. The following is a proposal.<br />
<pre><br />
* look at the "remaining_percent" values for both batteries<br />
* if one is more than THRESHOLD percent less than the other one, <br />
force charging to the battery with less capacity left<br />
* honor pre-set values in stop_charge_thresh and start_charge_thresh<br />
</pre><br />
<br />
I would like to get feedback in the form of "better" algorithms or requests for this daemon.<br />
<br />
--[[User:Zak Smith|Zak]] 19:03, 12 September 2006 (CEST)<br />
<br />
It sounds like your algorithm will indeed minimize wear on both batteries. A side benefit is that charging will toggle between the batteries, which may help keep them cooler while charging and thus prolong their life. OTOH, if you plan to occasionally swap the UltraBay battery for other devices, you may want to fully charge the system battery (up to stop_charge_thresh) first.<br />
<br />
--[[User:Thinker|Thinker]] 22:57, 12 September 2006 (CEST)<br />
<br />
<br />
I have noticed that when force_discharge is set and the batteries switch, the gnome battery monitoring applet gets totally confused about remaining runtime. Besides being a nuisance, this could presumably cause premature emergency shutduwn.<br />
<br />
I have also noticed that the reported remaining runtimes vary greatly between acpi, the applet, and /proc/acpi/battery/*/state<br />
<br />
--[[User:Zak Smith|Zak]] 21:46, 14 September 2006 (CEST)<br />
<br />
What do you mean by "acpi" vs. "/proc/acpi/battery/*/state"? <br />
<br />
The most accurate readout is probably {{path|/sys/devices/platform/smapi/BAT0/remaining_running_time}}, but I don't think any applet uses that yet.<br />
<br />
--[[User:Thinker|Thinker]] 12:07, 15 September 2006 (CEST)<br />
<br />
By acpi, I meant the output of the acpi (1) command. I'll get some comparative numbers later and post them here.<br />
<br />
--[[User:Zak Smith|Zak]] 20:37, 15 September 2006 (CEST)<br />
<br />
Odd, my version of {{path|/usr/bin/acpi}} doesn't report remaining time, just percent (which is the same as {{path|/sys/devices/platform/smapi/BAT0/remaining_percent}}).<br />
<br />
--[[User:Thinker|Thinker]] 21:32, 15 September 2006 (CEST)<br />
<br />
I have been running batteryd for a while with good results. I will upload it here shortly.<br />
<br />
I disabled the preferential charging mode, and only control discharging.<br />
<br />
--[[User:Zak Smith|Zak]] 23:15, 14 November 2006 (CET)<br />
<br />
http://demigod.org/~zak/src/batteryd.cc<br />
<br />
--[[User:Zak Smith|Zak]] 20:18, 5 December 2006 (CET)<br />
<br />
Have you developed this further since then? I just got my first dual-battery-setup for my Z60m. Anyway, it says it doesn't support hotplugging the battery? What does this mean? Do things break if I change batteries or switch a DVD drive to the ultrabay slot while it's running? <br />
<br />
Anyway, I deciphered your source code enough that it basically seems to poll the stuff under /sys/devices/platform/BAT?/* every 10 seconds. Anyway, I don't see what's so tough about hotswapping - the BAT1 directory does not seem to vanish either by issuing echo 1 > /sys/devices/platform/bay.0/eject or just yanking it out. The /sys/devices/platform/BAT1/installed goes to zero though.<br />
<br />
Can you add a check to the condition if (b0->on_ac == 0) ...change this to<br />
<br />
if ((b0->on_ac == 0) && (b0->installed == 1) && (b1->installed == 1))<br />
<br />
then the equal discharging logic would handle hotswapping too (ie. situations where you're running only on 1 battery instead of 2). <br />
<br />
I hope you keep on honing this.<br />
<br />
One of the few things I miss from Dell is that when operating with dual batteries, it discharges both of them evenly.<br />
<br />
--[[User:Zarhan|Zarhan]] 18:31, 13 May 2007 (CEST)<br />
<br />
== Instructions for X60 with Bios 1.11 under Debian Etch ==<br />
<br />
Could someone please provide step-by-step instructions of how to make this work with Debian? What have I to do after apt-get install kernel-patch-tpsmapi? Thank you!<br />
<br />
--[[User:PeterBursch|PeterBursch]] 21:39, 15 September 2006 (CEST)<br />
<br />
== tp_smapi 0.30 with kernel 2.6.20? ==<br />
<br />
<pre>T60:~/tp_smapi-0.30# uname -rm<br />
2.6.20 x86_64<br />
<br />
T60:~/tp_smapi-0.30# make load<br />
if lsmod | grep -q '^hdaps '; then rmmod hdaps; fi<br />
if lsmod | grep -q '^tp_smapi '; then rmmod tp_smapi; fi<br />
if lsmod | grep -q '^thinkpad_ec '; then rmmod thinkpad_ec; fi<br />
if lsmod | grep -q '^tp_base '; then rmmod tp_base; fi # old thinkpad_ec<br />
make -C /lib/modules/2.6.20/source M=/root/tp_smapi-0.30 O=/lib/modules/2.6.20/build modules<br />
make[1]: Entering directory `/usr/src/linux-2.6.20'<br />
CC [M] /root/tp_smapi-0.30/thinkpad_ec.o<br />
/root/tp_smapi-0.30/thinkpad_ec.c:83: warning: type defaults to 'int' in declaration of 'DECLARE_MUTEX'<br />
/root/tp_smapi-0.30/thinkpad_ec.c:83: warning: parameter names (without types) in function declaration<br />
/root/tp_smapi-0.30/thinkpad_ec.c: In function 'thinkpad_ec_lock':<br />
/root/tp_smapi-0.30/thinkpad_ec.c:94: warning: implicit declaration of function 'down_interruptible'<br />
/root/tp_smapi-0.30/thinkpad_ec.c:94: error: 'thinkpad_ec_mutex' undeclared (first use in this function)<br />
/root/tp_smapi-0.30/thinkpad_ec.c:94: error: (Each undeclared identifier is reported only once<br />
/root/tp_smapi-0.30/thinkpad_ec.c:94: error: for each function it appears in.)<br />
/root/tp_smapi-0.30/thinkpad_ec.c: In function 'thinkpad_ec_try_lock':<br />
/root/tp_smapi-0.30/thinkpad_ec.c:109: warning: implicit declaration of function 'down_trylock'<br />
/root/tp_smapi-0.30/thinkpad_ec.c:109: error: 'thinkpad_ec_mutex' undeclared (first use in this function)<br />
/root/tp_smapi-0.30/thinkpad_ec.c: In function 'thinkpad_ec_unlock':<br />
/root/tp_smapi-0.30/thinkpad_ec.c:122: warning: implicit declaration of function 'up'<br />
/root/tp_smapi-0.30/thinkpad_ec.c:122: error: 'thinkpad_ec_mutex' undeclared (first use in this function)<br />
make[3]: *** [/root/tp_smapi-0.30/thinkpad_ec.o] Error 1<br />
make[2]: *** [_module_/root/tp_smapi-0.30] Error 2<br />
make[1]: *** [modules] Error 2<br />
make[1]: Leaving directory `/usr/src/linux-2.6.20'<br />
make: *** [modules] Error 2<br />
</pre><br />
<br />
:Works here with 2.6.21-rc1 (didn't try 2.6.20) without problems --[[User:Zhenech|Zhenech]] 14:32, 22 February 2007 (CET)<br />
<br />
:I have this problem when compiling for x86_64 too. It seems to be limited to 64bit kernels though. I've notified the author of tp_smapi about it, so lets hope a solution is found soon. --[[User:Esmil|Esmil]] 20:08, 6 March 2007 (CET)<br />
<br />
The author was happy about the report, but didn't have time too look at it right now, so I thought I'd give it my best shot. Apparently I should have done that sooner, cause this seems to fix it (for me at least):<br />
<pre><br />
diff -Naur tp_smapi-0.30/hdaps.c tp_smapi-0.30-64bit_fix/hdaps.c<br />
--- tp_smapi-0.30/hdaps.c 2006-09-03 12:13:34.000000000 +0200<br />
+++ tp_smapi-0.30-64bit_fix/hdaps.c 2007-03-07 00:43:26.000000000 +0100<br />
@@ -34,6 +34,7 @@<br />
#include <linux/timer.h><br />
#include <linux/dmi.h><br />
#include <linux/thinkpad_ec.h><br />
+#include <linux/jiffies.h><br />
<br />
/* Embedded controller accelerometer read command and its result: */<br />
static const struct thinkpad_ec_row ec_accel_args =<br />
diff -Naur tp_smapi-0.30/thinkpad_ec.c tp_smapi-0.30-64bit_fix/thinkpad_ec.c<br />
--- tp_smapi-0.30/thinkpad_ec.c 2006-09-02 21:46:18.000000000 +0200<br />
+++ tp_smapi-0.30-64bit_fix/thinkpad_ec.c 2007-03-07 00:43:13.000000000 +0100<br />
@@ -34,6 +34,7 @@<br />
#include <linux/delay.h><br />
#include <linux/thinkpad_ec.h><br />
#include <linux/jiffies.h><br />
+#include <asm/semaphore.h><br />
#include <asm/io.h><br />
<br />
#define TP_VERSION "0.30"<br />
</pre><br />
Copy the above to {{path|64bit_fix.patch}}, enter the {{path|tp_smapi-0.30}} directory and type<br />
:{{cmduser|patch -p1 < /path/to/64bit_fix.patch}}<br />
Now cross your fingers and compile as normal.<br />
--[[User:Esmil|Esmil]] 01:06, 7 March 2007 (CET)<br />
: tp_smapi 0.31 fixes this issue --[[User:Esmil|Esmil]] 19:22, 8 March 2007 (CET)<br />
<br />
== X60: tp_smapi 0.31 with kernel 2.6.20 issue ==<br />
[[category:X60]]<br />
1st of all: Thanks alot for your work. I do really appreciate this (tp_smapi/thinkwiki).<br />
<br />
2nd: On a Debian (testing) w/ vanilla 2.6.20+tp_smapi+hdaps (w/ modules loaded) the kernel panics (init oops) on reboot just before resetting the system. It has a minor impact, you need to press power-off for 5 secs to switch off the machine. Just FYI.<br />
<br />
--[[User:Runia|Runia]] 23:48, 16 April 2007 (CEST)<br />
<br />
Is this consistently reproducible? What's the oops message and stackdump (you can snap a digicam shot)? Does this happen when...<br />
* rebooting with tp_smapi loaded but hdaps not loaded?<br />
* rebooting with neither tp_smapi nor hdaps loaded?<br />
* rebooting with vanilla hdaps loaded (instead of the tp_smapi version)?<br />
* removing just these modules ("rmmod") instead of rebooting?<br />
<br />
--[[User:Thinker|Thinker]] 01:56, 17 April 2007 (CEST)<br />
----<br />
<br />
Hey Thinker,<br />
Sorry, failed to follow the thread. Didn't pay attention to that bug any more. Skipped use of smapi on next kernel release for some reason. IRC, the panic could be prevented running the kernel w/o hdaps loaded.. hdaps didn't work out correctly for me anyway..<br />
<br />
Cheers,<br />
<br />
--[[User:Runia|Runia]] 16:05, 15 February 2008 (CET)<br />
<br />
== battery start/stop thresholds saved after reboot? ==<br />
<br />
Hi<br />
<br />
Are the values in stop_charge_thresh and start_charge_thresh just used when Linux is running, or are they saved in the battery? Here after a reboot the values are reset to 96/100. I set these values to 40/85 shut the thinkpad down and charged the battery - sadly it did not use the 85% setting and charged the battery to 100%.<br />
<br />
--[[User:Burp|Burp]] 15:31, 13 March 2007 (CET)<br />
----<br />
<br />
The thresholds are saved in the embedded controller, which keeps them as long as there is AC or battery power. If you take away both, the state is reset. If you use suspend-to-disk, tp_smapi will remember the threholds and restore them during resume; but you'll need to write your own init script to set the thresholds during normal reboot after full power loss.<br />
<br />
--[[User:Thinker|Thinker]] 16:19, 13 March 2007 (CET)<br />
----<br />
<br />
Under Ubuntu, you can set the thresholds under {{path| /etc/default/tpsmapi-utils}}.<br />
<br />
START_CHARGE_THRESH_BAT0=40<br />
#START_CHARGE_THRESH_BAT1=40<br />
<br />
STOP_CHARGE_THRESH_BAT0=95<br />
#STOP_CHARGE_THRESH_BAT1=70<br />
----<br />
<br />
If I set the value, plug in in the power cord to charge it after I have shut down the thinkpad, it will charge to 100%?<br />
So I have to plug in the power cord while the thinkpad is running and then shut it down to make it work?<br />
--[[User:Burp|Burp]] 17:45, 15 March 2007 (CET)<br />
----<br />
<br />
Changes take effect immediately, and last as long as the machine has any power source (battery or AC).<br />
<br />
--[[User:Thinker|Thinker]] 18:59, 15 March 2007 (CET)<br />
----<br />
<br />
I've experienced the same problem. When I poweroff my X60 after setting the thresh-values and then reboot it, the values are set to 96/100. If I want the thresholds to be regarded I have to plug in the power cord when the thinkpad is running and then shut it down. If I turn it off before connect it to AC, the values are ignored. <br />
So, are the values only saved in standby-mode? This isn't clear for me, and I think I'm not alone with it ;)<br />
<br />
--[[User:Alexb|Alexb]] 20:56, 15 March 2007 (CET)<br />
<br />
The values are not '''saved''' anywhere. They are set on the EC, and as long as the EC is kept powered on and not rebooted, they are retained. Sleep cycles and reboots on the main machine do not affect the EC. An EC firmware upgrade reboots the EC. Powering off the ThinkPad while it is on battery also powers down the EC. The ThinkPad does not power down the EC while on AC (it has to be powered up to charge the batteries).<br />
<br />
I hope that answered all your doubts...<br />
<br />
--[[User:Hmh|hmh]] 04:45, 28 March 2007 (CEST)<br />
<br />
On my x61s, these values are remembered after powering off the ThinkPad while it is on battery. I didn't try to remove the battery. But it looks like the x61s behaves as Thinker described, not as Hmh did.<br />
<br />
--[[User:Jannic|Jannic]] 13:58, 3 November 2007 (UTC)<br />
<br />
Curious. That would mean the x61s does not power off the EC even while on battery and powered off, or that it is storing the SMAPI thresholds away in CMOS. Care to test it? If you want to check that theory, just hexdump /dev/nvram, change a threshold, than hexdump it again...<br />
<br />
--[[User:Hmh|hmh]] 12:09, 11 November 2007 (UTC)<br />
<br />
Seems like it's the former choice: I didn't see any nvram changes after changing the thresholds. Shutting down the system while on battery does not reset thresholds. Shutting down while on battery and then removing the battery does reset them to start_charge_threshold=96, stop_charge_threshold=100, though. I guess they put the EC in some low-power sleep mode while the notebook is turned off and on battery. The specs linked from [[Embedded_Controller_Chips]] list sleep mode currents below 5µA, which is probably negligible compared to self-discharge of Li-Ion batteries.<br />
<br />
--[[User:Jannic|Jannic]] 14:36, 12 November 2007 (UTC)<br />
<br />
== stop_charge_thresh on t42p ==<br />
<br />
Hi,<br />
<br />
'cat /sys/devices/platform/smapi/BAT0/stop_charge_thres' does not work. I get:<br />
'Function not implemented'. Under windows the ibm tool shows me both thresholds. I am using tp_smapi version 0.31 with kernel 2.6.20 (ubuntu feisty).<br />
<br />
----<br />
<br />
Same problem, I want to know what I can do to help figure out why this works in windows and not with tp_smapi.<br>I am running tp_smapi 0.32 on 2.6.20 Ubuntu Feisty (7.04)<br>Here is the debug output from tp_smapi.<br><br />
{{cmdroot|echo 30 > /sys/devices/platform/smapi/BAT0/start_charge_thresh}}<br><br />
{{cmdroot|dmseg}}<br />
<pre>[68311.752000] smapi smapi: smapi_request: req_in: BX=211a CX=100 DI=0 SI=0<br />
[68311.812000] smapi smapi: smapi_request: req_out: AX=8680 BX=211a CX=100 DX=b2 DI=0 SI=0 r=-38<br />
[68311.812000] smapi smapi: smapi_request: SMAPI error: Function is not supported by SMAPI BIOS (func=211a)<br />
[68311.812000] smapi smapi: __get_real_thresh: cannot get stop_thresh of bat=0: Function is not supported by SMAPI BIOS<br />
[68311.812000] smapi smapi: smapi_request: req_in: BX=2116 CX=100 DI=0 SI=0<br />
[68311.868000] smapi smapi: smapi_request: req_out: AX=80 BX=2116 CX=31d DX=b2 DI=0 SI=0 r=0<br />
[68311.868000] smapi smapi: smapi_request: req_in: BX=2117 CX=11d DI=0 SI=0<br />
[68311.924000] smapi smapi: smapi_request: req_out: AX=80 BX=2117 CX=11d DX=b2 DI=0 SI=0 r=0<br />
[68311.924000] smapi smapi: set_real_thresh: set start to 29 for bat=0</pre><br />
{{cmdroot|echo 85 > /sys/devices/platform/smapi/BAT0/stop_charge_thresh}}<br><br />
{{cmdroot|dmesg}}<br />
<pre>[68385.652000] smapi smapi: smapi_request: req_in: BX=2116 CX=100 DI=0 SI=0<br />
[68385.708000] smapi smapi: smapi_request: req_out: AX=80 BX=2116 CX=31d DX=b2 DI=0 SI=0 r=0<br />
[68385.708000] smapi smapi: smapi_request: req_in: BX=211a CX=100 DI=0 SI=0<br />
[68385.764000] smapi smapi: smapi_request: req_out: AX=8680 BX=211a CX=100 DX=b2 DI=0 SI=0 r=-38<br />
[68385.764000] smapi smapi: smapi_request: SMAPI error: Function is not supported by SMAPI BIOS (func=211a)<br />
[68385.764000] smapi smapi: __get_real_thresh: cannot get stop_thresh of bat=0: Function is not supported by SMAPI BIOS</pre><br />
<p><br />
<br />
--[[User:Airbornespent|Airbornespent]] 16:18, 13 August 2007 (UTC)<br />
----<br />
<br />
Looks like the T42(p) is using a different SMAPI interface for the stop threshold. For example, it could be using the same interface as inhibit_charge_minutes_interface, and monitoring the charge levels manually. Maybe you can use a debugger (e.g., SoftICE) to find out what SMAPI calls are made when you change the thresholds under Windows.<br />
<br />
--[[User:Thinker|Thinker]] 17:40, 13 August 2007 (UTC)<br />
----<br />
<br />
What BIOS and EC version? If a T42/p is doing this, all the T4X but the two T43 types should also suffer the same problem... Not to mention a bunch of R5x models, etc (BIOS TP-1R).<br />
<br />
--[[User:Hmh|hmh]] 23:17, 13 August 2007 (UTC)<br />
----<br />
<br />
This is copy and pasted from the DMI info I put on the DMI list page yesterday:<br />
1RETDPWW (3.21 ) 06/02/2006 Handle 0x0029, DMI type 11, 5 byte String 1: IBM ThinkPad Embedded Controller -[1RHT71WW-3.04 ]-<br />
<br />
I just noticed that the T40 through the T42p use this EC model. The T43s are different. No one with a T40-T42 has claimed success with the stop_charge_thresh on the tp_smapi status table.<br />
<br />
I will try to get windows on a harddrive and pop it in my t42p to use softICE or whatever debuggers soon.<br />
<br />
--[[User:Airbornespent|Airbornespent]] 15:39, 15 August 2007 (UTC)<br />
----<br />
<br />
I've installed windows, I can again confirm that the start and stop thresholds work with the maximiser. I couldn't seem to find softICE but I got a debugger called syser. I have no clue what I should be looking for though, a certain set of CPU calls, addresses, etc? Any advice would be great. If you are more familiar with softICE I will find and install that.<br />
<br />
I just had an idea though. Maybe I can set the thresholds to known values in windows, and then reboot to linux without removing the AC, then the thresholds would be saved on the EC. Is there then a way I can dump the settings in linux and if I do this with several known thresholds that might be enough information to figure this out?<br />
<br />
--[[User:Airbornespent|Airbornespent]] 19:48, 15 August 2007 (UTC)<br />
----<br />
<br />
You need to trace the SMAPI calls made when the thresholds are changed. You can look at tp_smapi.c or the vanilla kernel drivers/char/mwave/smapi.c to see how SMAPI work. Basically, the parameters are loaded into registers, with the SMAPI function code in register EBX. Then, a byte is written to IO ports 0xB2 and 0x4F. The write to port 0xB2 invokes the BIOS SMAPI code in SMM mode. So the first thing to check is what SMAPI functions are called, i.e., the value of EBX before each wrote to port 0xB2. You can see some of the known codes in the SMAPI_* constants near the top of smapi.c.<br />
<br />
--[[User:Thinker|Thinker]] 21:57, 15 August 2007 (UTC)<br />
----<br />
<br />
== Does smapi interface include communication with eeprom? ==<br />
<br />
There exists a windows program (which I haven't tracked down yet) which will reset the eeprom in the battery to clear an error. Could the smapi interface do the same?<br />
<br />
Or are there other ways to do this? I have a relatively new battery (< 10 cycles) with all my tests showing the cells are fine, but since it reports "damage" to the thinkpad, it won't charge it.<br />
<br />
----<br />
<br />
No. Can you provide a link to that Windows program and (more important) information about how it works?<br />
<br />
--[[User:Thinker|Thinker]] 02:17, 25 June 2007 (UTC)<br />
----<br />
<br />
Acc plus v1.3 [http://www.microsys.ro/accplus.htm] communicates over SMBus via a parallel port adapter. It says it can reset the eeprom via direct connection to the chip. But version 1.4 claims to be able to reset the chip via SMBus. I haven't verified this claim because only v1.3 is available for download. But I figured anything that can be done via the parallel port adapter ought to be able to be done natively by the thinkpad.<br />
<br />
The Smart Battery Workshop also claims to be able to reset the eeprom. This is the program that is hard to track down because all the links you find are broken. I finally found it by searching for "smart battery workshop" on download.com [http://download.com]. They use those random urls so I can't post a direct link.<br />
<br />
In summary: mostly these programs are just a way to communicate with the battery over SMBus using a parallel port. But there's the tantalizing claims of being able to reset the chip too....<br />
<br />
--[[User:Kdnelson|Kdnelson]] 03:14, 3 August 2007 (UTC)<br />
----<br />
<br />
If I read this correctly, both AccPlus and Smart Battery Workshop require you to take out the battery and communicate with it via a parallel-to-SMBus adapter. This is out of scope for tp_smapi. AccSmart probably uses the Smart Battery interface through the laptop's internal SMBus bus; this is already supported by Linux's smart battery drivers, but doesn't work on ThinkPads since we don't know of any way the CPU can directly access the SMBus.<br />
<br />
--[[User:Thinker|Thinker]] 13:56, 3 August 2007 (UTC)<br />
----<br />
<br />
== kernel 2.6.24 compatibility ==<br />
<br />
Version 0.32 of tp_smapi seems to be incompatible with the prereleases of 2.6.24. Does anybody know if there are updated patches available?<br />
<br />
--[[User:Jannic|Jannic]] 13:13, 1 November 2007 (UTC)<br />
<br />
Update: It were the renames of BIT() to BIT_MASK in commit 7b19ada2ed3c1eccb9fe94d74b05e1428224663d which did not<br />
apply cleanly to my tp_smapi patched tree. This looks like a minor change which should be fixable easily.<br />
<br />
--[[User:Jannic|Jannic]] 13:58, 3 November 2007 (UTC)<br />
----<br />
<br />
== t400 data ==<br />
<br />
Version .40, ubuntu kernel 2.6.27-9. bios version 1.18,ec version 1.01<br><br />
HDAPS needs both X and Y inversion. <br><br />
Battey testing will take awhile more. <br><br />
[[User:Mrthefter|Mrthefter]] 18:58, 20 December 2008 (CET)<br />
<br />
== gnome-power-management support ==<br />
<br />
It would be nice to have tp smapi support in g-p-m. If anyone interested please 'vote' (i.e. cc) for [http://bugzilla.gnome.org/show_bug.cgi?id=533553 feature bug]. [[User:Uzytkownik|Uzytkownik]] 00:31, 14 January 2009 (CET)<br />
<br />
<br />
OK - there it is! (for gnome-power-manager-2.22.1 and gnome-power-manager-2.24.4)<br />
* For all gentoo users: you can use this [http://projects.implicits.de/gentoo/implicit.xml Overlay].<br />
* For users with rpm System: the [http://projects.implicits.de/_archive/gnome-power-manager/gnome-power-manager-2.22.1-r1.x86_64.rpm rpm-file] has not been tested!!<br />
* For dpkg Users: the [http://projects.implicits.de/_archive/gnome-power-manager/gnome-power-manager_2.22.1-1_amd64.deb deb-file] has not been tested!!<br />
* For all the other Users: You have to patch your gnome-power-manager. Patch can be found [http://projects.implicits.de/gentoo/gnome-extra/gnome-power-manager/files/gnome-power-manager-2.22.1.smapi.patch here]<br />
<br />
The precompiled Packages are compiled with -march=core2 (gcc-4.3.3)<br />
<br />
Note: user rights of sysfs files have to be changed. you can use the following udev rules, to do so.<br />
<br />
<pre><br />
DRIVER=="smapi", RUN+="/bin/sh -c 'find /sys/devices/platform/smapi/ -name force_discharge | xargs /bin/chmod 666'"<br />
DRIVER=="smapi", RUN+="/bin/sh -c 'find /sys/devices/platform/smapi/ -name start_charge_thresh | xargs /bin/chmod 666'"<br />
DRIVER=="smapi", RUN+="/bin/sh -c 'find /sys/devices/platform/smapi/ -name stop_charge_thresh | xargs /bin/chmod 666'"<br />
</pre><br />
<br />
Have phun ;)<br />
<br />
Edit: Support for more than one battery (only on start and stop threshs) will be included later - i'm busy this time, sry.<br />
<br />
== SL Series ==<br />
Unfortunately I did not succeed in installing HDSAP support on my SL 500, both tp_smapi and hdaspd report a device problem (although my harddisk is supported: Model=FUJITSU MHZ2320BH G1, FwRev=0084000A)<br />
<br />
linux-blu3:/home/quentin # modprobe tp_smapi hdaps<br />
FATAL: Error inserting tp_smapi (/lib/modules/2.6.31.12-0.2-desktop/updates/tp_smapi.ko): No such device<br />
linux-blu3:/home/quentin # hdapsd -f -d sda<br />
Tue May 25 10:15:53 2010: Starting hdapsd<br />
Tue May 25 10:15:53 2010: Forcely enabled UNLOAD for sda<br />
Tue May 25 10:15:53 2010: Could not find a suitable interface<br />
<br />
Support is highly appreciated! Thanks!<br />
<br />
~~user~~</div>Denisqhttps://www.thinkwiki.org/w/index.php?title=Talk:Tp_smapi&diff=48640Talk:Tp smapi2010-05-25T08:19:37Z<p>Denisq: </p>
<hr />
<div>== Feedback ==<br />
<br />
Great, great work! Really! This completely rocks. I just stopped my battery from charging at 77% and restarted charging a bit later, no problems whatsoever. BTW, this is on kernel 2.6.14.3.<br />
<br />
--[[User:Spiney|spiney]] 21:25, 5 Dec 2005 (CET)<br />
----<br />
None of the fuctions is working on my T40, kernel 2.6.14-mm2.<br />
<br />
--[[User:Lammic|lammic]], 2005.12.05<br />
<br />
Works for me on a T41 running 2.6.12-10-686 (Ubuntu 5.10).<br />
<br />
--[[User:berndtnm|berndtnm]], 2005.12.06<br />
<br />
Including stop_charge_thresh? That one seems to be missing on the T42p.<br />
<br />
--[[User:Thinker|Thinker]] 00:46, 7 Dec 2005 (CET)<br />
----<br />
<br />
tp_smapi works just fine on an R52 with Ubuntu Breezy stock kernel.<br />
<br />
--[[User:Micampe|Micampe]] 12:52, 7 Dec 2005 (CET)<br />
<br />
----<br />
<br />
''To set the thresholds for starting and stopping battery charging (in percent of current capacity):''<br />
<br />
'''current''' really? That'd be weird, I'd expect it to be percent of '''total''' capacity.<br />
<br />
--[[User:Micampe|Micampe]] 14:39, 7 Dec 2005 (CET)<br />
<br />
"Current full charge capacity", as opposed to "current remaining capacity" or "designed full charge capacity"...<br />
<br />
--[[User:Thinker|Thinker]] 15:05, 7 Dec 2005 (CET)<br />
----<br />
<br />
Battery features don't work with my T41p. I can't check this with windows. Can anybody try these features?<br />
<br />
-- Nils, 7 Dec 2005<br />
----<br />
<br />
Nils, does cdrom_speed work for you on the T41p? Could you provide the details requested in the README (dmesg etc.)?<br />
<br />
--[[User:Thinker|Thinker]] 21:57, 7 Dec 2005 (CET)<br />
----<br />
<br />
CDRom Speed seems to work. (I see no warnings, but I have to do a speed test.) Now, I've send all outputs to the email-address in the readme.<br />
<br />
-- Nils, 8 Dec 2005<br />
----<br />
<br />
All the features except the stop_charge_thresh seem to work here on a t42p. <br />
One note, the start_charge_thresh seems to really be stop_charge_thresh. Ie, If I set that to lower than my current battery %, it will never charge, <br />
and if I set it to 100 the battery charges all the way. <br />
<br />
--[[User:Nirik|Nirik]] 16 Dec 2005<br />
----<br />
<br />
Nirik, "all the features" as of which version? For example, do the force_discharge{1,2} in tp_smapi 0.12 also work for you? See the table in the article page. About start_charge, that's odd. Can you send me a log of what you did, what was the result a what was the dmesg output for each operation?<br />
<br />
--[[User:Thinker|Thinker]] 14:16, 16 Dec 2005 (CET)<br />
----<br />
<br />
System T40p:<br />
<br />
<pre><br />
fairlight:/sys/devices/platform/smapi/BAT0# echo 1 > /sys/devices/platform/smapi/BAT0/force_discharge1<br />
fairlight:/sys/devices/platform/smapi/BAT0# echo 1 > /sys/devices/platform/smapi/BAT0/force_discharge2<br />
fairlight:/sys/devices/platform/smapi/BAT0# dmesg <br />
tp_smapi: req_in: BX=2118 CX=100 DI=0 SI=0<br />
tp_smapi: req_out: AX=8680 BX=2118 CX=100 DX=b2 DI=0 SI=0 ret=-38<br />
tp_smapi: SMAPI error: Function is not supported by SMAPI BIOS (func=2118)<br />
tp_smapi: cannot get force_discharge1 of battery 0: Function is not supported by SMAPI BIOS<br />
tp_smapi: req_in: BX=2104 CX=100 DI=0 SI=0<br />
tp_smapi: req_out: AX=80 BX=2103 CX=100 DX=78 DI=0 SI=0 ret=0<br />
tp_smapi: cannot get force_discharge2 of battery 0: bx=2103<br />
</pre><br />
<br />
So it seems force_discharge1 is not supported at all. But force_discharge2? By the way, i think wiki is a _very_ good idea for collecting information, but not for discussion. I would prefer a maillinglist. We can use sourceforge.<br />
<br />
--[[User|StefanSchmidt]]<br />
<br />
force_discharge2 is indicating a real error condition (bx=2103 which has bit 0x02 on), but I have no idea what the error is or how to fix it. Sorry. If you can trigger this function under Windows and have SoftICE or equivalent, maybe it can be worked out.<br />
<br />
About the Wiki discussion, I'm not sure a mailing list is justified yet, but you can use the linux-thinkpad list or the e-mail address in the README. <br />
<br />
--[[User:Thinker|Thinker]] 21:42, 16 Dec 2005 (CET)<br />
<br />
OK, then i use linux-thinkpad to get more people involved. I'am away the next weeks, but i hope to find some time to hacking on tp_smapi.<br />
<br />
--[[User:StefanSchmidt]]<br />
----<br />
<br />
Someone reported cd_speed works on T42 but on mine, it doesn't: this is 2378DXU<br />
<br />
--[[User:eBug]] 22:55, 17 Dec 2005 (CET)<br />
----<br />
<br />
eBug, how does it fail? If the file doesn't exist, it means you didn't enable PROVIDE_CD_SPEED (see the README). If it does exist, can you provide the dmesg output when you read an write to the file?<br />
<br />
--[[User:Thinker|Thinker]] 11:53, 18 Dec 2005 (CET)<br />
----<br />
<br />
To confirm:<br />
tp_smapi 0.13 works with hdaps module loaded on T41 (2373-8RG). However, force_discharge*, inhibit_charge_minutes, start_charge_thresh, stop_charge_thresh don't seem to be implemented on this model.<br />
<br />
--[[User:LJSBRokken|LJSBrokken]] 21 Dec 2005<br />
----<br />
<br />
tp_smapi version 0.13 with T23 (2647-3QG) (I have dual batteries)...<br />
<br />
None of the functions which make any changes work...<br />
<br />
<pre># cd /sys/devices/platform/smapi && cat BAT*/* > /dev/null<br />
cat: BAT0/force_discharge1: Function not implemented<br />
cat: BAT0/force_discharge2: Input/output error<br />
cat: BAT0/inhibit_charge_minutes: Function not implemented<br />
cat: BAT0/start_charge_thresh: Function not implemented<br />
cat: BAT0/stop_charge_thresh: Function not implemented<br />
cat: BAT1/force_discharge1: Function not implemented<br />
cat: BAT1/force_discharge2: Input/output error<br />
cat: BAT1/inhibit_charge_minutes: Function not implemented<br />
cat: BAT1/start_charge_thresh: Function not implemented<br />
cat: BAT1/stop_charge_thresh: Function not implemented</pre><br />
<br />
However, all the battery status information is available, and functions appear for both BAT0 and BAT1, regardless of when the UltraBay battery was inserted or ejected- this is very useful, it is the only way I can monitor my UltraBay battery unless it was present on boot.<br />
<br />
--[[User:SystemParadox|SystemParadox]] 21:51, 4 Jan 2006 (CET)<br />
----<br />
<br />
SystemParadox, what's the dmesg output produced by "cat BAT0/force_discharge2"?<br />
<br />
--[[User:Thinker|Thinker]] 22:02, 4 Jan 2006 (CET)<br />
----<br />
<br />
After the upgrade to 0.14 (with kernel 2.6.15, using the patch) I can't use inhibit_charge and start/stop_charge_thresh any longer (getting an input/output error), the dmesg debug output when {{cmd|cat|}}-ing those three files:<br />
<br />
<pre><br />
tp_smapi: tp_smapi 0.14 loading...<br />
tp_smapi: successfully loaded (smapi_port=0xb2).<br />
tp_smapi: req_in: BX=2114 CX=100 DI=0 SI=0<br />
tp_smapi: req_out: AX=ea210080 BX=ec192114 CX=c18d0700 DX=f7cc00b2 DI=f7f50000 SI=c18d0000 ret=-5<br />
tp_smapi: SMAPI error: Unknown error code (func=2114)<br />
tp_smapi: cannot get inhibit charge of battery 0: Unknown error code<br />
tp_smapi: req_in: BX=2116 CX=100 DI=0 SI=0<br />
tp_smapi: req_out: AX=c03b0080 BX=c18d2116 CX=c0160328 DX=ec7600b2 DI=ec760000 SI=a0810000 ret=-5<br />
tp_smapi: SMAPI error: Unknown error code (func=2116)<br />
tp_smapi: cannot get start thresh of battery 0: Unknown error code<br />
tp_smapi: req_in: BX=211a CX=100 DI=0 SI=0<br />
tp_smapi: req_out: AX=c03b0080 BX=c18d211a CX=c016032c DX=eb4500b2 DI=eb450000 SI=241e0000 ret=-5<br />
tp_smapi: SMAPI error: Unknown error code (func=211a)<br />
tp_smapi: cannot get stop thresh of battery 0: Unknown error code<br />
</pre><br />
<br />
--[[User:Spiney|spiney]] 08:12, 10 Jan 2006 (CET)<br />
----<br />
<br />
Oops, the transition to 32-bit SMAPI calls was broken. Fixed in 0.15. Thanks for the quick report!<br />
<br />
--[[User:Thinker|Thinker]] 12:10, 10 Jan 2006 (CET)<br />
----<br />
<br />
Yep, 0.15 works again. Quick response, bravo! :)<br />
<br />
--[[User:Spiney|spiney]] 12:23, 10 Jan 2006 (CET)<br />
----<br />
<br />
On a T22, nothing seems to work with 0.16.<br />
<br />
[[http://www.rafb.net/paste/results/fcUUDs49.html|dmesg output]] when doing cat *<br />
<br />
I am using an Ultrabay2000 battery, so it would be really usefull to be able to control that<br />
<br />
--[[User:nusse|nusse]]<br />
----<br />
<br />
Nusse: Not even the extended battery status? That does work on T23. About the control features, I believe they're not available on the T23; did you have any kind of (dis)charge control under WindowS?<br />
<br />
--[[User:Thinker|Thinker]] 20:59, 11 Jan 2006 (CET)<br />
----<br />
<br />
I don't really know what 'extended battery' status means, but here an example:<br />
<pre><br />
$ cat current_* /sys/devices/platform/smapi/BAT1<br />
cat: current_avg: Input/output error<br />
cat: current_now: Input/output error<br />
</pre><br />
This is what happens when i cat any file in this directory and also in ../BAT1 :(<br />
<br />
--[[User:nusse|nusse]] Thu Jan 12 22:07:26 CET 2006<br />
----<br />
<br />
Nusse: Yes, that's what I meant. What's the {{cmdroot|dmesg}} output generated by these commands?<br />
<br />
--[[User:Thinker|Thinker]] 00:27, 13 Jan 2006 (CET)<br />
----<br />
<br />
<br />
Thinker: I attached some link to my first comment but it seems to be down and the link was wrong anyway.<br />
<pre><br />
thinkpad controller read(%hx,%hx): failed writing to 0x1610<br />
thinkpad controller read(%hx,%hx): failed writing to 0x1610<br />
thinkpad controller read(%hx,%hx): failed writing to 0x1610<br />
thinkpad controller read(%hx,%hx): failed writing to 0x1610<br />
thinkpad controller read(%hx,%hx): failed writing to 0x1610<br />
thinkpad controller read(%hx,%hx): failed writing to 0x1610<br />
thinkpad controller read(%hx,%hx): failed writing to 0x1610<br />
thinkpad controller read(%hx,%hx): failed writing to 0x1610<br />
thinkpad controller read(%hx,%hx): failed writing to 0x1610<br />
thinkpad controller read(%hx,%hx): failed writing to 0x1610<br />
thinkpad controller read(%hx,%hx): failed writing to 0x1610<br />
thinkpad controller read(%hx,%hx): failed writing to 0x1610<br />
thinkpad controller read(%hx,%hx): failed writing to 0x1610<br />
thinkpad controller read(%hx,%hx): failed writing to 0x1610<br />
thinkpad controller read(%hx,%hx): failed writing to 0x1610<br />
tp_smapi: SMAPI error: Function is not supported by SMAPI BIOS (func=2118)<br />
tp_smapi: cannot get force_discharge of battery 0: Function is not supported by SMAPI BIOS<br />
tp_smapi: SMAPI error: Function is not supported by SMAPI BIOS (func=2114)<br />
tp_smapi: cannot get inhibit charge of battery 0: Function is not supported by SMAPI BIOS<br />
thinkpad controller read(%hx,%hx): failed writing to 0x1610<br />
thinkpad controller read(%hx,%hx): failed writing to 0x1610<br />
thinkpad controller read(%hx,%hx): failed writing to 0x1610<br />
thinkpad controller read(%hx,%hx): failed writing to 0x1610<br />
thinkpad controller read(%hx,%hx): failed writing to 0x1610<br />
thinkpad controller read(%hx,%hx): failed writing to 0x1610<br />
thinkpad controller read(%hx,%hx): failed writing to 0x1610<br />
thinkpad controller read(%hx,%hx): failed writing to 0x1610<br />
thinkpad controller read(%hx,%hx): failed writing to 0x1610<br />
thinkpad controller read(%hx,%hx): failed writing to 0x1610<br />
thinkpad controller read(%hx,%hx): failed writing to 0x1610<br />
thinkpad controller read(%hx,%hx): failed writing to 0x1610<br />
thinkpad controller read(%hx,%hx): failed writing to 0x1610<br />
thinkpad controller read(%hx,%hx): failed writing to 0x1610<br />
thinkpad controller read(%hx,%hx): failed writing to 0x1610<br />
tp_smapi: SMAPI error: Function is not supported by SMAPI BIOS (func=2116)<br />
tp_smapi: cannot get start thresh of battery 0: Function is not supported by SMAPI BIOS<br />
thinkpad controller read(%hx,%hx): failed writing to 0x1610<br />
thinkpad controller read(%hx,%hx): failed writing to 0x1610<br />
tp_smapi: SMAPI error: Function is not supported by SMAPI BIOS (func=211a)<br />
tp_smapi: cannot get stop thresh of battery 0: Function is not supported by SMAPI BIOS<br />
thinkpad controller read(%hx,%hx): failed writing to 0x1610<br />
thinkpad controller read(%hx,%hx): failed writing to 0x1610<br />
</pre><br />
<br />
--[[User:nusse|nusse]] Fri Jan 13 14:35:57 CET 2006<br />
----<br />
<br />
Nusse: Thanks; but there's not much we can do. Maybe the T22 uses a different interface, or doesn't have that feature.<br />
<br />
--[[User:Thinker|Thinker]] 23:23, 15 January 2006 (CET)<br />
----<br />
<br />
Thinker: Is there anything I can do to check if the interface is different? Changing 0x1610 to some random number?<br />
<br />
Is there a chance to get it by try and error?<br />
<br />
--[[User:nusse|nusse]] Mon Jan 16 19:10:12 CET 2006<br />
----<br />
<br />
0x1610 is the number of an IO port it writes to, so changing it to a random number will pretty much guarantee a system crash...<br />
<br />
The only way I can think of for figuring out the T22 interface is to see what the Windows software does.<br />
<br />
--[[User:Thinker|Thinker]] 19:47, 16 January 2006 (CET)<br />
----<br />
<br />
I have a R40 (2722-B3G), and several things don't work with 0.16 on linux 2.6.15.1:<br />
<br />
<pre><br />
tp_smapi: SMAPI error: Function is not supported by SMAPI BIOS (func=2118)<br />
tp_smapi: cannot get force_discharge of battery 0: Function is not supported by SMAPI BIOS<br />
tp_smapi: SMAPI error: Function is not supported by SMAPI BIOS (func=2114)<br />
tp_smapi: cannot get inhibit charge of battery 0: Function is not supported by SMAPI BIOS<br />
tp_smapi: SMAPI error: Function is not supported by SMAPI BIOS (func=2116)<br />
tp_smapi: cannot get start thresh of battery 0: Function is not supported by SMAPI BIOS<br />
tp_smapi: SMAPI error: Function is not supported by SMAPI BIOS (func=211a)<br />
tp_smapi: cannot get stop thresh of battery 0: Function is not supported by SMAPI BIOS<br />
</pre><br />
<br />
Don't know about Windows, haven't booted it for weeks nor used it for years...<br />
<br />
--[[User:Wonka|Wonka]] 19:00, 19 January 2006 (CET)<br />
----<br />
<br />
Wonka: do the other features (i.e., extended battery status) work on your R40?<br />
<br />
--[[User:Thinker|Thinker]] 20:30, 20 January 2006 (CET)<br />
----<br />
<br />
--[[User:lisch|lisch]] 16:14, 11 April 2006 (CDT)<br />
<br />
On my X32, with two batteries, I get just what I expect. Looks good:<br />
<pre>$ cat BAT?/* > /dev/null<br />
cat: BAT0/force_discharge: Function not implemented<br />
cat: BAT0/inhibit_charge_minutes: Function not implemented<br />
cat: BAT0/start_charge_thresh: Function not implemented<br />
cat: BAT0/stop_charge_thresh: Function not implemented<br />
cat: BAT1/force_discharge: Function not implemented<br />
cat: BAT1/inhibit_charge_minutes: Function not implemented<br />
cat: BAT1/start_charge_thresh: Function not implemented<br />
cat: BAT1/stop_charge_thresh: Function not implemented<br />
$<br />
</pre><br />
==Changing the CD speed when the CD is being accessed will hang your computer==<br />
<br />
I don't have this problem on my T40p. CDROM is mounted and file on CD is opened. Change speed do '''not''' hang my system.<br />
<br />
-- Stefan Schmidt<br />
----<br />
<br />
An open file looks fine if you're not reading/writing at that point. But my T43 does hangs on this:<br />
# dd if=/dev/scd0 of=/dev/null &<br />
# echo 1 > /sys/devices/platform/smapi/cdrom_speed<br />
<br />
--[[User:Thinker|Thinker]] 16:41, 7 Dec 2005 (CET)<br />
----<br />
<br />
OK, sorry. I was to fast. My system hangs on this commands, too. :(<br />
<br />
-- Stefan Schmidt<br />
<br />
Works well. Great.<br />
<br />
T42 2373-8zh. Working :cdrom_speed and start_charge_thresh. Untest : inhibit_charge_minutes.<br />
<br />
-- Haifeng Chen<br />
<br />
cdrom_speed works on my T40.<br />
<br />
-- [[User:Lammic|lammic]], 2005.12.09<br />
<br />
== Kernel Patch? ==<br />
<br />
Hello Thinker,<br />
<br />
would it be possible to provide the SMAPI support as kernel patch as well? Something along the lines of: (0.12 against 2.6.15-rc5)<br />
<br />
''(deleted, see below for how to create a patch file)''<br />
<br />
Deleted the tp_smapi.c file at the end, out of obvious reasons, and I'm not sure about the placement in the ACPI section, OTOH there it would be found easily next to ibm_acpi.<br />
<br />
Providing a patch would help when recompiling the kernel often, I hate recompiling external modules every time (even got me a kernel-upgrade script to do most of it automatically). But of course it's up to you. :)<br />
<br />
--[[User:Spiney|spiney]] 09:52, 16 Dec 2005 (CET)<br />
----<br />
<br />
I'll be glad to add this, but I don't want to go through additional manual steps in the release process (there are already quite a few). Can you add a "make patch" functionality to the Makefile, or something of the sort, to automatically generate a full patch (including tp_smapi.c) against current kernel sources?<br />
<br />
Also, this shouldn't be under drivers/acpi, since it doesn't use ACPI at all (that's why I didn't make it a patch to ibm_acpi). I think the right place is drivers/firmware, like the dell_rbu driver for Dell laptops.<br />
<br />
BTW, the convention for kernel patches is to start them once level higher:<br />
diff -Nurp kernel-2.6.14-vanilla kernel-2.6.14-patched<br />
<br />
--[[User:Thinker|Thinker]] 17:12, 16 Dec 2005 (CET)<br />
----<br />
<br />
Of course it's from the wrong level, as usual I was just lazy/inattentive. And at one point I'll remember who likes what patch format, promise. ;)<br />
<br />
A patch target as in "create a new file holding a correct diff to current kernel source" would be rather difficult, since line numbers might change etc., but applying the patch should be straighforward with a bit of sed. Of course I could just do that, create a patch with the diff command and then apply the new patch file in reverse. ;)<br />
<br />
--[[User:Spiney|spiney]] 18:36, 16 Dec 2005 (CET)<br />
----<br />
<br />
If it does that on a local copy (no changes the original kernel tree) and cleans up after itself, that's fine with me. :-)<br />
<br />
--[[User:Thinker|Thinker]] 18:50, 16 Dec 2005 (CET)<br />
----<br />
<br />
Ok, here's a shell script that creates the patch, feel free to use it under the terms of the GPL. For example call it from your Makefile with the patch target: (I didn't want to put all the script into the Makefile, since the rules about escaping in Makefiles, well, escape me ;)<br />
<br />
<pre><br />
#!/bin/bash<br />
<br />
KDIR=/lib/modules/$(uname -r)/build<br />
FDIR=drivers/firmware<br />
OPWD=$(pwd)<br />
<br />
TMPDIR=$(mktemp -d)<br />
cd $TMPDIR<br />
<br />
mkdir -p a/$FDIR<br />
cp $KDIR/$FDIR/{Kconfig,Makefile} a/$FDIR<br />
cp -r a b<br />
sed -i -e '/endmenu/i\<br />
config IBM_SMAPI\<br />
tristate "IBM ThinkPad SMAPI Support"\<br />
depends on X86\<br />
---help---\<br />
This adds SMAPI support on IBM ThinkPads, mostly used for battery\<br />
charge control. For more information about this driver see\<br />
<http://www.thinkwiki.org/wiki/SMAPI_support_for_Linux> .\<br />
\<br />
If you have an IBM ThinkPad laptop, say Y or M here.\<br />
' b/$FDIR/Kconfig<br />
sed -i -e '$a\<br />
obj-$(CONFIG_IBM_SMAPI) += tp_smapi.o' b/$FDIR/Makefile<br />
cp $OPWD/tp_smapi.c b/$FDIR<br />
diff -Nurp a b > $OPWD/tp_smapi-$(uname -r).patch<br />
rm -r a b<br />
cd $OPWD<br />
</pre><br />
<br />
BTW, [http://qbnz.com/highlighter/ GeSHi]-based syntax-highlighting would be great...<br />
<br />
--[[User:Spiney|spiney]] 19:28, 16 Dec 2005 (CET)<br />
----<br />
<br />
Ah, neat sed foo. How about [http://tpctl.sourceforge.net/tmp/Makefile this] escapade, then? <br />
<br />
What's the sed spell needed to replace the Makefile's<br />
VER := 0.13<br />
with auto-parsing of<br />
#define TP_VERSION "0.13"<br />
from tp_smapi.c?<br />
<br />
--[[User:Thinker|Thinker]] 20:37, 16 Dec 2005 (CET)<br />
----<br />
<br />
Hmm, something like<br />
VERFROMC=$(sed -ne 's/^#define TP_VERSION "\(.*\)"/\1/gp' tp_smapi.c)<br />
sed -i -e "s/^VER := .*$/VER := $VERFROMC/" Makefile<br />
should do (untested, from the top of my head, maybe the temporary variable isn't even necessary?). And neat Makefile wizardry, at one point I'll learn the syntax.<br />
<br />
--[[User:Spiney|spiney]] 20:44, 16 Dec 2005 (CET)<br />
----<br />
<br />
Makefile escaping is horrible, keep avoiding it... Anyway, the updated [http://tpctl.sourceforge.net/tmp/Makefile make patch] seems to do the right thing.<br />
<br />
--[[User:Thinker|Thinker]] 21:36, 16 Dec 2005 (CET)<br />
----<br />
<br />
Small documentation request: just needed to create a patch for the not-yet-installed 2.6.16-rc2, which is no problem with<br />
make KSRC=/path/to/linux-2.6.16-rc2 KVER=2.6.16-rc2 patch<br />
but I guess it would be a good addition to the README file. :)<br />
<br />
--[[User:Spiney|spiney]] 10:48, 8 February 2006 (CET)<br />
----<br />
<br />
Right, added (to next release).<br />
<br />
--[[User:Thinker|Thinker]] 13:40, 8 February 2006 (CET)<br />
----<br />
<br />
==Installation questions==<br />
Amazing! I've loaded this module in my T43 which is running SuSE 10 with the kernel of 2.6.13-15. I have three points to share:<br />
<br />
1. The battery control part seems to work but has a minor problem. I set the stop_charge_threshold to 70, but the battery stops charging at 55%. Don't know why and how to fix it. :P<br />
<br />
2. I don't have the cd speed control function. Here is what I have under /sys/devices/platform/smapi/:<br />
<br />
./ ../ ac_connected BAT0/ BAT1/ bus@ driver@ power/<br />
<br />
3. SuSE 10 doesn't have the necessary C files under .../drivers/hwmon/, I copied them from a 2.6.14.5 kernel source. Maybe it causes the two problems above. :(<br />
<br />
When I have time, I'll install the new kernel to see if the problems are gone and report the result.<br />
<br />
--[[User:68.51.153.96|68.51.153.96]] 04:31, 2 Jan 2006 (CET)<br />
----<br />
<br />
1. It should stop charging at 70, but will only ''start'' charging when remaining capacity has dipped below <tt>start_charge_thresh</tt>.<br />
<br />
2. See the note about PROVIDE_CD_SPEED.<br />
<br />
3. That's should be needed only for patching the HDAPS driver in order to make it compatible with tp_smapi. If your kernel (which version is it?) doens't inlude the HDAPS driver anyway, you don't need to patch....<br />
<br />
--[[User:Thinker|Thinker]] 09:28, 2 Jan 2006 (CET)<br />
----<br />
<br />
Thanks Thinker.<br />
<br />
1. I discharged and recharged the battery again. This time, it stops at 68% percent, which is pretty good.<br />
<br />
2. I missed the NOTE in README, for I just followed this wiki. :P<br />
<br />
3. My kernel version is 2.6.13-15.<br />
<br />
By the way, I just got this T43 whose model number is 266896U. I feel that the noise of the fan is much louder than my previous T21. I think it is so since it has a CPU with bigger power but am wondering if other T43 has the same big noise?<br />
<br />
--[[User:Tyne|Tyne]] 00:14, 3 Jan 2006 (CET)<br />
----<br />
<br />
The note about PROVIDE_CD_SPEED is also in the Wiki...<br />
<br />
About the T43 fan noise: yes, this is a very common (and annoying) problem. See [[Problem_with_fan_noise]] and our [[ACPI fan control script]], and send Lenovo a complaint in hope they'll fix this at the firmware level.<br />
<br />
--[[User:Thinker|Thinker]] 08:48, 3 Jan 2006 (CET)<br />
----<br />
I spent hours, trying to compile this on ubuntu edgy without success. It starts with warnings about missing files:<br />
<br />
<pre><br />
root@t40:/home/bernd/Desktop/tp_smapi-0.31/tp_smapi-0.31# make install<br />
make -C /lib/modules/2.6.17-11-386/source M=/home/bernd/Desktop/tp_smapi-0.31/tp_smapi-0.31 O=/lib/modules/2.6.17-11-386/build modules<br />
make[1]: Betrete Verzeichnis '/usr/src/linux-source-2.6.17'<br />
/usr/src/linux-source-2.6.17/Makefile:450: .config: No such file or directory<br />
<br />
WARNING: Symbol version dump /lib/modules/2.6.17-11-386/build/Module.symvers<br />
is missing; modules will have no dependencies and modversions.<br />
<br />
CC [M] /home/bernd/Desktop/tp_smapi-0.31/tp_smapi-0.31/thinkpad_ec.o<br />
cc1: error: include/linux/autoconf.h: No such file or directory<br />
[...]<br />
</pre><br />
and then many thousand lines later it finally stops:<br />
<pre><br />
[...]<br />
/home/bernd/Desktop/tp_smapi-0.31/tp_smapi-0.31/thinkpad_ec.c:357: error: ‘CONFIG_HZ’ undeclared (first use in this function)<br />
/home/bernd/Desktop/tp_smapi-0.31/tp_smapi-0.31/thinkpad_ec.c: In function ‘thinkpad_ec_invalidate’:<br />
/home/bernd/Desktop/tp_smapi-0.31/tp_smapi-0.31/thinkpad_ec.c:378: error: ‘CONFIG_HZ’ undeclared (first use in this function)<br />
/home/bernd/Desktop/tp_smapi-0.31/tp_smapi-0.31/thinkpad_ec.c: In function ‘thinkpad_ec_init’:<br />
/home/bernd/Desktop/tp_smapi-0.31/tp_smapi-0.31/thinkpad_ec.c:460: error: ‘CONFIG_HZ’ undeclared (first use in this function)<br />
make[3]: *** [/home/bernd/Desktop/tp_smapi-0.31/tp_smapi-0.31/thinkpad_ec.o] Fehler 1<br />
make[2]: *** [_module_/home/bernd/Desktop/tp_smapi-0.31/tp_smapi-0.31] Fehler 2<br />
make[1]: *** [modules] Fehler 2<br />
make[1]: Verlasse Verzeichnis '/usr/src/linux-source-2.6.17'<br />
make: *** [modules] Fehler 2<br />
</pre><br />
<br />
There must be something fundamentally wrong with the makefile. I have for example never seen that a symlink has to point from /lib/modules/someversion/somewhere to /usr/src/linux. I have installed other modules in the past and they all worked with installed linux-headers package. I didn't ever have to download 40MB kernel source, unpack it, configure it to have a .config and compile the whole kernel just to have 2 or three of the other files needed. This cannot be the correct way to install a driver.<br />
<br />
[[User:7bit|7bit]] 07:42, 27 March 2007 (CEST)<br />
----<br />
<br />
I tried compiling tp_smapi with the module-assistant . However, I cannot see how to add the option HDAPS=1. I edited the Makefile in the source archive of tp_smapi by adding HDAPS:=1 in the beginning of the file, but that didn't work. I get accelerometer readings but hdapsd gives back "open(protect_file): No such file or directory". I'm using ubuntu 9.04 beta, with kernel 2.6.28-11.<br />
<br />
--[[User:Sv3t|Sv3t]] 18:52, 9 April 2009 (UTC)<br />
<br />
== Formatting ==<br />
<br />
Wyrfel, that was some heavy editing you did... I agree with most changes (including the saner color choice). I did like those HINT floats, though - they keep the hints from interrupting the flow of text too much, and this particular text needs any help it can get.<br />
<br />
--[[User:Thinker|Thinker]] 17:04, 3 Jan 2006 (CET)<br />
----<br />
Hei Thinker,<br />
<br />
I'll look into it again. I felt that the floating HINTs were tearing the text apart too much. Maybe we could fix it by placing the clear marks somewhere else.<br />
<br />
[[User:Wyrfel|Wyrfel]] 18:46, 3 Jan 2006 (CET)<br />
----<br />
<br />
== Dual battery operation with tp_smapi ==<br />
<br />
It looks like it is working quite fine with tp_smapi-0.13 and 2.6.15 (it may also work with other versions, but those are the ones I have running right now).<br />
<br />
The juicy details:<br />
<br />
{{cmdroot|cd /sys/devices/platform/smapi/}}<br />
{{cmdroot|cat ac_connected}}<br />
<br />
{{cmdresult|0}}<br />
{{cmdroot|cat BAT{0,1}/state}}<br />
{{cmdresult|discharging}}<br />
{{cmdresult|idle}}<br />
<br />
{{cmdroot|echo 1 > BAT1/force_discharge1}}<br />
{{cmdroot|cat BAT{0,1}/state}}<br />
{{cmdresult|idle}}<br />
{{cmdresult|discharging}}<br />
<br />
Checking capacity values shows that the corrent battery is being depleted.<br />
<br />
And remember, before you yank the CD/DVD drive out, issue:<br />
<br />
{{cmdroot|cat eject > /proc/acpi/ibm/bay}}<br />
<br />
----<br />
<br />
Great! Which ThinkPad model is it? Could you also {{cmdroot|cat /sys/devices/platform/smapi/BAT{0,1}/force_discharge2}} and report the dmesg output (after {{cmdroot|make load}} or {{cmdroot|1=modprobe tp_smapi debug=1}})?<br />
<br />
About the eject command, I think it should be possible to do that automatically when the Ultrabay handle is ejected, via <tt>acpid</tt>.<br />
<br />
--[[User:Thinker|Thinker]] 15:45, 10 Jan 2006 (CET)<br />
----<br />
<br />
It's a T43 (2669). cat'ing force_discharge2 gives me an I/O error and I see<br />
<br />
tp_smapi: cannot get force_discharge2 of battery 0: bx=2103<br />
<br />
tp_smapi: cannot get force_discharge2 of battery 1: bx=2103<br />
<br />
I find these errors irrelevant from the user's point of view, though. <br />
<br />
Indeed, it should be possible to automatise the "eject" command. I should also be noted that once a force_discharge1 is set, it will NOT unset automatically, event when the AC is plugged back in. An obvious fix is to fiddle with the appropriate ACPI event to force_discharge1 back to 0 for all batteries once the AC is attached.<br />
<br />
----<br />
<br />
Thanks, this eliminates the last situation I imagined <tt>force_discharge2</tt> might work. The next tp_smapi version will remove <tt>force_discharge2</tt> and rename <tt>force_discharge1</tt> to <tt>force_discharge</tt>.<br />
<br />
If you write those ACPI scripts, it would be great if you put them on the Wiki.<br />
<br />
--[[User:Thinker|Thinker]] 16:31, 10 Jan 2006 (CET)<br />
----<br />
<br />
Well, I still do not preclude the fact that <tt>force_discharge2</tt> may be useful for something else on other models.<br />
<br />
The ACPI scripts (as well as an installation guide) is underway. It may take a while, though.<br />
<br />
----<br />
<br />
See the new article: [[Using an Ultrabay battery]].<br />
<br />
--[[User:Thinker|Thinker]] 17:05, 10 Jan 2006 (CET)<br />
----<br />
<br />
Hei Thinker,<br />
<br />
i just renamed the new page. Will adjust your links later on. Keeping the redirect page until that's done. Please set any new links you create to the new page (the pages of the individual UltraBay batteries should contain a pointer).<br />
<br />
On a sidenote: I would like to split the SMAPI support under Linux page into a tp_smapi driver page, just listing the features, and a "How to use tp_smapi" page. I would also split the thinkpad/tpctl page off that again. Any objections?<br />
<br />
[[User:Wyrfel|Wyrfel]] 20:42, 10 Jan 2006 (CET)<br />
----<br />
<br />
ACK about the page rename (the old one did sound a bit out of line to my ear, but I couldn't spot why...).<br />
<br />
About the splitting tp_smapi vs. thinkpad/tpctl, no objection.<br />
<br />
About splitting tp_smapi: currently most of that section doubles as both a spec and a HOWTO, which I think is a convenient and concise way to describe things (hey, it must be right, the Perl docs do it!). I'm not sure there's much benefit in duplicating that. Perhaps we should wait for a critical mass of additional lore to accumulate?<br />
<br />
--[[User:Thinker|Thinker]] 21:04, 10 Jan 2006 (CET)<br />
----<br />
Ok, i agree on the latter.<br />
<br />
[[User:Wyrfel|Wyrfel]] 00:57, 11 Jan 2006 (CET)<br />
----<br />
<br />
==Article name capitalization== <br />
<br />
Wikimedia autocapitalizes the article name upon submit. How do I concince Wikimedia that I really want a lowercase "t"? The underline is probably too much too ask...<br />
<br />
--[[User:Thinker|Thinker]] 11:03, 11 Jan 2006 (CET)<br />
----<br />
<br />
Impossible, according to [http://en.wikipedia.org/wiki/Wikipedia:Canonicalization Wikipedia:Canonicalization].<br />
<br />
--[[User:Thinker|Thinker]] 12:04, 11 Jan 2006 (CET)<br />
----<br />
<br />
Look at how Mozilla folks took care of it: http://kb.mozillazine.org/About:config<br />
<br />
--[[User:Domicius|domicius]] 00:33, 29 Sep 2008 (CET)<br />
----<br />
<br />
==Status Table==<br />
For at least the T series i think that charge control was not supported prior to the T42, hardware/BIOS side. Perhaps "N/A" flags would be better here?<br />
<br />
I also created <nowiki>{{Isup}}</nowiki> style templates for status, they just include images, like {{Isup}}.<br />
Not emotional about it, just wanted to let you know in case you want to use them.<br />
<br />
Third and last...would it possibly be better to make the table headers more human readable like i.e. "lower charge threshold" or something like that instead of "start_charge_thresh"?<br />
<br />
[[User:Wyrfel|Wyrfel]] 19:21, 11 Jan 2006 (CET)<br />
----<br />
<br />
About "N/A", sure, if we get reliable data about the hardware capabilities. Alas, most negative reports were just "it doesn't work", and in some cases gave contradictory information (SMAPI interface says a function is unsupported but user says it works under Windows).<br />
<br />
About {{Iyes}} and friends, they're very cute, but I think think they're harder to parse visually and would add some clutter to an already dense table.<br />
<br />
The table headers are just the names of the control files - that's important to keep, sine it's the most natural lookup key. Adding friendly description would be great, if we can fit them in (not everyone has an SXGA+ display...). I tried and failed.<br />
<br />
--[[User:Thinker|Thinker]] 20:38, 11 Jan 2006 (CET)<br />
----<br />
<br />
I have a T41p and the windows tools still don't offer me battery management, even though it's quite a while since the T42 came out.<br />
<br />
I'm ok with the rest.<br />
<br />
[[User:Wyrfel|Wyrfel]] 22:35, 11 Jan 2006 (CET)<br />
----<br />
<br />
For the {{X40}}, I can report success using the stop_charge_thresh feature with BIOS v2.03 (1UETC8WW) and Embedded Controller Program v1.60 (1UHTB0WW).<br />
<br />
[[User:Peterco|Peterco]] 12:07, 28 February 2006 (CET)<br />
----<br />
<br />
[[User:roam|roam]] 13:43, 11 January 2008 (CET)<br />
<br />
I need invert=1 for hdaps. The additional invert parameters (2-7) didn't work for me with tp_smapi 0.33. They work with 0.34.<br />
<br />
== Z60t ==<br />
<br />
Tested on Z60t. No errors using cat. Setting thresholds works. Status and capacity queries work. --[[User:Alon|Alon]] 21:44, 4 May 2006 (CEST)<br />
<br />
== Problem setting thresholds with X40 ==<br />
<br />
My X40, kernel 2.6.16 and tp_smapi 0.20. I try to set the thresholds to 40% and 90% using:<br />
<pre><br />
# echo 90 > stop_charge_thresh<br />
# echo 40 > start_charge_thresh<br />
</pre><br />
which should work, and the kernel reports from dmesg:<br />
<pre><br />
tp_smapi: successfully loaded (smapi_port=0xb2).<br />
tp_smapi: battery 0: changed start threshold to 85(+1)<br />
tp_smapi: battery 0: changed stop threshold to 90<br />
tp_smapi: battery 0: changed start threshold to 39(+1)<br />
</pre><br />
but, on confirmation here is what happens:<br />
<pre><br />
# cat stop_charge_thresh<br />
90<br />
# cat start_charge_thresh<br />
91<br />
</pre><br />
Any clues as to why start doesn't keep? Or why its always at 1 above stop_charge_thresh?<br />
<br />
--[[User:Xmm0|Xmm0]] 15:01, 17 May 2006 (CEST)<br />
----<br />
<br />
Is it any different if you first set start_charge_thresh and then stop_charge_thresh? <br />
<br />
Can you please load tp_smapi with module option "debug=1" and report the dmesg output genereated by each command?<br />
<br />
--[[User:Thinker|Thinker]] 16:31, 17 May 2006 (CEST)<br />
----<br />
<br />
== Battery daemon feedback requested ==<br />
<br />
I am writing a battery-management daemon to control charging and discharging BAT0 and BAT1 in accordance with usage patterns that extend Li-Ion and Li-Py battery life.<br />
<br />
By default, the machine fully discharges BAT1 first, and it is said that deep-cycling all the time dramatically shortens their lifetime.<br />
<br />
My Z61t is the test machine, and it is configured with two batteries, the stock 4-cell, and an "Advanced Ultrabay", which about doubles the runtime of the machine.<br />
<br />
Currently there are two "modes" of the daemon:<br />
<br />
Discharging mode.<br />
<pre><br />
* look at the "remaining_percent" values for both batteries<br />
* if one is more than THRESHOLD percent less than the other one, <br />
force discharge from the battery with more capacity left<br />
(the current value for THRESHOLD is 10%)<br />
</pre><br />
I believe the preceeding will prevent either battery from being deep-cycled disproportionately.<br />
<br />
Charging mode. I am less sure what the "right" algorithm is here. The following is a proposal.<br />
<pre><br />
* look at the "remaining_percent" values for both batteries<br />
* if one is more than THRESHOLD percent less than the other one, <br />
force charging to the battery with less capacity left<br />
* honor pre-set values in stop_charge_thresh and start_charge_thresh<br />
</pre><br />
<br />
I would like to get feedback in the form of "better" algorithms or requests for this daemon.<br />
<br />
--[[User:Zak Smith|Zak]] 19:03, 12 September 2006 (CEST)<br />
<br />
It sounds like your algorithm will indeed minimize wear on both batteries. A side benefit is that charging will toggle between the batteries, which may help keep them cooler while charging and thus prolong their life. OTOH, if you plan to occasionally swap the UltraBay battery for other devices, you may want to fully charge the system battery (up to stop_charge_thresh) first.<br />
<br />
--[[User:Thinker|Thinker]] 22:57, 12 September 2006 (CEST)<br />
<br />
<br />
I have noticed that when force_discharge is set and the batteries switch, the gnome battery monitoring applet gets totally confused about remaining runtime. Besides being a nuisance, this could presumably cause premature emergency shutduwn.<br />
<br />
I have also noticed that the reported remaining runtimes vary greatly between acpi, the applet, and /proc/acpi/battery/*/state<br />
<br />
--[[User:Zak Smith|Zak]] 21:46, 14 September 2006 (CEST)<br />
<br />
What do you mean by "acpi" vs. "/proc/acpi/battery/*/state"? <br />
<br />
The most accurate readout is probably {{path|/sys/devices/platform/smapi/BAT0/remaining_running_time}}, but I don't think any applet uses that yet.<br />
<br />
--[[User:Thinker|Thinker]] 12:07, 15 September 2006 (CEST)<br />
<br />
By acpi, I meant the output of the acpi (1) command. I'll get some comparative numbers later and post them here.<br />
<br />
--[[User:Zak Smith|Zak]] 20:37, 15 September 2006 (CEST)<br />
<br />
Odd, my version of {{path|/usr/bin/acpi}} doesn't report remaining time, just percent (which is the same as {{path|/sys/devices/platform/smapi/BAT0/remaining_percent}}).<br />
<br />
--[[User:Thinker|Thinker]] 21:32, 15 September 2006 (CEST)<br />
<br />
I have been running batteryd for a while with good results. I will upload it here shortly.<br />
<br />
I disabled the preferential charging mode, and only control discharging.<br />
<br />
--[[User:Zak Smith|Zak]] 23:15, 14 November 2006 (CET)<br />
<br />
http://demigod.org/~zak/src/batteryd.cc<br />
<br />
--[[User:Zak Smith|Zak]] 20:18, 5 December 2006 (CET)<br />
<br />
Have you developed this further since then? I just got my first dual-battery-setup for my Z60m. Anyway, it says it doesn't support hotplugging the battery? What does this mean? Do things break if I change batteries or switch a DVD drive to the ultrabay slot while it's running? <br />
<br />
Anyway, I deciphered your source code enough that it basically seems to poll the stuff under /sys/devices/platform/BAT?/* every 10 seconds. Anyway, I don't see what's so tough about hotswapping - the BAT1 directory does not seem to vanish either by issuing echo 1 > /sys/devices/platform/bay.0/eject or just yanking it out. The /sys/devices/platform/BAT1/installed goes to zero though.<br />
<br />
Can you add a check to the condition if (b0->on_ac == 0) ...change this to<br />
<br />
if ((b0->on_ac == 0) && (b0->installed == 1) && (b1->installed == 1))<br />
<br />
then the equal discharging logic would handle hotswapping too (ie. situations where you're running only on 1 battery instead of 2). <br />
<br />
I hope you keep on honing this.<br />
<br />
One of the few things I miss from Dell is that when operating with dual batteries, it discharges both of them evenly.<br />
<br />
--[[User:Zarhan|Zarhan]] 18:31, 13 May 2007 (CEST)<br />
<br />
== Instructions for X60 with Bios 1.11 under Debian Etch ==<br />
<br />
Could someone please provide step-by-step instructions of how to make this work with Debian? What have I to do after apt-get install kernel-patch-tpsmapi? Thank you!<br />
<br />
--[[User:PeterBursch|PeterBursch]] 21:39, 15 September 2006 (CEST)<br />
<br />
== tp_smapi 0.30 with kernel 2.6.20? ==<br />
<br />
<pre>T60:~/tp_smapi-0.30# uname -rm<br />
2.6.20 x86_64<br />
<br />
T60:~/tp_smapi-0.30# make load<br />
if lsmod | grep -q '^hdaps '; then rmmod hdaps; fi<br />
if lsmod | grep -q '^tp_smapi '; then rmmod tp_smapi; fi<br />
if lsmod | grep -q '^thinkpad_ec '; then rmmod thinkpad_ec; fi<br />
if lsmod | grep -q '^tp_base '; then rmmod tp_base; fi # old thinkpad_ec<br />
make -C /lib/modules/2.6.20/source M=/root/tp_smapi-0.30 O=/lib/modules/2.6.20/build modules<br />
make[1]: Entering directory `/usr/src/linux-2.6.20'<br />
CC [M] /root/tp_smapi-0.30/thinkpad_ec.o<br />
/root/tp_smapi-0.30/thinkpad_ec.c:83: warning: type defaults to 'int' in declaration of 'DECLARE_MUTEX'<br />
/root/tp_smapi-0.30/thinkpad_ec.c:83: warning: parameter names (without types) in function declaration<br />
/root/tp_smapi-0.30/thinkpad_ec.c: In function 'thinkpad_ec_lock':<br />
/root/tp_smapi-0.30/thinkpad_ec.c:94: warning: implicit declaration of function 'down_interruptible'<br />
/root/tp_smapi-0.30/thinkpad_ec.c:94: error: 'thinkpad_ec_mutex' undeclared (first use in this function)<br />
/root/tp_smapi-0.30/thinkpad_ec.c:94: error: (Each undeclared identifier is reported only once<br />
/root/tp_smapi-0.30/thinkpad_ec.c:94: error: for each function it appears in.)<br />
/root/tp_smapi-0.30/thinkpad_ec.c: In function 'thinkpad_ec_try_lock':<br />
/root/tp_smapi-0.30/thinkpad_ec.c:109: warning: implicit declaration of function 'down_trylock'<br />
/root/tp_smapi-0.30/thinkpad_ec.c:109: error: 'thinkpad_ec_mutex' undeclared (first use in this function)<br />
/root/tp_smapi-0.30/thinkpad_ec.c: In function 'thinkpad_ec_unlock':<br />
/root/tp_smapi-0.30/thinkpad_ec.c:122: warning: implicit declaration of function 'up'<br />
/root/tp_smapi-0.30/thinkpad_ec.c:122: error: 'thinkpad_ec_mutex' undeclared (first use in this function)<br />
make[3]: *** [/root/tp_smapi-0.30/thinkpad_ec.o] Error 1<br />
make[2]: *** [_module_/root/tp_smapi-0.30] Error 2<br />
make[1]: *** [modules] Error 2<br />
make[1]: Leaving directory `/usr/src/linux-2.6.20'<br />
make: *** [modules] Error 2<br />
</pre><br />
<br />
:Works here with 2.6.21-rc1 (didn't try 2.6.20) without problems --[[User:Zhenech|Zhenech]] 14:32, 22 February 2007 (CET)<br />
<br />
:I have this problem when compiling for x86_64 too. It seems to be limited to 64bit kernels though. I've notified the author of tp_smapi about it, so lets hope a solution is found soon. --[[User:Esmil|Esmil]] 20:08, 6 March 2007 (CET)<br />
<br />
The author was happy about the report, but didn't have time too look at it right now, so I thought I'd give it my best shot. Apparently I should have done that sooner, cause this seems to fix it (for me at least):<br />
<pre><br />
diff -Naur tp_smapi-0.30/hdaps.c tp_smapi-0.30-64bit_fix/hdaps.c<br />
--- tp_smapi-0.30/hdaps.c 2006-09-03 12:13:34.000000000 +0200<br />
+++ tp_smapi-0.30-64bit_fix/hdaps.c 2007-03-07 00:43:26.000000000 +0100<br />
@@ -34,6 +34,7 @@<br />
#include <linux/timer.h><br />
#include <linux/dmi.h><br />
#include <linux/thinkpad_ec.h><br />
+#include <linux/jiffies.h><br />
<br />
/* Embedded controller accelerometer read command and its result: */<br />
static const struct thinkpad_ec_row ec_accel_args =<br />
diff -Naur tp_smapi-0.30/thinkpad_ec.c tp_smapi-0.30-64bit_fix/thinkpad_ec.c<br />
--- tp_smapi-0.30/thinkpad_ec.c 2006-09-02 21:46:18.000000000 +0200<br />
+++ tp_smapi-0.30-64bit_fix/thinkpad_ec.c 2007-03-07 00:43:13.000000000 +0100<br />
@@ -34,6 +34,7 @@<br />
#include <linux/delay.h><br />
#include <linux/thinkpad_ec.h><br />
#include <linux/jiffies.h><br />
+#include <asm/semaphore.h><br />
#include <asm/io.h><br />
<br />
#define TP_VERSION "0.30"<br />
</pre><br />
Copy the above to {{path|64bit_fix.patch}}, enter the {{path|tp_smapi-0.30}} directory and type<br />
:{{cmduser|patch -p1 < /path/to/64bit_fix.patch}}<br />
Now cross your fingers and compile as normal.<br />
--[[User:Esmil|Esmil]] 01:06, 7 March 2007 (CET)<br />
: tp_smapi 0.31 fixes this issue --[[User:Esmil|Esmil]] 19:22, 8 March 2007 (CET)<br />
<br />
== X60: tp_smapi 0.31 with kernel 2.6.20 issue ==<br />
[[category:X60]]<br />
1st of all: Thanks alot for your work. I do really appreciate this (tp_smapi/thinkwiki).<br />
<br />
2nd: On a Debian (testing) w/ vanilla 2.6.20+tp_smapi+hdaps (w/ modules loaded) the kernel panics (init oops) on reboot just before resetting the system. It has a minor impact, you need to press power-off for 5 secs to switch off the machine. Just FYI.<br />
<br />
--[[User:Runia|Runia]] 23:48, 16 April 2007 (CEST)<br />
<br />
Is this consistently reproducible? What's the oops message and stackdump (you can snap a digicam shot)? Does this happen when...<br />
* rebooting with tp_smapi loaded but hdaps not loaded?<br />
* rebooting with neither tp_smapi nor hdaps loaded?<br />
* rebooting with vanilla hdaps loaded (instead of the tp_smapi version)?<br />
* removing just these modules ("rmmod") instead of rebooting?<br />
<br />
--[[User:Thinker|Thinker]] 01:56, 17 April 2007 (CEST)<br />
----<br />
<br />
Hey Thinker,<br />
Sorry, failed to follow the thread. Didn't pay attention to that bug any more. Skipped use of smapi on next kernel release for some reason. IRC, the panic could be prevented running the kernel w/o hdaps loaded.. hdaps didn't work out correctly for me anyway..<br />
<br />
Cheers,<br />
<br />
--[[User:Runia|Runia]] 16:05, 15 February 2008 (CET)<br />
<br />
== battery start/stop thresholds saved after reboot? ==<br />
<br />
Hi<br />
<br />
Are the values in stop_charge_thresh and start_charge_thresh just used when Linux is running, or are they saved in the battery? Here after a reboot the values are reset to 96/100. I set these values to 40/85 shut the thinkpad down and charged the battery - sadly it did not use the 85% setting and charged the battery to 100%.<br />
<br />
--[[User:Burp|Burp]] 15:31, 13 March 2007 (CET)<br />
----<br />
<br />
The thresholds are saved in the embedded controller, which keeps them as long as there is AC or battery power. If you take away both, the state is reset. If you use suspend-to-disk, tp_smapi will remember the threholds and restore them during resume; but you'll need to write your own init script to set the thresholds during normal reboot after full power loss.<br />
<br />
--[[User:Thinker|Thinker]] 16:19, 13 March 2007 (CET)<br />
----<br />
<br />
Under Ubuntu, you can set the thresholds under {{path| /etc/default/tpsmapi-utils}}.<br />
<br />
START_CHARGE_THRESH_BAT0=40<br />
#START_CHARGE_THRESH_BAT1=40<br />
<br />
STOP_CHARGE_THRESH_BAT0=95<br />
#STOP_CHARGE_THRESH_BAT1=70<br />
----<br />
<br />
If I set the value, plug in in the power cord to charge it after I have shut down the thinkpad, it will charge to 100%?<br />
So I have to plug in the power cord while the thinkpad is running and then shut it down to make it work?<br />
--[[User:Burp|Burp]] 17:45, 15 March 2007 (CET)<br />
----<br />
<br />
Changes take effect immediately, and last as long as the machine has any power source (battery or AC).<br />
<br />
--[[User:Thinker|Thinker]] 18:59, 15 March 2007 (CET)<br />
----<br />
<br />
I've experienced the same problem. When I poweroff my X60 after setting the thresh-values and then reboot it, the values are set to 96/100. If I want the thresholds to be regarded I have to plug in the power cord when the thinkpad is running and then shut it down. If I turn it off before connect it to AC, the values are ignored. <br />
So, are the values only saved in standby-mode? This isn't clear for me, and I think I'm not alone with it ;)<br />
<br />
--[[User:Alexb|Alexb]] 20:56, 15 March 2007 (CET)<br />
<br />
The values are not '''saved''' anywhere. They are set on the EC, and as long as the EC is kept powered on and not rebooted, they are retained. Sleep cycles and reboots on the main machine do not affect the EC. An EC firmware upgrade reboots the EC. Powering off the ThinkPad while it is on battery also powers down the EC. The ThinkPad does not power down the EC while on AC (it has to be powered up to charge the batteries).<br />
<br />
I hope that answered all your doubts...<br />
<br />
--[[User:Hmh|hmh]] 04:45, 28 March 2007 (CEST)<br />
<br />
On my x61s, these values are remembered after powering off the ThinkPad while it is on battery. I didn't try to remove the battery. But it looks like the x61s behaves as Thinker described, not as Hmh did.<br />
<br />
--[[User:Jannic|Jannic]] 13:58, 3 November 2007 (UTC)<br />
<br />
Curious. That would mean the x61s does not power off the EC even while on battery and powered off, or that it is storing the SMAPI thresholds away in CMOS. Care to test it? If you want to check that theory, just hexdump /dev/nvram, change a threshold, than hexdump it again...<br />
<br />
--[[User:Hmh|hmh]] 12:09, 11 November 2007 (UTC)<br />
<br />
Seems like it's the former choice: I didn't see any nvram changes after changing the thresholds. Shutting down the system while on battery does not reset thresholds. Shutting down while on battery and then removing the battery does reset them to start_charge_threshold=96, stop_charge_threshold=100, though. I guess they put the EC in some low-power sleep mode while the notebook is turned off and on battery. The specs linked from [[Embedded_Controller_Chips]] list sleep mode currents below 5µA, which is probably negligible compared to self-discharge of Li-Ion batteries.<br />
<br />
--[[User:Jannic|Jannic]] 14:36, 12 November 2007 (UTC)<br />
<br />
== stop_charge_thresh on t42p ==<br />
<br />
Hi,<br />
<br />
'cat /sys/devices/platform/smapi/BAT0/stop_charge_thres' does not work. I get:<br />
'Function not implemented'. Under windows the ibm tool shows me both thresholds. I am using tp_smapi version 0.31 with kernel 2.6.20 (ubuntu feisty).<br />
<br />
----<br />
<br />
Same problem, I want to know what I can do to help figure out why this works in windows and not with tp_smapi.<br>I am running tp_smapi 0.32 on 2.6.20 Ubuntu Feisty (7.04)<br>Here is the debug output from tp_smapi.<br><br />
{{cmdroot|echo 30 > /sys/devices/platform/smapi/BAT0/start_charge_thresh}}<br><br />
{{cmdroot|dmseg}}<br />
<pre>[68311.752000] smapi smapi: smapi_request: req_in: BX=211a CX=100 DI=0 SI=0<br />
[68311.812000] smapi smapi: smapi_request: req_out: AX=8680 BX=211a CX=100 DX=b2 DI=0 SI=0 r=-38<br />
[68311.812000] smapi smapi: smapi_request: SMAPI error: Function is not supported by SMAPI BIOS (func=211a)<br />
[68311.812000] smapi smapi: __get_real_thresh: cannot get stop_thresh of bat=0: Function is not supported by SMAPI BIOS<br />
[68311.812000] smapi smapi: smapi_request: req_in: BX=2116 CX=100 DI=0 SI=0<br />
[68311.868000] smapi smapi: smapi_request: req_out: AX=80 BX=2116 CX=31d DX=b2 DI=0 SI=0 r=0<br />
[68311.868000] smapi smapi: smapi_request: req_in: BX=2117 CX=11d DI=0 SI=0<br />
[68311.924000] smapi smapi: smapi_request: req_out: AX=80 BX=2117 CX=11d DX=b2 DI=0 SI=0 r=0<br />
[68311.924000] smapi smapi: set_real_thresh: set start to 29 for bat=0</pre><br />
{{cmdroot|echo 85 > /sys/devices/platform/smapi/BAT0/stop_charge_thresh}}<br><br />
{{cmdroot|dmesg}}<br />
<pre>[68385.652000] smapi smapi: smapi_request: req_in: BX=2116 CX=100 DI=0 SI=0<br />
[68385.708000] smapi smapi: smapi_request: req_out: AX=80 BX=2116 CX=31d DX=b2 DI=0 SI=0 r=0<br />
[68385.708000] smapi smapi: smapi_request: req_in: BX=211a CX=100 DI=0 SI=0<br />
[68385.764000] smapi smapi: smapi_request: req_out: AX=8680 BX=211a CX=100 DX=b2 DI=0 SI=0 r=-38<br />
[68385.764000] smapi smapi: smapi_request: SMAPI error: Function is not supported by SMAPI BIOS (func=211a)<br />
[68385.764000] smapi smapi: __get_real_thresh: cannot get stop_thresh of bat=0: Function is not supported by SMAPI BIOS</pre><br />
<p><br />
<br />
--[[User:Airbornespent|Airbornespent]] 16:18, 13 August 2007 (UTC)<br />
----<br />
<br />
Looks like the T42(p) is using a different SMAPI interface for the stop threshold. For example, it could be using the same interface as inhibit_charge_minutes_interface, and monitoring the charge levels manually. Maybe you can use a debugger (e.g., SoftICE) to find out what SMAPI calls are made when you change the thresholds under Windows.<br />
<br />
--[[User:Thinker|Thinker]] 17:40, 13 August 2007 (UTC)<br />
----<br />
<br />
What BIOS and EC version? If a T42/p is doing this, all the T4X but the two T43 types should also suffer the same problem... Not to mention a bunch of R5x models, etc (BIOS TP-1R).<br />
<br />
--[[User:Hmh|hmh]] 23:17, 13 August 2007 (UTC)<br />
----<br />
<br />
This is copy and pasted from the DMI info I put on the DMI list page yesterday:<br />
1RETDPWW (3.21 ) 06/02/2006 Handle 0x0029, DMI type 11, 5 byte String 1: IBM ThinkPad Embedded Controller -[1RHT71WW-3.04 ]-<br />
<br />
I just noticed that the T40 through the T42p use this EC model. The T43s are different. No one with a T40-T42 has claimed success with the stop_charge_thresh on the tp_smapi status table.<br />
<br />
I will try to get windows on a harddrive and pop it in my t42p to use softICE or whatever debuggers soon.<br />
<br />
--[[User:Airbornespent|Airbornespent]] 15:39, 15 August 2007 (UTC)<br />
----<br />
<br />
I've installed windows, I can again confirm that the start and stop thresholds work with the maximiser. I couldn't seem to find softICE but I got a debugger called syser. I have no clue what I should be looking for though, a certain set of CPU calls, addresses, etc? Any advice would be great. If you are more familiar with softICE I will find and install that.<br />
<br />
I just had an idea though. Maybe I can set the thresholds to known values in windows, and then reboot to linux without removing the AC, then the thresholds would be saved on the EC. Is there then a way I can dump the settings in linux and if I do this with several known thresholds that might be enough information to figure this out?<br />
<br />
--[[User:Airbornespent|Airbornespent]] 19:48, 15 August 2007 (UTC)<br />
----<br />
<br />
You need to trace the SMAPI calls made when the thresholds are changed. You can look at tp_smapi.c or the vanilla kernel drivers/char/mwave/smapi.c to see how SMAPI work. Basically, the parameters are loaded into registers, with the SMAPI function code in register EBX. Then, a byte is written to IO ports 0xB2 and 0x4F. The write to port 0xB2 invokes the BIOS SMAPI code in SMM mode. So the first thing to check is what SMAPI functions are called, i.e., the value of EBX before each wrote to port 0xB2. You can see some of the known codes in the SMAPI_* constants near the top of smapi.c.<br />
<br />
--[[User:Thinker|Thinker]] 21:57, 15 August 2007 (UTC)<br />
----<br />
<br />
== Does smapi interface include communication with eeprom? ==<br />
<br />
There exists a windows program (which I haven't tracked down yet) which will reset the eeprom in the battery to clear an error. Could the smapi interface do the same?<br />
<br />
Or are there other ways to do this? I have a relatively new battery (< 10 cycles) with all my tests showing the cells are fine, but since it reports "damage" to the thinkpad, it won't charge it.<br />
<br />
----<br />
<br />
No. Can you provide a link to that Windows program and (more important) information about how it works?<br />
<br />
--[[User:Thinker|Thinker]] 02:17, 25 June 2007 (UTC)<br />
----<br />
<br />
Acc plus v1.3 [http://www.microsys.ro/accplus.htm] communicates over SMBus via a parallel port adapter. It says it can reset the eeprom via direct connection to the chip. But version 1.4 claims to be able to reset the chip via SMBus. I haven't verified this claim because only v1.3 is available for download. But I figured anything that can be done via the parallel port adapter ought to be able to be done natively by the thinkpad.<br />
<br />
The Smart Battery Workshop also claims to be able to reset the eeprom. This is the program that is hard to track down because all the links you find are broken. I finally found it by searching for "smart battery workshop" on download.com [http://download.com]. They use those random urls so I can't post a direct link.<br />
<br />
In summary: mostly these programs are just a way to communicate with the battery over SMBus using a parallel port. But there's the tantalizing claims of being able to reset the chip too....<br />
<br />
--[[User:Kdnelson|Kdnelson]] 03:14, 3 August 2007 (UTC)<br />
----<br />
<br />
If I read this correctly, both AccPlus and Smart Battery Workshop require you to take out the battery and communicate with it via a parallel-to-SMBus adapter. This is out of scope for tp_smapi. AccSmart probably uses the Smart Battery interface through the laptop's internal SMBus bus; this is already supported by Linux's smart battery drivers, but doesn't work on ThinkPads since we don't know of any way the CPU can directly access the SMBus.<br />
<br />
--[[User:Thinker|Thinker]] 13:56, 3 August 2007 (UTC)<br />
----<br />
<br />
== kernel 2.6.24 compatibility ==<br />
<br />
Version 0.32 of tp_smapi seems to be incompatible with the prereleases of 2.6.24. Does anybody know if there are updated patches available?<br />
<br />
--[[User:Jannic|Jannic]] 13:13, 1 November 2007 (UTC)<br />
<br />
Update: It were the renames of BIT() to BIT_MASK in commit 7b19ada2ed3c1eccb9fe94d74b05e1428224663d which did not<br />
apply cleanly to my tp_smapi patched tree. This looks like a minor change which should be fixable easily.<br />
<br />
--[[User:Jannic|Jannic]] 13:58, 3 November 2007 (UTC)<br />
----<br />
<br />
== t400 data ==<br />
<br />
Version .40, ubuntu kernel 2.6.27-9. bios version 1.18,ec version 1.01<br><br />
HDAPS needs both X and Y inversion. <br><br />
Battey testing will take awhile more. <br><br />
[[User:Mrthefter|Mrthefter]] 18:58, 20 December 2008 (CET)<br />
<br />
== gnome-power-management support ==<br />
<br />
It would be nice to have tp smapi support in g-p-m. If anyone interested please 'vote' (i.e. cc) for [http://bugzilla.gnome.org/show_bug.cgi?id=533553 feature bug]. [[User:Uzytkownik|Uzytkownik]] 00:31, 14 January 2009 (CET)<br />
<br />
<br />
OK - there it is! (for gnome-power-manager-2.22.1 and gnome-power-manager-2.24.4)<br />
* For all gentoo users: you can use this [http://projects.implicits.de/gentoo/implicit.xml Overlay].<br />
* For users with rpm System: the [http://projects.implicits.de/_archive/gnome-power-manager/gnome-power-manager-2.22.1-r1.x86_64.rpm rpm-file] has not been tested!!<br />
* For dpkg Users: the [http://projects.implicits.de/_archive/gnome-power-manager/gnome-power-manager_2.22.1-1_amd64.deb deb-file] has not been tested!!<br />
* For all the other Users: You have to patch your gnome-power-manager. Patch can be found [http://projects.implicits.de/gentoo/gnome-extra/gnome-power-manager/files/gnome-power-manager-2.22.1.smapi.patch here]<br />
<br />
The precompiled Packages are compiled with -march=core2 (gcc-4.3.3)<br />
<br />
Note: user rights of sysfs files have to be changed. you can use the following udev rules, to do so.<br />
<br />
<pre><br />
DRIVER=="smapi", RUN+="/bin/sh -c 'find /sys/devices/platform/smapi/ -name force_discharge | xargs /bin/chmod 666'"<br />
DRIVER=="smapi", RUN+="/bin/sh -c 'find /sys/devices/platform/smapi/ -name start_charge_thresh | xargs /bin/chmod 666'"<br />
DRIVER=="smapi", RUN+="/bin/sh -c 'find /sys/devices/platform/smapi/ -name stop_charge_thresh | xargs /bin/chmod 666'"<br />
</pre><br />
<br />
Have phun ;)<br />
<br />
Edit: Support for more than one battery (only on start and stop threshs) will be included later - i'm busy this time, sry.<br />
<br />
== SL Series ==<br />
Unfortunately I did not succeed in installing HDSAP support on my SL 500, both tp_smapi and hdaspd report a device problem (although my harddisk is supported: Model=FUJITSU MHZ2320BH G1, FwRev=0084000A)<br />
<br />
linux-blu3:/home/quentin # modprobe tp_smapi hdaps<br />
FATAL: Error inserting tp_smapi (/lib/modules/2.6.31.12-0.2-desktop/updates/tp_smapi.ko): No such device<br />
linux-blu3:/home/quentin # hdapsd -f -d sda<br />
Tue May 25 10:15:53 2010: Starting hdapsd<br />
Tue May 25 10:15:53 2010: Forcely enabled UNLOAD for sda<br />
Tue May 25 10:15:53 2010: Could not find a suitable interface<br />
<br />
Support is highly appreciated! Thanks!<br />
<br />
~~user</div>Denisq