https://www.thinkwiki.org/w/api.php?action=feedcontributions&user=Tyne&feedformat=atomThinkWiki - User contributions [en]2024-03-28T16:56:08ZUser contributionsMediaWiki 1.31.12https://www.thinkwiki.org/w/index.php?title=Talk:How_to_enable_integrated_fingerprint_reader_with_BioAPI&diff=17243Talk:How to enable integrated fingerprint reader with BioAPI2006-01-12T08:51:29Z<p>Tyne: </p>
<hr />
<div>== chmod 777 -R /usr/local/var/bioapi/ ==<br />
<br />
Is the above necessary? I just made a debian package of xscreensaver with the patch applied, and when using the bioapi debian pacakge from [http://www.qrivy.net/~michael/temp/ Michael R. Crusoe's site] which has this directory put in /usr/var/bioapi I had not to change the permissions to world-writeable there. Write access to the logfile and usb device are necessary, but that directory works with 755 as well (even though it comes with 777 in Michael's package), and all files and subdirectories are 644/755 too.<br />
<br />
--[[User:Spiney|spiney]] 00:08, 11 Nov 2005 (CET)<br />
----<br />
<br />
== Qt Compilation Success ==<br />
<br />
Here it worked with qt ;)<br />
<br />
--<br />
<br />
I didn't get it to work anyway, but I'm curious about your Qt version(s) as it seemed to want Qt 3 when I was playing with it.<br />
<br />
--[[User:Keegan|keegan]] 05:07, 24 Dec 2005 (CET)<br />
<br />
== using absolute paths for commands ==<br />
<br />
I don't know whether using absolute paths in the articles is a good idea, at least not for tools like {{cmd|lsusb|}} which are not established utilities (i.e. used for more than a decade or something ;)) and happen to be in different locations in different distributions. E.g. said {{cmd|lsusb|}} resides in {{path|/usr/sbin|}} on Debian systems.<br />
<br />
--[[User:Spiney|spiney]] 16:45, 12 Nov 2005 (CET)<br />
----<br />
<br />
I'm using debian testing and it's in {{path|/usr/bin|}}. I agree that the confusion is bad; dropping the absolute paths and adding a general note about checking {{cmd|$PATH|}} in case of problems is probably good.<br />
<br />
--[[User:keegan|keegan]]<br />
<br />
== BioAPI error #3 ==<br />
<br />
Its kind of strage it used to work with everythig (kdm,console,lock,etc)<br />
Now it only works with kdm. It allways gives back:<br />
<br />
pam_bioapi[8113]: Unable to initialize Bioapi framework, BioAPI error #:3.<br />
<br />
Even when I set the right permissions on /proc/bus/usb.<br />
<br />
I am able to run the Sample program as normal user after setting the permissions, but when I change within a user session by su I amnot able to run the Sample program a also get an error Code #3.<br />
<br />
From an other terminal (alt+strg+Fx) I am able to run the Sample program but at the login I still get the error #3.<br />
<br />
I cant remember to have changed anything an d bevor I was able to login in a console with my fingerprint now only kdm is working even kde lock-session <br />
isnt working anymore.<br />
<br />
Any suggestions ?<br />
<br />
==Permission errors exclusive to xscreensaver==<br />
<br />
I followed the instructions above and got everything working, including non-root programs like xscreensaver. However, the script to change usbfs permissions is finicky and fails to work with a lot of things like suspend/resume. Therefore, I switched to specifying <tt>devgid=108,devmode=0660,busgid=108,busmode=0770,listgid=108,listmode=0660</tt> as mount parameters for usbfs, where group 108 is a group I created and added my normal user to. This seems like a much better way of doing things, and it almost works. However, xscreensaver (using the newer patch) gives the familiar <tt>Unable to load BioAPI BSP with UUID of <nowiki>{</nowiki>5550454b-2054-464d-2f45-535320425350<nowiki>}</nowiki>, BioAPI error #194d.</tt> error in {{path|/var/log/auth.log|}}. I don't think this is a straightfoward permissions problem because<br />
<ul><br />
<li>the permissions in {{path|/proc/bus/usb|}} are correct by inspection</li><br />
<li>I can write to the device file as my normal user</li><br />
<li>other programs like {{cmd|test_verify-pam_bioapi|}} and [http://pamtester.sourceforge.net/ {{cmd|pamtester|}}] work as my normal user</li><br />
<li>the weirdest one: xscreensaver works when the {{cmd|xscreensaver|}} daemon is launched from within {{cmd|strace|}}. It's still running as my normal user ({{cmd|strace|}} is not setuid root). I have absolutely no idea what would cause this. I thought it might be an environment issue, but the difference in environment between the {{cmd|strace|}} session and my normal session is trivial.</li><br />
</ul><br />
<br />
At this point I'm hoping it's something dumb, but I'm out of ideas. The {{cmd|xscreensaver|}} error is <tt>pam_authenticate (...) ==&gt; 7 (Authentication failure)</tt>, for the record.<br />
<br />
--[[User:keegan|keegan]]<br />
----<br />
<br />
Could you provide all the log lines between pam_start and pam_end when running {{cmd|xscreensaver -verbose|}}?<br />
<br />
BTW, the idea with using the mount options for usbfs is very good, maybe you should add that info to the article page? I use the permission changing script without problems, also after resume, but the usbfs version is probably easier to set up, most people will be able to find {{path|/etc/fstab|}}.<br />
<br />
--[[User:Spiney|spiney]] 10:12, 23 Dec 2005 (CET)<br />
----<br />
<pre><br />
xscreensaver: 20:56:01: alternative_pam: 1 -> pam service: xscreensaver-alternative<br />
xscreensaver: 20:56:01: pam_start ("xscreensaver-alternative", "keegan", ...) ==> 0 (Success)<br />
xscreensaver: 20:56:01: pam_set_item (p, PAM_TTY, ":0.0") ==> 0 (Success)<br />
xscreensaver: 20:56:01: PAM ECHO_OFF("Password: ") ==> password<br />
xscreensaver: 20:56:03: pam_authenticate (...) ==> 7 (Authentication failure)<br />
xscreensaver: 20:56:03: pam_end (...) ==> 0 (Success)<br />
xscreensaver: 20:56:03: prompting for password.<br />
xscreensaver: 20:56:03: 0: creating password dialog.<br />
xscreensaver: 20:56:03: 0: mouse is at 442,412.<br />
xscreensaver: 20:56:03: grabbing server...<br />
xscreensaver: 20:56:03: 0: ungrabbing mouse (was 0x48).<br />
xscreensaver: 20:56:03: 0: grabbing mouse on 0xe0002b... GrabSuccess.<br />
xscreensaver: 20:56:03: ungrabbing server.<br />
xscreensaver: 20:56:05: alternative_pam: 12582928 -> pam service: xscreensaver<br />
xscreensaver: 20:56:05: pam_start ("xscreensaver", "keegan", ...) ==> 0 (Success)<br />
xscreensaver: 20:56:05: pam_set_item (p, PAM_TTY, ":0.0") ==> 0 (Success)<br />
xscreensaver: 20:56:05: PAM ECHO_OFF("Password: ") ==> password<br />
xscreensaver: 20:56:05: pam_authenticate (...) ==> 0 (Success)<br />
xscreensaver: 20:56:05: pam_acct_mgmt (...) ==> 9 (Authentication service cannot retrieve authentication info.)<br />
xscreensaver: 20:56:05: pam_setcred (...) ==> 0 (Success)<br />
xscreensaver: 20:56:05: pam_end (...) ==> 0 (Success)<br />
xscreensaver: 20:56:05: password correct.<br />
</pre><br />
So we've got the first attempt with {{cmd|pam_bioapi|}}, which fails immediately (no sign of the GUI fingerprint prompt, nor a "silent" chance to swipe the finger as with xdm), then the fallback to {{cmd|pam_unix|}} which succeeds. Earlier I had xscreensaver set up to only try {{cmd|pam_bioapi|}}, with essentially the same result -- it gives up on pam entirely and does unix auth itself.<br />
<br />
I'd really like to strace the pam module and see what it's attempting to do to {{path|/proc/bus/usb|}}, but as that actually fixes the problem I'm kinda at a loss. Maybe there's some kernel option to print debugging info for usbfs? I'd be all for changing the article to suggest using mount options in {{path|/etc/fstab|}}, if it weren't for this one weird bug. Has anyone else had the same problem?<br />
<br />
-- [[User:keegan|keegan]]<br />
<br />
==Driver Expiring!!!==<br />
Don't anyone notice that both betas of the UPEK driver is expiring in<br />
about a month in the new year, Jan 1st 2006? They really mean it! <br />
I set my computer date to next year and get a message "the driver has expired" when using fingerprint reader! This is a grave threat to our computer lifestyle, i.e. for those of us who got it working and use it<br />
daily:) <br />
Is there any workaround other than setting the date back a year when<br />
new year come and wait for new driver? Is there a way to figure out where exactly in the driver it checked the date and how? The must have set it <br />
somewhere in file libtfmessbsp.so, but it is binary and I can't figure out how to Reverse Engineer it.<br />
<br />
---Jiang<br />
<br />
Yes, the beta driver will expire. The final version (which is due REALLY soon now) will not.<br />
<br />
Sumedha<br />
<br />
Any news? Just 9 days left to expiry. --[[User:Thinker|Thinker]] 21:36, 22 Dec 2005 (CET)<br />
<br />
The final is out, get it at [http://www.upek.com/support/dl_linux_bsp.asp UPEK's download page]. And how does one edit the industry watch section of the main page?<br />
<br />
--[[User:Spiney|spiney]] 21:39, 22 Dec 2005 (CET)<br />
<br />
Ah, great! Both the article page and the driver page it points to are out of date... For the news, just follow the "[[ThinkWiki:News|News]]" link in the main page. <br />
<br />
--[[User:Thinker|Thinker]] 21:44, 22 Dec 2005 (CET)<br />
<br />
As this is now very soon I've updated the article page to link to the final driver, which is better in a few ways anyway. This is unless anyone minds (are there any unresolved issues with the final that don't exist in the betas?).<br />
<br />
--[[User:Keegan|keegan]] 05:06, 24 Dec 2005 (CET)<br />
<br />
== Updated xscreensaver patch ==<br />
<br />
I've tried to address some usability issues with the old patch, e.g. that it calls the PAM bioapi module twice before falling back to the normal authentication methods. It can be found on my [http://linux.spiney.org/debian_gnu_linux_on_an_ibm_thinkpad_t43p_fingerprint_reader Fingerprint Reader] page, feedback is very welcome.<br />
<br />
--[[User:Spiney|spiney]] 20:36, 22 Dec 2005 (CET)<br />
----<br />
<br />
== Fingerprint or password ==<br />
<br />
Is there any way to have PAM accept either a password or a finger swipe, right away? Sometimes one is more convenient, sometimes the other, so and it's a lot of trouble to wait for the UPEK scanner prompt and then cancel it in order to reach the password entry.<br />
<br />
--[[User:Thinker|Thinker]] 19:27, 24 Dec 2005 (CET)<br />
<br />
== KDE screensaver ==<br />
<br />
If you get the following in {{path|/var/log/secure}} when you try to unlock the KDE screensaver, it means you forgot to set the USB device permissions.<br />
localhost pam_bioapi[24981]: Unable to load BioAPI BSP with UUID of {5550454b-2054-464d-2f45-535320425350}, BioAPI error #194d.<br />
<br />
--[[User:Thinker|Thinker]] 21:21, 24 Dec 2005 (CET)<br />
----<br />
<br />
== fingerprint reader in action. ==<br />
<br />
small video with fingerprint reader in action with login: http://chao.ch/tmp/mov01302.mpg<br />
<br />
--[[User:62.202.35.30|62.202.35.30]] 17:57, 29 Dec 2005 (CET)<br />
<br />
==A little feedback...==<br />
...for all the editors of this article:<br />
<br />
"[[How to enable the fingerprint reader]] over at ThinkWiki.org is some real exhaustive documentation for getting the fingerprint scanner working on the ThinkPads. There is also a troubleshooting section towards the end that might be very useful to anyone messing around with it.<br />
<br />
Thanks to those responsible for taking the time to write up this excellent guide."<br />
<br />
Those thanks come from [http://linuxbiometrics.com/modules/news/ LinuxBiometrics.com]<br />
<br />
[[User:Wyrfel|Wyrfel]] 01:24, 9 Jan 2006 (CET)<br />
----<br />
<br />
==pam_bioapi.so is not linked to libbioapi100.so==<br />
I downloaded the pam_bioapi package and patched the file by following the wiki. However, I got the following result:<br />
<br />
~/soft/thinkpad/pam_bioapi-0.2.1/libpam_bioapi/.libs$ ls -la<br />
total 48<br />
drwxr-xr-x 2 louis users 248 2006-01-12 01:18 ./<br />
drwxr-xr-x 4 louis users 312 2006-01-12 01:18 ../<br />
lrwxrwxrwx 1 louis users 16 2006-01-12 01:18 pam_bioapi.la -> ../pam_bioapi.la<br />
-rw-r--r-- 1 louis users 824 2006-01-12 01:18 pam_bioapi.lai<br />
-rw-r--r-- 1 louis users 19716 2006-01-12 01:18 pam_bioapi.o<br />
lrwxrwxrwx 1 louis users 19 2006-01-12 01:18 pam_bioapi.so -> pam_bioapi.so.0.0.0*<br />
lrwxrwxrwx 1 louis users 19 2006-01-12 01:18 pam_bioapi.so.0 -> pam_bioapi.so.0.0.0*<br />
-rwxr-xr-x 1 louis users 21789 2006-01-12 01:18 pam_bioapi.so.0.0.0*<br />
<br />
~/soft/thinkpad/pam_bioapi-0.2.1/libpam_bioapi/.libs$ ldd pam_bioapi.so<br />
linux-gate.so.1 => (0xffffe000)<br />
libc.so.6 => /lib/tls/libc.so.6 (0x40025000)<br />
/lib/ld-linux.so.2 (0x80000000)<br />
~/soft/thinkpad/pam_bioapi-0.2.1/libpam_bioapi/.libs$<br />
<br />
pam_bioapi.so is NOT linked to libbioapi100.so. The latter is in the ld path:<br />
<br />
~/soft/thinkpad/pam_bioapi-0.2.1/libpam_bioapi/.libs$ ldconfig -p |grep bioapi<br />
libtfmessbsp.so (libc6) => /opt/bioapi/lib/libtfmessbsp.so<br />
libpwbsp.so.0 (libc6) => /opt/bioapi/lib/libpwbsp.so.0<br />
libpwbsp.so (libc6) => /opt/bioapi/lib/libpwbsp.so<br />
libmds_util.so.0 (libc6) => /opt/bioapi/lib/libmds_util.so.0<br />
libmds_util.so (libc6) => /opt/bioapi/lib/libmds_util.so<br />
libbioapi100.so.0 (libc6) => /opt/bioapi/lib/libbioapi100.so.0<br />
libbioapi100.so (libc6) => /opt/bioapi/lib/libbioapi100.so<br />
libbioapi_mds300.so.0 (libc6) => /opt/bioapi/lib/libbioapi_mds300.so.0<br />
libbioapi_mds300.so (libc6) => /opt/bioapi/lib/libbioapi_mds300.so<br />
libbioapi_dummy100.so.0 (libc6) => /opt/bioapi/lib/libbioapi_dummy100.so.0<br />
libbioapi_dummy100.so (libc6) => /opt/bioapi/lib/libbioapi_dummy100.so<br />
<br />
and the Sample program also works allowing me to enroll and test a fingerprint.<br />
<br />
My system is SuSE 10 with the kernel of 2.6.13-15. Any ideas?<br />
<br />
Thanks.<br />
<br />
--[[User:Tyne|Tyne]] 09:51, 12 Jan 2006 (CET)</div>Tynehttps://www.thinkwiki.org/w/index.php?title=Talk:SMAPI_support_for_Linux&diff=13984Talk:SMAPI support for Linux2006-01-02T23:14:24Z<p>Tyne: </p>
<hr />
<div>== Feedback ==<br />
<br />
Great, great work! Really! This completely rocks. I just stopped my battery from charging at 77% and restarted charging a bit later, no problems whatsoever. BTW, this is on kernel 2.6.14.3.<br />
<br />
--[[User:Spiney|spiney]] 21:25, 5 Dec 2005 (CET)<br />
----<br />
None of the fuctions is working on my T40, kernel 2.6.14-mm2.<br />
<br />
--[[User:Lammic|lammic]], 2005.12.05<br />
<br />
Works for me on a T41 running 2.6.12-10-686 (Ubuntu 5.10).<br />
<br />
--[[User:berndtnm|berndtnm]], 2005.12.06<br />
<br />
Including stop_charge_thresh? That one seems to be missing on the T42p.<br />
<br />
--[[User:Thinker|Thinker]] 00:46, 7 Dec 2005 (CET)<br />
----<br />
<br />
tp_smapi works just fine on an R52 with Ubuntu Breezy stock kernel.<br />
<br />
--[[User:Micampe|Micampe]] 12:52, 7 Dec 2005 (CET)<br />
<br />
----<br />
<br />
''To set the thresholds for starting and stopping battery charging (in percent of current capacity):''<br />
<br />
'''current''' really? That'd be weird, I'd expect it to be percent of '''total''' capacity.<br />
<br />
--[[User:Micampe|Micampe]] 14:39, 7 Dec 2005 (CET)<br />
<br />
"Current full charge capacity", as opposed to "current remaining capacity" or "designed full charge capacity"...<br />
<br />
--[[User:Thinker|Thinker]] 15:05, 7 Dec 2005 (CET)<br />
----<br />
<br />
Battery features don't work with my T41p. I can't check this with windows. Can anybody try these features?<br />
<br />
-- Nils, 7 Dec 2005<br />
----<br />
<br />
Nils, does cdrom_speed work for you on the T41p? Could you provide the details requested in the README (dmesg etc.)?<br />
<br />
--[[User:Thinker|Thinker]] 21:57, 7 Dec 2005 (CET)<br />
----<br />
<br />
CDRom Speed seems to work. (I see no warnings, but I have to do a speed test.) Now, I've send all outputs to the email-address in the readme.<br />
<br />
-- Nils, 8 Dec 2005<br />
----<br />
<br />
All the features except the stop_charge_thresh seem to work here on a t42p. <br />
One note, the start_charge_thresh seems to really be stop_charge_thresh. Ie, If I set that to lower than my current battery %, it will never charge, <br />
and if I set it to 100 the battery charges all the way. <br />
<br />
--[[User:Nirik|Nirik]] 16 Dec 2005<br />
----<br />
<br />
Nirik, "all the features" as of which version? For example, do the force_discharge{1,2} in tp_smapi 0.12 also work for you? See the table in the article page. About start_charge, that's odd. Can you send me a log of what you did, what was the result a what was the dmesg output for each operation?<br />
<br />
--[[User:Thinker|Thinker]] 14:16, 16 Dec 2005 (CET)<br />
----<br />
<br />
System T40p:<br />
<br />
<pre><br />
fairlight:/sys/devices/platform/smapi/BAT0# echo 1 > /sys/devices/platform/smapi/BAT0/force_discharge1<br />
fairlight:/sys/devices/platform/smapi/BAT0# echo 1 > /sys/devices/platform/smapi/BAT0/force_discharge2<br />
fairlight:/sys/devices/platform/smapi/BAT0# dmesg <br />
tp_smapi: req_in: BX=2118 CX=100 DI=0 SI=0<br />
tp_smapi: req_out: AX=8680 BX=2118 CX=100 DX=b2 DI=0 SI=0 ret=-38<br />
tp_smapi: SMAPI error: Function is not supported by SMAPI BIOS (func=2118)<br />
tp_smapi: cannot get force_discharge1 of battery 0: Function is not supported by SMAPI BIOS<br />
tp_smapi: req_in: BX=2104 CX=100 DI=0 SI=0<br />
tp_smapi: req_out: AX=80 BX=2103 CX=100 DX=78 DI=0 SI=0 ret=0<br />
tp_smapi: cannot get force_discharge2 of battery 0: bx=2103<br />
</pre><br />
<br />
So it seems force_discharge1 is not supported at all. But force_discharge2? By the way, i think wiki is a _very_ good idea for collecting information, but not for discussion. I would prefer a maillinglist. We can use sourceforge.<br />
<br />
--[[User|StefanSchmidt]]<br />
<br />
force_discharge2 is indicating a real error condition (bx=2103 which has bit 0x02 on), but I have no idea what the error is or how to fix it. Sorry. If you can trigger this function under Windows and have SoftICE or equivalent, maybe it can be worked out.<br />
<br />
About the Wiki discussion, I'm not sure a mailing list is justified yet, but you can use the linux-thinkpad list or the e-mail address in the README. <br />
<br />
--[[User:Thinker|Thinker]] 21:42, 16 Dec 2005 (CET)<br />
<br />
OK, then i use linux-thinkpad to get more people involved. I'am away the next weeks, but i hope to find some time to hacking on tp_smapi.<br />
<br />
--[[User:StefanSchmidt]]<br />
----<br />
<br />
Someone reported cd_speed works on T42 but on mine, it doesn't: this is 2378DXU<br />
<br />
--[[User:eBug]] 22:55, 17 Dec 2005 (CET)<br />
----<br />
<br />
eBug, how does it fail? If the file doesn't exist, it means you didn't enable PROVIDE_CD_SPEED (see the README). If it does exist, can you provide the dmesg output when you read an write to the file?<br />
<br />
--[[User:Thinker|Thinker]] 11:53, 18 Dec 2005 (CET)<br />
----<br />
<br />
To confirm:<br />
tp_smapi 0.13 works with hdaps module loaded on T41 (2373-8RG). However, force_discharge*, inhibit_charge_minutes, start_charge_thresh, stop_charge_thresh don't seem to be implemented on this model.<br />
<br />
--[[User:LJSBRokken|LJSBrokken]] 21 Dec 2005<br />
----<br />
<br />
==Changing the CD speed when the CD is being accessed will hang your computer==<br />
<br />
I don't have this problem on my T40p. CDROM is mounted and file on CD is opened. Change speed do '''not''' hang my system.<br />
<br />
-- Stefan Schmidt<br />
----<br />
<br />
An open file looks fine if you're not reading/writing at that point. But my T43 does hangs on this:<br />
# dd if=/dev/scd0 of=/dev/null &<br />
# echo 1 > /sys/devices/platform/smapi/cdrom_speed<br />
<br />
--[[User:Thinker|Thinker]] 16:41, 7 Dec 2005 (CET)<br />
----<br />
<br />
OK, sorry. I was to fast. My system hangs on this commands, too. :(<br />
<br />
-- Stefan Schmidt<br />
<br />
Works well. Great.<br />
<br />
T42 2373-8zh. Working :cdrom_speed and start_charge_thresh. Untest : inhibit_charge_minutes.<br />
<br />
-- Haifeng Chen<br />
<br />
cdrom_speed works on my T40.<br />
<br />
-- [[User:Lammic|lammic]], 2005.12.09<br />
<br />
== "thinkpad" module kernel compatibility ==<br />
<br />
Ajunge, how do you compile the "thinkpad" module compile on kernel >=2.6.9? The latest thinkpad version (5.8) still uses "get_cpu_ptr" and "set_cpu_ptr", which were removed in 2.6.9.<br />
<br />
--[[User:Thinker|Thinker]] 13:53, 10 Dec 2005 (CET)<br />
----<br />
<br />
The Debian thinkpad-source package in unstable (version 5.8-4) works just fine; I'm compiling it with 2.6.14 without any problems. And get_cpu_ptr is present; it's defined in include/linux/percpu.h.<br />
<br />
--[[User:TedTso|TedTso]] 18:56, 17 Dec 2005 (EDT)<br />
----<br />
<br />
Stock thinkpad_5.8.tar.gz doesn't #include percpu.h anyway, and doesn't compile on vanilla 2.6.14.3 or 2.6.15-rc5. Maybe Debian patched it? In that case the article page should ref the patch.<br />
<br />
--[[User:Thinker|Thinker]] 11:50, 18 Dec 2005 (CET)<br />
----<br />
<br />
Oops, my mistake. I forgot that I had patched my copy of thinkpadpm.c. I replaced the use of get_cpu_ptr and set_cpu_ptr with get_cpu_val() and set_cpu_val(). I just double checked, and it tpctl is working for me on 2.6.15-rc5.<br />
<br />
--[[User:TedTso|TedTso]] 14:45, 19 Dec 2005 (EDT)<br />
----<br />
<br />
Care to send a patch? It would be useful on the article page, and maybe we can get it into upstream.<br />
<br />
--[[User:Thinker|Thinker]] 23:11, 19 Dec 2005 (CET)<br />
----<br />
<br />
== Kernel Patch? ==<br />
<br />
Hello Thinker,<br />
<br />
would it be possible to provide the SMAPI support as kernel patch as well? Something along the lines of: (0.12 against 2.6.15-rc5)<br />
<br />
''(deleted, see below for how to create a patch file)''<br />
<br />
Deleted the tp_smapi.c file at the end, out of obvious reasons, and I'm not sure about the placement in the ACPI section, OTOH there it would be found easily next to ibm_acpi.<br />
<br />
Providing a patch would help when recompiling the kernel often, I hate recompiling external modules every time (even got me a kernel-upgrade script to do most of it automatically). But of course it's up to you. :)<br />
<br />
--[[User:Spiney|spiney]] 09:52, 16 Dec 2005 (CET)<br />
----<br />
<br />
I'll be glad to add this, but I don't want to go through additional manual steps in the release process (there are already quite a few). Can you add a "make patch" functionality to the Makefile, or something of the sort, to automatically generate a full patch (including tp_smapi.c) against current kernel sources?<br />
<br />
Also, this shouldn't be under drivers/acpi, since it doesn't use ACPI at all (that's why I didn't make it a patch to ibm_acpi). I think the right place is drivers/firmware, like the dell_rbu driver for Dell laptops.<br />
<br />
BTW, the convention for kernel patches is to start them once level higher:<br />
diff -Nurp kernel-2.6.14-vanilla kernel-2.6.14-patched<br />
<br />
--[[User:Thinker|Thinker]] 17:12, 16 Dec 2005 (CET)<br />
----<br />
<br />
Of course it's from the wrong level, as usual I was just lazy/inattentive. And at one point I'll remember who likes what patch format, promise. ;)<br />
<br />
A patch target as in "create a new file holding a correct diff to current kernel source" would be rather difficult, since line numbers might change etc., but applying the patch should be straighforward with a bit of sed. Of course I could just do that, create a patch with the diff command and then apply the new patch file in reverse. ;)<br />
<br />
--[[User:Spiney|spiney]] 18:36, 16 Dec 2005 (CET)<br />
----<br />
<br />
If it does that on a local copy (no changes the original kernel tree) and cleans up after itself, that's fine with me. :-)<br />
<br />
--[[User:Thinker|Thinker]] 18:50, 16 Dec 2005 (CET)<br />
----<br />
<br />
Ok, here's a shell script that creates the patch, feel free to use it under the terms of the GPL. For example call it from your Makefile with the patch target: (I didn't want to put all the script into the Makefile, since the rules about escaping in Makefiles, well, escape me ;)<br />
<br />
<pre><br />
#!/bin/bash<br />
<br />
KDIR=/lib/modules/$(uname -r)/build<br />
FDIR=drivers/firmware<br />
OPWD=$(pwd)<br />
<br />
TMPDIR=$(mktemp -d)<br />
cd $TMPDIR<br />
<br />
mkdir -p a/$FDIR<br />
cp $KDIR/$FDIR/{Kconfig,Makefile} a/$FDIR<br />
cp -r a b<br />
sed -i -e '/endmenu/i\<br />
config IBM_SMAPI\<br />
tristate "IBM ThinkPad SMAPI Support"\<br />
depends on X86\<br />
---help---\<br />
This adds SMAPI support on IBM ThinkPads, mostly used for battery\<br />
charge control. For more information about this driver see\<br />
<http://www.thinkwiki.org/wiki/SMAPI_support_for_Linux> .\<br />
\<br />
If you have an IBM ThinkPad laptop, say Y or M here.\<br />
' b/$FDIR/Kconfig<br />
sed -i -e '$a\<br />
obj-$(CONFIG_IBM_SMAPI) += tp_smapi.o' b/$FDIR/Makefile<br />
cp $OPWD/tp_smapi.c b/$FDIR<br />
diff -Nurp a b > $OPWD/tp_smapi-$(uname -r).patch<br />
rm -r a b<br />
cd $OPWD<br />
</pre><br />
<br />
BTW, [http://qbnz.com/highlighter/ GeSHi]-based syntax-highlighting would be great...<br />
<br />
--[[User:Spiney|spiney]] 19:28, 16 Dec 2005 (CET)<br />
----<br />
<br />
Ah, neat sed foo. How about [http://tpctl.sourceforge.net/tmp/Makefile this] escapade, then? <br />
<br />
What's the sed spell needed to replace the Makefile's<br />
VER := 0.13<br />
with auto-parsing of<br />
#define TP_VERSION "0.13"<br />
from tp_smapi.c?<br />
<br />
--[[User:Thinker|Thinker]] 20:37, 16 Dec 2005 (CET)<br />
----<br />
<br />
Hmm, something like<br />
VERFROMC=$(sed -ne 's/^#define TP_VERSION "\(.*\)"/\1/gp' tp_smapi.c)<br />
sed -i -e "s/^VER := .*$/VER := $VERFROMC/" Makefile<br />
should do (untested, from the top of my head, maybe the temporary variable isn't even necessary?). And neat Makefile wizardry, at one point I'll learn the syntax.<br />
<br />
--[[User:Spiney|spiney]] 20:44, 16 Dec 2005 (CET)<br />
----<br />
<br />
Makefile escaping is horrible, keep avoiding it... Anyway, the updated [http://tpctl.sourceforge.net/tmp/Makefile make patch] seems to do the right thing.<br />
<br />
--[[User:Thinker|Thinker]] 21:36, 16 Dec 2005 (CET)<br />
----<br />
<br />
==Installation questions==<br />
Amazing! I've loaded this module in my T43 which is running SuSE 10 with the kernel of 2.6.13-15. I have three points to share:<br />
<br />
1. The battery control part seems to work but has a minor problem. I set the stop_charge_threshold to 70, but the battery stops charging at 55%. Don't know why and how to fix it. :P<br />
<br />
2. I don't have the cd speed control function. Here is what I have under /sys/devices/platform/smapi/:<br />
<br />
./ ../ ac_connected BAT0/ BAT1/ bus@ driver@ power/<br />
<br />
3. SuSE 10 doesn't have the necessary C files under .../drivers/hwmon/, I copied them from a 2.6.14.5 kernel source. Maybe it causes the two problems above. :(<br />
<br />
When I have time, I'll install the new kernel to see if the problems are gone and report the result.<br />
<br />
--[[User:68.51.153.96|68.51.153.96]] 04:31, 2 Jan 2006 (CET)<br />
----<br />
<br />
1. It should stop charging at 70, but will only ''start'' charging when remaining capacity has dipped below <tt>start_charge_thresh</tt>.<br />
<br />
2. See the note about PROVIDE_CD_SPEED.<br />
<br />
3. That's should be needed only for patching the HDAPS driver in order to make it compatible with tp_smapi. If your kernel (which version is it?) doens't inlude the HDAPS driver anyway, you don't need to patch....<br />
<br />
--[[User:Thinker|Thinker]] 09:28, 2 Jan 2006 (CET)<br />
----<br />
<br />
Thanks Thinker.<br />
<br />
1. I discharged and recharged the battery again. This time, it stops at 68% percent, which is pretty good.<br />
<br />
2. I missed the NOTE in README, for I just followed this wiki. :P<br />
<br />
3. My kernel version is 2.6.13-15.<br />
<br />
By the way, I just got this T43 whose model number is 266896U. I feel that the noise of the fan is much louder than my previous T21. I think it is so since it has a CPU with bigger power but am wondering if other T43 has the same big noise?<br />
<br />
--[[User:Tyne|Tyne]] 00:14, 3 Jan 2006 (CET)</div>Tyne