ThinkWiki - User contributions [en]

How to save memory

2007-03-21T08:59:51Z

Esmil: /* Window Manager */ Added OpenBox

{| width="100%"
|style="vertical-align:top;padding-right:20px;width:10px;white-space:nowrap;" | __TOC__
|style="vertical-align:top" |This page is meant as a collection of information on how to save memory to make Linux work reasonable on older system with limited amount of RAM.

Most distributions nowadays don't take much care about it anymore, so there are a lot of things you can do to save memory. To get a smoothly working linux environment on a low memory machine you will need to conciously choose a lot of aspects of your system, most importantly the graphical environment, desktop environment and applications. This page provides detailed information about these various optimization possibilities.
|}

==Alternative graphical environments==
{{Todo|...}}

==Streamlining the desktop environment==
The common Desktop environments GNOME and KDE are, in their modern state, focused more on features, integration, and beauty rather than on resource saving. Understandable, but running Linux on an older ThinkPad with limited RAM requires conscious and sensitive resource usage more than anything else. The good thing about Linux is that a lot of things stay adjustable and customizable. So lets see what we can do about desktops.

One of the most important things is to decide for one graphical widget library and stick with that when you are choosing your desktop environment and applications. Having several toolkits in use means more libraries being loaded and hence more memory being used by those. Possibilities are:
* [http://www.fltk.org/ FLTK]
* [http://www.fox-toolkit.org/ FOX toolkit]
* [http://www.gnustep.org GNUstep toolkit]
* [http://www.gtk.org/ GTK] <tt>(not recommended, use GTK 2 if possible)</tt>
* [http://www.gtk.org/ GTK 2]
* [http://www.lesstif.org/ Lesstif] / [http://www.openmotif.org/ OpenMotif]
* [http://www.trolltech.com/products/qt/index.html QT]
* [http://www.windowmaker.org/development-wings.html WINGs] <tt>(kind of a lightweight GNUstep toolkit, provided by the WindowMaker developers)</tt>
* [http://www.x.org/ X Toolkit]

Of those, at current state, there are enough applications for the X Toolkit, GTK, GTK 2 and QT to provide you with a solution for every task you should want.

===GNOME===
It's like with humans, the worst feature is in most cases also the best one. For GNOME it is probably the many little parts it consists of. Makes it hard to install, but enables one to customize the installation. So, the first thing you should do to streamline GNOME is not to launch it. Sound stupid? Well, lets have a look.

GNOME is basically a set of libraries built around the GTK+ libs and extending its functionality. Add some nice little applications, a session manager, a panel, beautiful icons, and some other stuff and you have GNOME as you know it. Reversing those additions is what you can do to use GNOME applications on a machine that this desktop environment would normally take your nerves on.

The GNOME panel, the session manager, the desktop manager and the window manager are all parts of GNOME that eat a lot of memory for something that others can do in a maybe little less beautiful but much more resource saving way.
So first off configure your login manager not to launch gnome-session at login. If you are using GDM this is quite straight forward, you just need to add a different session script, launching your favorite window manager. See the list below and pick one, lets say i.e. WindowMaker. WindowMaker uses a desktop menu, a dock and a notification area to provide you with an organized way of launching applications and iconfying running ones. So we don't need a panel anymore. Also, think if you really need icons on your desktop. If you do, think about using something like ROX filer instead of nautilus for that. In any case, tell nautilus not to manage the desktop by default by unchecking the according setting within gconf-editor. To keep GNOME applications happy we would need to have gconf and gnome-settings-manager running at every session start. One way to do this is to either include them in your new session script. They both need to be running to make GNOME applications realize their settings properly.

===KDE===
{{Todo|...}}

===Alternative Desktop Environments===
First of all, it is important to notice that GNOME and KDE are not the only Desktop Environments around.
Other complete (featuring most of: window management, session management, desktop management, file management and panel) desktop environments are:
* [http://xfce.org/ XFCE] <tt>uses GTK 2</tt>
* [http://rox.sourceforge.net ROX Desktop]
* [http://ede.sourceforge.net Equinox Desktop Environment] <tt>uses eFLTK, a modified version of FLTK</tt>
* [http://www.nongnu.org/antiright/ AntiRight Desktop Environment] <tt>uses LessTif / OpenMotif</tt>
* [http://foxdesktop.sourceforge.net/ FOX Desktop Environment] <tt>uses FOX Toolkit</tt>
* [http://www.gnustep.org/ GNUstep] <tt>provides it's own toolkit</tt>

But also, some Window Managers exceed the task of managing windows towards providing a functional workbench. See below for a list.

===Building your own Desktop===

====Window Manager====
If you want to build your own customized desktop, a good start is choosing the window manager of your liking. A list of window managers is at [http://xwinman.org].

Here's a list of some of them:
*including basic Desktop Environment functionality
**the [[Wikipedia:NextStep|NextStep]] alike ones
***[http://www.windowmaker.org/ WindowMaker] <tt>(probably the most widespread NextStep like WM)</tt>
***[http://www.afterstep.org/ AfterStep] <tt>(another one of those)</tt>
**the Blackbox-like ones
***[http://blackboxwm.sourceforge.net/ BlackBox]
***[http://fluxbox.sourceforge.net/ FluxBox] <tt>(tabbed windows, lighweight)</tt>
***[http://www.icculus.org/openbox/ OpenBox] <tt>(written from scratch to be fully ICCCM and EWMH compliant, fast and light-weight)</tt>
**others
***[http://www.icewm.org/ IceWM] <tt>(lightweight, widespread)</tt>
***[http://enlightenment.sourceforge.net/ Enlightenment] <tt>(lots of features and eye candy)</tt>
***[http://www.pekwm.org PekWM] <tt>(kind of a one man show, but feature rich and extremely customizable)</tt>
*pure WindowManagers
**[http://golem.sourceforge.net/ Golem]
**[http://home.earthlink.net/~lab1701/larswm/ LarsWM] <tt>(unique tiling Window Manager)</tt>
**[http://www.nongnu.org/ratpoison/ ratpoison] <tt>(modeled after gnu screen)</tt>
**[http://fvwm.org/ fvwm] <tt>(small but powerful)</tt>
**[http://www.jfc.org.uk/software/lwm.html lwm] <tt>(very small, and fast)</tt>
**[http://www.all-day-breakfast.com/wm2/ wm2] <tt>really small Window Manager</tt>
**[http://www.all-day-breakfast.com/wmx/ wmx] <tt>slightly more featureful version of wm2</tt>
**[http://wmii.suckless.org wmii] <tt>keyboard driven approach, very small, dynamic window managing</tt>

====Taskbar/Panel====
Another thing that especially users coming to Linux from the Windows world would probably like is a Panel or Taskbar.

Here's a collection of independant low resource panels:
*[http://www.chatjunkies.org/fspanel/ F***ing Small Panel] <tt>(doesn't use any toolkit)</tt>
*[http://freshmeat.net/projects/hpanel/ HPanel] <tt>(doesn't use any toolkit)</tt>
*[http://fbpanel.sourceforge.net/ fbpanel] <tt>(depends on GTK 2)</tt>
*[http://jodrell.net/projects/perlpanel Perl Panel] <tt>(depends on GTK 2, gnomevfs, perl)</tt>
*[http://www.gkrellm.net/ GKrellM] <tt>(depends on GTK 2, flexible plugin based skinable vertical panel)</tt>

====Desktop Pinboard====
Then, the next thing you might be looking for is how to get icons onto your desktop. Usually this is done by the file manager who displays the content of a special directory as icons on the desktop. See the File Manager section to follow this approach.

However, you might decide for a really lightwight file manager which doesn't offer this feature. In that case all hope is not lost, for there are also special programs specialized in desktop icon management. Such are:
* [http://idesk.sourceforge.net/ iDesk] <tt>(recent versions need imlib2 only)</tt>

====File Manager====
File Managers are the fourth really important compontent of a desktop environment. There are plenty out their ranging from resource hugs to really lightweight and slim ones.

File Managers come with three distinct general user interface approaches: the two pane gui, the spacial and the browser gui. The browser gui is the one the Windows Explorer starting from Windows 2000 uses as well as earlier versions of Nautilus. The spacial view is the one known from Windows 95 and more recent versions of Nautilus. The two pane view is know to many from Norten Commander, Directory Opus or your favorite FTP client.

The following list provides an overview.
*FLTK
** [http://www.oksid.ch/flfm/ Fast Light File Manager] <tt>(spacial gui)</tt>
* FOX toolkit
** [http://roland65.free.fr/xfe/ X File Explorer] <tt>(browser and two pane gui)</tt>
*GTK
** [http://www.kaisersite.de/dfm/ Desktop File Manager] <tt>(spacial gui, incl. desktop icon management)</tt>
** [http://www.uwyn.com/projects/fm/ FM] <tt>(spacial, MAC OS 9 like gui)</tt>
** [http://radekc.regnet.cz/ Seksi Commander] <tt>(two pane gui)</tt>
*GTK 2
** [http://rox.sourceforge.net/ ROX Filer] <tt>(highly productive spacial gui, incl. panel and desktop icon management)</tt>
** [http://blog.perldude.de/projects/filer/ Filer] <tt>(browser and two pane gui, requires Perl)</tt>
** [http://xffm.sourceforge.net/ XFFM] <tt>(browser and spacial gui, requires some XFCE libs)</tt>
** [http://logicaldesktop.sourceforge.net/ Logical Desktop] <tt>(browser gui, actually a very special approach)</tt>
** [http://tuxcmd.sourceforge.net/ Tux Commander] <tt>(two pane gui)</tt>
** [http://www.nongnu.org/gcmd/index.html Gnome Commander] <tt>(two pane gui)</tt>
** [http://emelfm2.net/emelFM2/ emelFM2] <tt>(two pane gui with full customizable menu and toolbar, the best for power users)</tt>
** [http://thunar.xfce.org/index.xhtml Thunar] <tt>(requires some XFCE libs)</tt>
** [http://pcmanfm.sourceforge.net/ PCMan File Manager] <tt>(An extremly fast and lightweight file manager which features tabbed browsing and user-friendly interface. Requires GTK+ version 2.8.x)</tt>
* OpenMotif
** [http://www.musikwissenschaft.uni-mainz.de/~ag/xplore/xplore.php Xplore] <tt>(browser gui with productive 4 pane concept)</tt>
* QT 2
** [http://www.hi-net.cz/blaza/bfcommander/en/index.html BF-Commander] <tt>(two pane gui)</tt>
*Qt3
** [http://www.beesoft.org/download_bsc.html Beesoft Commander] <tt> (fast & easy two panel file manager, like Norton Commander)</tt>
* Tcl/Tk
** [http://users.tkk.fi/~mkivinie/X-Files/ X-Files] <tt>(two pane gui)</tt>
*X Toolkit
** [http://www.musikwissenschaft.uni-mainz.de/~ag/xfm/ X File Manager] <tt>(spacial gui)</tt>
** [http://www.boomerangsworld.de/worker/ Worker] <tt>(two pane gui, highly productive and configurable)</tt>
** [http://xnc.dubna.su/ X Northern Captain] <tt>(interesting flexible two pane gui)</tt>
*3D Filemanagers
** [http://www.determinate.net/webdata/seg/tdfsb.html TDFSB] <tt>(3D gui, the most impressing 3D file browser so far)</tt>
** [http://www.forchheimer.se/bfm/ Brutal File Manager] <tt>(3D gui more for fun than productivity)</tt>
** [http://turma.sourceforge.net/software/3dfile/ 3DFile] <tt>(3D gui)</tt>
** [http://orbis.sourceforge.net/ Orbis] <tt>(3D gui)</tt>

==Choosing applications==
===Web Browser===
This is highly dependent on the way you use your browser, it's often worth it to try out all and just track general
memory usage. Remember that <tt>top</tt> and <tt>ps</tt> don't report correct memory usage, track totals only.

====Firefox====
Firefox is graphical web browser. One can install features like AdBlock and FlashClicktoplay which will decrease memory and
processor usage by hiding Flash and Java -adverts.

====Opera====
Opera is graphical web browser. You can easily enable/disable plug-ins and java (press F12) and decrease memory usage.
Opera uses QT as toolkit, so you may shave off some Mbytes off memory usage by using dynamically linked version if you use KDE.

====Konqueror====
Konqueror is graphical web browser. It's integrated with KDE and has several advanced features (esp. ca. KDE 3.5).
You may save some megabytes by using it instead of other browsers when using KDE.
It's not necessarily heavy even when used without running KDE.

====Dillo====
Dillo is minimalistic and very small graphical web browser.

====Elinks/Lynx====
elinks/lynx are both text mode web browsers. <tt>elinks</tt> handles tables and formatting much nicer than <tt>lynx</tt>.
Both go very easy on memory footprint.

{{Todo|...}}

==Disabling unneeded system deamons==
Another thing you can do to improve performance is to get rid of unneaded system daemons launched from your init scripts. Disable them by using the according configuration interface of your distro or by deleting links in the according runlevel directories (usually in <code>/etc/rc.d/</code>).

Daemons you usually don't need:
* httpd <tt>(Apache web server)</tt>
* mysqld <tt>(MySQL database server)</tt>
* smbd <tt>(SMB windows filesharing server)</tt>
* pppd <tt>(PPP server for connections through modems and serial lines)</tt>

==Adjusting filesystems==
You can also try to optimize memory usage by making sure that you have as little as possible of your filesystem residing in RAM. To do this make sure that the following mount points are set to reside on your harddisk in {{path|/etc/fstab}}.
* /dev (not possible if you use udev)
* /tmp

Also make sure that you mount filesystems with extensive usage with noatime parameter (mount -o remount,ro /...), which disabled access time writes every time you access some file. Note that many incremental backups needs atime to work, such backups will then behave like full backup everytime. This depends on backup systems.

==Other tips==
===Disk space===
When using Debian/Ubuntu/other derivative, use <tt>aptitude</tt> as package manager, and use it as soon as possible. Use it and only it to install and remove packages.

One of its most useful features is that it tracks packages you install and marks packages installed via dependency as such, so when you remove a package that is no longer used, or package updates and doesn't use a library anymore, that dependency will get uninstalled.

You can mark packages installed as automatically installed by hitting 'M' (uppercase m), it will be marked for deinstallation if it's not longer required.

You could also install <tt>localepurge</tt> wich will remove all unneeded locales and localized manpages for packages you install.

===System clock===
<tt>ntpd</tt> can occupy around 4MB of memory, which is a substantial proportion of many older systems' total. [http://chrony.sunsite.dk/ <tt>chrony</tt>] is a pair of programs that replace the standard <tt>ntp</tt> and require much less memory.

Ipw3945

2007-03-08T22:39:07Z

Esmil: /* Some comments */ Fixed link

__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;">
=== Intel PRO/Wireless 3945ABG Mini-PCI Express Adapter ===
This is a Mini-PCI Express WiFi Adapter

=== Features ===
* Chipset: Intel WM3945AG
* IEEE Standards: 802.11a, 802.11b, 802.11g
* PCI ID: 8086:4227
</div>
|style="vertical-align:top" |
[[image:3945abg.jpg|Mini-PCI WiFi Adapter]]
|}
=== IBM Partnumbers ===
41A4068 (From [http://www.ibm.com/pc/support/site.wss/document.do?sitestyle=lenovo&lndocid=MIGR-62764 Wireless & networking accessories - ThinkPad T60/p])

{{NOTE| Only the IBM Parts will work, any other parts will give an 1802 error on Post because the sub-vendor PCI ID is different, see [[Problem with unauthorized MiniPCI network card]] for more details}}

=== Also known (in IBM literature) as.... ===
* From [http://www.ibm.com/common/ssi/rep_ca/8/897/ENUS106-068/ENUS106-068.PDF announcement letter 106-068], 'Intel PRO/Wireless 3945ABG8 wireless connection'

=== Hardware switch ===

Some ThinkPads have a hardware switch that must be in the '''on''' position for the radio to work, regardless of driver state:

[[Image:Wireless-switch.png|(ThinkPad R60 radio switch in the ON position)]]

=== Packages ===
*{{Fedora}}
** Packages: http://www.atrpms.net/dist/fc5/ipw3945
** Helpful Thread: http://www.linuxquestions.org/questions/showthread.php?t=436357
** ATrpms yum repo rpm: http://atrpms.net/dist/common/atrpms/atrpms-67-1.at.noarch.rpm.html
** '''NOTE:''' The T60p uses the smp kernel which the ipw3945 yum install does not provide. You will need the smp kernel for your architecture found at http://www.atrpms.net/dist/fc5/ipw3945. Remove the non-smp kernel and replace it with the appropriate smp kernel. Wireless works great for me... --[[User:Herlo|Herlo]] 18:06, 22 June 2006 (CEST)
*{{Mandriva}}
** Mandriva's kernel comes with the ipw3945 module (since at least 2006.0 Update One)
** dkms package (dkms-ipw3945) can be found in contrib (currenlty cooker only, thus will probably be in 2007.0)
** Additional Packages: ipw3945d and ipw3945-ucode, both either available in the commercial distribution (or club) or from http://plf.zarb.org/
*{{Gentoo}}
** The net-wireless/ipw3945 package contains everything you need
*{{Debian}}
** The ipw3945 microcode is available in the [http://packages.debian.org/testing/admin/firmware-ipw3945 firmware-ip3945] package (currently in testing and unstable (same versions)).
** The ipw3945 regulatory daemon is available in the [http://packages.debian.org/testing/net/ipw3945d ipw3945d] package (currently in testing and unstable (same versions)).
** The ipw3945 module source is available in the [http://packages.debian.org/testing/net/ipw3945-source ipw3945-source] package (currently in testing and unstable (same versions)).
** '''DEPRECIATED:''' Unofficial packages are available from [http://ace-host.stuart.id.au/russell/files/debian/sarge/ipw3945/ Russell Stuart], [http://kanotix.com/files/debian/pool/contrib/i/ Stefan Lippers-Hollmann], and [http://www.joachim-reichel.de/debian/sid/ Joachim Reichel].
* [[OpenBSD]]
** Supported with the [http://www.openbsd.org/cgi-bin/man.cgi?query=wpi wpi] driver in 4.0.
* [[Ubuntu]]
** Works out of the box in edgy. Requires ''restricted'' repository.

=== Linux WiFi driver ===
The most recent revision of the Intel Centrino platform utilizes a new generation of wireless networking device connected to the system via '''PCI-E''', and not PCI (like the [[ipw2200]]-line used to do). Therefore, a new driver must be used. A sourceforge-project supporting the new cards is available at [http://ipw3945.sourceforge.net/ http://ipw3945.sourceforge.net/]. However, as of today, the project's code ([http://downloadfinder.intel.com/scripts-df-external/detail_desc.aspx?ProductID=2259&DwnldID=10315&agr=Y Stable Release 1.2.0]) depends on a '''binary-only, proprietary''' user-space-daemon communicating with the driver via sysfs. It is '''not possible''' to operate this device with Free Software exclusively at the moment. The license-terms the daemon is released under prohibit reverse-engineering of the communication-protocol; this will hopefully not hold developers outside the US, where clauses like this one are not enforceable, from re-implementing a free variant of some sort.
==== External Discussion ====
This issue already sparked discussions on the [http://lkml.org/ Linux Kernel Mailing List], accessible via [http://lkml.org/lkml/2006/2/24/266 http://lkml.org/lkml/2006/2/24/266].

There is also a very revealing [http://kerneltrap.org/node/6650 interview] with the author of the OpenBSD driver for the 3945, in which it comes out that Intel has lied (at least by omission) about the purpose of the "regulatory daemon".

==== Current State ====
The [[ipw2200]]-drivers in kernel 2.6.15 (and possibly later) do '''not''' work with this adapter. There is '''no mainline-kernel support''' at the moment, and without a change in the license of the required user-space-daemon, or mechanics of the code itself, '''probably''' will never be any.

==== Some comments ====
ipw3945 works with [http://ipw3945.sourceforge.net/ http://ipw3945.sourceforge.net/] drivers.
A Spanish summary, but easy to understand about how to install:
[http://www.esdebian.org/forum/viewtopic.php?forum=18&showtopic=69543 esDebian Forum], maxim_o message (longer)

Thinkpad topic: on ThinkPads like the Z60 that have one. remember to put the wireless switch in the on state! But you will not be able to enable the Wireless LED with Fn+F5, it is not a problem.

One more comment: if you want monitor mode (e.g for use with Kismet or other network sniffers), you need to uncomment CONFIG_IPW3945_MONITOR=y line from ipw3945-1.1.0 Makefile.

=== ThinkPads this card may be found in ===
* {{T43}}, {{T43p}} as an external ExpressCard
* {{R60}}
* {{T60}}, {{T60p}}
* {{X60}}, {{X60s}}
* {{Z61e}}, {{Z61m}}, {{Z61t}}, {{Z61p}}
[[Category:Components]]

Ipw3945

2007-03-08T22:36:30Z

Esmil: /* Linux WiFi driver */ Stable release of ipw3945 is now 1.2.0

__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;">
=== Intel PRO/Wireless 3945ABG Mini-PCI Express Adapter ===
This is a Mini-PCI Express WiFi Adapter

=== Features ===
* Chipset: Intel WM3945AG
* IEEE Standards: 802.11a, 802.11b, 802.11g
* PCI ID: 8086:4227
</div>
|style="vertical-align:top" |
[[image:3945abg.jpg|Mini-PCI WiFi Adapter]]
|}
=== IBM Partnumbers ===
41A4068 (From [http://www.ibm.com/pc/support/site.wss/document.do?sitestyle=lenovo&lndocid=MIGR-62764 Wireless & networking accessories - ThinkPad T60/p])

{{NOTE| Only the IBM Parts will work, any other parts will give an 1802 error on Post because the sub-vendor PCI ID is different, see [[Problem with unauthorized MiniPCI network card]] for more details}}

=== Also known (in IBM literature) as.... ===
* From [http://www.ibm.com/common/ssi/rep_ca/8/897/ENUS106-068/ENUS106-068.PDF announcement letter 106-068], 'Intel PRO/Wireless 3945ABG8 wireless connection'

=== Hardware switch ===

Some ThinkPads have a hardware switch that must be in the '''on''' position for the radio to work, regardless of driver state:

[[Image:Wireless-switch.png|(ThinkPad R60 radio switch in the ON position)]]

=== Packages ===
*{{Fedora}}
** Packages: http://www.atrpms.net/dist/fc5/ipw3945
** Helpful Thread: http://www.linuxquestions.org/questions/showthread.php?t=436357
** ATrpms yum repo rpm: http://atrpms.net/dist/common/atrpms/atrpms-67-1.at.noarch.rpm.html
** '''NOTE:''' The T60p uses the smp kernel which the ipw3945 yum install does not provide. You will need the smp kernel for your architecture found at http://www.atrpms.net/dist/fc5/ipw3945. Remove the non-smp kernel and replace it with the appropriate smp kernel. Wireless works great for me... --[[User:Herlo|Herlo]] 18:06, 22 June 2006 (CEST)
*{{Mandriva}}
** Mandriva's kernel comes with the ipw3945 module (since at least 2006.0 Update One)
** dkms package (dkms-ipw3945) can be found in contrib (currenlty cooker only, thus will probably be in 2007.0)
** Additional Packages: ipw3945d and ipw3945-ucode, both either available in the commercial distribution (or club) or from http://plf.zarb.org/
*{{Gentoo}}
** The net-wireless/ipw3945 package contains everything you need
*{{Debian}}
** The ipw3945 microcode is available in the [http://packages.debian.org/testing/admin/firmware-ipw3945 firmware-ip3945] package (currently in testing and unstable (same versions)).
** The ipw3945 regulatory daemon is available in the [http://packages.debian.org/testing/net/ipw3945d ipw3945d] package (currently in testing and unstable (same versions)).
** The ipw3945 module source is available in the [http://packages.debian.org/testing/net/ipw3945-source ipw3945-source] package (currently in testing and unstable (same versions)).
** '''DEPRECIATED:''' Unofficial packages are available from [http://ace-host.stuart.id.au/russell/files/debian/sarge/ipw3945/ Russell Stuart], [http://kanotix.com/files/debian/pool/contrib/i/ Stefan Lippers-Hollmann], and [http://www.joachim-reichel.de/debian/sid/ Joachim Reichel].
* [[OpenBSD]]
** Supported with the [http://www.openbsd.org/cgi-bin/man.cgi?query=wpi wpi] driver in 4.0.
* [[Ubuntu]]
** Works out of the box in edgy. Requires ''restricted'' repository.

=== Linux WiFi driver ===
The most recent revision of the Intel Centrino platform utilizes a new generation of wireless networking device connected to the system via '''PCI-E''', and not PCI (like the [[ipw2200]]-line used to do). Therefore, a new driver must be used. A sourceforge-project supporting the new cards is available at [http://ipw3945.sourceforge.net/ http://ipw3945.sourceforge.net/]. However, as of today, the project's code ([http://downloadfinder.intel.com/scripts-df-external/detail_desc.aspx?ProductID=2259&DwnldID=10315&agr=Y Stable Release 1.2.0]) depends on a '''binary-only, proprietary''' user-space-daemon communicating with the driver via sysfs. It is '''not possible''' to operate this device with Free Software exclusively at the moment. The license-terms the daemon is released under prohibit reverse-engineering of the communication-protocol; this will hopefully not hold developers outside the US, where clauses like this one are not enforceable, from re-implementing a free variant of some sort.
==== External Discussion ====
This issue already sparked discussions on the [http://lkml.org/ Linux Kernel Mailing List], accessible via [http://lkml.org/lkml/2006/2/24/266 http://lkml.org/lkml/2006/2/24/266].

There is also a very revealing [http://kerneltrap.org/node/6650 interview] with the author of the OpenBSD driver for the 3945, in which it comes out that Intel has lied (at least by omission) about the purpose of the "regulatory daemon".

==== Current State ====
The [[ipw2200]]-drivers in kernel 2.6.15 (and possibly later) do '''not''' work with this adapter. There is '''no mainline-kernel support''' at the moment, and without a change in the license of the required user-space-daemon, or mechanics of the code itself, '''probably''' will never be any.

==== Some comments ====
ipw3945 works with [http://ipw3945.sourceforge.net/ http://ipw3945.sourceforge.net/] drivers.
A Spanish summary, but easy to understand about how to install:
[EsDebian-es Forum|http://www.esdebian.org/forum/viewtopic.php?forum=18&showtopic=69543], maxim_o message (longer)

Thinkpad topic: on ThinkPads like the Z60 that have one. remember to put the wireless switch in the on state! But you will not be able to enable the Wireless LED with Fn+F5, it is not a problem.

One more comment: if you want monitor mode (e.g for use with Kismet or other network sniffers), you need to uncomment CONFIG_IPW3945_MONITOR=y line from ipw3945-1.1.0 Makefile.

=== ThinkPads this card may be found in ===
* {{T43}}, {{T43p}} as an external ExpressCard
* {{R60}}
* {{T60}}, {{T60p}}
* {{X60}}, {{X60s}}
* {{Z61e}}, {{Z61m}}, {{Z61t}}, {{Z61p}}
[[Category:Components]]

Talk:Tp smapi

2007-03-08T18:22:36Z

Esmil: /* tp_smapi 0.30 with kernel 2.6.20? */ Made redundant by tp_smapi 0.31

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

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

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

Talk:Tp smapi

2007-03-07T00:06:32Z

Esmil: /* tp_smapi 0.30 with kernel 2.6.20? */ Fixed

Talk:Tp smapi

2007-03-06T19:08:42Z

Esmil: /* tp_smapi 0.30 with kernel 2.6.20? */ Problem is limited to 64bit kernels

Talk:Problems with fglrx

2007-02-10T20:23:06Z

Esmil: My adventures with fglrx

== using kernel AGP vs fglrx AGP ==

Anyone know whether this makes a performance and/or stability difference?

== 8.20.8 and later works with current Debian sid packages ==

<pre>
spiney@t43p:~$ dpkg -l xserver-xorg
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Installed/Config-files/Unpacked/Failed-config/Half-installed
|/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: uppercase=bad)
||/ Name Version Description
+++-============================-============================-==================
ii xserver-xorg 6.9.0.dfsg.1-2 the X.Org X server
spiney@t43p:~$ fglrxinfo
display: :0.0 screen: 0
OpenGL vendor string: ATI Technologies Inc.
OpenGL renderer string: MOBILITY FireGL V3200 Pentium 4 (SSE2) (FireGL) (GNU_ICD)
OpenGL version string: 1.3.5519 (X4.3.0-8.20.8)
</pre>

--[[User:Spiney|spiney]]
----

Ahh - thanks for the info. You perhaps compiled the modules for the drivers yourself and did not use the debian packaged fglrx-driver? Thus, it must be an unneeded limitation on the debian packaged driver which limits its installation... Full listing at http://packages.debian.org/unstable/x11/fglrx-driver which lists as required packages:

xserver-xorg (<< 6.8.99)
the X.Org X server
xserver-xorg (>= 6.8.0)

The first limitation (<<6.8.99) is what prevents installation. I'm sure I could force apt to install it, but I may go back to compiling the modules myself, as using fglrx 8.20.8 with kernel 2.6.15 needs a small patch to compile correctly anyway... --[[User:gsmenden|gsmenden]]

Spiney, where exactly do you have your package from? I re-build the 8.20.8-package from debian with the <<6.8.99 dependecy removed, but when I try to run X, I get
[R200Setup] X version mismatch - detected X.org 7.0.0.0, required X.org 6.8.0.0
(EE) Failed to load module "fglrx" (module requirement mismatch, 0)
Any hints? --[User:nomeata|nomeata]

I used the ati-installer (the huge download), created a Debian sid package and installed it, but got the same error. The installer seems to fetch the wrong driver version from the archive, so I extracted it with

{{cmd|./ati-driver-installer-8.20.8-i386.run --extract <sometempdir>|}}

and put the necessary files from the created {{path|<sometempdir>/x690}} subdirectory into {{path|/usr}} by hand. All IIRC, it's been some time since. :)

--[[User:Spiney|spiney]] 07:29, 11 Jan 2006 (CET)

Thanks for the pointer. This is how you get proper debian packages out of the ati-installer:
./ati-driver-installer-8.20.8-i386.run --extract fglrx-tmp
cd fglrx-tmp
$editor packages/Debian/ati-packager.sh # in the line "sid|unstable) X_DIR=x680;;", put a x690 for the x680
./fglrx-tmp/packages/Debian/ati-packager.sh --buildpkg sid
cd ..
sudo dpkg -i fglrx-kernel-src_8.20.8-1_i386.deb fglrx-driver_8.20.8-1_i386.deb
--[[User:Nomeata|Nomeata]] 00:35, 13 Jan 2006 (CET)

----

I had to do following steps :

$ ./ati-driver-installer-8.20.8-i386.run --extract fglrx-tmp
$ cd fglrx-tmp
$ ''editor'' packages/Debian/ati-packager.sh # in the line "sid|unstable) X_DIR=x680;;", put a x690 for the x680
$ ./packages/Debian/ati-packager.sh --buildpkg sid
$ cd /tmp
$ sudo dpkg -i fglrx-kernel-src_8.20.8-1_i386.deb fglrx-driver_8.20.8-1_i386.deb
--[[User:Fbianco|Fbianco]] 13:36, 26 February 2006 (CET)

----

Nice - confirmed works on my T43p running sid. From then on (or until 8.21.x comes out) you'll have to tell apt to hold back fglrx-driver package, or it will try to "update" fglrx-driver to 8.20.8-1.1 and therefore revert back to the problematic drivers.
--[[User:gsmenden|gsmenden]]
----

Thanks for the info, Nomeata, that's a lot cleaner a solution than my manual way.

--[[User:Spiney|spiney]] 08:32, 13 Jan 2006 (CET)
----

To get this working under 2.6.15 with x.org 6.9, you will also need to apply a small patch - there is a link on the main article page. After you install the fglrx-driver package with the 6.9 versioning hack above, go to
/usr/src/modules
and copy the patch here. Modify the first two lines of the patch file to take out the "build_mod" directory, e.g. first line should begin with
--- fglrx.orig/firegl_public.c
and call it with the -p0 strip option. It should patch the firegl_public.c file cleanly. You can then install as usual for your kernel (2.6.14.x or 2.6.15) using module-assistant.

Update - although X will come up in kernel 2.6.15 with the fglrx drivers patched as above, there is some strange behavior exhibited in all of X apllications - frequent hanging of applications when closing windows. Reverting back to the radeon driver in 2.6.15 solves these - so it is likely the ATI proprietary driver causing some problems.

Yet another update - fglrx 8.21.7 is out as of 1/19/2006, now supporting OpenGL 2.0, so eventually we will have beautiful complex shading / fog effects on Linux, too. It works well with X.Org 6.9 out of the box.

Unfortunately, this version gives the same problems when used (unpatched) with kernel 2.6.15 with strange lockups occasionally requiring reset of X. I have not tried this with the ~10 line patch listed on the main site, but that patch not work for me with 8.20.8. Anybody else have experience with 2.6.15 and fglrx?

Yay - new version out - 8.22.5 - works well with 2.6.15.x. Finally, running a plain-vanilla kernel on a T43p! (SATA+libata passthrough+SMART in mainline, 3d accel drivers up to date. Linux life is good.)

--[[User:gsmenden|gsmenden]] 12:39, 9 Feb 2006 (EST)
----

I don't know which patch you mean exactly (10 lines? the patch from lkml is just one line changed, no?), but I've been using 8.20.8 with 2.6.15 for quite some time (actually started with some -rc version IIRC), no lockups at all. No idea about 8.21.7 though, because I switched to 2.6.16-rc1 and can't compile the fglrx module at the moment, need to investigate the cause.

--[[User:Spiney|spiney]] 07:24, 21 January 2006 (CET)
----

Ok - strange. Yeah, the actual change is only one line, the rest is just commenting, etc. The lockups that I get are quite rare, but flightgear occasionally gives a hard lock. glxgears and fgl_glxgears work fine, netscape occasionally will hard-lock, and strangely enough issuing a shutdown command often makes the display blank and hard lock. I can't reproduce them too consistently, but these _never_ occur with the radeon driver / mesa or under 2.6.14.x.

Unfortunately vanilla 8.21.7 with kernel 2.6.15.1 (Xorg 6.9) gives the same X lockups.

--[[User:gsmenden|gsmenden]] 11:36, 21 Jan 2006 (EST)
----

I can't compile the 8.21.7 driver modules with 2.6.15.1 at all. They compile with 2.6.14.4 cleanly and 8.20.8 compile with 2.6.15.1.
What I don't understand though is, that when I let the ATI installer build debian packages, it does so without hassle, but the packages don't work.
(this is about 8.21.7 - 2.6.15.1) Also patching doesn't seem to help. It shouldn't of course.

--[[User:Rasto|Rasto]] 15:04, 23 Jan 2006 (CET)

I looked at the compile problems last night. I have no idea, how it is possible that it works for other people with 2.6.15, perhaps when you install
precompiled modules? I don't really understand how that ati-installer thing works. Anyway. This may solve the problems with 8.21.7 and 2.6.15-
it is just two minor line changes (+ the one line patch with little extra), but now it compiles. pm_register and similar were moved to linux/pm_legacy.h
in 2.6.15, so that's one problem. It also reports unknown symbol verify_area, but this should not pose a problem, as it is already obsolete and redundant.
If you feel, that the one line should be left as the separate patch, copy it somewhere else and change it. It's here [http://people.ksp.sk/~rasto/fglrx_with_2.6.15.patch], but I'll put it on the main page as well.

--[[User:Rasto|Rasto]] 18:29, 25 Jan 2006 (CET)

== Disabling the external VGA port? ==

Does anyone know how disable the VGA port ''completely'' even when a cable is attached? Fiddling around with the DesktopSetup and ForceMonitor options didn't do the trick for me, and the MonitorLayout option found in some documentation is no longer valid in the current fglrx driver.

--[[User:Spiney|spiney]] 19:42, 10 Jan 2006 (CET)
----

== Debian-specific script to switch fglrx<->radeon ==

Don't know where to put it exactly, but if someone's interested (and using Debian), I've put up a [http://linux.spiney.org/debian_gnu_linux_on_an_ibm_thinkpad_t43p_graphics_card_switching_fglrx_radeon script for easily switching graphics driver configurations]. Feedback appreciated (altho I haven't got any to the xscreensaver patch ;)), especially if someone could do something similar for other distributions (Gentoo being half-way there it seems) and incorporate it into the script.

--[[User:Spiney|spiney]] 15:25, 17 January 2006 (CET)
----

----
==Compile ATI driver???==
How can you compile a binary only distributed driver? If I'm not getting something wrong, please change the formulation of the just added info.
[[User:Wyrfel|Wyrfel]] 20:10, 25 January 2006 (CET)
----
[http://xoomer.virgilio.it/flavio.stanchina/debian/fglrx-installer.html#overview1]
"The driver as a whole is made of three main components: the driver proper, a replacement libGL and a kernel module. The driver and libGL are in the fglrx-driver package, the kernel module's source code is in the fglrx-kernel-src package."
--[[User:Dunno|Dunno]] 23:49, 13 February 2006 (CET)
----
Yepp, my fault, didn't think of the kernel part when i wrote that. [[User:Wyrfel|Wyrfel]] 02:50, 14 February 2006 (CET)
----

== On Kernel 2.6.16(_rc4-mm1) fglrx doesnÂ´t load anymore ==

Hi,

if i emerge ati-drivers 8.22.5 and try to modprobe it on Kernel 2.6.16_rc4-mm1 i get the following console output:
<pre>
FATAL: Error inserting fglrx (/lib/modules/2.6.16-rc4-mm1/video/fglrx.ko): Unknown symbol in module, or unknown parameter (see dmesg)
</pre>
my dmesg Output reads:
<pre>
fglrx: Unknown symbol inter_module_unregister
fglrx: Unknown symbol inter_module_get_request
fglrx: Unknown symbol inter_module_put
fglrx: Unknown symbol inter_module_register
</pre>
from the ati-driver wiki i know that the driver runs on 2.6.16 up to rc3. But on the mm Series it doesnt run since 2.6.15.4-mm4.

Help would be appreciated...

Thanks and Greets

Oli

----
Have a look at the (currently) last entry on http://www.rage3d.com/board/showthread.php?t=33847019, which explains how to revive the old inter_module routines. HTH

--[[User:Nephilim|Nephilim]] 19:41, 22 March 2006 (CET)

Link to the specific post: http://www.rage3d.com/board/showthread.php?p=1334242855#post1334242855
--[[User:Thinker|Thinker]] 20:00, 22 March 2006 (CET)
----
I have a t43p / Debian Sid running 2.6.16 debian kernel compile the debian way. And the fglrx modules compiled.
There are two problems that I can not seem to fix...
o If I log out of kde to kdm/ or the login, everything goes black, even Alt+Ctrl+F1 does not work.<br> It is not locked up as Ctrl+Alt+Del does a proper restart.
o The other problem is on the second monitor the screen boundary is not right. <br> Putting the mouse to the bottom cause a vertical blur. <br> As long as the mouse is not at the bottom of the second screen all is well.

--[[User:Lters|Lters]] 14:35, 7 April 2006 (CEST)

Did you tell KDM to restart the X server when logging out? It is described in a link on the main article page under "Hang when logging out." I don't have two monitors so I'm not sure about your other problem...
--[[User:gsmenden|gsmenden]] 20:55, 9 April 2006 (EST)

== Suspend2 and fglrx ==

There seems to be a nice trick that allows the laptop to hibernate properly when set.
One should set this setting into the hibernate.conf file:

ProcSetting extra_pages_allowance 5000

Source: http://wiki.cchtml.com/index.php/Suspend2

--[[User:Assen|Assen]] 22:04, 3 May 2006 (CEST)

==Emacs with GUI affected==
I installed fglrx 8.20.8 on SuSE 10.0 with kernel 2.6.13 on T43 and fglrx 8.24.8 on Ubuntu 5.10 with kernel 2.6.12 on T40. On both systems, emacs works well with "-nw" option. However, in the first system, emacs doesn't respond to any key stroke when started with GUI interface, but it works well with "emacs -font fixed". In the second system, Emacs displays all characters as empty rectangles and responds to all key strokes althouth they are illegible. If I use the xorg.conf before fglrx was installed, then emacs works perfectly. I doubt that the problem is caused by the font. But it stays there even if I use the same fontpaths under section "Files".

Does anyone else have this problem? I haven't found any other X applications affected by the use of the driver.
--[[User:Bitcalc|Bitcalc]] 04:02, 30 May 2006 (CEST)

==atieventsd==
With driver version 8.25.16, I noticed a blinking of the HDD-LED every second. When viewing {{path|/var/log/messages}}, it revealed that each second, there was a message

atieventsd[3331]: Unable to bind control socket to /var/run/atieventsd.socket: Address already in use.

Anybody else with this problem? What is this atieventsd for anyways? When I kill it, the led stops blinking the there are no more messages...

--[[User:Hypnotoad|Hypnotoad]] 19:07, 21 June 2006 (CEST)

Nevermind, problem solved with the newest driver version. It was obviously a quite common bug...
--[[User:Hypnotoad|Hypnotoad]] 21:25, 29 June 2006 (CEST)

==PreInitDAL failed==
On my T60 with a Radeon X1400 card and fglrx 8.33.6 installed I was getting this error when trying to launch the X server for a long time.
<pre>
(EE) fglrx(0): PreInitDAL failed
(EE) fglrx(0): PreInit failed
...
(EE) Screen(s) found, but none have a usable configuration.
</pre>
Other places on the net told me that this could happen when you run your console in framebuffer mode, but apparently just switching the console mode to anything else than the standard will do this to you. So don't pass the vga=... parameter to the kernel if you see this error.

When I finally made X run, I was getting this error
<pre>
(EE) AIGLX error: dlsym for __driCreateNewScreen_20050727 failed (/usr/lib/xorg/modules/dri/fglrx_dri.so: undefined symbol: __driCreateNewScreen_20050727)
(EE) AIGLX: reverting to software rendering
</pre>
and the information [http://wiki.archlinux.org/index.php/ATI_Radeon_&_Kernel_2.6#Errors_about_AIGLX_in_.2Fvar.2Flog.2FXorg.0.log here] proved useful.
Perhaps some of this information should go to the problems page, just to prevent others having the same trouble as me ;) --[[User:Esmil|Esmil]] 21:23, 10 February 2007 (CET)

ATI Mobility Radeon X1400

2007-01-05T15:17:52Z

Esmil: /* ATI Mobility Radeon X1400 */

__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;">
=== ATI Mobility Radeon X1400 ===
This is an ATI video adapter.

=== Features ===
* Chipset: ATI M54
* PCI ID: 1002:7145
* PCI Express x16
* 128MB GDDR1 video memory
</div>
|style="vertical-align:top" |
|}

=== Linux X.Org driver ===
Not Supported

==== ThinkPad LCD ====
Display on the internal LCD works as long as you set the monitor settings correct.

==== External VGA port ====
??

==== SVideo port ====
??

==== DVI port ====
??

=== Proprietary ATI driver ===
Proprietary [[fglrx]] driver version 8.24.8 adds support for the x1400 chipset (according to ATI changelog). It works, including dualhead, 3d and video (XV) acceleration, when using the fglrx kernel module. (Without it, you get screen corruption including underlined mouse pointers.)

Sample "Device" section for xorg.conf:

Section "Device"
Identifier "ATI Graphics Adapter 0"
Driver "fglrx"
Option "ForceMonitors" "lvds,crt1"
Option "Centermode" "off"
Option "VideoOverlay" "on"
Option "OpenGLOverlay" "off"
Option "OverlayOnCRTC2" "0"
Option "PseudoColorVisuals" "off"
Option "HSync2" "31-64"
Option "VRefresh2" "56-75"
Option "UseFastTLS" "off"
Option "Mode2" "1280x1024,1024x768,800x600,640x480"
BusID "PCI:1:0:0"
EndSection

The kernel module doesn't work out of the box with the 2.6.16 kernel, you get undefined symbols such as module_get_request when inserting the module. The following patch to firegl_public.c fixes it (from http://www.stanchina.net/~flavio/debian/fglrx-archive/msg01158.html ):

--- firegl_public.c-orig 2006-02-23 14:54:16.386740016 -0600
+++ firegl_public.c 2006-02-23 14:56:38.054203288 -0600
@@ -361,13 +361,15 @@
} firegl_drm_stub_info_t;
static firegl_drm_stub_info_t firegl_stub_info;

-#if LINUX_VERSION_CODE < 0x020400
+#if LINUX_VERSION_CODE > 0x02060F
struct firegl_drm_stub_info_t *firegl_stub_pointer = NULL;
#define inter_module_put(x)
#define inter_module_unregister(x)
#define inter_module_get_request(x,y) firegl_stub_pointer
#define inter_module_register(x,y,z) do { firegl_stub_pointer = z; } while (0)
+#endif
/* This is a kludge for backward compatibility that is only useful in DRM(stub_open) */
+#if LINUX_VERSION_CODE < 0x020400
#define fops_put(fops) MOD_DEC_USE_COUNT
#define fops_get(fops) (fops); MOD_INC_USE_COUNT
#endif // LINUX_VERSION_CODE < 0x020400

XVideo support using the VideoOverlay option may not work with recent drivers. With version 8.29.6 of the fglrx driver, you can instead use

Option "TexturedVideo" "on"

Use the '''xvinfo''' utility to verify if XVideo support is available.

=== Linux kernel Framebuffer driver ===
Works with the VESA driver at 1280x1024 (you have to append {{bootparm|vga|794}} to the kernel boot parameters)

=== ThinkPads this chip may be found in ===
* {{T60}}
* {{Z61m}}

[[Category:Components]]