ThinkWiki - User contributions [en]

Talk:Qualcomm Gobi 2000

2011-01-11T08:53:39Z

Zarhan: /* GPS */

== Firmware ==

I found out a way to get the firmware on a linux-only system. Mine is a debian squeeze, but it should apply to any system.

First, I entered my model number on the [http://www.lenovo.com/support/ Lenovo support page] in the right siderow (Select you system / Quick Path) to get to my drivers page. There I clicked to download drivers and on the UMTS drivers. Afterwards I downloaded the "<code>7xwc42ww.exe</code>" driver package.

You dont need to enter your serial number to the lenovo support page. With some googling i came up with [http://www-307.ibm.com/pc/support/site.wss/MIGR-72938.html this] page. This is very useful for all those owning a laptop not built by lenovo. ([[User:Bob the builder|bob]])

With wine I was able to install the driver package, but all it does, was unpacking the GOBI driver setup. This one comes packaged as a <code>.msi</code> file, so we have to [http://sysblogd.wordpress.com/2008/05/10/howto-extract-all-files-from-microsoft-installer-files-msi-rather-than-to-install-the-package/ unpack] it:

user@machine:~$ wine msiexec /a ~/.wine/drive_c/DRIVERS/WWANQL/Driver/GobiInstaller.msi TARGETDIR=C:\\DRIVERS\\GOBI

The installer quits with errors, but leaves the files on the disk, success. But now there are several subdirectories, in which the files for the specific network operators reside:

{| {{prettytable}}
! Dir !! Image !! Remarks
|-
| 0 || Vodafone Image ||
|-
| 1 || Verizon Image ||
|-
| 2 || ATT Image ||
|-
| 3 || Sprint Image || includes special Firmware
|-
| 4 || T-Mobile Image ||
|-
| 6 || Generic UMTS Image ||
|-
| 7 || Telefonica Image ||
|-
| 8 || Telecom Italia Image ||
|-
| 9 || Orange Image ||
|-
| 12 || DoCoMo Image || includes special Firmware
|-
| UMTS || Default Firmware || the MD5-sum on the page matches these
|}
t

I found this out by reading the <code>ReadMe.rtf</code>, looking into the <code>UQCN.mbn</code>-Files and apply a little bit of thinking.

Now I'll move the files over and try them out.
------------------------------------------------------------------------------------------------------------------------------------------

So I got the Sprint Image with firmware, how does one flash the Gobi with this firmware?

You do not need to flash the gobi as such. Firmware must be loaded at every boot. Simply use the gobi_loader mentioned on the main page, with the 3 firmware files from the sprint directory. You will need to modify it to match your USB IDs. After the firmware it loaded it will last until you power off your laptop. I usually reboot after loading the firmware, but before trying to use the modem. The firmware remains loaded. [[User:Catphish|Catphish]]

--
I appear to have got the WWAN portion functioning but can't find any reference to anyone using the GPS part. Does this work under Linux yet? [[User:Bjb|Bjb]]

For me this images work with eplus germany --[[User:Lynxis|Lynxis]] 23:13, 8 June 2010 (UTC)

84d002b0ef003cde6c95826bfbf067fe /lib/firmware/gobi/amss.mbn
d7496085f1af3d1bfdf0fa60c3222766 /lib/firmware/gobi/apps.mbn
c3d6fd93ae2e52775ef9cd8fccbc20be /lib/firmware/gobi/UQCN.mbn

$ find -type f -exec md5sum {} \; | sort -k 2
c3d6fd93ae2e52775ef9cd8fccbc20be ./0/UQCN.mbn
4d6203bf9fe8ae1af439d4d163e91596 ./12/amss.mbn
385a22740f80c0d00f8acdd9ad637032 ./12/apps.mbn
e868df00bfa88596d588a52f872ff703 ./12/UQCN.mbn
48191d62dc4091fb9d23e0b947611c58 ./1/amss.mbn
4f46a856fcceb197943d0cf3257c3621 ./1/apps.mbn
bb05d912e27b822348d4de93fc3ac911 ./1/UQCN.mbn
ff935ec4da6f6711b48caaddcf737566 ./2/UQCN.mbn
4f74d79ed8df027db3b75e36feb2bd27 ./3/amss.mbn
d9ff7b27c491332650b1efbbee64ee31 ./3/apps.mbn
6f6462fe0cc185cc3dc24720a28770fb ./3/UQCN.mbn
46418504e70971bda7b2ee34cc80b5b7 ./4/UQCN.mbn
1aa5727b034dd1f371a3412d5800c1a3 ./6/UQCN.mbn
9f6773625d59098f9360c24263d99615 ./7/UQCN.mbn
e012286117c0c7708369f8dbc7906e64 ./8/UQCN.mbn
c65246da47695b4ecaaf098a02718c9d ./9/UQCN.mbn
84d002b0ef003cde6c95826bfbf067fe ./UMTS/amss.mbn
d7496085f1af3d1bfdf0fa60c3222766 ./UMTS/apps.mbn

For me this tutorial above worked, too. Is there anything which prevents us from copying it to the page itself? --[[User:Aneiser|Aneiser]] 20:58, 21 August 2010 (UTC)

== 2.6.32, 2.6.34, git snapshots and later ==

so it's working with recent kernels or no? And add any info about GPS, please. [[User:Tensai.cirno|Tensai.cirno]] 02:26, 16 June 2010 (UTC)

I had no luck with 2.6.34. however i tested 2.6.35-rc3 + gobi_loader 0.6 and it worked. had to load the firmware by hand though ...
"/lib/udev/gobi_loader -2000 /dev/ttyUSB0 /lib/firmware/gobi" but i guess the id in the udev file is not the right one for my card. --[[User:Max p|Max p]] 02:09, 22 June 2010 (UTC)

Thanks a lot, this is ''very good'' news. [[User:Tensai.cirno|Tensai.cirno]] 06:54, 23 June 2010 (UTC)

Yes, with 2.6.35 and gobi_loader 0.7 it works for me (T510, O2 Germany, Generic firmware) --[[User:Aneiser|Aneiser]] 21:00, 21 August 2010 (UTC)

The modem also works with 2.6.36 (2.6.36-1~experimental.1) and gobi-loader 0.6.1 from current Debian Testing/Sid/Experimental. GPS doesn’t, although I did apply the patch; /dev/ttyUSB2 doesn't output anything at all – maybe testing outside is necessary. [[User:X2017|X2017]] 20:44, 14 November 2010 (UTC)

== GPS ==

Has anyone managed to get GPS to work yet? I think one has to send certain AT commands to receive the NMEA information (at least that is how it works with some Ericsson modems).
Unfortunately I can't find an AT command reference for the Qualcomm Gobi 2000 ...
[[User:Flyser|Flyser]] 14:15, 27 July 2010 (UTC)

i was asking the qualcomm support about that subject, handing out all AT commands. lets say it that way they were not very cooperative. but you could ask them as well, maybe you got more effective than me and we can have the commands :)--[[User:Max p|Max p]] 09:10, 4 August 2010 (UTC)

so did I. I was told to contact Lenovo about the issue -.- --[[User:Flyser|Flyser]] 08:10, 9 August 2010 (UTC)

You can find the documentation and sdk [http://gobianywhere.com/sdk/index.php here]. However I didn't find any useful AT commands, and I think the SDK is win only. [[User:bbandi|bbandi]] 22:32, 14 August 2010 (UTC)

Did you try to install the SDK? Is it possible to analyze how GPS works? --[[User:Aneiser|Aneiser]] 22:00, 21 August 2010 (UTC)

Has anyone managed to get GPS to work with the information published on this wiki page? I get all three devices (ttyUSB[012]), but ttyUSB2 does not output anything. Do I have to connect to a wireless network to get this to work? Could someone publish a more detailed guide how to _use_ the gps? I tried:
# cat /dev/ttyUSB2 &
# echo -n "\$GPS_START" > /dev/ttyUSB2
--[[User:Flyser|Flyser]] 11:03, 30 September 2010 (UTC)

I also cannot get the GPS to work even with the new instructions. Googling around, I found that the start string could be "$GPS-START" (Hyphen instead of underline). However, this doesn't work either. The GPS *did* work on the preinstalled Windows 7. I'm using basic UMTS firmware (firmware from folders "UMTS" and "6").
--[[User:Zarhan|Zarhan]] 06:40, 1 October 2010 (UTC)

I was able to get it to work on a X201, after using the 6/UQCN.mbn image from my Windows 7 x64 partition. This seems to be different from the files/checksums above:
root@polaris:~# md5sum /lib/firmware/gobi/*.mbn
84d002b0ef003cde6c95826bfbf067fe /lib/firmware/gobi/amss.mbn
d7496085f1af3d1bfdf0fa60c3222766 /lib/firmware/gobi/apps.mbn
68e46b936d5400862a0381b101af3972 /lib/firmware/gobi/UQCN.mbn

Now to seems to work:
root@polaris:~# cat /dev/ttyUSB2 &
[1] 3320
root@polaris:~# echo "\$GPS_START" > /dev/ttyUSB2; sleep 3; echo "\$GPS_STOP" > /dev/ttyUSB2
$GPGSA,A,1,,,,,,,,,,,,,,,*1E
$GPGSV,4,1,16,14,33,050,35,24,42,115,28,20,55,246,26,19,19,172,25*77
$GPGSV,4,2,16,11,75,237,,17,29,309,,23,07,192,,28,10,267,*7F
$GPGSV,4,3,16,31,08,106,,32,80,227,,30,,,,29,,,*72
$GPGSV,4,4,16,27,,,,26,,,,25,,,,22,,,*78
$GPGGA,192126.0,,,,,0,,,,,,,,*77
$PQXFI,192126.0,,,,,,,,*6B
$GPVTG,,T,,M,,N,,K,N*2C
$GPRMC,,V,,,,,,,,,,N*53
$GPGSA,A,1,,,,,,,,,,,,,,,*1E
$GPGGA,192127.0,52xx.xxxxxx,N,0xxxx.xxxxxx,E,1,05,1.8,30.6,M,46.0,M,,*61
$PQXFI,192127.0,52xx.xxxxxx,N,0xxxx.xxxxxx,E,30.6,80.58,93.58,3.17*5B
$GPVTG,nan,T,nan,M,0.0,N,0.0,K,A*23
root@polaris:~#

On Debian, using '/lib/udev/gpsd.hotplug add /dev/ttyUSB2' you can tell gpsd about the serial device.
--[[User:Shoragan|Shoragan]] 20:07, 11 October 2010 (UTC)

I'm using exactly same firmwares as Shoragan, and I can see the ttyUSB2 device - however, no NMEA data starts to appear after issuing $GPS_START. I'm using W510 --[[User:Zarhan|Zarhan]] 06:03, 13 October 2010 (UTC)

Same here: using {{openSUSE}} 11.3 with kernel of the day (2.6.37-rc3-3, includes the qcserial patches), gobi_loader 0.7 and current fw files from win partition:
* Gps works in win 7/64 ({{T510i}}) with drivers updated yesterday (most fw files have different md5 sums from those above)
* Copied fw from 1/ to /lib/firmware/gobi/ (also tried the others, but these are the ones working in windows)
* Usb device id changes from x9204 to x9205 automatically (fw gets loaded)
* 3 tty devices appear automatically (udev and module config is ok)
* Modem at ttyUSB1 is functional (at i command in minicom gives fw version and imei)
* ttyUSB0 and ttyUSB2 seem to be dead though (cat, minicom)
--[[User:Joban|Joban]] 19:08, 13 December 2010 (UTC)
*** In windows GPS & wifi work simultaneously? Maybe you should switch off wifi & try GPS? I read official "Lenovo Russia" blog - in the earlier versions BIOS in X100e you can use only wifi '''or''' 3G --[[User:Evadim|Evadim]] 21:10, 13 December 2010 (UTC)

Evadim, I assume with wifi you mean UMTS/GSM, not WLAN (agn) I don't know. I don't use UMTS/GSM (for now). How would I explicitly deactivate 3G/wifi/UMTS/GSM in linux?
Btw. I narrowed down used fw a bit: The firmwares in the "1" directory sometimes hangs the boot process for me and fw dosn't load. I use UMTS/ and 6/
files now --[[User:Joban|Joban]] 16:26, 16 December 2010 (UTC)

I tried with newer firmware that comes with the latest WWan driver (driver version 2.0.7.3) at http://www-307.ibm.com/pc/support/site.wss/document.do?sitestyle=lenovo&lndocid=MIGR-72938&medium=rssW510#20101028 - still doesn't work. --[[User:Zarhan|Zarhan]] 15:25, 29 November 2010 (UTC)

Got it! Wooohooo! I think it work after last BIOS upgrade (lenovo s10-3t), I install win7 for testing GOBI module, upgrade BIOS, test GPS & 3G. After I reboot in to linux - GPS start working. --[[User:Evadim|Evadim]] 17:01, 5 December 2010 (UTC)

Guys! 4 hours of sex with USB protocol debugging in Qemu and "$GPS_START/GPS_STOP" is working now! :)
No firmwares, no bios upgrades, forget about it.
All is simple, in default Lenovo GPS application(ThinkVantage GPS) all NMEA data goes through broadband ethernet virtual interface and enabled by some proprietary protocol. Windows NMEA port is uneuseful before you click button "Start" in ThinkVantage GPS(driver automatically prepend GPS_START string to any connection started on qualcomm nmea port). But if we go to the Preferences of this GPS tracker, and enable checkbox "Auto tracking", Gobi 2000 start to automaticlly enable GPS through its proprietary protocol when new connection appears on NMEA port and it see string "$GPS_START".

So, u only need to install Windows on your machine(or install it on virtual machine), install GPS tracker from Lenovo and simple enable "Auto tracking" checkbox in GPS tracker preferences. After that, u can remove Windows and enjoy GPS in any OS on your notebook. --[[User:Invented|Invented]] 21:50, 25 December 2010 (UTC)

I can confirm that the above trick works. I simply installed VirtualBox, placed Windows XP in it, set Virtualbox to pass-through Qualcomm USB to the Windows, and installed the WWan drivers (see link above) and the GPS Tracker software. Thanks a lot! --[[User:Zarhan|Zarhan]] 08:30, 27 December 2010 (UTC)

I owe you a beer if this works. Sounds awesome, thanks!
EDIT: works fine (also with the vbox method). --[[User:Flyser|Flyser]] 14:36, 29 December 2010 (UTC)

I use WinXP I have updated my WWAN driver and have enabled the checkbox "Auto tracking" and rebooted my linux but I just have a ttyUSB0 what to do?

You have to use a kernel newer than 2.6.37 or you have to apply this patch to your kernel http://marc.info/?l=linux-kernel&m=128534473802312&w=2 --[[User:Flyser|Flyser]] 9. Januar 2011

I tryed Ubuntu alpha 1 with 2.6.37.X but just got a ttyUSB0. Do you know a liveCD in wich the gobi GPS is working?

You also need to install firmware and load it with gobi-loader. See other parts of discussion. If you type "lsusb" and see 05c6:9204, you haven't loaded the firmware and see just ttyUSB0. Once you have loaded the firmware, lsusb shows 05c6:9205, and you should have ttyUSB0-2. --[[User:Zarhan|Zarhan]] 08:53, 11 January 2011 (UTC)

Category:W510

2011-01-07T10:13:48Z

Zarhan: USB suspend in kernel 2.6.37.

__NOTOC__
{| width="100%"
|style="vertical-align:top" |
<div style="margin: 0; margin-right:10px; border: 1px solid #dfdfdf; padding: 0em 1em 1em 1em; background-color:#F8F8FF; align:right;">
=== ThinkPad W510 ===

==== Standard Features ====

* One of the following [[Intel Core i7]] processors:
** Intel Quad Core Processor i7 720QM (1.6GHz 1066MHz 6MB L3)
** Intel Quad Core Processor i7 820QM (1.73GHz 1066MHz 8MB L3)
** Intel Quad Core Extreme Processor i7-920XM (2.0GHz 1333MHz 8MB L3)
* [[NVIDIA Quadro FX 880M]] with 1GB DDR3
* One of the following [[TFT display|TFT displays]]:
** 15.6" TFT display with 1366x768 (HD) resolution with LED backlight
** 15.6" TFT display with 1600x900 (HD+) resolution with LED backlight
** 15.6" TFT display with 1920x1080 (FHD) resolution with LED backlight
** 15.6" TFT display with 1920x1080 (FHD) resolution with LED backlight Multi Touch
* 2GB (1 DIMM) or 4GB (2 DIMMs) [[PC3-10600]] memory standard upgradable to 16GB (4 DIMM slots)
*One of the following storage options:
** 320GB 7200rpm 2.5" SATA HDD Available with [[Full Disk Encryption (FDE)]]
** 320GB 7200rpm 2.5" SATA HDD
** 500GB 7200rpm 2.5" SATA HDD
** 128GB 1.8" SATA SSD
** 160GB 1.8" SATA SSD
** 256GB 1.8" SATA SSD
* [[Intel Gigabit Ethernet (10/100/1000) PCI-Express]]
* Intel HD Audio with a [[CX20585]] codec
* [[ThinkPad Modem (MDC-3.0, 56kbps HDA)]]
* [[Ultrabay|Ultrabay Enhanced]] with one of the following:
** [[Serial UltraBay Enhanced DVD Burner II]]
* [[MiniPCI Express slot]] 1 with one of the following:
** [[Intel Centrino Ultimate-N 6300]]
** [[Intel Centrino Advanced-N + WiMAX 6250]]
* [[MiniPCI Express slot]] 2 with one of the following:
** None (empty)
** [[Qualcomm Gobi 2000]] WWAN with GPS
* [[ExpressCard slot|ExpressCard/34 slot]]
* [[Lenovo Integrated Smart Card Reader]] (Optional)
* [[Ricoh 5-in-1 MultiCard Reader|5-in-1 MultiCard Reader]]
* 2.0MP [[Integrated camera]] on select models
* Color Sensor on select models
* [[Embedded Security Subsystem|Trusted Computing Group TPM 1.2]]
* [[Active Protection System]]
* [[Integrated Fingerprint Reader]] on select models
* [[ThinkPad Bluetooth with Enhanced Data Rate (BDC-2.1)|Bluetooth]] on select models
* [[UltraNav]] (TrackPoint / Touchpad combo)
* [[Firewire Port|Firewire 400]] (IEEE1394a)
* [[DisplayPort]]
* [[Intel Active Management Technology (AMT)]] on select models

</div>
|style="vertical-align:top" |
[[Image:ThinkPadW510.jpg|ThinkPad W510|300px]]
|}

=== Linux Installation ===

As of 2010-03-01 the following problems exist with the W510 under Linux:

* Audio on some W510's has been "destroyed" after running for a while. It has been confirmed that speakers have melted in t400s and t410s as well, this is unrelated to Linux.
* nVidia FX 880M requires driver >= 195.36.15. Earlier versions have stability or graphics corruption problems.
* To enable brightness control in X, append 'Option "RegistryDwords" "EnableBrightnessControl=1"' to the Device-Section of xorg.conf, orginal source: http://www.nvnews.net/vbulletin/showthread.php?p=2204839#post2204839. This may result in a high-pitched whine after lowering the brightness within X. Brightness may not be lowered and raised in the same increments on Archlinux.
* Suspend not implemented yet in USB 3.0 (xhci) driver - system cannot suspend unless driver is unloaded first - https://bugs.launchpad.net/ubuntu/+source/linux/+bug/522998
** xhci driver was renamed to xhci_hcd in Ubuntu 10.10 (Maverick Meerkat). Also, iwlagn may need to be unloaded as well - https://bugs.launchpad.net/ubuntu/+source/linux/+bug/664398
** xhci suspend has finally been included in kernel 2.6.37. You don't need module unloading tricks anymore.
* System can only resume from suspend once - acpi related kernel crash occurs on resume (but system continues to operate), next resume shows BIOS screen and hangs - https://bugzilla.kernel.org/show_bug.cgi?id=15407
* Lenovo has issued a www-307.ibm.com/pc/support/site.wss/MIGR-74858.html BIOS update that fixes the 2nd suspend problem (c.f. bugs.launchpad.net/bugs/532374 Ubuntu bug tracker)
* TEMPORARY WORKAROUND for suspend issues: Use kernel > 2.6.33 mainline and add "acpi_sleep=sci_force_enable" to kernel arguments. This allows the system to suspend and resume multiple times without issue, however it doesn't fix it the "right" way. Lenovo BIOS update mentioned above will eliminate the need for this step.
* Wired networking stuck at 10Mbit without manual change using ethtool. For Ubuntu Karmic this can easily be fixed by manually downloading and installing the [http://bit.ly/bTvbWx e1000e driver from Intel]. After installing this driver however, the wireless stopped working me.
(NOT true for me on kernel 2.6.33 ethtool says " Speed: 1000Mb/s " -[[User_talk:mstragowski|mstragowski]])

* Archlinux before version 2010.5 cannot easily be configured, as the wireless and ethernet cards both require drivers that are not present in the 2009.08 release. This may be a problem for other distros, as well. With Archlinux 2010.5, ethernet works out of the box and wireless works after kernel update.'''
* While Turbo Boost IS working properly with recent distros, built in Linux utilities do not currently show Turbo Boost activity. Intel Powertop or i7z will show actual CPU state properly, including Turbo Boost and advanced C-states. Can be verified running Ubuntu Lucid and compiling a kernel or other tasks, WHILE ON AC POWER.
* 2-finger scroll on touchpad not working even wtih gpointing-device-settings

Option "EmulateTwoFingerMinZ" "4"
Option "VertEdgeScroll" "off"
Option "HorizEdgeScroll" "off"
Option "VertTwoFingerScroll" "on"

in the synaptics section in xorg.conf solved that one for me
(EmulateTwoFingerMinZ is the relevant part here I think.)

* The fingerprint reader (USB ID 147e:2016) is recognized by fprint and should be supported. However, attempting to enroll a print results in an error "-22". Using proprietary driver found at http://www.upek.com/solutions/pc_and_networking/sdks/linux/ allows using this new chip. Using fingerprint from software http://www.pdfserver.net/fingerprint helps working with this reader.

* If you find the flashing wireless LED annoying, you can change its behavior so it will be on steady whenever the radio is powered on, and off when the radio is off. Add "options iwlcore led_mode=1" to /etc/modprobe.d/iwlcore.conf to set the LED on steady, or you can set led_mode=0 to have it flash whenever there is wireless activity (default)

* XEN and W510 - After trying numerous combinations of Linux distributions & XEN to get the W510 running a dom0 the problem was well-integrated XEN environments with no support for the W510 or new distributions (like Ubuntu) fixing driver problems but no XEN support whatsoever. I have (false?) hope that XEN and ubuntu will one day work again.... but I got through manual compilation, having Ubuntu 10.04 (jeremy git at 2.6.32-14) dom0 booting ok (with some manual grub editing for Ubuntu) but stuck at 800x600 graphics as NVIDIA driver seems to lock up the kernel and no success getting Nouveau working in a dom0 environment. No matter what flags or changes I made to the grub startup and/or blacklisting drivers etc as per online guides made any difference. SO.... an alternative while XEN ubuntu kernel makes its way towards 2.6.34... I tried OpenSuse 11.3 milestone 7 and it worked flawlessly with full resolution graphic support using Nouveau (2.6.34-8) in a dom0. Note: you have to enable VT-d support in BIOS if you want HVM support. But presently having networking issues getting an HVM to launch without hotplugin script errors (https://bugzilla.novell.com/show_bug.cgi?id=612006) --[[User:Diti2202|Diti2202]] 21:25, 6 June 2010 (UTC)

* Memory - Only since Bios version 1.24 you may use more than 3GB under amd64 Linux --[[User:carpf|carpf]])

Workarounds:'''

* On Ubuntu Karmic, Wireless can be enabled by installing linux-backport-modules-karmic. This adds missing firmware for 6000-series cards. This does not seem to work with the 2.6.31-20 kernel but I have no problems in the 2.6.31-19.
* All Versions: System cannot suspend unless <nowiki>SUSPEND_MODULES="xhci"</nowiki> (on ArchLinux with 2.6.35 the Module is called "xhci_hcd") is added to /etc/pm/config.d/unload_modules (may need to create this file) Note that this does not resolve the "crash on second resume" problem.
* On archlinux, ethernet will work after one manually installs the newest kernel26 package, while wifi requires the appropriate microcode package, iwlwifi-6000-ucode.
* The Nouveau open source nVidia driver [http://www.nvnews.net/vbulletin/showpost.php?p=2194707&postcount=20] works at full resolution without freezing (but without 3D acceleration). This driver is included in Ubuntu Lucid. Note that you may experience elevated (but safe) system temperatures when running Nouveau.
* Full touchpoint support can be activated by installing <nowiki>gpointing-device-settings</nowiki> - this allows middle click scroll, etc.
* To control brightness without the (admittedly minor) nvidia driver issues, do not add the EnableBrightnessControl option, but instead switch to a virtual console to change the brightness--this change will remain when you switch back to X.

=== Hardware notes ===
* The W510 ships with a large (nearly doubled size of the 90W version) 135W power supply. However, it is possible to plug 90W power supplies, but they get rather warm. Upon boot there's a notification message, that a power supply with reduced performance is connected. '''Note''': In order to avoid overloading the weaker power supply, the CPU is throttled drastically and usually does not go above 400 Mhz.
* If the binary nVidia drivers are not installed the system runs about 10 degrees warmer and uses a few watts more power. It seems the open source 'nouveau' driver does not have power saving functionality with the nVidia chipset. The program "nvclock" might be able to alleviate this, but I haven't tried.
* A high pitched noise can sometimes be heard when the computer is running. I was informed that this is the CPU's power management unit. If it annoys you it can be disabled in the BIOS.
* The computer does not boot at all when some USB keyboards are plugged in at power on. This is a problem with the BIOS and not with Linux or Windows. The only solution is to unplug the keyboard and plug it in again once the laptop is past the BIOS screen and booting as normal.
* After upgrading to Ubuntu 10.04 the system hangs very often. Nothing unusual in dmesg or system logs. Seems to happen more often when using wireless. (see bug https://bugs.launchpad.net/bugs/576352)
** this is mostly alleviated by updating to Nvidia driver version 256 (now higher) from the SWAT reposistory for Ubuntu. https://launchpad.net/~ubuntu-x-swat/+archive/x-updates. Also throttle the clock speed of the GPU to the minimum (reducing heat) following guidelines from here: http://linux.aldeby.org/nvidia-powermizer-powersaving.html to pretty much end the hangs. Issue has been seen to exist on Windows and Ubuntu. Current Nvidia drivers (v.256+) appear to reduce (but not solve) the problem on both platforms.

[[Category:W Series]]

Talk:Qualcomm Gobi 2000

2010-12-27T08:30:51Z

Zarhan: /* GPS */

Talk:Qualcomm Gobi 2000

2010-11-29T15:25:29Z

Zarhan: /* GPS */ Tried newer firmware, no go.

== Firmware ==

I found out a way to get the firmware on a linux-only system. Mine is a debian squeeze, but it should apply to any system.

First, I entered my model number on the [http://www.lenovo.com/support/ Lenovo support page] in the right siderow (Select you system / Quick Path) to get to my drivers page. There I clicked to download drivers and on the UMTS drivers. Afterwards I downloaded the "<code>7xwc42ww.exe</code>" driver package.

You dont need to enter your serial number to the lenovo support page. With some googling i came up with [http://www-307.ibm.com/pc/support/site.wss/MIGR-72938.html this] page. This is very useful for all those owning a laptop not built by lenovo. ([[User:Bob the builder|bob]])

With wine I was able to install the driver package, but all it does, was unpacking the GOBI driver setup. This one comes packaged as a <code>.msi</code> file, so we have to [http://sysblogd.wordpress.com/2008/05/10/howto-extract-all-files-from-microsoft-installer-files-msi-rather-than-to-install-the-package/ unpack] it:

user@machine:~$ wine msiexec /a ~/.wine/drive_c/DRIVERS/WWANQL/Driver/GobiInstaller.msi TARGETDIR=C:\\DRIVERS\\GOBI

The installer quits with errors, but leaves the files on the disk, success. But now there are several subdirectories, in which the files for the specific network operators reside:

{| {{prettytable}}
! Dir !! Image !! Remarks
|-
| 0 || Vodafone Image ||
|-
| 1 || Verizon Image ||
|-
| 2 || ATT Image ||
|-
| 3 || Sprint Image || includes special Firmware
|-
| 4 || T-Mobile Image ||
|-
| 6 || Generic UMTS Image ||
|-
| 7 || Telefonica Image ||
|-
| 8 || Telecom Italia Image ||
|-
| 9 || Orange Image ||
|-
| 12 || DoCoMo Image || includes special Firmware
|-
| UMTS || Default Firmware || the MD5-sum on the page matches these
|}
t

I found this out by reading the <code>ReadMe.rtf</code>, looking into the <code>UQCN.mbn</code>-Files and apply a little bit of thinking.

Now I'll move the files over and try them out.
------------------------------------------------------------------------------------------------------------------------------------------

So I got the Sprint Image with firmware, how does one flash the Gobi with this firmware?

You do not need to flash the gobi as such. Firmware must be loaded at every boot. Simply use the gobi_loader mentioned on the main page, with the 3 firmware files from the sprint directory. You will need to modify it to match your USB IDs. After the firmware it loaded it will last until you power off your laptop. I usually reboot after loading the firmware, but before trying to use the modem. The firmware remains loaded. [[User:Catphish|Catphish]]

--
I appear to have got the WWAN portion functioning but can't find any reference to anyone using the GPS part. Does this work under Linux yet? [[User:Bjb|Bjb]]

For me this images work with eplus germany --[[User:Lynxis|Lynxis]] 23:13, 8 June 2010 (UTC)

84d002b0ef003cde6c95826bfbf067fe /lib/firmware/gobi/amss.mbn
d7496085f1af3d1bfdf0fa60c3222766 /lib/firmware/gobi/apps.mbn
c3d6fd93ae2e52775ef9cd8fccbc20be /lib/firmware/gobi/UQCN.mbn

$ find -type f -exec md5sum {} \; | sort -k 2
c3d6fd93ae2e52775ef9cd8fccbc20be ./0/UQCN.mbn
4d6203bf9fe8ae1af439d4d163e91596 ./12/amss.mbn
385a22740f80c0d00f8acdd9ad637032 ./12/apps.mbn
e868df00bfa88596d588a52f872ff703 ./12/UQCN.mbn
48191d62dc4091fb9d23e0b947611c58 ./1/amss.mbn
4f46a856fcceb197943d0cf3257c3621 ./1/apps.mbn
bb05d912e27b822348d4de93fc3ac911 ./1/UQCN.mbn
ff935ec4da6f6711b48caaddcf737566 ./2/UQCN.mbn
4f74d79ed8df027db3b75e36feb2bd27 ./3/amss.mbn
d9ff7b27c491332650b1efbbee64ee31 ./3/apps.mbn
6f6462fe0cc185cc3dc24720a28770fb ./3/UQCN.mbn
46418504e70971bda7b2ee34cc80b5b7 ./4/UQCN.mbn
1aa5727b034dd1f371a3412d5800c1a3 ./6/UQCN.mbn
9f6773625d59098f9360c24263d99615 ./7/UQCN.mbn
e012286117c0c7708369f8dbc7906e64 ./8/UQCN.mbn
c65246da47695b4ecaaf098a02718c9d ./9/UQCN.mbn
84d002b0ef003cde6c95826bfbf067fe ./UMTS/amss.mbn
d7496085f1af3d1bfdf0fa60c3222766 ./UMTS/apps.mbn

For me this tutorial above worked, too. Is there anything which prevents us from copying it to the page itself? --[[User:Aneiser|Aneiser]] 20:58, 21 August 2010 (UTC)

== 2.6.32, 2.6.34, git snapshots and later ==

so it's working with recent kernels or no? And add any info about GPS, please. [[User:Tensai.cirno|Tensai.cirno]] 02:26, 16 June 2010 (UTC)

I had no luck with 2.6.34. however i tested 2.6.35-rc3 + gobi_loader 0.6 and it worked. had to load the firmware by hand though ...
"/lib/udev/gobi_loader -2000 /dev/ttyUSB0 /lib/firmware/gobi" but i guess the id in the udev file is not the right one for my card. --[[User:Max p|Max p]] 02:09, 22 June 2010 (UTC)

Thanks a lot, this is ''very good'' news. [[User:Tensai.cirno|Tensai.cirno]] 06:54, 23 June 2010 (UTC)

Yes, with 2.6.35 and gobi_loader 0.7 it works for me (T510, O2 Germany, Generic firmware) --[[User:Aneiser|Aneiser]] 21:00, 21 August 2010 (UTC)

The modem also works with 2.6.36 (2.6.36-1~experimental.1) and gobi-loader 0.6.1 from current Debian Testing/Sid/Experimental. GPS doesn’t, although I did apply the patch; /dev/ttyUSB2 doesn't output anything at all – maybe testing outside is necessary. [[User:X2017|X2017]] 20:44, 14 November 2010 (UTC)

== GPS ==

Has anyone managed to get GPS to work yet? I think one has to send certain AT commands to receive the NMEA information (at least that is how it works with some Ericsson modems).
Unfortunately I can't find an AT command reference for the Qualcomm Gobi 2000 ...
[[User:Flyser|Flyser]] 14:15, 27 July 2010 (UTC)

i was asking the qualcomm support about that subject, handing out all AT commands. lets say it that way they were not very cooperative. but you could ask them as well, maybe you got more effective than me and we can have the commands :)--[[User:Max p|Max p]] 09:10, 4 August 2010 (UTC)

so did I. I was told to contact Lenovo about the issue -.- --[[User:Flyser|Flyser]] 08:10, 9 August 2010 (UTC)

You can find the documentation and sdk [http://gobianywhere.com/sdk/index.php here]. However I didn't find any useful AT commands, and I think the SDK is win only. [[User:bbandi|bbandi]] 22:32, 14 August 2010 (UTC)

Did you try to install the SDK? Is it possible to analyze how GPS works? --[[User:Aneiser|Aneiser]] 22:00, 21 August 2010 (UTC)

Has anyone managed to get GPS to work with the information published on this wiki page? I get all three devices (ttyUSB[012]), but ttyUSB2 does not output anything. Do I have to connect to a wireless network to get this to work? Could someone publish a more detailed guide how to _use_ the gps? I tried:
# cat /dev/ttyUSB2 &
# echo -n "\$GPS_START" > /dev/ttyUSB2
--[[User:Flyser|Flyser]] 11:03, 30 September 2010 (UTC)

I also cannot get the GPS to work even with the new instructions. Googling around, I found that the start string could be "$GPS-START" (Hyphen instead of underline). However, this doesn't work either. The GPS *did* work on the preinstalled Windows 7. I'm using basic UMTS firmware (firmware from folders "UMTS" and "6").
--[[User:Zarhan|Zarhan]] 06:40, 1 October 2010 (UTC)

I was able to get it to work on a X201, after using the 6/UQCN.mbn image from my Windows 7 x64 partition. This seems to be different from the files/checksums above:
root@polaris:~# md5sum /lib/firmware/gobi/*.mbn
84d002b0ef003cde6c95826bfbf067fe /lib/firmware/gobi/amss.mbn
d7496085f1af3d1bfdf0fa60c3222766 /lib/firmware/gobi/apps.mbn
68e46b936d5400862a0381b101af3972 /lib/firmware/gobi/UQCN.mbn

Now to seems to work:
root@polaris:~# cat /dev/ttyUSB2 &
[1] 3320
root@polaris:~# echo "\$GPS_START" > /dev/ttyUSB2; sleep 3; echo "\$GPS_STOP" > /dev/ttyUSB2
$GPGSA,A,1,,,,,,,,,,,,,,,*1E
$GPGSV,4,1,16,14,33,050,35,24,42,115,28,20,55,246,26,19,19,172,25*77
$GPGSV,4,2,16,11,75,237,,17,29,309,,23,07,192,,28,10,267,*7F
$GPGSV,4,3,16,31,08,106,,32,80,227,,30,,,,29,,,*72
$GPGSV,4,4,16,27,,,,26,,,,25,,,,22,,,*78
$GPGGA,192126.0,,,,,0,,,,,,,,*77
$PQXFI,192126.0,,,,,,,,*6B
$GPVTG,,T,,M,,N,,K,N*2C
$GPRMC,,V,,,,,,,,,,N*53
$GPGSA,A,1,,,,,,,,,,,,,,,*1E
$GPGGA,192127.0,52xx.xxxxxx,N,0xxxx.xxxxxx,E,1,05,1.8,30.6,M,46.0,M,,*61
$PQXFI,192127.0,52xx.xxxxxx,N,0xxxx.xxxxxx,E,30.6,80.58,93.58,3.17*5B
$GPVTG,nan,T,nan,M,0.0,N,0.0,K,A*23
root@polaris:~#

On Debian, using '/lib/udev/gpsd.hotplug add /dev/ttyUSB2' you can tell gpsd about the serial device.
--[[User:Shoragan|Shoragan]] 20:07, 11 October 2010 (UTC)

I'm using exactly same firmwares as Shoragan, and I can see the ttyUSB2 device - however, no NMEA data starts to appear after issuing $GPS_START. I'm using W510 --[[User:Zarhan|Zarhan]] 06:03, 13 October 2010 (UTC)

Same here: using {{openSUSE}} 11.3 with kernel of the day (2.6.37-rc3-3, includes the qcserial patches), gobi_loader 0.7 and current fw files from win partition:
* Gps works in win 7/64 ({{T510i}}) with drivers updated yesterday (most fw files have different md5 sums from those above)
* Copied fw from UMTS/ and 6/ to /lib/firmware/gobi/
* Usb device id changes from x9204 to x9205 automatically (fw gets loaded)
* 3 tty devices appear automatically (udev and module config is ok)
* Modem at ttyUSB1 is functional (at i command in minicom gives fw version and imei)
* ttyUSB0 and ttyUSB2 seem to be dead though (cat, minicom)
I'll try the other fw later and update if it changes something (I guess I have to powercycle between tests?) --[[User:Joban|Joban]] 14:54, 24 November 2010 (UTC)

I tried with newer firmware that comes with the latest WWan driver (driver version 2.0.7.3) at http://www-307.ibm.com/pc/support/site.wss/document.do?sitestyle=lenovo&lndocid=MIGR-72938&medium=rssW510#20101028 - still doesn't work. --[[User:Zarhan|Zarhan]] 15:25, 29 November 2010 (UTC)

Talk:Qualcomm Gobi 2000

2010-10-13T06:03:02Z

Zarhan: /* GPS */

Talk:Qualcomm Gobi 2000

2010-10-01T06:40:45Z

Zarhan: /* GPS */

Talk:Tp smapi

2007-05-13T16:32:25Z

Zarhan: /* Battery daemon feedback requested */

== Feedback ==

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.

--[[User:Spiney|spiney]] 21:25, 5 Dec 2005 (CET)
----
None of the fuctions is working on my T40, kernel 2.6.14-mm2.

--[[User:Lammic|lammic]], 2005.12.05

Works for me on a T41 running 2.6.12-10-686 (Ubuntu 5.10).

--[[User:berndtnm|berndtnm]], 2005.12.06

Including stop_charge_thresh? That one seems to be missing on the T42p.

--[[User:Thinker|Thinker]] 00:46, 7 Dec 2005 (CET)
----

tp_smapi works just fine on an R52 with Ubuntu Breezy stock kernel.

--[[User:Micampe|Micampe]] 12:52, 7 Dec 2005 (CET)

----

''To set the thresholds for starting and stopping battery charging (in percent of current capacity):''

'''current''' really? That'd be weird, I'd expect it to be percent of '''total''' capacity.

--[[User:Micampe|Micampe]] 14:39, 7 Dec 2005 (CET)

"Current full charge capacity", as opposed to "current remaining capacity" or "designed full charge capacity"...

--[[User:Thinker|Thinker]] 15:05, 7 Dec 2005 (CET)
----

Battery features don't work with my T41p. I can't check this with windows. Can anybody try these features?

-- Nils, 7 Dec 2005
----

Nils, does cdrom_speed work for you on the T41p? Could you provide the details requested in the README (dmesg etc.)?

--[[User:Thinker|Thinker]] 21:57, 7 Dec 2005 (CET)
----

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.

-- Nils, 8 Dec 2005
----

All the features except the stop_charge_thresh seem to work here on a t42p.
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,
and if I set it to 100 the battery charges all the way.

--[[User:Nirik|Nirik]] 16 Dec 2005
----

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?

--[[User:Thinker|Thinker]] 14:16, 16 Dec 2005 (CET)
----

System T40p:

<pre>
fairlight:/sys/devices/platform/smapi/BAT0# echo 1 > /sys/devices/platform/smapi/BAT0/force_discharge1
fairlight:/sys/devices/platform/smapi/BAT0# echo 1 > /sys/devices/platform/smapi/BAT0/force_discharge2
fairlight:/sys/devices/platform/smapi/BAT0# dmesg
tp_smapi: req_in: BX=2118 CX=100 DI=0 SI=0
tp_smapi: req_out: AX=8680 BX=2118 CX=100 DX=b2 DI=0 SI=0 ret=-38
tp_smapi: SMAPI error: Function is not supported by SMAPI BIOS (func=2118)
tp_smapi: cannot get force_discharge1 of battery 0: Function is not supported by SMAPI BIOS
tp_smapi: req_in: BX=2104 CX=100 DI=0 SI=0
tp_smapi: req_out: AX=80 BX=2103 CX=100 DX=78 DI=0 SI=0 ret=0
tp_smapi: cannot get force_discharge2 of battery 0: bx=2103
</pre>

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.

--[[User|StefanSchmidt]]

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.

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.

--[[User:Thinker|Thinker]] 21:42, 16 Dec 2005 (CET)

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.

--[[User:StefanSchmidt]]
----

Someone reported cd_speed works on T42 but on mine, it doesn't: this is 2378DXU

--[[User:eBug]] 22:55, 17 Dec 2005 (CET)
----

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?

--[[User:Thinker|Thinker]] 11:53, 18 Dec 2005 (CET)
----

To confirm:
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.

--[[User:LJSBRokken|LJSBrokken]] 21 Dec 2005
----

tp_smapi version 0.13 with T23 (2647-3QG) (I have dual batteries)...

None of the functions which make any changes work...

<pre># cd /sys/devices/platform/smapi && cat BAT*/* > /dev/null
cat: BAT0/force_discharge1: Function not implemented
cat: BAT0/force_discharge2: Input/output error
cat: BAT0/inhibit_charge_minutes: Function not implemented
cat: BAT0/start_charge_thresh: Function not implemented
cat: BAT0/stop_charge_thresh: Function not implemented
cat: BAT1/force_discharge1: Function not implemented
cat: BAT1/force_discharge2: Input/output error
cat: BAT1/inhibit_charge_minutes: Function not implemented
cat: BAT1/start_charge_thresh: Function not implemented
cat: BAT1/stop_charge_thresh: Function not implemented</pre>

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.

--[[User:SystemParadox|SystemParadox]] 21:51, 4 Jan 2006 (CET)
----

SystemParadox, what's the dmesg output produced by "cat BAT0/force_discharge2"?

--[[User:Thinker|Thinker]] 22:02, 4 Jan 2006 (CET)
----

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:

<pre>
tp_smapi: tp_smapi 0.14 loading...
tp_smapi: successfully loaded (smapi_port=0xb2).
tp_smapi: req_in: BX=2114 CX=100 DI=0 SI=0
tp_smapi: req_out: AX=ea210080 BX=ec192114 CX=c18d0700 DX=f7cc00b2 DI=f7f50000 SI=c18d0000 ret=-5
tp_smapi: SMAPI error: Unknown error code (func=2114)
tp_smapi: cannot get inhibit charge of battery 0: Unknown error code
tp_smapi: req_in: BX=2116 CX=100 DI=0 SI=0
tp_smapi: req_out: AX=c03b0080 BX=c18d2116 CX=c0160328 DX=ec7600b2 DI=ec760000 SI=a0810000 ret=-5
tp_smapi: SMAPI error: Unknown error code (func=2116)
tp_smapi: cannot get start thresh of battery 0: Unknown error code
tp_smapi: req_in: BX=211a CX=100 DI=0 SI=0
tp_smapi: req_out: AX=c03b0080 BX=c18d211a CX=c016032c DX=eb4500b2 DI=eb450000 SI=241e0000 ret=-5
tp_smapi: SMAPI error: Unknown error code (func=211a)
tp_smapi: cannot get stop thresh of battery 0: Unknown error code
</pre>

--[[User:Spiney|spiney]] 08:12, 10 Jan 2006 (CET)
----

Oops, the transition to 32-bit SMAPI calls was broken. Fixed in 0.15. Thanks for the quick report!

--[[User:Thinker|Thinker]] 12:10, 10 Jan 2006 (CET)
----

Yep, 0.15 works again. Quick response, bravo! :)

--[[User:Spiney|spiney]] 12:23, 10 Jan 2006 (CET)
----

On a T22, nothing seems to work with 0.16.

[[http://www.rafb.net/paste/results/fcUUDs49.html|dmesg output]] when doing cat *

I am using an Ultrabay2000 battery, so it would be really usefull to be able to control that

--[[User:nusse|nusse]]
----

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?

--[[User:Thinker|Thinker]] 20:59, 11 Jan 2006 (CET)
----

I don't really know what 'extended battery' status means, but here an example:
<pre>
$ cat current_* /sys/devices/platform/smapi/BAT1
cat: current_avg: Input/output error
cat: current_now: Input/output error
</pre>
This is what happens when i cat any file in this directory and also in ../BAT1 :(

--[[User:nusse|nusse]] Thu Jan 12 22:07:26 CET 2006
----

Nusse: Yes, that's what I meant. What's the {{cmdroot|dmesg}} output generated by these commands?

--[[User:Thinker|Thinker]] 00:27, 13 Jan 2006 (CET)
----

Thinker: I attached some link to my first comment but it seems to be down and the link was wrong anyway.
<pre>
thinkpad controller read(%hx,%hx): failed writing to 0x1610
thinkpad controller read(%hx,%hx): failed writing to 0x1610
thinkpad controller read(%hx,%hx): failed writing to 0x1610
thinkpad controller read(%hx,%hx): failed writing to 0x1610
thinkpad controller read(%hx,%hx): failed writing to 0x1610
thinkpad controller read(%hx,%hx): failed writing to 0x1610
thinkpad controller read(%hx,%hx): failed writing to 0x1610
thinkpad controller read(%hx,%hx): failed writing to 0x1610
thinkpad controller read(%hx,%hx): failed writing to 0x1610
thinkpad controller read(%hx,%hx): failed writing to 0x1610
thinkpad controller read(%hx,%hx): failed writing to 0x1610
thinkpad controller read(%hx,%hx): failed writing to 0x1610
thinkpad controller read(%hx,%hx): failed writing to 0x1610
thinkpad controller read(%hx,%hx): failed writing to 0x1610
thinkpad controller read(%hx,%hx): failed writing to 0x1610
tp_smapi: SMAPI error: Function is not supported by SMAPI BIOS (func=2118)
tp_smapi: cannot get force_discharge of battery 0: Function is not supported by SMAPI BIOS
tp_smapi: SMAPI error: Function is not supported by SMAPI BIOS (func=2114)
tp_smapi: cannot get inhibit charge of battery 0: Function is not supported by SMAPI BIOS
thinkpad controller read(%hx,%hx): failed writing to 0x1610
thinkpad controller read(%hx,%hx): failed writing to 0x1610
thinkpad controller read(%hx,%hx): failed writing to 0x1610
thinkpad controller read(%hx,%hx): failed writing to 0x1610
thinkpad controller read(%hx,%hx): failed writing to 0x1610
thinkpad controller read(%hx,%hx): failed writing to 0x1610
thinkpad controller read(%hx,%hx): failed writing to 0x1610
thinkpad controller read(%hx,%hx): failed writing to 0x1610
thinkpad controller read(%hx,%hx): failed writing to 0x1610
thinkpad controller read(%hx,%hx): failed writing to 0x1610
thinkpad controller read(%hx,%hx): failed writing to 0x1610
thinkpad controller read(%hx,%hx): failed writing to 0x1610
thinkpad controller read(%hx,%hx): failed writing to 0x1610
thinkpad controller read(%hx,%hx): failed writing to 0x1610
thinkpad controller read(%hx,%hx): failed writing to 0x1610
tp_smapi: SMAPI error: Function is not supported by SMAPI BIOS (func=2116)
tp_smapi: cannot get start thresh of battery 0: Function is not supported by SMAPI BIOS
thinkpad controller read(%hx,%hx): failed writing to 0x1610
thinkpad controller read(%hx,%hx): failed writing to 0x1610
tp_smapi: SMAPI error: Function is not supported by SMAPI BIOS (func=211a)
tp_smapi: cannot get stop thresh of battery 0: Function is not supported by SMAPI BIOS
thinkpad controller read(%hx,%hx): failed writing to 0x1610
thinkpad controller read(%hx,%hx): failed writing to 0x1610
</pre>

--[[User:nusse|nusse]] Fri Jan 13 14:35:57 CET 2006
----

Nusse: Thanks; but there's not much we can do. Maybe the T22 uses a different interface, or doesn't have that feature.

--[[User:Thinker|Thinker]] 23:23, 15 January 2006 (CET)
----

Thinker: Is there anything I can do to check if the interface is different? Changing 0x1610 to some random number?

Is there a chance to get it by try and error?

--[[User:nusse|nusse]] Mon Jan 16 19:10:12 CET 2006
----

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

The only way I can think of for figuring out the T22 interface is to see what the Windows software does.

--[[User:Thinker|Thinker]] 19:47, 16 January 2006 (CET)
----

I have a R40 (2722-B3G), and several things don't work with 0.16 on linux 2.6.15.1:

<pre>
tp_smapi: SMAPI error: Function is not supported by SMAPI BIOS (func=2118)
tp_smapi: cannot get force_discharge of battery 0: Function is not supported by SMAPI BIOS
tp_smapi: SMAPI error: Function is not supported by SMAPI BIOS (func=2114)
tp_smapi: cannot get inhibit charge of battery 0: Function is not supported by SMAPI BIOS
tp_smapi: SMAPI error: Function is not supported by SMAPI BIOS (func=2116)
tp_smapi: cannot get start thresh of battery 0: Function is not supported by SMAPI BIOS
tp_smapi: SMAPI error: Function is not supported by SMAPI BIOS (func=211a)
tp_smapi: cannot get stop thresh of battery 0: Function is not supported by SMAPI BIOS
</pre>

Don't know about Windows, haven't booted it for weeks nor used it for years...

--[[User:Wonka|Wonka]] 19:00, 19 January 2006 (CET)
----

Wonka: do the other features (i.e., extended battery status) work on your R40?

--[[User:Thinker|Thinker]] 20:30, 20 January 2006 (CET)
----

--[[User:lisch|lisch]] 16:14, 11 April 2006 (CDT)

On my X32, with two batteries, I get just what I expect. Looks good:
<pre>$ cat BAT?/* > /dev/null
cat: BAT0/force_discharge: Function not implemented
cat: BAT0/inhibit_charge_minutes: Function not implemented
cat: BAT0/start_charge_thresh: Function not implemented
cat: BAT0/stop_charge_thresh: Function not implemented
cat: BAT1/force_discharge: Function not implemented
cat: BAT1/inhibit_charge_minutes: Function not implemented
cat: BAT1/start_charge_thresh: Function not implemented
cat: BAT1/stop_charge_thresh: Function not implemented
$
</pre>
==Changing the CD speed when the CD is being accessed will hang your computer==

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.

-- Stefan Schmidt
----

An open file looks fine if you're not reading/writing at that point. But my T43 does hangs on this:
# dd if=/dev/scd0 of=/dev/null &
# echo 1 > /sys/devices/platform/smapi/cdrom_speed

--[[User:Thinker|Thinker]] 16:41, 7 Dec 2005 (CET)
----

OK, sorry. I was to fast. My system hangs on this commands, too. :(

-- Stefan Schmidt

Works well. Great.

T42 2373-8zh. Working :cdrom_speed and start_charge_thresh. Untest : inhibit_charge_minutes.

-- Haifeng Chen

cdrom_speed works on my T40.

-- [[User:Lammic|lammic]], 2005.12.09

== Kernel Patch? ==

Hello Thinker,

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)

''(deleted, see below for how to create a patch file)''

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.

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

--[[User:Spiney|spiney]] 09:52, 16 Dec 2005 (CET)
----

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?

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.

BTW, the convention for kernel patches is to start them once level higher:
diff -Nurp kernel-2.6.14-vanilla kernel-2.6.14-patched

--[[User:Thinker|Thinker]] 17:12, 16 Dec 2005 (CET)
----

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

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

--[[User:Spiney|spiney]] 18:36, 16 Dec 2005 (CET)
----

If it does that on a local copy (no changes the original kernel tree) and cleans up after itself, that's fine with me. :-)

--[[User:Thinker|Thinker]] 18:50, 16 Dec 2005 (CET)
----

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

<pre>
#!/bin/bash

KDIR=/lib/modules/$(uname -r)/build
FDIR=drivers/firmware
OPWD=$(pwd)

TMPDIR=$(mktemp -d)
cd $TMPDIR

mkdir -p a/$FDIR
cp $KDIR/$FDIR/{Kconfig,Makefile} a/$FDIR
cp -r a b
sed -i -e '/endmenu/i\
config IBM_SMAPI\
tristate "IBM ThinkPad SMAPI Support"\
depends on X86\
---help---\
This adds SMAPI support on IBM ThinkPads, mostly used for battery\
charge control. For more information about this driver see\
<http://www.thinkwiki.org/wiki/SMAPI_support_for_Linux> .\
\
If you have an IBM ThinkPad laptop, say Y or M here.\
' b/$FDIR/Kconfig
sed -i -e '$a\
obj-$(CONFIG_IBM_SMAPI) += tp_smapi.o' b/$FDIR/Makefile
cp $OPWD/tp_smapi.c b/$FDIR
diff -Nurp a b > $OPWD/tp_smapi-$(uname -r).patch
rm -r a b
cd $OPWD
</pre>

BTW, [http://qbnz.com/highlighter/ GeSHi]-based syntax-highlighting would be great...

--[[User:Spiney|spiney]] 19:28, 16 Dec 2005 (CET)
----

Ah, neat sed foo. How about [http://tpctl.sourceforge.net/tmp/Makefile this] escapade, then?

What's the sed spell needed to replace the Makefile's
VER := 0.13
with auto-parsing of
#define TP_VERSION "0.13"
from tp_smapi.c?

--[[User:Thinker|Thinker]] 20:37, 16 Dec 2005 (CET)
----

Hmm, something like
VERFROMC=$(sed -ne 's/^#define TP_VERSION "$.*$"/\1/gp' tp_smapi.c)
sed -i -e "s/^VER := .*$/VER := $VERFROMC/" Makefile
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.

--[[User:Spiney|spiney]] 20:44, 16 Dec 2005 (CET)
----

Makefile escaping is horrible, keep avoiding it... Anyway, the updated [http://tpctl.sourceforge.net/tmp/Makefile make patch] seems to do the right thing.

--[[User:Thinker|Thinker]] 21:36, 16 Dec 2005 (CET)
----

Small documentation request: just needed to create a patch for the not-yet-installed 2.6.16-rc2, which is no problem with
make KSRC=/path/to/linux-2.6.16-rc2 KVER=2.6.16-rc2 patch
but I guess it would be a good addition to the README file. :)

--[[User:Spiney|spiney]] 10:48, 8 February 2006 (CET)
----

Right, added (to next release).

--[[User:Thinker|Thinker]] 13:40, 8 February 2006 (CET)
----

==Installation questions==
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:

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

2. I don't have the cd speed control function. Here is what I have under /sys/devices/platform/smapi/:

./ ../ ac_connected BAT0/ BAT1/ bus@ driver@ power/

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

When I have time, I'll install the new kernel to see if the problems are gone and report the result.

--[[User:68.51.153.96|68.51.153.96]] 04:31, 2 Jan 2006 (CET)
----

1. It should stop charging at 70, but will only ''start'' charging when remaining capacity has dipped below <tt>start_charge_thresh</tt>.

2. See the note about PROVIDE_CD_SPEED.

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

--[[User:Thinker|Thinker]] 09:28, 2 Jan 2006 (CET)
----

Thanks Thinker.

1. I discharged and recharged the battery again. This time, it stops at 68% percent, which is pretty good.

2. I missed the NOTE in README, for I just followed this wiki. :P

3. My kernel version is 2.6.13-15.

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?

--[[User:Tyne|Tyne]] 00:14, 3 Jan 2006 (CET)
----

The note about PROVIDE_CD_SPEED is also in the Wiki...

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.

--[[User:Thinker|Thinker]] 08:48, 3 Jan 2006 (CET)
----
I spent hours, trying to compile this on ubuntu edgy without success. It starts with warnings about missing files:

<pre>
root@t40:/home/bernd/Desktop/tp_smapi-0.31/tp_smapi-0.31# make install
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
make[1]: Betrete Verzeichnis '/usr/src/linux-source-2.6.17'
/usr/src/linux-source-2.6.17/Makefile:450: .config: No such file or directory

WARNING: Symbol version dump /lib/modules/2.6.17-11-386/build/Module.symvers
is missing; modules will have no dependencies and modversions.

CC [M] /home/bernd/Desktop/tp_smapi-0.31/tp_smapi-0.31/thinkpad_ec.o
cc1: error: include/linux/autoconf.h: No such file or directory
[...]
</pre>
and then many thousand lines later it finally stops:
<pre>
[...]
/home/bernd/Desktop/tp_smapi-0.31/tp_smapi-0.31/thinkpad_ec.c:357: error: â€˜CONFIG_HZâ€™ undeclared (first use in this function)
/home/bernd/Desktop/tp_smapi-0.31/tp_smapi-0.31/thinkpad_ec.c: In function â€˜thinkpad_ec_invalidateâ€™:
/home/bernd/Desktop/tp_smapi-0.31/tp_smapi-0.31/thinkpad_ec.c:378: error: â€˜CONFIG_HZâ€™ undeclared (first use in this function)
/home/bernd/Desktop/tp_smapi-0.31/tp_smapi-0.31/thinkpad_ec.c: In function â€˜thinkpad_ec_initâ€™:
/home/bernd/Desktop/tp_smapi-0.31/tp_smapi-0.31/thinkpad_ec.c:460: error: â€˜CONFIG_HZâ€™ undeclared (first use in this function)
make[3]: *** [/home/bernd/Desktop/tp_smapi-0.31/tp_smapi-0.31/thinkpad_ec.o] Fehler 1
make[2]: *** [_module_/home/bernd/Desktop/tp_smapi-0.31/tp_smapi-0.31] Fehler 2
make[1]: *** [modules] Fehler 2
make[1]: Verlasse Verzeichnis '/usr/src/linux-source-2.6.17'
make: *** [modules] Fehler 2
</pre>

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.

[[User:7bit|7bit]] 07:42, 27 March 2007 (CEST)
----

== Formatting ==

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.

--[[User:Thinker|Thinker]] 17:04, 3 Jan 2006 (CET)
----
Hei Thinker,

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.

[[User:Wyrfel|Wyrfel]] 18:46, 3 Jan 2006 (CET)
----

== Dual battery operation with tp_smapi ==

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

The juicy details:

{{cmdroot|cd /sys/devices/platform/smapi/}}
{{cmdroot|cat ac_connected}}

{{cmdresult|0}}
{{cmdroot|cat BAT{0,1}/state}}
{{cmdresult|discharging}}
{{cmdresult|idle}}

{{cmdroot|echo 1 > BAT1/force_discharge1}}
{{cmdroot|cat BAT{0,1}/state}}
{{cmdresult|idle}}
{{cmdresult|discharging}}

Checking capacity values shows that the corrent battery is being depleted.

And remember, before you yank the CD/DVD drive out, issue:

{{cmdroot|cat eject > /proc/acpi/ibm/bay}}

----

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}})?

About the eject command, I think it should be possible to do that automatically when the Ultrabay handle is ejected, via <tt>acpid</tt>.

--[[User:Thinker|Thinker]] 15:45, 10 Jan 2006 (CET)
----

It's a T43 (2669). cat'ing force_discharge2 gives me an I/O error and I see

tp_smapi: cannot get force_discharge2 of battery 0: bx=2103

tp_smapi: cannot get force_discharge2 of battery 1: bx=2103

I find these errors irrelevant from the user's point of view, though.

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.

----

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

If you write those ACPI scripts, it would be great if you put them on the Wiki.

--[[User:Thinker|Thinker]] 16:31, 10 Jan 2006 (CET)
----

Well, I still do not preclude the fact that <tt>force_discharge2</tt> may be useful for something else on other models.

The ACPI scripts (as well as an installation guide) is underway. It may take a while, though.

----

See the new article: [[Using an Ultrabay battery]].

--[[User:Thinker|Thinker]] 17:05, 10 Jan 2006 (CET)
----

Hei Thinker,

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

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?

[[User:Wyrfel|Wyrfel]] 20:42, 10 Jan 2006 (CET)
----

ACK about the page rename (the old one did sound a bit out of line to my ear, but I couldn't spot why...).

About the splitting tp_smapi vs. thinkpad/tpctl, no objection.

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?

--[[User:Thinker|Thinker]] 21:04, 10 Jan 2006 (CET)
----
Ok, i agree on the latter.

[[User:Wyrfel|Wyrfel]] 00:57, 11 Jan 2006 (CET)
----

==Article name capitalization==

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

--[[User:Thinker|Thinker]] 11:03, 11 Jan 2006 (CET)
----

Impossible, according to [http://en.wikipedia.org/wiki/Wikipedia:Canonicalization Wikipedia:Canonicalization].

--[[User:Thinker|Thinker]] 12:04, 11 Jan 2006 (CET)
----

==Status Table==
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?

I also created <nowiki>{{Isup}}</nowiki> style templates for status, they just include images, like {{Isup}}.
Not emotional about it, just wanted to let you know in case you want to use them.

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"?

[[User:Wyrfel|Wyrfel]] 19:21, 11 Jan 2006 (CET)
----

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

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.

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.

--[[User:Thinker|Thinker]] 20:38, 11 Jan 2006 (CET)
----

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.

I'm ok with the rest.

[[User:Wyrfel|Wyrfel]] 22:35, 11 Jan 2006 (CET)
----

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

[[User:Peterco|Peterco]] 12:07, 28 February 2006 (CET)
----

== Z60t ==

Tested on Z60t. No errors using cat. Setting thresholds works. Status and capacity queries work. --[[User:Alon|Alon]] 21:44, 4 May 2006 (CEST)

== Problem setting thresholds with X40 ==

My X40, kernel 2.6.16 and tp_smapi 0.20. I try to set the thresholds to 40% and 90% using:
<pre>
# echo 90 > stop_charge_thresh
# echo 40 > start_charge_thresh
</pre>
which should work, and the kernel reports from dmesg:
<pre>
tp_smapi: successfully loaded (smapi_port=0xb2).
tp_smapi: battery 0: changed start threshold to 85(+1)
tp_smapi: battery 0: changed stop threshold to 90
tp_smapi: battery 0: changed start threshold to 39(+1)
</pre>
but, on confirmation here is what happens:
<pre>
# cat stop_charge_thresh
90
# cat start_charge_thresh
91
</pre>
Any clues as to why start doesn't keep? Or why its always at 1 above stop_charge_thresh?

--[[User:Xmm0|Xmm0]] 15:01, 17 May 2006 (CEST)
----

Is it any different if you first set start_charge_thresh and then stop_charge_thresh?

Can you please load tp_smapi with module option "debug=1" and report the dmesg output genereated by each command?

--[[User:Thinker|Thinker]] 16:31, 17 May 2006 (CEST)
----

== Battery daemon feedback requested ==

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.

By default, the machine fully discharges BAT1 first, and it is said that deep-cycling all the time dramatically shortens their lifetime.

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.

Currently there are two "modes" of the daemon:

Discharging mode.
<pre>
* look at the "remaining_percent" values for both batteries
* if one is more than THRESHOLD percent less than the other one,
force discharge from the battery with more capacity left
(the current value for THRESHOLD is 10%)
</pre>
I believe the preceeding will prevent either battery from being deep-cycled disproportionately.

Charging mode. I am less sure what the "right" algorithm is here. The following is a proposal.
<pre>
* look at the "remaining_percent" values for both batteries
* if one is more than THRESHOLD percent less than the other one,
force charging to the battery with less capacity left
* honor pre-set values in stop_charge_thresh and start_charge_thresh
</pre>

I would like to get feedback in the form of "better" algorithms or requests for this daemon.

--[[User:Zak Smith|Zak]] 19:03, 12 September 2006 (CEST)

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.

--[[User:Thinker|Thinker]] 22:57, 12 September 2006 (CEST)

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.

I have also noticed that the reported remaining runtimes vary greatly between acpi, the applet, and /proc/acpi/battery/*/state

--[[User:Zak Smith|Zak]] 21:46, 14 September 2006 (CEST)

What do you mean by "acpi" vs. "/proc/acpi/battery/*/state"?

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.

--[[User:Thinker|Thinker]] 12:07, 15 September 2006 (CEST)

By acpi, I meant the output of the acpi (1) command. I'll get some comparative numbers later and post them here.

--[[User:Zak Smith|Zak]] 20:37, 15 September 2006 (CEST)

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

--[[User:Thinker|Thinker]] 21:32, 15 September 2006 (CEST)

I have been running batteryd for a while with good results. I will upload it here shortly.

I disabled the preferential charging mode, and only control discharging.

--[[User:Zak Smith|Zak]] 23:15, 14 November 2006 (CET)

http://demigod.org/~zak/src/batteryd.cc

--[[User:Zak Smith|Zak]] 20:18, 5 December 2006 (CET)

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?

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.

Can you add a check to the condition if (b0->on_ac == 0) ...change this to

if ((b0->on_ac == 0) && (b0->installed == 1) && (b1->installed == 1))

then the equal discharging logic would handle hotswapping too (ie. situations where you're running only on 1 battery instead of 2).

I hope you keep on honing this.

One of the few things I miss from Dell is that when operating with dual batteries, it discharges both of them evenly.

--[[User:Zarhan|Zarhan]] 18:31, 13 May 2007 (CEST)

== Instructions for X60 with Bios 1.11 under Debian Etch ==

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!

--[[User:PeterBursch|PeterBursch]] 21:39, 15 September 2006 (CEST)

== tp_smapi 0.30 with kernel 2.6.20? ==

<pre>T60:~/tp_smapi-0.30# uname -rm
2.6.20 x86_64

T60:~/tp_smapi-0.30# make load
if lsmod | grep -q '^hdaps '; then rmmod hdaps; fi
if lsmod | grep -q '^tp_smapi '; then rmmod tp_smapi; fi
if lsmod | grep -q '^thinkpad_ec '; then rmmod thinkpad_ec; fi
if lsmod | grep -q '^tp_base '; then rmmod tp_base; fi # old thinkpad_ec
make -C /lib/modules/2.6.20/source M=/root/tp_smapi-0.30 O=/lib/modules/2.6.20/build modules
make[1]: Entering directory `/usr/src/linux-2.6.20'
CC [M] /root/tp_smapi-0.30/thinkpad_ec.o
/root/tp_smapi-0.30/thinkpad_ec.c:83: warning: type defaults to 'int' in declaration of 'DECLARE_MUTEX'
/root/tp_smapi-0.30/thinkpad_ec.c:83: warning: parameter names (without types) in function declaration
/root/tp_smapi-0.30/thinkpad_ec.c: In function 'thinkpad_ec_lock':
/root/tp_smapi-0.30/thinkpad_ec.c:94: warning: implicit declaration of function 'down_interruptible'
/root/tp_smapi-0.30/thinkpad_ec.c:94: error: 'thinkpad_ec_mutex' undeclared (first use in this function)
/root/tp_smapi-0.30/thinkpad_ec.c:94: error: (Each undeclared identifier is reported only once
/root/tp_smapi-0.30/thinkpad_ec.c:94: error: for each function it appears in.)
/root/tp_smapi-0.30/thinkpad_ec.c: In function 'thinkpad_ec_try_lock':
/root/tp_smapi-0.30/thinkpad_ec.c:109: warning: implicit declaration of function 'down_trylock'
/root/tp_smapi-0.30/thinkpad_ec.c:109: error: 'thinkpad_ec_mutex' undeclared (first use in this function)
/root/tp_smapi-0.30/thinkpad_ec.c: In function 'thinkpad_ec_unlock':
/root/tp_smapi-0.30/thinkpad_ec.c:122: warning: implicit declaration of function 'up'
/root/tp_smapi-0.30/thinkpad_ec.c:122: error: 'thinkpad_ec_mutex' undeclared (first use in this function)
make[3]: *** [/root/tp_smapi-0.30/thinkpad_ec.o] Error 1
make[2]: *** [_module_/root/tp_smapi-0.30] Error 2
make[1]: *** [modules] Error 2
make[1]: Leaving directory `/usr/src/linux-2.6.20'
make: *** [modules] Error 2
</pre>

:Works here with 2.6.21-rc1 (didn't try 2.6.20) without problems --[[User:Zhenech|Zhenech]] 14:32, 22 February 2007 (CET)

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

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):
<pre>
diff -Naur tp_smapi-0.30/hdaps.c tp_smapi-0.30-64bit_fix/hdaps.c
--- tp_smapi-0.30/hdaps.c 2006-09-03 12:13:34.000000000 +0200
+++ tp_smapi-0.30-64bit_fix/hdaps.c 2007-03-07 00:43:26.000000000 +0100
@@ -34,6 +34,7 @@
#include <linux/timer.h>
#include <linux/dmi.h>
#include <linux/thinkpad_ec.h>
+#include <linux/jiffies.h>

/* Embedded controller accelerometer read command and its result: */
static const struct thinkpad_ec_row ec_accel_args =
diff -Naur tp_smapi-0.30/thinkpad_ec.c tp_smapi-0.30-64bit_fix/thinkpad_ec.c
--- tp_smapi-0.30/thinkpad_ec.c 2006-09-02 21:46:18.000000000 +0200
+++ tp_smapi-0.30-64bit_fix/thinkpad_ec.c 2007-03-07 00:43:13.000000000 +0100
@@ -34,6 +34,7 @@
#include <linux/delay.h>
#include <linux/thinkpad_ec.h>
#include <linux/jiffies.h>
+#include <asm/semaphore.h>
#include <asm/io.h>

#define TP_VERSION "0.30"
</pre>
Copy the above to {{path|64bit_fix.patch}}, enter the {{path|tp_smapi-0.30}} directory and type
:{{cmduser|patch -p1 < /path/to/64bit_fix.patch}}
Now cross your fingers and compile as normal.
--[[User:Esmil|Esmil]] 01:06, 7 March 2007 (CET)
: tp_smapi 0.31 fixes this issue --[[User:Esmil|Esmil]] 19:22, 8 March 2007 (CET)

== X60: tp_smapi 0.31 with kernel 2.6.20 issue ==
[[category:X60]]
1st of all: Thanks alot for your work. I do really appreciate this (tp_smapi/thinkwiki).

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.

--[[User:Runia|Runia]] 23:48, 16 April 2007 (CEST)

Is this consistently reproducible? What's the oops message and stackdump (you can snap a digicam shot)? Does this happen when...
* rebooting with tp_smapi loaded but hdaps not loaded?
* rebooting with neither tp_smapi nor hdaps loaded?
* rebooting with vanilla hdaps loaded (instead of the tp_smapi version)?
* removing just these modules ("rmmod") instead of rebooting?

--[[User:Thinker|Thinker]] 01:56, 17 April 2007 (CEST)
----

== battery start/stop thresholds saved after reboot? ==

Hi

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

--[[User:Burp|Burp]] 15:31, 13 March 2007 (CET)
----

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.

--[[User:Thinker|Thinker]] 16:19, 13 March 2007 (CET)
----

Under Ubuntu, you can set the thresholds under {{path| /etc/default/tpsmapi-utils}}.

START_CHARGE_THRESH_BAT0=40
#START_CHARGE_THRESH_BAT1=40

STOP_CHARGE_THRESH_BAT0=95
#STOP_CHARGE_THRESH_BAT1=70
----

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%?
So I have to plug in the power cord while the thinkpad is running and then shut it down to make it work?
--[[User:Burp|Burp]] 17:45, 15 March 2007 (CET)
----

Changes take effect immediately, and last as long as the machine has any power source (battery or AC).

--[[User:Thinker|Thinker]] 18:59, 15 March 2007 (CET)
----

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.
So, are the values only saved in standby-mode? This isn't clear for me, and I think I'm not alone with it ;)

--[[User:Alexb|Alexb]] 20:56, 15 March 2007 (CET)

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

I hope that answered all your doubts...

--[[User:Hmh|hmh]] 04:45, 28 March 2007 (CEST)
----
Well, I can't find that file ({{path| /etc/default/tpsmapi-utils}}) on my fresh Ubuntu 7.04 installation, nor is it found in the Ubuntu repositories in any release :(
Where can i get it from? Which packages contains it? Where to get that package?

Thanks!

== stop_charge_thres on t42p ==

Hi,

'cat /sys/devices/platform/smapi/BAT0/stop_charge_thres' does not work. I get:
'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).

Talk:Tp smapi

2007-05-13T16:31:30Z

Zarhan: /* Battery daemon feedback requested */

== Feedback ==

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.

--[[User:Spiney|spiney]] 21:25, 5 Dec 2005 (CET)
----
None of the fuctions is working on my T40, kernel 2.6.14-mm2.

--[[User:Lammic|lammic]], 2005.12.05

Works for me on a T41 running 2.6.12-10-686 (Ubuntu 5.10).

--[[User:berndtnm|berndtnm]], 2005.12.06

Including stop_charge_thresh? That one seems to be missing on the T42p.

--[[User:Thinker|Thinker]] 00:46, 7 Dec 2005 (CET)
----

tp_smapi works just fine on an R52 with Ubuntu Breezy stock kernel.

--[[User:Micampe|Micampe]] 12:52, 7 Dec 2005 (CET)

----

''To set the thresholds for starting and stopping battery charging (in percent of current capacity):''

'''current''' really? That'd be weird, I'd expect it to be percent of '''total''' capacity.

--[[User:Micampe|Micampe]] 14:39, 7 Dec 2005 (CET)

"Current full charge capacity", as opposed to "current remaining capacity" or "designed full charge capacity"...

--[[User:Thinker|Thinker]] 15:05, 7 Dec 2005 (CET)
----

Battery features don't work with my T41p. I can't check this with windows. Can anybody try these features?

-- Nils, 7 Dec 2005
----

Nils, does cdrom_speed work for you on the T41p? Could you provide the details requested in the README (dmesg etc.)?

--[[User:Thinker|Thinker]] 21:57, 7 Dec 2005 (CET)
----

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.

-- Nils, 8 Dec 2005
----

All the features except the stop_charge_thresh seem to work here on a t42p.
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,
and if I set it to 100 the battery charges all the way.

--[[User:Nirik|Nirik]] 16 Dec 2005
----

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?

--[[User:Thinker|Thinker]] 14:16, 16 Dec 2005 (CET)
----

System T40p:

<pre>
fairlight:/sys/devices/platform/smapi/BAT0# echo 1 > /sys/devices/platform/smapi/BAT0/force_discharge1
fairlight:/sys/devices/platform/smapi/BAT0# echo 1 > /sys/devices/platform/smapi/BAT0/force_discharge2
fairlight:/sys/devices/platform/smapi/BAT0# dmesg
tp_smapi: req_in: BX=2118 CX=100 DI=0 SI=0
tp_smapi: req_out: AX=8680 BX=2118 CX=100 DX=b2 DI=0 SI=0 ret=-38
tp_smapi: SMAPI error: Function is not supported by SMAPI BIOS (func=2118)
tp_smapi: cannot get force_discharge1 of battery 0: Function is not supported by SMAPI BIOS
tp_smapi: req_in: BX=2104 CX=100 DI=0 SI=0
tp_smapi: req_out: AX=80 BX=2103 CX=100 DX=78 DI=0 SI=0 ret=0
tp_smapi: cannot get force_discharge2 of battery 0: bx=2103
</pre>

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.

--[[User|StefanSchmidt]]

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.

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.

--[[User:Thinker|Thinker]] 21:42, 16 Dec 2005 (CET)

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.

--[[User:StefanSchmidt]]
----

Someone reported cd_speed works on T42 but on mine, it doesn't: this is 2378DXU

--[[User:eBug]] 22:55, 17 Dec 2005 (CET)
----

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?

--[[User:Thinker|Thinker]] 11:53, 18 Dec 2005 (CET)
----

To confirm:
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.

--[[User:LJSBRokken|LJSBrokken]] 21 Dec 2005
----

tp_smapi version 0.13 with T23 (2647-3QG) (I have dual batteries)...

None of the functions which make any changes work...

<pre># cd /sys/devices/platform/smapi && cat BAT*/* > /dev/null
cat: BAT0/force_discharge1: Function not implemented
cat: BAT0/force_discharge2: Input/output error
cat: BAT0/inhibit_charge_minutes: Function not implemented
cat: BAT0/start_charge_thresh: Function not implemented
cat: BAT0/stop_charge_thresh: Function not implemented
cat: BAT1/force_discharge1: Function not implemented
cat: BAT1/force_discharge2: Input/output error
cat: BAT1/inhibit_charge_minutes: Function not implemented
cat: BAT1/start_charge_thresh: Function not implemented
cat: BAT1/stop_charge_thresh: Function not implemented</pre>

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.

--[[User:SystemParadox|SystemParadox]] 21:51, 4 Jan 2006 (CET)
----

SystemParadox, what's the dmesg output produced by "cat BAT0/force_discharge2"?

--[[User:Thinker|Thinker]] 22:02, 4 Jan 2006 (CET)
----

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:

<pre>
tp_smapi: tp_smapi 0.14 loading...
tp_smapi: successfully loaded (smapi_port=0xb2).
tp_smapi: req_in: BX=2114 CX=100 DI=0 SI=0
tp_smapi: req_out: AX=ea210080 BX=ec192114 CX=c18d0700 DX=f7cc00b2 DI=f7f50000 SI=c18d0000 ret=-5
tp_smapi: SMAPI error: Unknown error code (func=2114)
tp_smapi: cannot get inhibit charge of battery 0: Unknown error code
tp_smapi: req_in: BX=2116 CX=100 DI=0 SI=0
tp_smapi: req_out: AX=c03b0080 BX=c18d2116 CX=c0160328 DX=ec7600b2 DI=ec760000 SI=a0810000 ret=-5
tp_smapi: SMAPI error: Unknown error code (func=2116)
tp_smapi: cannot get start thresh of battery 0: Unknown error code
tp_smapi: req_in: BX=211a CX=100 DI=0 SI=0
tp_smapi: req_out: AX=c03b0080 BX=c18d211a CX=c016032c DX=eb4500b2 DI=eb450000 SI=241e0000 ret=-5
tp_smapi: SMAPI error: Unknown error code (func=211a)
tp_smapi: cannot get stop thresh of battery 0: Unknown error code
</pre>

--[[User:Spiney|spiney]] 08:12, 10 Jan 2006 (CET)
----

Oops, the transition to 32-bit SMAPI calls was broken. Fixed in 0.15. Thanks for the quick report!

--[[User:Thinker|Thinker]] 12:10, 10 Jan 2006 (CET)
----

Yep, 0.15 works again. Quick response, bravo! :)

--[[User:Spiney|spiney]] 12:23, 10 Jan 2006 (CET)
----

On a T22, nothing seems to work with 0.16.

[[http://www.rafb.net/paste/results/fcUUDs49.html|dmesg output]] when doing cat *

I am using an Ultrabay2000 battery, so it would be really usefull to be able to control that

--[[User:nusse|nusse]]
----

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?

--[[User:Thinker|Thinker]] 20:59, 11 Jan 2006 (CET)
----

I don't really know what 'extended battery' status means, but here an example:
<pre>
$ cat current_* /sys/devices/platform/smapi/BAT1
cat: current_avg: Input/output error
cat: current_now: Input/output error
</pre>
This is what happens when i cat any file in this directory and also in ../BAT1 :(

--[[User:nusse|nusse]] Thu Jan 12 22:07:26 CET 2006
----

Nusse: Yes, that's what I meant. What's the {{cmdroot|dmesg}} output generated by these commands?

--[[User:Thinker|Thinker]] 00:27, 13 Jan 2006 (CET)
----

Thinker: I attached some link to my first comment but it seems to be down and the link was wrong anyway.
<pre>
thinkpad controller read(%hx,%hx): failed writing to 0x1610
thinkpad controller read(%hx,%hx): failed writing to 0x1610
thinkpad controller read(%hx,%hx): failed writing to 0x1610
thinkpad controller read(%hx,%hx): failed writing to 0x1610
thinkpad controller read(%hx,%hx): failed writing to 0x1610
thinkpad controller read(%hx,%hx): failed writing to 0x1610
thinkpad controller read(%hx,%hx): failed writing to 0x1610
thinkpad controller read(%hx,%hx): failed writing to 0x1610
thinkpad controller read(%hx,%hx): failed writing to 0x1610
thinkpad controller read(%hx,%hx): failed writing to 0x1610
thinkpad controller read(%hx,%hx): failed writing to 0x1610
thinkpad controller read(%hx,%hx): failed writing to 0x1610
thinkpad controller read(%hx,%hx): failed writing to 0x1610
thinkpad controller read(%hx,%hx): failed writing to 0x1610
thinkpad controller read(%hx,%hx): failed writing to 0x1610
tp_smapi: SMAPI error: Function is not supported by SMAPI BIOS (func=2118)
tp_smapi: cannot get force_discharge of battery 0: Function is not supported by SMAPI BIOS
tp_smapi: SMAPI error: Function is not supported by SMAPI BIOS (func=2114)
tp_smapi: cannot get inhibit charge of battery 0: Function is not supported by SMAPI BIOS
thinkpad controller read(%hx,%hx): failed writing to 0x1610
thinkpad controller read(%hx,%hx): failed writing to 0x1610
thinkpad controller read(%hx,%hx): failed writing to 0x1610
thinkpad controller read(%hx,%hx): failed writing to 0x1610
thinkpad controller read(%hx,%hx): failed writing to 0x1610
thinkpad controller read(%hx,%hx): failed writing to 0x1610
thinkpad controller read(%hx,%hx): failed writing to 0x1610
thinkpad controller read(%hx,%hx): failed writing to 0x1610
thinkpad controller read(%hx,%hx): failed writing to 0x1610
thinkpad controller read(%hx,%hx): failed writing to 0x1610
thinkpad controller read(%hx,%hx): failed writing to 0x1610
thinkpad controller read(%hx,%hx): failed writing to 0x1610
thinkpad controller read(%hx,%hx): failed writing to 0x1610
thinkpad controller read(%hx,%hx): failed writing to 0x1610
thinkpad controller read(%hx,%hx): failed writing to 0x1610
tp_smapi: SMAPI error: Function is not supported by SMAPI BIOS (func=2116)
tp_smapi: cannot get start thresh of battery 0: Function is not supported by SMAPI BIOS
thinkpad controller read(%hx,%hx): failed writing to 0x1610
thinkpad controller read(%hx,%hx): failed writing to 0x1610
tp_smapi: SMAPI error: Function is not supported by SMAPI BIOS (func=211a)
tp_smapi: cannot get stop thresh of battery 0: Function is not supported by SMAPI BIOS
thinkpad controller read(%hx,%hx): failed writing to 0x1610
thinkpad controller read(%hx,%hx): failed writing to 0x1610
</pre>

--[[User:nusse|nusse]] Fri Jan 13 14:35:57 CET 2006
----

Nusse: Thanks; but there's not much we can do. Maybe the T22 uses a different interface, or doesn't have that feature.

--[[User:Thinker|Thinker]] 23:23, 15 January 2006 (CET)
----

Thinker: Is there anything I can do to check if the interface is different? Changing 0x1610 to some random number?

Is there a chance to get it by try and error?

--[[User:nusse|nusse]] Mon Jan 16 19:10:12 CET 2006
----

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

The only way I can think of for figuring out the T22 interface is to see what the Windows software does.

--[[User:Thinker|Thinker]] 19:47, 16 January 2006 (CET)
----

I have a R40 (2722-B3G), and several things don't work with 0.16 on linux 2.6.15.1:

<pre>
tp_smapi: SMAPI error: Function is not supported by SMAPI BIOS (func=2118)
tp_smapi: cannot get force_discharge of battery 0: Function is not supported by SMAPI BIOS
tp_smapi: SMAPI error: Function is not supported by SMAPI BIOS (func=2114)
tp_smapi: cannot get inhibit charge of battery 0: Function is not supported by SMAPI BIOS
tp_smapi: SMAPI error: Function is not supported by SMAPI BIOS (func=2116)
tp_smapi: cannot get start thresh of battery 0: Function is not supported by SMAPI BIOS
tp_smapi: SMAPI error: Function is not supported by SMAPI BIOS (func=211a)
tp_smapi: cannot get stop thresh of battery 0: Function is not supported by SMAPI BIOS
</pre>

Don't know about Windows, haven't booted it for weeks nor used it for years...

--[[User:Wonka|Wonka]] 19:00, 19 January 2006 (CET)
----

Wonka: do the other features (i.e., extended battery status) work on your R40?

--[[User:Thinker|Thinker]] 20:30, 20 January 2006 (CET)
----

--[[User:lisch|lisch]] 16:14, 11 April 2006 (CDT)

On my X32, with two batteries, I get just what I expect. Looks good:
<pre>$ cat BAT?/* > /dev/null
cat: BAT0/force_discharge: Function not implemented
cat: BAT0/inhibit_charge_minutes: Function not implemented
cat: BAT0/start_charge_thresh: Function not implemented
cat: BAT0/stop_charge_thresh: Function not implemented
cat: BAT1/force_discharge: Function not implemented
cat: BAT1/inhibit_charge_minutes: Function not implemented
cat: BAT1/start_charge_thresh: Function not implemented
cat: BAT1/stop_charge_thresh: Function not implemented
$
</pre>
==Changing the CD speed when the CD is being accessed will hang your computer==

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.

-- Stefan Schmidt
----

An open file looks fine if you're not reading/writing at that point. But my T43 does hangs on this:
# dd if=/dev/scd0 of=/dev/null &
# echo 1 > /sys/devices/platform/smapi/cdrom_speed

--[[User:Thinker|Thinker]] 16:41, 7 Dec 2005 (CET)
----

OK, sorry. I was to fast. My system hangs on this commands, too. :(

-- Stefan Schmidt

Works well. Great.

T42 2373-8zh. Working :cdrom_speed and start_charge_thresh. Untest : inhibit_charge_minutes.

-- Haifeng Chen

cdrom_speed works on my T40.

-- [[User:Lammic|lammic]], 2005.12.09

== Kernel Patch? ==

Hello Thinker,

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)

''(deleted, see below for how to create a patch file)''

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.

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

--[[User:Spiney|spiney]] 09:52, 16 Dec 2005 (CET)
----

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?

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.

BTW, the convention for kernel patches is to start them once level higher:
diff -Nurp kernel-2.6.14-vanilla kernel-2.6.14-patched

--[[User:Thinker|Thinker]] 17:12, 16 Dec 2005 (CET)
----

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

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

--[[User:Spiney|spiney]] 18:36, 16 Dec 2005 (CET)
----

If it does that on a local copy (no changes the original kernel tree) and cleans up after itself, that's fine with me. :-)

--[[User:Thinker|Thinker]] 18:50, 16 Dec 2005 (CET)
----

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

<pre>
#!/bin/bash

KDIR=/lib/modules/$(uname -r)/build
FDIR=drivers/firmware
OPWD=$(pwd)

TMPDIR=$(mktemp -d)
cd $TMPDIR

mkdir -p a/$FDIR
cp $KDIR/$FDIR/{Kconfig,Makefile} a/$FDIR
cp -r a b
sed -i -e '/endmenu/i\
config IBM_SMAPI\
tristate "IBM ThinkPad SMAPI Support"\
depends on X86\
---help---\
This adds SMAPI support on IBM ThinkPads, mostly used for battery\
charge control. For more information about this driver see\
<http://www.thinkwiki.org/wiki/SMAPI_support_for_Linux> .\
\
If you have an IBM ThinkPad laptop, say Y or M here.\
' b/$FDIR/Kconfig
sed -i -e '$a\
obj-$(CONFIG_IBM_SMAPI) += tp_smapi.o' b/$FDIR/Makefile
cp $OPWD/tp_smapi.c b/$FDIR
diff -Nurp a b > $OPWD/tp_smapi-$(uname -r).patch
rm -r a b
cd $OPWD
</pre>

BTW, [http://qbnz.com/highlighter/ GeSHi]-based syntax-highlighting would be great...

--[[User:Spiney|spiney]] 19:28, 16 Dec 2005 (CET)
----

Ah, neat sed foo. How about [http://tpctl.sourceforge.net/tmp/Makefile this] escapade, then?

What's the sed spell needed to replace the Makefile's
VER := 0.13
with auto-parsing of
#define TP_VERSION "0.13"
from tp_smapi.c?

--[[User:Thinker|Thinker]] 20:37, 16 Dec 2005 (CET)
----

Hmm, something like
VERFROMC=$(sed -ne 's/^#define TP_VERSION "$.*$"/\1/gp' tp_smapi.c)
sed -i -e "s/^VER := .*$/VER := $VERFROMC/" Makefile
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.

--[[User:Spiney|spiney]] 20:44, 16 Dec 2005 (CET)
----

Makefile escaping is horrible, keep avoiding it... Anyway, the updated [http://tpctl.sourceforge.net/tmp/Makefile make patch] seems to do the right thing.

--[[User:Thinker|Thinker]] 21:36, 16 Dec 2005 (CET)
----

Small documentation request: just needed to create a patch for the not-yet-installed 2.6.16-rc2, which is no problem with
make KSRC=/path/to/linux-2.6.16-rc2 KVER=2.6.16-rc2 patch
but I guess it would be a good addition to the README file. :)

--[[User:Spiney|spiney]] 10:48, 8 February 2006 (CET)
----

Right, added (to next release).

--[[User:Thinker|Thinker]] 13:40, 8 February 2006 (CET)
----

==Installation questions==
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:

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

2. I don't have the cd speed control function. Here is what I have under /sys/devices/platform/smapi/:

./ ../ ac_connected BAT0/ BAT1/ bus@ driver@ power/

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

When I have time, I'll install the new kernel to see if the problems are gone and report the result.

--[[User:68.51.153.96|68.51.153.96]] 04:31, 2 Jan 2006 (CET)
----

1. It should stop charging at 70, but will only ''start'' charging when remaining capacity has dipped below <tt>start_charge_thresh</tt>.

2. See the note about PROVIDE_CD_SPEED.

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

--[[User:Thinker|Thinker]] 09:28, 2 Jan 2006 (CET)
----

Thanks Thinker.

1. I discharged and recharged the battery again. This time, it stops at 68% percent, which is pretty good.

2. I missed the NOTE in README, for I just followed this wiki. :P

3. My kernel version is 2.6.13-15.

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?

--[[User:Tyne|Tyne]] 00:14, 3 Jan 2006 (CET)
----

The note about PROVIDE_CD_SPEED is also in the Wiki...

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.

--[[User:Thinker|Thinker]] 08:48, 3 Jan 2006 (CET)
----
I spent hours, trying to compile this on ubuntu edgy without success. It starts with warnings about missing files:

<pre>
root@t40:/home/bernd/Desktop/tp_smapi-0.31/tp_smapi-0.31# make install
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
make[1]: Betrete Verzeichnis '/usr/src/linux-source-2.6.17'
/usr/src/linux-source-2.6.17/Makefile:450: .config: No such file or directory

WARNING: Symbol version dump /lib/modules/2.6.17-11-386/build/Module.symvers
is missing; modules will have no dependencies and modversions.

CC [M] /home/bernd/Desktop/tp_smapi-0.31/tp_smapi-0.31/thinkpad_ec.o
cc1: error: include/linux/autoconf.h: No such file or directory
[...]
</pre>
and then many thousand lines later it finally stops:
<pre>
[...]
/home/bernd/Desktop/tp_smapi-0.31/tp_smapi-0.31/thinkpad_ec.c:357: error: â€˜CONFIG_HZâ€™ undeclared (first use in this function)
/home/bernd/Desktop/tp_smapi-0.31/tp_smapi-0.31/thinkpad_ec.c: In function â€˜thinkpad_ec_invalidateâ€™:
/home/bernd/Desktop/tp_smapi-0.31/tp_smapi-0.31/thinkpad_ec.c:378: error: â€˜CONFIG_HZâ€™ undeclared (first use in this function)
/home/bernd/Desktop/tp_smapi-0.31/tp_smapi-0.31/thinkpad_ec.c: In function â€˜thinkpad_ec_initâ€™:
/home/bernd/Desktop/tp_smapi-0.31/tp_smapi-0.31/thinkpad_ec.c:460: error: â€˜CONFIG_HZâ€™ undeclared (first use in this function)
make[3]: *** [/home/bernd/Desktop/tp_smapi-0.31/tp_smapi-0.31/thinkpad_ec.o] Fehler 1
make[2]: *** [_module_/home/bernd/Desktop/tp_smapi-0.31/tp_smapi-0.31] Fehler 2
make[1]: *** [modules] Fehler 2
make[1]: Verlasse Verzeichnis '/usr/src/linux-source-2.6.17'
make: *** [modules] Fehler 2
</pre>

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.

[[User:7bit|7bit]] 07:42, 27 March 2007 (CEST)
----

== Formatting ==

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.

--[[User:Thinker|Thinker]] 17:04, 3 Jan 2006 (CET)
----
Hei Thinker,

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.

[[User:Wyrfel|Wyrfel]] 18:46, 3 Jan 2006 (CET)
----

== Dual battery operation with tp_smapi ==

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

The juicy details:

{{cmdroot|cd /sys/devices/platform/smapi/}}
{{cmdroot|cat ac_connected}}

{{cmdresult|0}}
{{cmdroot|cat BAT{0,1}/state}}
{{cmdresult|discharging}}
{{cmdresult|idle}}

{{cmdroot|echo 1 > BAT1/force_discharge1}}
{{cmdroot|cat BAT{0,1}/state}}
{{cmdresult|idle}}
{{cmdresult|discharging}}

Checking capacity values shows that the corrent battery is being depleted.

And remember, before you yank the CD/DVD drive out, issue:

{{cmdroot|cat eject > /proc/acpi/ibm/bay}}

----

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}})?

About the eject command, I think it should be possible to do that automatically when the Ultrabay handle is ejected, via <tt>acpid</tt>.

--[[User:Thinker|Thinker]] 15:45, 10 Jan 2006 (CET)
----

It's a T43 (2669). cat'ing force_discharge2 gives me an I/O error and I see

tp_smapi: cannot get force_discharge2 of battery 0: bx=2103

tp_smapi: cannot get force_discharge2 of battery 1: bx=2103

I find these errors irrelevant from the user's point of view, though.

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.

----

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

If you write those ACPI scripts, it would be great if you put them on the Wiki.

--[[User:Thinker|Thinker]] 16:31, 10 Jan 2006 (CET)
----

Well, I still do not preclude the fact that <tt>force_discharge2</tt> may be useful for something else on other models.

The ACPI scripts (as well as an installation guide) is underway. It may take a while, though.

----

See the new article: [[Using an Ultrabay battery]].

--[[User:Thinker|Thinker]] 17:05, 10 Jan 2006 (CET)
----

Hei Thinker,

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

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?

[[User:Wyrfel|Wyrfel]] 20:42, 10 Jan 2006 (CET)
----

ACK about the page rename (the old one did sound a bit out of line to my ear, but I couldn't spot why...).

About the splitting tp_smapi vs. thinkpad/tpctl, no objection.

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?

--[[User:Thinker|Thinker]] 21:04, 10 Jan 2006 (CET)
----
Ok, i agree on the latter.

[[User:Wyrfel|Wyrfel]] 00:57, 11 Jan 2006 (CET)
----

==Article name capitalization==

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

--[[User:Thinker|Thinker]] 11:03, 11 Jan 2006 (CET)
----

Impossible, according to [http://en.wikipedia.org/wiki/Wikipedia:Canonicalization Wikipedia:Canonicalization].

--[[User:Thinker|Thinker]] 12:04, 11 Jan 2006 (CET)
----

==Status Table==
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?

I also created <nowiki>{{Isup}}</nowiki> style templates for status, they just include images, like {{Isup}}.
Not emotional about it, just wanted to let you know in case you want to use them.

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"?

[[User:Wyrfel|Wyrfel]] 19:21, 11 Jan 2006 (CET)
----

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

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.

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.

--[[User:Thinker|Thinker]] 20:38, 11 Jan 2006 (CET)
----

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.

I'm ok with the rest.

[[User:Wyrfel|Wyrfel]] 22:35, 11 Jan 2006 (CET)
----

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

[[User:Peterco|Peterco]] 12:07, 28 February 2006 (CET)
----

== Z60t ==

Tested on Z60t. No errors using cat. Setting thresholds works. Status and capacity queries work. --[[User:Alon|Alon]] 21:44, 4 May 2006 (CEST)

== Problem setting thresholds with X40 ==

My X40, kernel 2.6.16 and tp_smapi 0.20. I try to set the thresholds to 40% and 90% using:
<pre>
# echo 90 > stop_charge_thresh
# echo 40 > start_charge_thresh
</pre>
which should work, and the kernel reports from dmesg:
<pre>
tp_smapi: successfully loaded (smapi_port=0xb2).
tp_smapi: battery 0: changed start threshold to 85(+1)
tp_smapi: battery 0: changed stop threshold to 90
tp_smapi: battery 0: changed start threshold to 39(+1)
</pre>
but, on confirmation here is what happens:
<pre>
# cat stop_charge_thresh
90
# cat start_charge_thresh
91
</pre>
Any clues as to why start doesn't keep? Or why its always at 1 above stop_charge_thresh?

--[[User:Xmm0|Xmm0]] 15:01, 17 May 2006 (CEST)
----

Is it any different if you first set start_charge_thresh and then stop_charge_thresh?

Can you please load tp_smapi with module option "debug=1" and report the dmesg output genereated by each command?

--[[User:Thinker|Thinker]] 16:31, 17 May 2006 (CEST)
----

== Battery daemon feedback requested ==

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.

By default, the machine fully discharges BAT1 first, and it is said that deep-cycling all the time dramatically shortens their lifetime.

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.

Currently there are two "modes" of the daemon:

Discharging mode.
<pre>
* look at the "remaining_percent" values for both batteries
* if one is more than THRESHOLD percent less than the other one,
force discharge from the battery with more capacity left
(the current value for THRESHOLD is 10%)
</pre>
I believe the preceeding will prevent either battery from being deep-cycled disproportionately.

Charging mode. I am less sure what the "right" algorithm is here. The following is a proposal.
<pre>
* look at the "remaining_percent" values for both batteries
* if one is more than THRESHOLD percent less than the other one,
force charging to the battery with less capacity left
* honor pre-set values in stop_charge_thresh and start_charge_thresh
</pre>

I would like to get feedback in the form of "better" algorithms or requests for this daemon.

--[[User:Zak Smith|Zak]] 19:03, 12 September 2006 (CEST)

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.

--[[User:Thinker|Thinker]] 22:57, 12 September 2006 (CEST)

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.

I have also noticed that the reported remaining runtimes vary greatly between acpi, the applet, and /proc/acpi/battery/*/state

--[[User:Zak Smith|Zak]] 21:46, 14 September 2006 (CEST)

What do you mean by "acpi" vs. "/proc/acpi/battery/*/state"?

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.

--[[User:Thinker|Thinker]] 12:07, 15 September 2006 (CEST)

By acpi, I meant the output of the acpi (1) command. I'll get some comparative numbers later and post them here.

--[[User:Zak Smith|Zak]] 20:37, 15 September 2006 (CEST)

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

--[[User:Thinker|Thinker]] 21:32, 15 September 2006 (CEST)

I have been running batteryd for a while with good results. I will upload it here shortly.

I disabled the preferential charging mode, and only control discharging.

--[[User:Zak Smith|Zak]] 23:15, 14 November 2006 (CET)

http://demigod.org/~zak/src/batteryd.cc

--[[User:Zak Smith|Zak]] 20:18, 5 December 2006 (CET)

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?

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.

Can you add a check to the condition if (b0->on_ac == 0) ...change this to

if ((b0->on_ac == 0) && (b0->installed == 1) && (b1->installed == 1) - then the equal discharging logic would handle hotswapping too (ie. situations where you're running only on 1 battery instead of 2).

I hope you keep on honing this :)

One of the few things I miss from Dell is that when operating with dual batteries, it discharges both of them evenly.

--[[User:Zarhan|Zarhan]] 18:31, 13 May 2007 (CEST)

== Instructions for X60 with Bios 1.11 under Debian Etch ==

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!

--[[User:PeterBursch|PeterBursch]] 21:39, 15 September 2006 (CEST)

== tp_smapi 0.30 with kernel 2.6.20? ==

<pre>T60:~/tp_smapi-0.30# uname -rm
2.6.20 x86_64

T60:~/tp_smapi-0.30# make load
if lsmod | grep -q '^hdaps '; then rmmod hdaps; fi
if lsmod | grep -q '^tp_smapi '; then rmmod tp_smapi; fi
if lsmod | grep -q '^thinkpad_ec '; then rmmod thinkpad_ec; fi
if lsmod | grep -q '^tp_base '; then rmmod tp_base; fi # old thinkpad_ec
make -C /lib/modules/2.6.20/source M=/root/tp_smapi-0.30 O=/lib/modules/2.6.20/build modules
make[1]: Entering directory `/usr/src/linux-2.6.20'
CC [M] /root/tp_smapi-0.30/thinkpad_ec.o
/root/tp_smapi-0.30/thinkpad_ec.c:83: warning: type defaults to 'int' in declaration of 'DECLARE_MUTEX'
/root/tp_smapi-0.30/thinkpad_ec.c:83: warning: parameter names (without types) in function declaration
/root/tp_smapi-0.30/thinkpad_ec.c: In function 'thinkpad_ec_lock':
/root/tp_smapi-0.30/thinkpad_ec.c:94: warning: implicit declaration of function 'down_interruptible'
/root/tp_smapi-0.30/thinkpad_ec.c:94: error: 'thinkpad_ec_mutex' undeclared (first use in this function)
/root/tp_smapi-0.30/thinkpad_ec.c:94: error: (Each undeclared identifier is reported only once
/root/tp_smapi-0.30/thinkpad_ec.c:94: error: for each function it appears in.)
/root/tp_smapi-0.30/thinkpad_ec.c: In function 'thinkpad_ec_try_lock':
/root/tp_smapi-0.30/thinkpad_ec.c:109: warning: implicit declaration of function 'down_trylock'
/root/tp_smapi-0.30/thinkpad_ec.c:109: error: 'thinkpad_ec_mutex' undeclared (first use in this function)
/root/tp_smapi-0.30/thinkpad_ec.c: In function 'thinkpad_ec_unlock':
/root/tp_smapi-0.30/thinkpad_ec.c:122: warning: implicit declaration of function 'up'
/root/tp_smapi-0.30/thinkpad_ec.c:122: error: 'thinkpad_ec_mutex' undeclared (first use in this function)
make[3]: *** [/root/tp_smapi-0.30/thinkpad_ec.o] Error 1
make[2]: *** [_module_/root/tp_smapi-0.30] Error 2
make[1]: *** [modules] Error 2
make[1]: Leaving directory `/usr/src/linux-2.6.20'
make: *** [modules] Error 2
</pre>

:Works here with 2.6.21-rc1 (didn't try 2.6.20) without problems --[[User:Zhenech|Zhenech]] 14:32, 22 February 2007 (CET)

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

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):
<pre>
diff -Naur tp_smapi-0.30/hdaps.c tp_smapi-0.30-64bit_fix/hdaps.c
--- tp_smapi-0.30/hdaps.c 2006-09-03 12:13:34.000000000 +0200
+++ tp_smapi-0.30-64bit_fix/hdaps.c 2007-03-07 00:43:26.000000000 +0100
@@ -34,6 +34,7 @@
#include <linux/timer.h>
#include <linux/dmi.h>
#include <linux/thinkpad_ec.h>
+#include <linux/jiffies.h>

/* Embedded controller accelerometer read command and its result: */
static const struct thinkpad_ec_row ec_accel_args =
diff -Naur tp_smapi-0.30/thinkpad_ec.c tp_smapi-0.30-64bit_fix/thinkpad_ec.c
--- tp_smapi-0.30/thinkpad_ec.c 2006-09-02 21:46:18.000000000 +0200
+++ tp_smapi-0.30-64bit_fix/thinkpad_ec.c 2007-03-07 00:43:13.000000000 +0100
@@ -34,6 +34,7 @@
#include <linux/delay.h>
#include <linux/thinkpad_ec.h>
#include <linux/jiffies.h>
+#include <asm/semaphore.h>
#include <asm/io.h>

#define TP_VERSION "0.30"
</pre>
Copy the above to {{path|64bit_fix.patch}}, enter the {{path|tp_smapi-0.30}} directory and type
:{{cmduser|patch -p1 < /path/to/64bit_fix.patch}}
Now cross your fingers and compile as normal.
--[[User:Esmil|Esmil]] 01:06, 7 March 2007 (CET)
: tp_smapi 0.31 fixes this issue --[[User:Esmil|Esmil]] 19:22, 8 March 2007 (CET)

== X60: tp_smapi 0.31 with kernel 2.6.20 issue ==
[[category:X60]]
1st of all: Thanks alot for your work. I do really appreciate this (tp_smapi/thinkwiki).

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.

--[[User:Runia|Runia]] 23:48, 16 April 2007 (CEST)

Is this consistently reproducible? What's the oops message and stackdump (you can snap a digicam shot)? Does this happen when...
* rebooting with tp_smapi loaded but hdaps not loaded?
* rebooting with neither tp_smapi nor hdaps loaded?
* rebooting with vanilla hdaps loaded (instead of the tp_smapi version)?
* removing just these modules ("rmmod") instead of rebooting?

--[[User:Thinker|Thinker]] 01:56, 17 April 2007 (CEST)
----

== battery start/stop thresholds saved after reboot? ==

Hi

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

--[[User:Burp|Burp]] 15:31, 13 March 2007 (CET)
----

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.

--[[User:Thinker|Thinker]] 16:19, 13 March 2007 (CET)
----

Under Ubuntu, you can set the thresholds under {{path| /etc/default/tpsmapi-utils}}.

START_CHARGE_THRESH_BAT0=40
#START_CHARGE_THRESH_BAT1=40

STOP_CHARGE_THRESH_BAT0=95
#STOP_CHARGE_THRESH_BAT1=70
----

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%?
So I have to plug in the power cord while the thinkpad is running and then shut it down to make it work?
--[[User:Burp|Burp]] 17:45, 15 March 2007 (CET)
----

Changes take effect immediately, and last as long as the machine has any power source (battery or AC).

--[[User:Thinker|Thinker]] 18:59, 15 March 2007 (CET)
----

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.
So, are the values only saved in standby-mode? This isn't clear for me, and I think I'm not alone with it ;)

--[[User:Alexb|Alexb]] 20:56, 15 March 2007 (CET)

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

I hope that answered all your doubts...

--[[User:Hmh|hmh]] 04:45, 28 March 2007 (CEST)
----
Well, I can't find that file ({{path| /etc/default/tpsmapi-utils}}) on my fresh Ubuntu 7.04 installation, nor is it found in the Ubuntu repositories in any release :(
Where can i get it from? Which packages contains it? Where to get that package?

Thanks!

== stop_charge_thres on t42p ==

Hi,

'cat /sys/devices/platform/smapi/BAT0/stop_charge_thres' does not work. I get:
'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).

How to enable integrated fingerprint reader with BioAPI

2006-09-14T12:01:43Z

Zarhan: Bioapi error #3 with Gentoo

{| width="100%"
|style="vertical-align:top;padding-right:20px;width:10px;white-space:nowrap;" | __TOC__
|style="vertical-align:top" |
This page describes the process of getting the [[Integrated Fingerprint Reader|integrated fingerprint reader]] to work under Linux, using bioapi and binary-only drivers. It is based on experiences in {{Ubuntu}} on a T43. The same works on {{Fedora}} 4 and 5, RHEL4, SuSE 9.3, SuSE 10, and {{Gentoo}}. Note that experimental open-source driver is available, see [[Integrated Fingerprint Reader|fingerprint reader]] page for details.
|}

==Basic installation==
===Installing the bioapi framework===
====Automated installation script====
The [[Script for enabling the fingerprint reader]] automates the installation of most components (bioapi framework, driver, pam_bioapi, pam setup, device permissions, pamtester and enrolling), for some Linux distributions.

====Binary packages====

Note that these packages only take care of this one section. If you can use one, you should do so and then proceed to the section entitled, Installing and Configuring the Driver.

=====Debian/ Ubuntu Dapper=====
*If you're using {{Debian}} Sid (the unstable branch) or {{Ubuntu}} Dapper Drake 6.06 LTS you can try the packages from Michael R. Crusoe's site, either [http://www.qrivy.net/~michael/temp/ version 1.2.3] (recommended) or [http://www.qrivy.net/~michael/debs/unstable/ older versions] which might not work with the steps in this howto.

{{HINT|Ignore the warning about not finding ''/usr/lib/libqtpwbsp.so'', it's not fatal.}}

=====Gentoo=====
You can either grab the [http://www.qrivy.net/~michael/blua/bioapi/bioapi-1.2.2.ebuild.tar.bz2 ebuild], or use the source-install procedure below.

Also see [http://toe.ch/~tsa/ibm-fingerprint/ http://toe.ch/~tsa/ibm-fingerprint/] for alternative documentation on installing on Gentoo including ebuilds for all the packages used.
=====Fedora Core=====
RPM packages for Fedora Core and installation instructions are available [[Installing Fedora Core 5 on a ThinkPad X41 Tablet#Fingerprint_Reader|here]]

====Installing from source====
*Get the bioapi source:
:{{cmduser|wget http://www.qrivy.net/~michael/blua/bioapi/bioapi-latest.tar.bz2}}
*I could not compile bioapi with the graphical Qt tools. To do it manually, do the following:
:{{cmduser|tar xjf bioapi-latest.tar.bz2}}
:{{cmduser|cd bioapi-1.2.2}}
:{{cmduser|1=./configure --with-Qt-dir=no}}
:{{cmduser|make}}
:and then as root
:{{cmdroot|make install}}
:If make install fails, be sure you're root and then:
:{{cmdroot|1=export LD_LIBRARY_PATH=/usr/local/lib}}
:{{cmdroot|make install}}
:and if you want to compile pam_bioapi for auth later
:{{cmdroot|cp include/bioapi_util.h include/installdefs.h imports/cdsa/v2_0/inc/cssmtype.h /usr/include}}
:Be aware that checkinstall will not work!
:(I got through configure with Qt, but got a cryptic build error. It all worked fine with Qt disabled as above)
:buzz: This is due to a wrong qt include path, set it manually in configure and everything should work.
*Bioapi (at least version 1.2.2) doesn't compile with GCC4. You need to patch it:
*This is neccessary to compile on SUSE 10.1 which it using gcc version 4.1.0.
:{{cmduser|wget http://upir.cz/linux/patches/bioapi-1.2.2-gcc4.patch}}
:{{cmduser|patch -p1 < bioapi-1.2.2-gcc4.patch}}
*Patch for gcc 4.1 is available here - http://cvs.pld-linux.org/cgi-bin/cvsweb/SOURCES/bioapi-c++.patch?rev=1.3
* By default, bioapi will install numerous files in {{path|/usr/local/<nowiki>{</nowiki>bin,lib,include<nowiki>}</nowiki>}}, including files with "self-explanatory" names such as {{path|/usr/local/bin/Sample}}. To prevent this pollution:
:Create a dedicated directory, for example {{path|/opt/bioapi}} .
:Append <tt>--prefix=/opt/bioapi</tt> to the above <tt>./configure</tt> command.
:Append {{path|/opt/bioapi/bin}} to <tt>$PATH</tt> and {{path|/opt/bioapi/lib}} to <tt>$LD_LIBRARY_PATH</tt>.
:When installing the driver (below), tell it the new install path: {{cmdroot|sh install.sh /opt/bioapi/lib}}

====Adjusting ldconfigs library search path====
At least on {{Fedora}} or {{Aurox}} 11, you may need to add {{path|/usr/local/lib}} to the library path so that the libraries referenced from <tt>pam_bioapi.so</tt> get picked up properly. The usual way to do this is adding it to the ldconfig configuration:
:{{cmdroot|echo '/usr/local/lib' > /etc/ld.so.conf.d/bioapi.conf}}
:{{cmdroot|ldconfig}}
Alternatively you can add it to the LD_LIBRARY variable.

If you see bioapi libs in the output of
:{{cmdroot|ldconfig -p | grep bioapi}}
then it should work.

===Installing and configuring the driver===
====Installing the driver====
*Download {{path|TFMESS_BSP_LIN_1.0.zip}} from the [http://www.upek.com/support/dl_linux_bsp.asp UPEK support site] and unzip it into a seperate folder, as it will not create one.
*Change to that folder and do as root:
:{{cmdroot|sh install.sh}}
:If you're running Gentoo or Ubuntu Dapper, use
:{{cmdroot|sh install.sh /usr/lib}}
{{HINT|
For me it didn't wor this way, but following did:
:sh install.sh /usr/local/lib
greetings, tec}}
:If that fails, it may be that make install failed up above -- try setting LD_LIBRARY_PATH, do the make install again, and come back here and try this again. You also need {{cmd|mod_install|}} from bioapi in your PATH.
:May there still occures and error, which means mod_install: command not found.
:Then login as root - not su!
:Do this:
:{{cmdroot|sh install.sh}}
:again. It should work. SU to root does not work since then the /usr/local/bin directory is not used per default.

====Configuring permissions for non-root use====
If you want to use PAM-aware applications like xscreensaver that are NOT running with root permissions (as opposed to login, gdm or other authentication mechanisms), you may need to do all or at least some of the things in this section. More details on what is necessary on which distributions would be greately appreciated.
*Create two groups, one for access to BioAPI files and the other for access to the usb files. (This is done for full generality; i.e., you may have other USB devices which you want accessable to other users, without exposing your BioAPI configuration to them). Add your normal user (the one you wish to use PAM-aware applications with) to both of these groups.
On {{Debian}} this is done with
:{{cmdroot|addgroup --system bioapi}}
:{{cmdroot|addgroup --system usbfs}}
:{{cmdroot|adduser yournormaluser bioapi}}
:{{cmdroot|adduser yournormaluser usbfs}}
On {{SUSE}} this is done with
:{{cmdroot|groupadd --system bioapi}}
:{{cmdroot|groupadd --system usbfs}}
:{{cmdroot|groupmod -A yournormaluser bioapi}}
:{{cmdroot|groupmod -A yournormaluser usbfs}}
On {{Mandriva}} this is done with
:{{cmdroot|groupadd -r bioapi}}
:{{cmdroot|groupadd -r usbfs}}
:{{cmdroot|usermod -G bioapi,usbfs yournormaluser}}

:(where {{cmd|yournormaluser|}} is your normal user name). You will need to log out and log back in for this to take effect.
*Set permissions on the BioAPI config/registry directory:
:{{cmdroot|chown -R root:bioapi /usr/local/var/bioapi/}}
:{{cmdroot|chmod -R 770 /usr/local/var/bioapi/}}
:(change this path if you used an alternate BioAPI install directory above)
*Set permissions on the files in {{path|/proc/bus/usb}}:
:{{cmdroot|chown -R root:usbfs /proc/bus/usb}}
:{{cmdroot|chmod -R g+X /proc/bus/usb}}
:{{cmdroot|chown root:usbfs /proc/bus/usb/`lsusb <nowiki>|</nowiki> sed -ne "/0483:2016/s/Bus\ $.*$\ Device\ $.*$:\ .*/\1\/\2/p"`}}
:{{cmdroot|chmod 660 /proc/bus/usb/`lsusb <nowiki>|</nowiki> sed -ne "/0483:2016/s/Bus\ $.*$\ Device\ $.*$:\ .*/\1\/\2/p"`}}
:You may need to replace {{cmd|lsusb|}} with its full path, which is something like {{cmd|/sbin/lsusb|}} or {{cmd|/usr/bin/lsusb|}} depending on your distro. It might be necessary to put these lines into a script which is run at startup and resume from suspend/hibernate.
*As an alternative to the {{cmd|chown|}}/{{cmd|chmod|}} commands above, you can set mount options for usbfs with a line in {{path|/etc/fstab|}}; an example would be
none /proc/bus/usb usbfs defaults,devgid=108,devmode=0660,busgid=108,busmode=0770,listgid=108,listmode=0660 0 0
:where 108 is replaced with the numerical group ID of the usbfs group (you can determine this with something like {{cmd|cat /etc/group <nowiki>|</nowiki> grep usbfs <nowiki>|</nowiki> cut -d':' -f 3|}}). Make sure you only have one {{path|/proc/bus/usb}} entry in {{path|/etc/fstab}}. See the {{cmd|mount(8)|}} manpage for more information on these options. This is "cleaner" but seems to have a few weird issues -- see the talk page for details.
*You may also have files in {{path|/dev/bus/usb}}, which the driver will try before {{path|/proc/bus/usb}}. If this is another usbfs mount point ({{cmd|mount|}} shows a line containing {{cmdresult|/dev/bus/usb type usbfs}}), then simply follow the above instructions with {{path|/dev/bus/usb}} rather than {{path|/proc/bus/usb}}. Otherwise, you may be running a new kernel (i.e. 2.6.15) that makes usbfs-like files available through {{path|/dev/bus/usb}}.
*On systems running udev these files are dynamically created; you can configure their permissions by editing a udev config file. On Debian this is done by changing the <tt>usb_device</tt> line of {{path|/etc/udev/permissions.rules}} to read
SUBSYSTEM=="usb_device", MODE="0660", GROUP="usbfs"
*For the beta versions only, there is a logfile, which needs to exist with the proper permissions:
:{{cmdroot|touch /var/log/BSP.log && chown root:bioapi /var/log/BSP.log && chmod 660 /var/log/BSP.log}}

====Miscellaneous configuration====
* To increase the security level (minimize false accept rate), set this in {{path|/etc/tfmessbsp.cfg}}:
security-level="5"
{{WARN|Please see discussion section Security Level!}}

===Testing the driver and enrolling a fingerprint===
To test the driver and generate the file containing your fingerprint information, you need a sample program included with the driver. The compilation steps below were discovered by trial and error; if they don't work for you, try the binary {{cmd|Sample|}} utility that came with the beta versions of the driver (i.e., {{path|TFMESS_BSP_LIN_1.0beta2.zip}} as mentioned above).
Go to the folder where you extracted {{path|TFMESS_BSP_LIN_1.0.zip}} and do:
:{{cmdroot|cd NonGUI_Sample}}
:Edit {{path|main.c|}} and remove (or comment out) the line
#include "port/bioapi_port.h"
:{{cmdroot|gcc -o Sample main.c -L/usr/local/lib -lbioapi100 -DUNIX -DLITTLE_ENDIAN}}
:{{cmdroot|./Sample}}
:Note that Sample may only run as root, unless you've already configured the usbfs file permissions.
:You can try to "e"nroll (to record a fingerprint for an account) and then "v"erify (to test a fingerprint against the one it expects for an account).
:You'll save a step later if you use your own login username as the username to enroll here.
:If running {{cmd |./Sample|}} produces the error message 'BioAPI_ModuleLoad failed, BioAPI Error Code: 6477 (0x194d)'
:then uncommenting the line
://BioAPI_SetGUICallbacks(gModuleHandle, NULL, NULL,TextGuiCallback, NULL);
:in {{path|main.c|}} can help.

==Login via pam_bioapi==

The following explains how to add fingerprint authentiation to programs that use the PAM (Pluggable Authentication Modules) framework, such as Gnome's GDM and KDE's KDM and screensaver.

===Getting required libs & tools===
====Installing pam_bioapi====
*Prerequisites
:On SuSE 10, I needed to install the pam-devel RPM
:In general, you will need pam itself (standard for most distros) as well as the pam development files (probably an optional package for your distro).
*Get and compile the pam_bioapi module.
{{HINT|A new version, pam_bioapi 0.3.0, with multi-finger and identification support can be found [http://www.nax.cz/pub/bioapi/pam_bioapi/pam-bioapi_0.3.0.tar.gz here].}}
:{{cmduser|wget http://www.qrivy.net/~michael/blua/pam_bioapi/pam_bioapi-latest.tar.bz2}}
:{{cmduser|tar xjf pam_bioapi-latest.tar.bz2}}
:{{cmduser|cd pam_bioapi-0.2.1}}
:{{cmduser|wget http://badcode.de/downloads/fingerprint.patch}}
:{{cmduser|patch -p0 < fingerprint.patch}}
:If you want to, review the patch. In general you should review all code you download and compile, if possible.
:{{cmduser|<nowiki>./configure --libdir=/lib && make </nowiki>}}
:and as root
:{{cmdroot| make install}}
{{NOTE|If you get a 'rpl_malloc' error in /var/log/auth.log when trying to use the fingerprint reader, redo these steps and remove the related term from Makefile after running ./configure. (FC3, Debian etch)}}
*If you get 'configure: error: cannot find required header: security/_pam_macros.h' and are on a Debian-like system, do "apt-get install libpam0g-dev" and try again. If you are using a Mandriva distribution, do "urpmi libpam0-devel" instead.
*If you get 'PAM [dlerror: /lib/security/pam_bioapi.so: undefined symbol: BioAPIMemoryFuncs]' error in your syslog, replace 'LIBS = ' line in {{path|libpam_bioapi/makefile}} with the following (of course, replace {{path|/opt/bioapi/}} with the path where you installed bioapi):
LIBS = -L/opt/bioapi/lib -lbioapi100 -lbioapi_mds300 -lmds_util
*Use the sample tool from the fingerprint reader to create {{path|<username>.bir}} (<tt><username></tt> '''must''' be the username you want to login with. gdm will probably break for any login name that has no .bir file).
*As root do:
:{{cmdroot|SERIAL<nowiki>=`BioAPITest | sed -ne "/Fingerprint/{n;n;s/^.*: $.\{9\}$$.\{4\}$$.\{4\}$$.\{4\}$$.*$/\1-\2-\3-\4-\5/gp}"` </nowiki>}}
:{{cmdroot|echo $SERIAL}} should print something like {{cmdresult|<nowiki>{5550454b-2054-464d-2f45-535320425350}</nowiki>}} now.
:If it does, do:
:{{cmdroot|mkdir -p /etc/bioapi/pam/$SERIAL}}
:{{cmdroot|cp <username>.bir /etc/bioapi/pam/$SERIAL}}
:If not, you might just try
:{{cmdroot|SERIAL<nowiki>={5550454b-2054-464d-2f45-535320425350}</nowiki>}}
:as this value is hardcoded into the UPEK docs.

===Configuring pam===
The following part is distribution specific. On {{Ubuntu}} or {{SUSE}} you can modify {{path|/etc/pam.d/common-auth}} (on {{Gentoo}} and {{Fedora}} it is {{path|/etc/pam.d/system-auth}}) to look like this:

#
# /etc/pam.d/common-auth - authentication settings common to all services
#
# This file is included from other service-specific PAM config files,
# and should contain a list of the authentication modules that define
# the central authentication scheme for use on the system
# (e.g., /etc/shadow, LDAP, Kerberos, etc.). The default is to use the
# traditional Unix authentication mechanisms.
#
auth sufficient pam_bioapi.so {5550454b-2054-464d-2f45-535320425350} /etc/bioapi/pam/
password sufficient pam_bioapi.so {5550454b-2054-464d-2f45-535320425350} /etc/bioapi/pam/
auth required pam_unix.so nullok_secure

----
For '''Gentoo'''-Users - this allows you to attempt a password first. If you simply press enter, it then prompts for a fingerprints. Create a file named {{path|/etc/pam.d/bioapi}}. This also means that remote services, such as SSH keep working:

auth required pam_env.so
auth sufficient pam_unix.so likeauth nullok
auth sufficient pam_bioapi.so {5550454b-2054-464d-2f45-535320425350} /etc/bioapi/pam/
auth required pam_deny.so

account required pam_unix.so

session required pam_limits.so
session required pam_unix.so

----

Now, simply replace "auth include system-auth" in all services that you wish to use fingerprint for with "auth include bioapi". For example, {{path|/etc/pam.d/kde}} by default contains

auth include system-auth
auth required pam_nologin.so

account include system-auth

password include system-auth

session include system-auth

Simply replace the first "system-auth" with bioapi and you can also get rid of KDE desktop lock with a fingerprint. If you do not wish to allow for "password fallback" then remove

auth sufficient pam_unix.so likeauth nullok

from {{path|/etc/pam.d/bioapi}}.

{{WARN|If su/sudo expects to receive the root password (SuSE 10), you need to have fingerprint settings for root (that is, copy in a root.bir as well as a your-username.bir). Otherwise, they get a segmentation fault. Which is a little unfortunate, given that you need to su or sudo to change your settings... }}
{{WARN|Not only SuSE 10 requires root.bir to be available for su to work. Just make sure you have root.bir when su is not working with your fingerprint reader but other applications are...}}
Note that sshd may pick up the fingerprint settings from {{path|/etc/pam.d/common-auth}}. I didn't want that, so I removed the "auth include common-auth" line from {{path|/etc/pam.d/sshd}} and replaced it with the lines that were originally in my {{path|/etc/pam.d/common-auth}}. That way most local services use the fingerprint reader, but sshd does not.

Another way to do this is to create a file ({{path|/etc/pam.d/bioapi|}} for example) which contains the {{cmd|pam_bioapi.so|}} lines, and explicitly {{cmd|@include|}} this '''before''' {{path|/etc/pam.d/common-auth|}} in the files for services which should use the fingerprint reader. In this case you should leave {{path|/etc/pam.d/common-auth|}} alone.

{{NOTE|This was discovered through trial and success, if it is plain wrong, wikorrect it, please.}}

In {{Fedora}} the original 'session' terms in {{path|/etc/pam.d/system-auth}} need to be kept.

{{HINT|The setup described above will/could affect remote ssh logins to also use biometric logins, which is a bit silly (who wants to remote ssh to the laptop, and then have to walk over to it and swipe your finger) To avoid that you can copy the default <tt>/etc/pam.d/system-auth</tt> to <tt>/etc/pam.d/sshd</tt> which will allow the sshd service to use the standard authentication procedure.}}

You can do some useful testing with [http://pamtester.sourceforge.net/ {{cmd|pamtester|}}], which calls the pam modules as if it were a program of your choice. Examples:
:{{cmdroot|pamtester xdm yourusername authenticate}}
:{{cmduser|pamtester xscreensaver yourusername authenticate}}
where {{cmd|yourusername|}} is your username. Note that {{cmd|pamtester|}} should run as root if and only if the program in question does.

===Application support===
The implementation of fingerprint scanning support in the relevant applications varies.

Here is the behaviour of the most common ones:
* In gdm enter your username and there should pop up an (ugly) image to swipe your finger and... magic - you can login without a password.
* kdm doesn't give any visual indication, other than that the cursor stops blinking. Just swipe your finger and hope it lets you log in.
* In xdm, enter your username and a blank password, then swipe (there is no popup as well). Identification support for xdm can be achieved with [http://www.nax.cz/pub/bioapi/2005/xdm/xdm_bio.patch this patch].
* The KDE screen saver in SUSE 10 requires you to enter an empty password (or select the correct user and then enter an empty password) in order to get the fingerprint prompt.
* For Fedora users, the redhat-config tools will crash if no root.bir presents. Also, there won't be any visual idication unless X server is properly configured for root to access. Just swipe your finger when the HDD stopped blinking or issue the following command in advance:
:{{cmduser|xhost +local:}}
* For RHEL4 users gdm, console (virtual terminal) logins and the xscreensaver all work

===kdm support===
To add graphical popup to kdm, you need following:
* Patch for pam_bioapi. This patch adds third parameter to {{path|pam_bioapi.so}} module, which is a name of file with additional environment variables that will be supplied to the UPEK driver.
:{{cmdroot|wget http://upir.cz/linux/patches/pam_bioapi-0.2.1-alter-environ.patch}}
:{{cmdroot|patch -p1 < pam_bioapi-0.2.1-alter-environ.patch}}
* Edit your {{path|Xsetup}} file (on SUSE 10 it's {{path|/etc/X11/xdm/Xsetup}}) and add these lines:
echo "XAUTHORITY=$XAUTHORITY" > /var/lib/xdm/kdm_env
echo "DISPLAY=$DISPLAY" >> /var/lib/xdm/kdm_env
* In {{path|/etc/pam.d/xdm}} file, add {{path|/var/lib/xdm/kdm_env}} as a third parameter for {{path|pam_bioapi.so}} module:
auth sufficient pam_bioapi.so {5550454b-2054-464d-2f45-535320425350} /etc/bioapi/pam/ /var/lib/xdm/kdm_env

Please note, that this won't work if you have more than one Xserver.

==Make xscreensaver use the scanner==
If you are using Gentoo, you can get a portage overlay with the necessary patches here: http://www.zzamboni.org/brt/files/xscreensaver-fingerprint-overlay.tar.gz
*Get the needed xscreensaver sources:
:{{cmduser|wget http://www.jwz.org/xscreensaver/xscreensaver-4.23.tar.gz}}
:{{cmduser|tar xzf xscreensaver-4.23.tar.gz}}
:{{cmduser|cd xscreensaver-4.23}}
:{{cmduser|wget http://www.nax.cz/pub/bioapi/2005/xscreensaver/xscreensaver-4.22_alternativeAuth.diff mirror: http://zepan.org/files/xscreensaver-4.22_alternativeAuth.diff For xscreensaver 5.00, you can get a patch here: http://www.zzamboni.org/brt/files/xscreensaver-5.00-alternativeauth.patch}}
*After reviewing the patch (it's small and straightforward), do
:{{cmduser|patch -p1 < xscreensaver-4.22_alternativeAuth.diff}} The patch prevents xscreensaver from opening an authentification window and dispatches the authentification request to another program, in our case <tt>pam</tt> and <tt>pam_bioapi</tt>. It should apply with some offset, don't mind that. If it says something about rejected though, then there's a problem.
*Compile with
:{{cmduser|./configure --with-pam && make}} 
*If you receive an error like "Couldn't find X11 headers/libs" and are running a Debian-like system, try "apt-get install xlibs-dev"
*If you receive an error like "undefined reference to `XmuPrintDefaultErrorMessage'" then install the libxmu-dev package and run the previous line again and then install as root with
:{{cmduser|su -c make install}} .
*Make sure that the newly compiled xscreensaver is used:
:{{cmduser|which xscreensaver}} should return
:{{cmdresult|/usr/local/bin/xscreensaver}} .
*In case it doesn't, try adjusting your PATH.

==Common problems==
===Bioapi error #3===
This is sometimes caused by improper permissions.

However, at least on Gentoo, recent upgrades to glibc and gcc 4.1.1 caused Bioapi to break down due to some sort of incompatibility with bioapi registry. Reinstalling does '''not''' repair the issue automatically. However, you can still fix the issue manually, by removing /var/bioapi. You need to reinstall tfm-fingerprint driver after reinstalling bioapi so that the driver is properly re-registered. As root, type

:{{cmdroot|emerge -C bioapi}}
:{{cmdroot|rm -rf /var/bioapi}}
:{{cmdroot|emerge -av1 bioapi tfm-fingerprint}}

BIOS Upgrade

2006-03-15T11:35:15Z

Zarhan: /* Z Series */ Now version 1.14

{| width="100%"
|style="vertical-align:top;padding-right:20px;width:10px;white-space:nowrap;" | __TOC__
|style="vertical-align:top" |
This page is meant to describe ways to update the BIOS on a ThinkPad that only runs Linux for users that don't have ready access to Windows. If you have Windows on your ThinkPad you can just boot into it and follow instructions on the IBM website.
{{NOTE|
In one case ([[APM setup on a type 2379 ThinkPad T40]]) it was not possible to upgrade the BIOS from Windows XP; a downgrade to Windows 98 was required to successfully run the BIOS upgrade app. The symptoms in this case were that, once the files had been extracted to the hard disk, and the machine was to reboot into the upgrade app, it would beep and hang just before reboot, requiring a power cycle. Once the power was cycled, it would simply reboot back into XP without performing any BIOS upgrade actions. So even if you have Windows, you may still need to use the info on this page.}}
|}
----
==Before You Begin==
Updating the BIOS in Linux (with few exceptions) '''is not officially supported''' by IBM. However there are work arounds.

{{WARN|By following any of the instructions here you are accepting the '''very real risk''' of turning your thinkpad into a big expensive paper weight, as a firmware update gone wrong can create unfixable problems.

'''Proceed at your own risk!'''

It is also '''important''' to understand that all newer thinkpads have 2 seperate firmwares, the BIOS and the Control Program. A specific version of the Control Program will only work with specific versions of the BIOS. If you go through the readme's on the IBM site they'll clearly state that '''you must''' [ftp://ftp.software.ibm.com/pc/pccbbs/mobiles/spsu1a62.txt update the BIOS first, then immediately update the Control Program]. Otherwise you risk turning your thinkpad into a very nice paper weight.}}

==BIOS Upgrade Paths==

For every firmware (either BIOS or Control Program) update on the IBM site there are two different firmware update programs provided.

===The Diskette Updater===

This installer appears to be a 16bit dos program which asks you to accept a license agreement. It will run in Windows, DOS, OS/2, or [http://dosemu.sf.net Dosemu] perfectly, but requires a real floppy disk attached via a real floppy control. The USB Floppy Drive to the new Thinkpads doesn't count.

===The Non Diskette Updater===
{{WARN|Though this process was successfully tested on one version of .exe files found on IBMs website this doesn't mean it will work for all of them. Use at your own risk.}}

This installer appears to be a 32bit windows exe which is designed for updating the BIOS directly from a running Windows OS. It turns out that the .exe is really a wrapper license program arround windows .cab files (this information is in [[How_to_change_the_BIOS_bootsplash_screen|BIOS-Bootsplash]]). If you install the Linux program [http://freshmeat.net/projects/cabextract/ '''cabextract'''] you can expand these files directly. Run the following:

:{{cmduser|cabextract FILENAME.exe}}

You will get 8 files in the current directory. One of them will be FILENAME.img. You can test that this is really a floppy image by running:

:{{cmdroot|mkdir mntfloppy}}
:{{cmdroot|mount -o loop FILENAME.img mntfloppy}}
:{{cmdroot|ls -la mntfloppy}}

If the results of {{cmdroot|ls -la mntfloppy}} look like a dos floppy, and no read errors were displayed, you have a pretty good chance that the floppy image is usable. Again, proceed at your own risk.

==Downloads==

{{NOTE|Firefox or Konqueror users should disable the '''Use IBM Download Director''' option when downloading files.}}

{| border="1" cellspacing="0" cellpadding="2"
| style="background:#ffdead;" rowspan="3"| '''Models'''
| style="background:#ffdead;" colspan="2"| '''Non-Diskette'''
| style="background:#ffdead;" colspan="3"| '''Diskette'''
|-
| style="background:#ffdead;" rowspan="2"| '''BIOS'''
| style="background:#ffdead;" rowspan="2"| '''Embedded Controller Program'''
| style="background:#ffdead;" colspan="2"| '''BIOS'''
| style="background:#ffdead;" rowspan="2"| '''Embedded Controller Program'''
|-
| style="background:#ffdead;"| '''Windows'''
| style="background:#ffdead;"| '''Linux'''
|-
! colspan=6 style="text-align:center;background:#efefef;" |
===200 Series===
|-
| {{240}}
|
|
| [http://www-307.ibm.com/pc/support/site.wss/document.do?lndocid=DSHY-42DLNW 1.18]
|
|
|-
| {{240X}}
|
|
| [http://www-307.ibm.com/pc/support/site.wss/document.do?lndocid=DSHY-42DLNW 1.09]
|
|
|-
! colspan=6 style="text-align:center;background:#efefef;" |
===300 Series===
|-
| {{365C}}, {{365CD}}, {{365CS}}, {{365CSD}}, {{365E}}, {{365ED}}
|
|
| [http://www-307.ibm.com/pc/support/site.wss/document.do?lndocid=MIGR-60567 2.0.14]
|
|
|-
| {{365X}}, {{365XD}}
|
|
| [http://www-307.ibm.com/pc/support/site.wss/document.do?lndocid=MIGR-60567 1.10]
|
|
|-
| {{380}}, {{380D}}, {{380E}}, {{380ED}}, {{385D}}, {{385ED}}
|
|
| [http://www-307.ibm.com/pc/support/site.wss/document.do?lndocid=DSHY-3XWNVG 1.14]
|
|
|-
| {{380XD}}, {{385XD}}
|
|
| [http://www-307.ibm.com/pc/support/site.wss/document.do?lndocid=DSHY-3XWNVG 1.19]
|
|
|-
| {{380Z}}
|
|
| [http://www-307.ibm.com/pc/support/site.wss/document.do?lndocid=DSHY-3XWNVG 1.08]
|
|
|-
| {{390}}
|
|
| [http://www.ibm.com/support/docview.wss?uid=psg1DSHY-427MCG 5.62]
|
|
|-
| {{390E}}
|
|
| [http://www.ibm.com/support/docview.wss?uid=psg1DSHY-46AKPY 1.55]
|
|
|-
| {{390X}}
|
|
| [http://www.ibm.com/support/docview.wss?uid=psg1MIGR-4C5UP9 0.55]
|
|
|-
! colspan=6 style="text-align:center;background:#efefef;" |
===500 Series===
|-
| {{560}}
|
|
| [http://www-307.ibm.com/pc/support/site.wss/document.do?lndocid=MIGR-60522 1.20]
|
|
|-
| {{560E}}
|
|
| [http://www-307.ibm.com/pc/support/site.wss/document.do?lndocid=MIGR-60522 1.13]
|
|
|-
| {{560X}}
|
|
| [http://www.ibm.com/support/docview.wss?uid=psg1DSHY-3QYK7L 1.15]
|
|
|-
| {{560Z}}
|
|
| [http://www.ibm.com/support/docview.wss?uid=psg1DSHY-3YTKKV 1.07]
|
|
|-
| {{570}}
|
|
| [http://www.ibm.com/support/docview.wss?uid=psg1MIGR-47JS5Z 1.16]
|
|
|-
| {{570E}}
| [http://www.ibm.com/support/docview.wss?uid=psg1MIGR-4HT3RD 1.07]
|
| [http://www.ibm.com/support/docview.wss?uid=psg1MIGR-4HA2BF 1.07]
|
|
|-
! colspan=6 style="text-align:center;background:#efefef;" |
===600 Series===
|-
| {{600}}
|
|
| [http://www.ibm.com/support/docview.wss?uid=psg1DSHY-3VRJPK 1.22]
|
|
|-
| {{600E}} (2645 selected models, 2646)
|
|
| [http://www.ibm.com/support/docview.wss?uid=psg1DSHY-46HLKQ 1.16]
|
|
|-
| {{600E}} (2645: 55x, 56x, 57x, 58x, A5x, A6x, Bxx [except for BAU], JJ1, JJ2, RRA)
|
|
| [http://www.ibm.com/support/docview.wss?uid=psg1DSHY-43DNQ5 1.15]
|
|
|-
| {{600X}}
| [http://www.ibm.com/support/docview.wss?uid=psg1MIGR-4HVUYL 1.11]
|
| [http://www.ibm.com/support/docview.wss?uid=psg1MIGR-4FYS2U 1.11]
|
|
|-
! colspan=6 style="text-align:center;background:#efefef;" |
===700 Series===
|-
| {{750}}, {{750CS}}, {{755C}}, {{755CS}}
|
|
| [http://www-307.ibm.com/pc/support/site.wss/document.do?lndocid=MIGR-60440 1.43]
|
|
|-
| {{755CE}}, {{755CSE}}, {{755CD}}, {{755CX}}, {{755CV}}, {{755CDV}}
|
|
| [http://www-307.ibm.com/pc/support/site.wss/document.do?lndocid=MIGR-60440 1.44]
|
|
|-
| {{760C}}, {{760CD}}, {{760L}}, {{760LD}}
|
|
| [http://www-307.ibm.com/pc/support/site.wss/document.do?lndocid=MIGR-59734 1.30]
|
|
|-
| {{760E}} (XGA), {{760ED}} (XGA), {{760XD}}, {{765D}}, {{765L}}
|
|
| [http://www-307.ibm.com/pc/support/site.wss/document.do?lndocid=MIGR-59734 2.13]
|
|
|-
| {{760E}} (SVGA), {{760ED}} (SVGA), {{760EL}}, {{760ELD}}, {{760XL}}
|
|
| [http://www-307.ibm.com/pc/support/site.wss/document.do?lndocid=MIGR-59734 2.13]
|
|
|-
| {{770}}, {{770E}}, {{770ED}}
|
|
| [http://www.ibm.com/support/docview.wss?uid=psg1DSHY-3P2MCB 1.34]
|
|
|-
| {{770X}}
|
|
| [http://www.ibm.com/support/docview.wss?uid=psg1DSHY-42QLVU 1.10]
|
|
|-
| {{770Z}}
|
|
| [http://www.ibm.com/support/docview.wss?uid=psg1MIGR-47F3VA 1.05]
|
|
|-
! colspan=6 style="text-align:center;background:#efefef;" |
===A Series===
|-
| {{A20m}}
| [http://www.ibm.com/support/docview.wss?uid=psg1MIGR-4MNN8Z 1.13]
|
| [http://www.ibm.com/support/docview.wss?uid=psg1MIGR-4JWNTQ 1.13]
|
|
|-
| {{A20p}}
| [http://www.ibm.com/support/docview.wss?uid=psg1MIGR-4MNN8Y 1.11]
|
| [http://www.ibm.com/support/docview.wss?uid=psg1MIGR-4JWNTR 1.11]
|
|
|-
| {{A21e}} (2165)
| [http://www.ibm.com/support/docview.wss?uid=psg1MIGR-4UNQKX 1.07]
|
| [http://www.ibm.com/support/docview.wss?uid=psg1MIGR-4UNRRF 1.07]
|
|
|-
| {{A21e}} (2628)
| [http://www.ibm.com/support/docview.wss?uid=psg1MIGR-4Q2KLU 1.13]
|
| [http://www.ibm.com/support/docview.wss?uid=psg1MIGR-4Q2KLV 1.13]
|
|
|-
| {{A21m}}
| [http://www.ibm.com/support/docview.wss?uid=psg1MIGR-4PJMXK 1.09]
|
| [http://www.ibm.com/support/docview.wss?uid=psg1MIGR-4Q2KM4 1.09]
|
|
|-
| {{A21p}}
| [http://www.ibm.com/support/docview.wss?uid=psg1MIGR-4Q2KM3 1.11]
|
| [http://www.ibm.com/support/docview.wss?uid=psg1MIGR-4PJN8X 1.11]
|
|
|-
| {{A22e}} Celeron
| [http://www.ibm.com/support/docview.wss?uid=psg1MIGR-4UNQKX 1.07]
|
| [http://www.ibm.com/support/docview.wss?uid=psg1MIGR-4UNRRF 1.07]
|
|
|-
| {{A22e}} Pentium
| [http://www.ibm.com/support/docview.wss?uid=psg1MIGR-4XQKLK 1.05]
|
| [http://www.ibm.com/support/docview.wss?uid=psg1MIGR-4XQL7B 1.05]
|
|
|-
| {{A22m}}
| [http://www.ibm.com/support/docview.wss?uid=psg1MIGR-4Q2KM4 1.09]
|
| [http://www.ibm.com/support/docview.wss?uid=psg1MIGR-4PJMXK 1.09]
|
|
|-
| {{A22m}} (2628-Sxx)
| [http://www.ibm.com/support/docview.wss?uid=psg1MIGR-4VXS2T 1.05]
|
| [http://www.ibm.com/support/docview.wss?uid=psg1MIGR-4VXRG4 1.05]
|
|
|-
| {{A22p}}
| [http://www.ibm.com/support/docview.wss?uid=psg1MIGR-4Q2KM3 1.11]
|
| [http://www.ibm.com/support/docview.wss?uid=psg1MIGR-4PJN8X 1.11]
|
|
|-
| {{A30}}, {{A30p}}
| [http://www.ibm.com/support/docview.wss?uid=psg1MIGR-39863 1.18]
| [http://www.ibm.com/support/docview.wss?uid=psg1MIGR-40846 1.08]
| [http://www.ibm.com/support/docview.wss?uid=psg1MIGR-39861 1.18]
|
| [http://www.ibm.com/support/docview.wss?uid=psg1MIGR-40847 1.08]
|-
| {{A31}}, {{A31p}} (Bios 1G*)
| [http://www.ibm.com/support/docview.wss?uid=psg1MIGR-42654 1.12]
| [http://www.ibm.com/support/docview.wss?uid=psg1MIGR-45771 1.05]
| [http://www.ibm.com/support/docview.wss?uid=psg1MIGR-42660 1.12]
| [http://www.ibm.com/support/docview.wss?uid=psg1MIGR-45900 1.05]
| [http://www.ibm.com/support/docview.wss?uid=psg1MIGR-45770 1.05]
|-
| {{A31}}, {{A31p}} (Bios 1N*)
| [http://www.ibm.com/support/docview.wss?uid=psg1MIGR-44450 1.09]
| [http://www.ibm.com/support/docview.wss?uid=psg1MIGR-45662 1.05]
| [http://www.ibm.com/support/docview.wss?uid=psg1MIGR-44451 1.09]
| [http://www.ibm.com/support/docview.wss?uid=psg1MIGR-45898 1.02]
| [http://www.ibm.com/support/docview.wss?uid=psg1MIGR-45663 1.05]
|-
! colspan=6 style="text-align:center;background:#efefef;" |
===G Series===
|-
| {{G40}}
| [http://www.ibm.com/support/docview.wss?uid=psg1MIGR-50672 1.20]
|
| [http://www.ibm.com/support/docview.wss?uid=psg1MIGR-50673 1.20]
|
|
|-
| {{G41}}
| [http://www.ibm.com/support/docview.wss?uid=psg1MIGR-58127 1.11]
|
| [http://www.ibm.com/support/docview.wss?uid=psg1MIGR-58129 1.11]
|
|
|-
! colspan=6 style="text-align:center;background:#efefef;" |

===R Series===
|-
| {{R30}}
| [http://www-307.ibm.com/pc/support/site.wss/document.do?lndocid=MIGR-40216 1.38]
|
| [http://www-307.ibm.com/pc/support/site.wss/document.do?lndocid=MIGR-40217 1.38]
|
|
|-
| {{R31}}
| [http://www-307.ibm.com/pc/support/site.wss/document.do?lndocid=MIGR-41378 3.11]
|
| [http://www-307.ibm.com/pc/support/site.wss/document.do?lndocid=MIGR-41535 3.11]
|
|
|-
| {{R32}}
| [http://www-307.ibm.com/pc/support/site.wss/document.do?lndocid=MIGR-43571 2.15]
|
| [http://www-307.ibm.com/pc/support/site.wss/document.do?lndocid=MIGR-43572 2.15]
|
|
|-
| {{R40}} (2681, 2682, 2683, 2896, 2898, 2899)
| [http://www.ibm.com/support/docview.wss?uid=psg1MIGR-46055 1.23]
| [http://www.ibm.com/support/docview.wss?uid=psg1MIGR-46143 1.14]
| [http://www.ibm.com/support/docview.wss?uid=psg1MIGR-46061 1.23]
|
| [http://www.ibm.com/support/docview.wss?uid=psg1MIGR-46144 1.14]
|-
| {{R40}} (2722, 2723, 2724, 2897)
| [http://www.ibm.com/support/docview.wss?uid=psg1MIGR-50320 1.29]
| [http://www.ibm.com/support/docview.wss?uid=psg1MIGR-46143 1.14]
| [http://www.ibm.com/support/docview.wss?uid=psg1MIGR-50321 1.29]
|
| [http://www.ibm.com/support/docview.wss?uid=psg1MIGR-46144 1.14]
|-
| {{R40e}}
| [http://www.ibm.com/support/docview.wss?uid=psg1MIGR-50302 1.36]
| [http://www.ibm.com/support/docview.wss?uid=psg1MIGR-50344 1.04]
| [http://www.ibm.com/support/docview.wss?uid=psg1MIGR-50301 1.36]
|
| [http://www.ibm.com/support/docview.wss?uid=psg1MIGR-50343 1.04]
|-
| {{R50}}, {{R50p}}
| [http://www.ibm.com/support/docview.wss?uid=psg1MIGR-50273 3.19]
| [http://www.ibm.com/support/docview.wss?uid=psg1MIGR-50279 3.04]
| [http://www.ibm.com/support/docview.wss?uid=psg1MIGR-50275 3.19]
|
| [http://www.ibm.com/support/docview.wss?uid=psg1MIGR-50277 3.04]
|-
| {{R50e}}
| [http://www.ibm.com/support/docview.wss?uid=psg1MIGR-55000 2.06]
| [http://www.ibm.com/support/docview.wss?uid=psg1MIGR-54996 1.04]
| [http://www.ibm.com/support/docview.wss?uid=psg1MIGR-55001 2.06]
|
| [http://www.ibm.com/support/docview.wss?uid=psg1MIGR-54997 1.04]
|-
| {{R51}} (1829, 1830, 1831, 1836)
| [http://www.ibm.com/support/docview.wss?uid=psg1MIGR-50273 3.19]
| [http://www.ibm.com/support/docview.wss?uid=psg1MIGR-50279 3.04]
| [http://www.ibm.com/support/docview.wss?uid=psg1MIGR-50275 3.19]
|
| [http://www.ibm.com/support/docview.wss?uid=psg1MIGR-50277 3.04]
|-
| {{R51}} (2883, 2887, 2888, 2889, 2894, 2895)
| [http://www.ibm.com/support/docview.wss?uid=psg1MIGR-55003 1.25]
| [http://www.ibm.com/support/docview.wss?uid=psg1MIGR-54996 1.04]
| [http://www.ibm.com/support/docview.wss?uid=psg1MIGR-55004 1.25]
|
| [http://www.ibm.com/support/docview.wss?uid=psg1MIGR-54997 1.04]
|-
| {{R51e}}
| [http://www.ibm.com/support/docview.wss?uid=psg1MIGR-61681 1.47]
| [http://www.ibm.com/support/docview.wss?uid=psg1MIGR-61677 1.00]
| [http://www.ibm.com/support/docview.wss?uid=psg1MIGR-61680 2.06]
|
| [http://www.ibm.com/support/docview.wss?uid=psg1MIGR-61675 1.00]
|-
| {{R52}} (1846, 1847, 1848, 1849, 1850, 1870)
| [http://www.ibm.com/support/docview.wss?uid=psg1MIGR-59221 1.22]
| [http://www.ibm.com/support/docview.wss?uid=psg1MIGR-59184 1.04]
| [http://www.ibm.com/support/docview.wss?uid=psg1MIGR-59220 1.22]
|
| [http://www.ibm.com/support/docview.wss?uid=psg1MIGR-59183 1.04]
|-
| {{R52}} (1858, 1859, 1860, 1861, 1862, 1863)
| [http://www.ibm.com/support/docview.wss?uid=psg1MIGR-59379 1.22]
| [http://www.ibm.com/support/docview.wss?uid=psg1MIGR-59439 1.03]
| [http://www.ibm.com/support/docview.wss?uid=psg1MIGR-59380 1.22]
|
| [http://www.ibm.com/support/docview.wss?uid=psg1MIGR-59440 1.03]
|-
! colspan=6 style="text-align:center;background:#efefef;" |
===T Series===
|-
| {{T20}}
| [http://www-307.ibm.com/pc/support/site.wss/document.do?lndocid=MIGR-4MNN8X 1.22]
|
| [http://www-307.ibm.com/pc/support/site.wss/document.do?lndocid=MIGR-4JWNJC 1.22]
|
|
|-
| {{T21}}
| [http://www-307.ibm.com/pc/support/site.wss/document.do?lndocid=MIGR-4Q2KM5 1.16]
|
| [http://www-307.ibm.com/pc/support/site.wss/document.do?lndocid=MIGR-4PJN8Y 1.16]
|
|
|-
| {{T22}}
| [http://www-307.ibm.com/pc/support/site.wss/document.do?lndocid=MIGR-4VWPPU 1.12]
|
| [http://www-307.ibm.com/pc/support/site.wss/document.do?lndocid=MIGR-4VWP54 1.12]
|
|
|-
| {{T23}}
| [http://www-307.ibm.com/pc/support/site.wss/document.do?lndocid=MIGR-39366 1.18]
| [http://www-307.ibm.com/pc/support/site.wss/document.do?lndocid=MIGR-40022 1.06a]
| [http://www-307.ibm.com/pc/support/site.wss/document.do?lndocid=MIGR-39362 1.18]
|
| [http://www-307.ibm.com/pc/support/site.wss/document.do?lndocid=MIGR-40021 1.06a]
|-
| {{T30}}
| [http://www.ibm.com/support/docview.wss?uid=psg1MIGR-42694 2.09]
| [http://www.ibm.com/support/docview.wss?uid=psg1MIGR-42711 1.07]
| [http://www.ibm.com/support/docview.wss?uid=psg1MIGR-42720 2.09]
| [http://www.ibm.com/support/docview.wss?uid=psg1MIGR-45745 2.02]
| [http://www.ibm.com/support/docview.wss?uid=psg1MIGR-42725 1.07]
|-
| {{T40}}, {{T40p}}, {{T41}}, {{T41p}}, {{T42}}, {{T42p}}
| [http://www.ibm.com/support/docview.wss?uid=psg1MIGR-50275 3.19]
| [http://www.ibm.com/support/docview.wss?uid=psg1MIGR-50279 3.04]
| [http://www.ibm.com/support/docview.wss?uid=psg1MIGR-50273 3.19]
|
| [http://www.ibm.com/support/docview.wss?uid=psg1MIGR-50277 3.04]
|-
| {{T43}} (1871, 1872, 1873, 1874, 1875, 1876)
| [http://www.ibm.com/support/docview.wss?uid=psg1MIGR-59379 1.23]
| [http://www.ibm.com/support/docview.wss?uid=psg1MIGR-59439 1.03]
| [http://www.ibm.com/support/docview.wss?uid=psg1MIGR-59380 1.23]
|
| [http://www.ibm.com/support/docview.wss?uid=psg1MIGR-59440 1.03]
|-
| {{T43}} (2668, 2669, 2678, 2679, 2686, 2687), {{T43p}}
| [http://www.ibm.com/support/docview.wss?uid=psg1MIGR-59096 1.24]
| [http://www.ibm.com/support/docview.wss?uid=psg1MIGR-59120 1.04]
| [http://www.ibm.com/support/docview.wss?uid=psg1MIGR-59097 1.24]
|
| [http://www.ibm.com/support/docview.wss?uid=psg1MIGR-59121 1.04]
|-
| {{T60}}, {{T60p}}
|
|
|
|
|
|-
! colspan=6 style="text-align:center;background:#efefef;" |

===X Series===
|-
| {{X20}}, {{X21}}
| [http://www.ibm.com/support/docview.wss?uid=psg1MIGR-4P52BM 2.25]
| [http://www.ibm.com/support/docview.wss?uid=psg1MIGR-4VQNTP 1.36]
| [http://www.ibm.com/support/docview.wss?uid=psg1MIGR-4P52BL 2.25]
|
| [http://www.ibm.com/support/docview.wss?uid=psg1MIGR-4PBMCT 1.36]
|-
| {{X22}}, {{X23}}, {{X24}}
| [http://www.ibm.com/support/docview.wss?uid=psg1MIGR-39672 1.32]
| [http://www.ibm.com/support/docview.wss?uid=psg1MIGR-39806 1.30]
| [http://www.ibm.com/support/docview.wss?uid=psg1MIGR-39665 1.32]
|
| [http://www.ibm.com/support/docview.wss?uid=psg1MIGR-39808 1.30]
|-
| {{X30}}
| [http://www.ibm.com/support/docview.wss?uid=psg1MIGR-44135 1.08]
| [http://www.ibm.com/support/docview.wss?uid=psg1MIGR-44152 1.06]
| [http://www.ibm.com/support/docview.wss?uid=psg1MIGR-44131 1.08]
|
| [http://www.ibm.com/support/docview.wss?uid=psg1MIGR-44149 1.06]
|-
| {{X31}}, {{X32}}
| [http://www.ibm.com/support/docview.wss?uid=psg1MIGR-50298 3.02]
| [http://www.ibm.com/support/docview.wss?uid=psg1MIGR-53480 1.08]
| [http://www.ibm.com/support/docview.wss?uid=psg1MIGR-50308 3.02]
|
| [http://www.ibm.com/support/docview.wss?uid=psg1MIGR-53479 1.08]
|-
| {{X40}}
| [http://www.ibm.com/support/docview.wss?uid=psg1MIGR-53881 2.03]
| [http://www.ibm.com/support/docview.wss?uid=psg1MIGR-53882 1.60]
| [http://www.ibm.com/support/docview.wss?uid=psg1MIGR-53883 2.03]
|
| [http://www.ibm.com/support/docview.wss?uid=psg1MIGR-53885 1.60]
|-
| {{X41}}
| [http://www.ibm.com/support/docview.wss?uid=psg1MIGR-59206 2.05]
| [http://www.ibm.com/support/docview.wss?uid=psg1MIGR-59208 1.01]
| [http://www.ibm.com/support/docview.wss?uid=psg1MIGR-59205 2.05]
|
| [http://www.ibm.com/support/docview.wss?uid=psg1MIGR-59207 1.01]
|-
| {{X41T}}
| [http://www.ibm.com/support/docview.wss?uid=psg1MIGR-60193 2.00]
| [http://www.ibm.com/support/docview.wss?uid=psg1MIGR-60191 1.00]
| [http://www.ibm.com/support/docview.wss?uid=psg1MIGR-60194 2.00]
|
| [http://www.ibm.com/support/docview.wss?uid=psg1MIGR-60189 1.00]
|-
| {{X60}}, {{X60s}}
|
|
|
|
|
|-
! colspan=6 style="text-align:center;background:#efefef;" |

===Z Series===
|-
| {{Z60m}}, {{Z60t}}
| [http://www.ibm.com/support/docview.wss?uid=psg1MIGR-61687 1.14]
| [http://www.ibm.com/support/docview.wss?uid=psg1MIGR-61686 1.14]
| [http://www.ibm.com/support/docview.wss?uid=psg1MIGR-61688 1.14]
|
| [http://www.ibm.com/support/docview.wss?uid=psg1MIGR-61685 1.14]
|-
! colspan=6 style="text-align:center;background:#efefef;" |

===Other===
|-
| {{TransNote}}
| [http://www-307.ibm.com/pc/support/site.wss/document.do?lndocid=MIGR-4UDSMK 1.02]
|
| [http://www-307.ibm.com/pc/support/site.wss/document.do?lndocid=MIGR-4UDRRF 1.02]
|
|
|}

If you were able to create the boot floppy per the Diskette update method, and you have a Floppy with your Thinkpad, the update should be simple.

==Updating via CD/DVD Drive==

The whole thing gets more complicated if you neither have Windows nor a floppy drive installed. This is what this page is intended to describe.

Another possibility which works even without a CD-drive or network is to boot the disk image via the grub initrd mechanism.

Be aware that IBM officially does '''not''' support this! The official statement to my support request was:

<blockquote style="background: white; border: 1px solid black; padding: 1em;">
<pre><nowiki>
I'm afraid we only support the options listed on our web page and no you
can't burn a CD/DVD, however you can try to use an external USB FDD
(floppy) drive. The experts recommend a IBM USB FDD, however they have also
tested it with a Sony USB FDD drive.

In order to make sure the drive is recognised you can boot up the FDD with
a bootable dos diskette for w98
</nowiki></pre>
</blockquote>

But it seems to be possible as Mathias Dalheimer describes this [http://mailman.linux-thinkpad.org/pipermail/linux-thinkpad/1998-January/009743.html here].

Another indication that it should work is that IBM uses PHLASH16.EXE (at least on T4x/p systems) to flash the BIOS into the chip. The same tool is used by [http://www.samsungpc.com/gb/support/p35/bios/bios-instructions.html other vendors] to flash the BIOS from bootable CD-ROMs.
{{WARN|Do '''not''' use the [http://syslinux.zytor.com/ SYSLINUX] image-loader [http://syslinux.zytor.com/memdisk.php MEMDISK] to boot the images! Some flash tools crash in that situation!}}

Some interesting but very technical information about the used flash tool can be found [http://www.paul.sladen.org/thinkpad-r31/wifi-card-pci-ids.html here].

===Creating a Floppy Image===
If you have created a boot floppy on another machine, you need to create an image file of that floppy. This can be easily done in linux by running a command line:

:{{cmdroot|1=dd bs=2x80x18b if=/dev/fd0 of=/tmp/floppy.img}}

You can also create a floppy image by using Ken Kato's [http://chitchat.at.infoseek.co.jp/vmware/vfd.html VMware's back]. It is a free Windoze tool that creates a virtual floppy drive and allows you to produce an image file ready to be ISO'ed. Note: you might have to 'manually' (through application's interface) assign the virtual drive a volume letter in order to be seen by IBM's application (as, by default, it seems not to do it).

You should verify this {{path|floppy.img}} as explained above.

===Creating a Bootable CD from a Floppy Image===
Once you have your floppy image, either from imaging a real floppy, or from extracting them via the cabextract method above, you need to make a boot CD out of it.

The eltorito bootable CD standard is a wonderful thing. What this means is that a bootable CD can be made with a bootable floppy in such as way that the CD believes that it is a 2.88 MB floppy drive. This allows you to replace a boot floppy by a boot CD in nearly all situations.

It is very easy to create such a bootable CD ISO image in Linux using the mkisofs tool. To do this run a command as follows:

:{{cmdroot|mkisofs -b bootfloppy.img -o bootcd.iso bootfloppy.img}}

Note: You don't strictly need the last {{path|bootfloppy.img}}, however some versions of mkisofs get confused about why you would want to create an iso with no contents, and thus won't let you. You don't actually care about the contents of the CD, you only care that the <tt>-b <boot image></tt> is applied to the CD. For more info on this read {{cmduser|man mkisofs}}.

You can now burn the {{path|bootcd.iso}} in your favorite CD burning program.

To get an overview which models have been tested with this version, here is a list:

===Does work:===
{| border="1" cellspacing="0" cellpadding="2"
| '''Model''' || '''Tested by'''
|-
| style="vertical-align:top;" | {{A20p}} (2629-6VU) ||
*Chris Pickett http://www.sable.mcgill.ca/~cpicke/. BIOS 1.11 flashed fine with cabextract/CD method.
|-
| style="vertical-align:top;" | {{A21e}} (2628-JXU) ||
*Amit Gurdasani <gurdasani at yahoo dot com>. BIOS 1.13 flashed fine with cabextract/CD method. Alarmingly, after the BIOS update, the laptop beeped but did not shut down as was indicated onscreen -- that was frozen on the "do not shut down the laptop" screen. On power down and up again, the BIOS setup showed the newer BIOS image running, and Linux booted up fine. Linux ACPI didn't complain about the BIOS being too old either.
|-
| style="vertical-align:top;" | {{R31}} ||
*[http://mailman.linux-thinkpad.org/pipermail/linux-thinkpad/1998-January/009743.html Mathias Dalheimer]
*Sebastian Sauer (with cabextract/CD method)
|-
| style="vertical-align:top;" | {{R40}} ||
*Matthew Lambie, http://lambie.org
|-
| style="vertical-align:top;" | {{R50}} (1836-3SU) ||
*jlbartos <jlbartos at hotmail dot com>
|-
| style="vertical-align:top;" | {{R51}} (1829) ||
*Robert Uhl <rob dot uhl at gmx dot de>, Jellby <jellby at yahoo dot com>
|-
| style="vertical-align:top;" | {{R51}} (2887) ||
*Ingo van Lil <inguin at gmx dot de>
|-
| style="vertical-align:top;" | {{T20}} ||
*Franz Hassels <fhassel at suse dot com>
|-
| style="vertical-align:top;" | {{T22}} ||
*Daniel Maier <nusse teamidiot de>
|-
| style="vertical-align:top;" | {{T23}} ||
*Bart Snapp <snapp at uiuc dot edu> Note: I followed IBM's instructions to flash the BIOS *first* and the Embedded Controller *second*.
*Moy Easwaran: BIOS 1.18 / EC 1.06a via cabextract and CD-boot. The BIOS-update exe generated errors in Windows 2000.
|-
| style="vertical-align:top;" | {{T40}} ||
*Sean Dague, http://dague.net
*Justin Mason, http://jmason.org
*Ivanhoe (Bios 3.19)
|-
| style="vertical-align:top;" | {{T40p}} ||
*Lukas KrÃ¤henbÃ¼hl, ismo at pop dot agri dot ch
*Thomas Achtemichuk, tom at tomchuk dot com. BIOS 3.15 flashed fine with cabextract/CD method
|-
| style="vertical-align:top;" | {{T41}} ||
*Lev Givon (Bios 3.15 / EC 3.04) <lev at columbia dot edu>
*Ernesto HernÃ¡ndez-Novich (Bios 3.19 / CP 3.04) < emhn at usb dot ve >
|-
| style="vertical-align:top;" | {{T41p}} ||
*Nils Newman, work great. (Version: Bios 3.14 / Embedded Controller 3.04)
|-
| style="vertical-align:top;" | {{T42p}} ||
*Robert Schiele <rschiele@uni-mannheim.de>, Joern Heissler <joern@heissler.de>
|-
| style="vertical-align:top;" | {{T43}} ||
*Tom Heady <tom-thinkwiki.org@punch.net>
*Carsten SÃ¶hrens <casoe at gmx dot de> (Version: Bios 1.05 / Embedded Controller 1.03)
*Carsten SÃ¶hrens <casoe at gmx dot de> (Version: Bios 1.24 / Embedded Controller 1.04)
*Florian Boucault <florian at boucault dot ath dot cx> (Model : 1871-W34 & Version: Bios 1.23 / Embedded Controller 1.03)
|-
| style="vertical-align:top;" | {{X20}} ||
*Neil Caunt <retardis at gmail dot com>
|-
| style="vertical-align:top;" | {{X21}} ||
*Patrick Leickner <ranma at web dot de>, (BIOS 2.21->2.25 / EC 1.31->1.36) via non-disk/cabextract/mkisofs/cdrecord
|-
| style="vertical-align:top;" | {{X22}} ||
*David Emery <dave at skiddlydee dot com>, (EC 1.30, BIOS 1.32 using non-disk/cabextract/CD method)
|-
| style="vertical-align:top;" | {{X23}} ||
*Nils Faerber <nils dot faerber at kernelconcepts dot de> (Embedded Controller 1.30, BIOS 1.32 with cabextract/CD method)
|-
| style="vertical-align:top;" | {{X30}} ||
*Hella Breitkopf, [http://hella.breitkopf.usr.ffb.org/en/ www] (Embedded Controller 1.04, BIOS 1.07 with cabextract/CD method)
|-
| style="vertical-align:top;" | {{X31}} ||
*Grzegorz KuÅ›nierz <koniu at sheket dot org> (Embedded Controller 1.08, BIOS 3.01 with cabextract/CD method)
|-
| style="vertical-align:top;" | {{X40}} ||
*Robbie Stone <robbie@serendipity.cx>
|}

===Does not work:===
{|
| '''Model''' || '''Tested by'''
|}

Please note that testing this is '''at your own risk'''!!!

==Updating with Network Boot Image==

BIOS, Embedded Controller (EC), CD/DVD and Harddisk firmware disks can be booted
over the network with [http://syslinux.zytor.com/pxe.php PXELINUX] as part of the [http://syslinux.zytor.com/ SYSLINUX] package.

This requires that you have a DHCP and tftp server configured and setup properly on
your network, and is probably not for the faint of heart.

Make sure the firmware bootdisk is in linux 'dd' format, as the self-extracting .exe disks
from the IBM website cannot be booted directly as such.

This worked on the {{R31}}, {{X22}}, {{T21}}, {{T30}} and {{T41p}} with various firmware updates.

==Check List==

The following is important to remember:
# You must update '''both''' the Control Program and the BIOS at the same time if your current Control Program is not compatible with the new BIOS (see below)
# You must find versions of the Control Program and BIOS that are compatible. Not all of them are, so follow the readmes on the IBM website carefully to determine which are.
# You must update the Control Program '''before''' you update the BIOS

When the Control Program '''and''' the BIOS need updating, have both update disks or CDs ready. Update the Control Program first and the system should switch itself off when finished. Insert the BIOS update disk and proceed to update the BIOS. When it's all finished, enter setup, reset the settings to their defaults and reboot. Enter setup again and tweak the settings as necessary.

How to enable integrated fingerprint reader with BioAPI

2006-02-27T09:45:55Z

Zarhan: /* Configuring pam */ Fingerprints concurrently with password (Gentoo point of view)

{| width="100%"
|style="vertical-align:top;padding-right:20px;width:10px;white-space:nowrap;" | __TOC__
|style="vertical-align:top" |
This page describes the process of getting the [[Integrated Fingerprint Reader|integrated fingerprint reader]] to work under Linux. It is based on experiences in {{Ubuntu}} on a T43. The same works on {{Fedora}} 4, SuSE 9.3, SuSE 10, and {{Gentoo}}.
|}

==Basic installation==
===Installing the bioapi framework===
====Automated installation script====
The [[Script for enabling the fingerprint reader]] automates the installation of most components (bioapi framework, driver, pam_bioapi, pam setup, device permissions, pamtester and enrolling), for some Linux distributions.

====Binary packages====
=====Debian=====
*If you're using {{Debian}} Sid (the unstable branch) you can try the packages from Michael R. Crusoe's site, either [http://www.qrivy.net/~michael/temp/ version 1.2.3] (recommended) or [http://www.qrivy.net/~michael/debs/unstable/ older versions] which might not work with the steps in this howto.
*This seems to work for {{Ubuntu}} Breezy/Dapper too, so save yourself some trouble and grab it.
=====Gentoo=====
You can either grab the [http://www.qrivy.net/~michael/blua/bioapi/bioapi-1.2.2.ebuild.tar.bz2 ebuild], or use the source-install procedure below.

Also see [http://toe.ch/~tsa/ibm-fingerprint/ http://toe.ch/~tsa/ibm-fingerprint/] for alternative documentation on installing on Gentoo including ebuilds for all the packages used.

====Installing from source====
*Get the bioapi source:
:{{cmduser|wget http://www.qrivy.net/~michael/blua/bioapi/bioapi-latest.tar.bz2}}
*I could not compile bioapi with the graphical Qt tools. To do it manually, do the following:
:{{cmduser|tar xjf bioapi-latest.tar.bz2}}
:{{cmduser|cd bioapi-1.2.2}}
:{{cmduser|1=./configure --with-Qt-dir=no}}
:{{cmduser|make}}
:and then as root
:{{cmdroot|make install}}
:If make install fails, be sure you're root and then:
:{{cmdroot|1=export LD_LIBRARY_PATH=/usr/local/lib}}
:{{cmdroot|make install}}
:and if you want to compile pam_bioapi for auth later
:{{cmdroot|cp include/bioapi_util.h include/installdefs.h imports/cdsa/v2_0/inc/cssmtype.h /usr/include}}
:Be aware that checkinstall will not work!
:(I got through configure with Qt, but got a cryptic build error. It all worked fine with Qt disabled as above)
:buzz: This is due to a wrong qt include path, set it manually in configure and everything should work.
* By default, bioapi will install numerous files in {{path|/usr/local/<nowiki>{</nowiki>bin,lib,include<nowiki>}</nowiki>}}, including files with "self-explanatory" names such as {{path|/usr/local/bin/Sample}}. To prevent this pollution:
:Create a dedicated directory, for example {{path|/opt/bioapi}} .
:Append <tt>--prefix=/opt/bioapi</tt> to the above <tt>./configure</tt> command.
:Append {{path|/opt/bioapi/bin}} to <tt>$PATH</tt> and {{path|/opt/bioapi/lib}} to <tt>$LD_LIBRARY_PATH</tt>.
:When installing the driver (below), tell it the new install path: {{cmdroot|sh install.sh /opt/bioapi/lib}}

====Adjusting ldconfigs library search path====
At least on {{Fedora}} or {{Aurox}} 11, you may need to add {{path|/usr/local/lib}} to the library path so that the libraries referenced from <tt>pam_bioapi.so</tt> get picked up properly. The usual way to do this is adding it to the ldconfig configuration:
:{{cmdroot|echo '/usr/local/lib' > /etc/ld.so.conf.d/bioapi.conf}}
:{{cmdroot|ldconfig}}
Alternatively you can add it to the LD_LIBRARY variable.

If you see bioapi libs in the output of
:{{cmdroot|ldconfig -p | grep bioapi}}
then it should work.

===Installing and configuring the driver===
====Installing the driver====
*Download {{path|TFMESS_BSP_LIN_1.0.zip}} from the [http://www.upek.com/support/dl_linux_bsp.asp UPEK support site] and unzip it into a seperate folder, as it will not create one.
*Change to that folder and do as root:
:{{cmdroot|sh install.sh}}
:If you're running Gentoo, use
:{{cmdroot|sh install.sh /usr/lib}}
:If that fails, it may be that make install failed up above -- try setting LD_LIBRARY_PATH, do the make install again, and come back here and try this again. You also need {{cmd|mod_install|}} from bioapi in your PATH.
====Configuring permissions for non-root use====
If you want to use PAM-aware applications like xscreensaver that are NOT running with root permissions (as opposed to login, gdm or other authentication mechanisms), you may need to do all or at least some of the things in this section. More details on what is necessary on which distributions would be greately appreciated.
*Create two groups, one for access to BioAPI files and the other for access to the usb files. (This is done for full generality; i.e., you may have other USB devices which you want accessable to other users, without exposing your BioAPI configuration to them). Add your normal user (the one you wish to use PAM-aware applications with) to both of these groups.
On {{Debian}} this is done with
:{{cmdroot|addgroup --system bioapi}}
:{{cmdroot|addgroup --system usbfs}}
:{{cmdroot|adduser yournormaluser bioapi}}
:{{cmdroot|adduser yournormaluser usbfs}}
On {{SUSE}} this is done with
:{{cmdroot|groupadd --system bioapi}}
:{{cmdroot|groupadd --system usbfs}}
:{{cmdroot|groupmod -A yournormaluser bioapi}}
:{{cmdroot|groupmod -A yournormaluser usbfs}}
On {{Mandriva}} this is done with
:{{cmdroot|groupadd -r bioapi}}
:{{cmdroot|groupadd -r usbfs}}
:{{cmdroot|usermod -G bioapi,usbfs yournormaluser}}

:(where {{cmd|yournormaluser|}} is your normal user name). You will need to log out and log back in for this to take effect.
*Set permissions on the BioAPI config/registry directory:
:{{cmdroot|chown -R root:bioapi /usr/local/var/bioapi/}}
:{{cmdroot|chmod -R 770 /usr/local/var/bioapi/}}
:(change this path if you used an alternate BioAPI install directory above)
*Set permissions on the files in {{path|/proc/bus/usb}}:
:{{cmdroot|chown -R root:usbfs /proc/bus/usb}}
:{{cmdroot|chmod -R g+X /proc/bus/usb}}
:{{cmdroot|chown root:usbfs /proc/bus/usb/`lsusb <nowiki>|</nowiki> sed -ne "/0483:2016/s/Bus\ $.*$\ Device\ $.*$:\ .*/\1\/\2/p"`}}
:{{cmdroot|chmod 660 /proc/bus/usb/`lsusb <nowiki>|</nowiki> sed -ne "/0483:2016/s/Bus\ $.*$\ Device\ $.*$:\ .*/\1\/\2/p"`}}
:You may need to replace {{cmd|lsusb|}} with its full path, which is something like {{cmd|/sbin/lsusb|}} or {{cmd|/usr/bin/lsusb|}} depending on your distro. It might be necessary to put these lines into a script which is run at startup and resume from suspend/hibernate.
*As an alternative to the {{cmd|chown|}}/{{cmd|chmod|}} commands above, you can set mount options for usbfs with a line in {{path|/etc/fstab|}}; an example would be
none /proc/bus/usb usbfs defaults,devgid=108,devmode=0660,busgid=108,busmode=0770,listgid=108,listmode=0660 0 0
:where 108 is replaced with the numerical group ID of the usbfs group (you can determine this with something like {{cmd|cat /etc/group <nowiki>|</nowiki> grep usbfs <nowiki>|</nowiki> cut -d':' -f 3|}}). Make sure you only have one {{path|/proc/bus/usb}} entry in {{path|/etc/fstab}}. See the {{cmd|mount(8)|}} manpage for more information on these options. This is "cleaner" but seems to have a few weird issues -- see the talk page for details.
*You may also have files in {{path|/dev/bus/usb}}, which the driver will try before {{path|/proc/bus/usb}}. If this is another usbfs mount point ({{cmd|mount|}} shows a line containing {{cmdresult|/dev/bus/usb type usbfs}}), then simply follow the above instructions with {{path|/dev/bus/usb}} rather than {{path|/proc/bus/usb}}. Otherwise, you may be running a new kernel (i.e. 2.6.15) that makes usbfs-like files available through {{path|/dev/bus/usb}}. On systems running udev these files are dynamically created; you can configure their permissions by editing a udev config file. On Debian this is done by changing the <tt>usb_device</tt> line of {{path|/etc/udev/permissions.rules}} to read
SUBSYSTEM=="usb_device", MODE="0660", GROUP="usbfs"
*For the beta versions only, there is a logfile, which needs to exist with the proper permissions:
:{{cmdroot|touch /var/log/BSP.log && chown root:bioapi /var/log/BSP.log && chmod 660 /var/log/BSP.log}}

====Miscellaneous configuration====
* To increase the security level (minimize false accept rate), set this in {{path|/etc/tfmessbsp.cfg}}:
security-level="5"

===Testing the driver and enrolling a fingerprint===
To test the driver and generate the file containing your fingerprint information, you need a sample program included with the driver. The compilation steps below were discovered by trial and error; if they don't work for you, try the binary {{cmd|Sample|}} utility that came with the beta versions of the driver (i.e., {{path|TFMESS_BSP_LIN_1.0beta2.zip}} as mentioned above).
Go to the folder where you extracted {{path|TFMESS_BSP_LIN_1.0.zip}} and do:
:{{cmdroot|cd NonGUI_Sample}}
:Edit {{path|main.c|}} and remove (or comment out) the line
#include "port/bioapi_port.h"
:{{cmdroot|gcc -o Sample main.c -L/usr/local/lib -lbioapi100 -DUNIX -DLITTLE_ENDIAN}}
:{{cmdroot|./Sample}}
:Note that Sample may only run as root, unless you've already configured the usbfs file permissions.
:You can try to "e"nroll (to record a fingerprint for an account) and then "v"erify (to test a fingerprint against the one it expects for an account).
:You'll save a step later if you use your own login username as the username to enroll here.

==Login via pam_bioapi==

The following explains how to add fingerprint authentiation to programs that use the PAM (Pluggable Authentication Modules) framework, such as Gnome's GDM and KDE's KDM and screensaver.

===Getting required libs & tools===
====Installing pam_bioapi====
*Prerequisites
:On SuSE 10, I needed to install the pam-devel RPM
:In general, you will need pam itself (standard for most distros) as well as the pam development files (probably an optional package for your distro).
*Get and compile the pam_bioapi module.
:{{cmduser|wget http://www.qrivy.net/~michael/blua/pam_bioapi/pam_bioapi-latest.tar.bz2}}
:{{cmduser|tar xjf pam_bioapi-latest.tar.bz2}}
:{{cmduser|cd pam_bioapi-0.2.1}}
:{{cmduser|wget http://badcode.de/downloads/fingerprint.patch}}
:{{cmduser|patch -p0 < fingerprint.patch}}
:If you want to, review the patch. In general you should review all code you download and compile, if possible. The patch comes from [http://linuxbiometrics.com/modules/newbb/viewtopic.php?viewmode=flat&topic_id=80&forum=1 this thread].
:{{cmduser|./configure && make}}
:and as root
:{{cmdroot| make install}}
:{{cmdroot| cp /usr/local/lib/security/* /lib/security/}}
{{NOTE|If you get a 'rpl_malloc' error in /var/log/auth.log when trying to use the fingerprint reader, redo these steps and remove the related term from Makefile after running ./configure. (FC3, Debian etch)}}
*Use the sample tool from the fingerprint reader to create {{path|<username>.bir}} (<tt><username></tt> '''must''' be the username you want to login with. gdm will probably break for any login name that has no .bir file).
*As root do:
:{{cmdroot|SERIAL<nowiki>=`BioAPITest | sed -ne "/Fingerprint/{n;n;s/^.*: $.\{9\}$$.\{4\}$$.\{4\}$$.\{4\}$$.*$/\1-\2-\3-\4-\5/gp}"` </nowiki>}}
:{{cmdroot|echo $SERIAL}} should print something like {{cmdresult|<nowiki>{5550454b-2054-464d-2f45-535320425350}</nowiki>}} now.
:If it does, do:
:{{cmdroot|mkdir -p /etc/bioapi/pam/$SERIAL}}
:{{cmdroot|cp <username>.bir /etc/bioapi/pam/$SERIAL}}
:If not, you might just try
:{{cmdroot|SERIAL<nowiki>={5550454b-2054-464d-2f45-535320425350}</nowiki>}}
:as this value is hardcoded into the UPEK docs.

===Configuring pam===
The following part is distribution specific. On {{Ubuntu}} or {{SUSE}} you can modify {{path|/etc/pam.d/common-auth}} (on {{Gentoo}} and {{Fedora}} it is {{path|/etc/pam.d/system-auth}}) to look like this:

#
# /etc/pam.d/common-auth - authentication settings common to all services
#
# This file is included from other service-specific PAM config files,
# and should contain a list of the authentication modules that define
# the central authentication scheme for use on the system
# (e.g., /etc/shadow, LDAP, Kerberos, etc.). The default is to use the
# traditional Unix authentication mechanisms.
#
auth sufficient pam_bioapi.so {5550454b-2054-464d-2f45-535320425350} /etc/bioapi/pam/
password sufficient pam_bioapi.so {5550454b-2054-464d-2f45-535320425350} /etc/bioapi/pam/
auth required pam_unix.so nullok_secure

----
For '''Gentoo'''-Users - this allows you to attempt a password first. If you simply press enter, it then prompts for a fingerprints. Create a file named {{path|/etc/pam.d/bioapi}}. This also means that remote services, such as SSH keep working:

auth required pam_env.so
auth sufficient pam_unix.so likeauth nullok
auth sufficient pam_bioapi.so {5550454b-2054-464d-2f45-535320425350} /etc/bioapi/pam/
auth required pam_deny.so

account required pam_unix.so

session required pam_limits.so
session required pam_unix.so

----

Now, simply replace "auth include system-auth" in all services that you wish to use fingerprint for with "auth include bioapi". For example, {{path|/etc/pam.d/kde}} by default contains

auth include system-auth
auth required pam_nologin.so

account include system-auth

password include system-auth

session include system-auth

Simply replace the first "system-auth" with bioapi and you can also get rid of KDE desktop lock with a fingerprint. If you do not wish to allow for "password fallback" then remove

auth sufficient pam_unix.so likeauth nullok

from {{path|/etc/pam.d/bioapi}}.

{{WARN|If su/sudo expects to receive the root password (SuSE 10), you need to have fingerprint settings for root (that is, copy in a root.bir as well as a your-username.bir). Otherwise, they get a segmentation fault. Which is a little unfortunate, given that you need to su or sudo to change your settings...}}

Note that sshd may pick up the fingerprint settings from {{path|/etc/pam.d/common-auth}}. I didn't want that, so I removed the "auth include common-auth" line from {{path|/etc/pam.d/sshd}} and replaced it with the lines that were originally in my {{path|/etc/pam.d/common-auth}}. That way most local services use the fingerprint reader, but sshd does not.

Another way to do this is to create a file ({{path|/etc/pam.d/bioapi|}} for example) which contains the {{cmd|pam_bioapi.so|}} lines, and explicitly {{cmd|@include|}} this '''before''' {{path|/etc/pam.d/common-auth|}} in the files for services which should use the fingerprint reader. In this case you should leave {{path|/etc/pam.d/common-auth|}} alone.

{{NOTE|This was discovered through trial and success, if it is plain wrong, wikorrect it, please.}}

In {{Fedora}} the original 'session' terms in {{path|/etc/pam.d/system-auth}} need to be kept.

{{HINT|The setup described above will/could affect remote ssh logins to also use biometric logins, which is a bit silly (who wants to remote ssh to the laptop, and then have to walk over to it and swipe your finger) To avoid that you can copy the default <tt>/etc/pam.d/system-auth</tt> to <tt>/etc/pam.d/sshd</tt> which will allow the sshd service to use the standard authentication procedure.}}

You can do some useful testing with [http://pamtester.sourceforge.net/ {{cmd|pamtester|}}], which calls the pam modules as if it were a program of your choice. Examples:
:{{cmdroot|pamtester xdm yourusername authenticate}}
:{{cmduser|pamtester xscreensaver yourusername authenticate}}
where {{cmd|yourusername|}} is your username. Note that {{cmd|pamtester|}} should run as root if and only if the program in question does.

===Application support===
The implementation of fingerprint scanning support in the relevant applications varies.

Here is the behaviour of the most common ones:
* gdm should pop up an (ugly) image to swipe your finger and... magic - you can login without a password.
* kdm doesn't give any visual indication, other than that the cursor stops blinking. Just swipe your finger and hope it lets you log in.
* In xdm, enter your username and a blank password, then swipe (there is no popup as well).
* The KDE screen saver in SUSE 10 requires you to enter an empty password (or select the correct user and then enter an empty password) in order to get the fingerprint prompt.
* For Fedora users, the redhat-config tools will crash if no root.bir presents. Also, there won't be any visual idication unless X server is properly configured for root to access. Just swipe your finger when the HDD stopped blinking or issue the following command in advance:
:{{cmduser|xhost +local:}}

==Make xscreensaver use the scanner==
*Get the needed xscreensaver sources:
:{{cmduser|wget http://www.jwz.org/xscreensaver/xscreensaver-4.23.tar.gz}}
:{{cmduser|tar xzf xscreensaver-4.23.tar.gz}}
:{{cmduser|cd xscreensaver-4.23}}
:{{cmduser|wget http://nax.hn.org/pub/bioapi/xscreensaver-4.22_alternativeAuth.diff}}
*After reviewing the patch (it's small and straightforward), do
:{{cmduser|patch -p1 < xscreensaver-4.22_alternativeAuth.diff}} The patch prevents xscreensaver from opening an authentification window and dispatches the authentification request to another program, in our case <tt>pam</tt> and <tt>pam_bioapi</tt>. It should apply with some offset, don't mind that. If it says something about rejected though, then there's a problem.
*Compile with
:{{cmduser|./configure --with-pam && make}} 
*If you recieve an error like "undefined reference to `XmuPrintDefaultErrorMessage'" then install the libxmu-dev package and run the previous line again
*and then install as root with
:{{cmduser|su -c make install}} .
*Make sure that the newly compiled xscreensaver is used:
:{{cmduser|which xscreensaver}} should return
:{{cmdresult|/usr/local/bin/xscreensaver}} .
:*In case it doesn't, try
::{{cmduser|1=export PATH=/usr/local/bin:$PATH}} and retry.
*Kill the running instance of xscreensaver:
:{{cmduser|xscreensaver-command -exit}}
*Make sure you have the following line in your {{path|~/.xscreensaver}}:
alternativeAuth: True
*Now edit {{path|/etc/pam.d/xscreensaver}} to include the following line (If you're on {{Ubuntu}} Breezy and you already changed {{path|/etc/pam.d/common-auth}} you should not need to do this.):
auth sufficient pam_bioapi.so {5550454b-2054-464d-2f45-535320425350} /etc/bioapi/pam/
*Start the new xscreensaver
:{{cmduser|xscreensaver}} There should be a splash screen with version 4.23.
*Now try:
:{{cmduser|xscreensaver-command -lock}}

If you have questions or problems with this procedure, ask: t43fingerprint (at) badcode.de .

===Package for Debian sid===

If you're running {{Debian}} sid (the unstable branch) you can also try the patched .deb-package (built from current Debian sources fetched with {{cmd|apt-get source|}}) from [http://linux.spiney.org/debian_gnu_linux_on_an_ibm_thinkpad_t43p_fingerprint_reader this page], which also has Debian-specific instructions on how to setup the fingerprint reader. Use it on your own risk.

==Troubleshooting and Hints==
# After installing the driver, don't forget to reboot!
## This might not be necessary. it worked here without having to reboot.
# To see if the fingerprint device is know on the USB bus do:
:{{cmdroot|lsusb}}
:as root and you should see a line like:
:{{cmdresult|Bus 003 Device 004: ID 0483:2016 SGS Thomson Microelectronics}}
:The bus and device number can be different. This should work without the driver installed. If the device does not show up, you have a hardware problem/quirk, Rebooting or removing/inserting USB kernel modules might fix this.
# For some installation, after installing the driver as in section [[#Installing the driver|Installing the driver]] and makingÂ´sure the device is recognized, try to test it by going to {{path|NonGUI_Sample}} directory and run {{cmdroot|./Sample}}, one get segmentation fault. In this case, try getting the Beta1 instead of Beta2 of the driver and installing it
# There was some confusion about the /etc/bioapi1.10/pam{5550454b-2054-464d-2f45-535320425350} path, this has been fixed in the howto, if you have problems, check the section again, the path needs to have the '-' in them
# When something goes wrong look at the tail of {{path|/var/log/auth.log}}. (on {{Fedora}} it is {{path|/var/log/secure}}) Specifically if you see an entry saying something like
pam_bioapi[10480]: Unable to load BioAPI BSP with UUID of {5550454b-2054-464d-2f45-535320425350}, BioAPI error <nowiki>#</nowiki>194d.
Check whether your {{path|/proc/bus/usb}} directory permissions are set up as in the
section [[#Installing the driver|Installing the driver]].
# To get the xscreensaver compiled you might need a bunch of header files (depending on which xscreensaver features you want), in my case I need the following:
#*python-gtk2-dev
#*libgstreamer0.8-dev
#*xlibs-dev
# Sometimes {{path|$HOME/.xscreensaver}} got overwritten, try changing it to read-only.
# If after suspending to RAM and resume, lsusb no longer have "SGS Thomson Microelectronics" entry, try adding a line
/etc/init.d/hotplug restart
to your {{path|/etc/acpi/resume.sh}} file
#If after resume lsusb shows the device but xscreensaver does not ask for fingerprint for login, you might want to check the permission of the usb bus in the appropriate {{path|/proc/bus/usb/}} entry. If necessesary you might need to add a line to {{path|/etc/acpi/resume.sh}} as in section [[#Installing the driver|Installing the driver]] to set the permission right.
-----
If it still doesn't work, ask me for help (and make sure all usefull stuff makes it back into this wiki :)
to get a starting point as to where your problem is please include the output of:

:{{cmduser|lsusb}}

:{{cmdroot|ldconfig -p <nowiki>|</nowiki> grep bioapi}}

:{{cmdroot|updatedb && locate bioapi}}

t43fingerprint (at) badcode.de

(15.12.2005: small Gentoo-update! {darcline (at) gmx.net} with a now fully operational Thinkpad X41 running Gentoo and E17)
Thank you badcode!

(20.12.2005: small Suse-update! {marten.gustafson (at) gmail.com} now with a fully operational Thinkpad T43 running Suse 10)
Thanks!