Die besten Informationen über UltraPort gibt erst einmal Wikipedia: en.wikipedia.org/wiki/IBM_UltraPort .
Danach gibt es Adapter, um normale USB-Geräte an den UltraPort anschließen zu können. Ein solcher Adapter war jedoch auf der IBM-Homepage nicht zu finden.

Der UltraPort connector ist eine proprietäre IBM-Schnittstelle auf dem oberen Display-Rand bei ThinkPads der Serien T, A (teilweise) und X ( www-307.ibm.com/pc/support/site.wss/document.do?lndocid=MIGR-4UKRG4 ). Aus en.wikipedia.org/wiki/Universal_serial_bus : »The USB 1.0, 1.1 and 2.0 specifications define two types of connectors for the attachment of devices to the bus: A, and B. However, the mechanical layer has changed in some examples. For example, the IBM UltraPort is a proprietary USB connector located on the top of IBM’s notebook LCDs. It uses a different mechanical connector while preserving the USB signaling and protocol.«

Allen UltraPort-Produkten liegt ein einfach aufgebauter USB-Adapter bei und der Linux-Treiber für die »IBM Ultraport Camera« wurde von einem USB-Treiber aus entwickelt ( www.gutwin.org/cam/source/ ). Es sollte also möglich sein, einen einfachen Adapter zu bauen um beliebige USB-Geräte an den UltraPort anzuschließen.

Für den UltraPort gibt es (mindestens): CompactFlash Card Reader (so gesehen bei eBay), Bluetooth-Adapter
( www-307.ibm.com/pc/support/site.wss/document.do?lndocid=MIGR-4UKRG4 ), »IBM ULTRAPORT DIGITAL ARRAY MICROPHONE« (IBM Part Number 09N4178) und Webcams (beste Beschreibung unter vowe.net/whatiuse/archives/002323.php ). Zur »IBM UltraPort Camera II« Dokumente auf der IBM-Homepage: www.ibm.com/search?en=utf&v=14&lang=en&cc=us&lv=c&q=04P6135&x=0&y=0 .

Die »IBM UltraPort Camera II« (IBM Part Number 04P6135) kostet in Deutschland neu um 90 EUR, als Vorführgerät hier 79 EUR: www.helex-computerhandel.de/50098594e00f8ea03/50098594e00fa1313/50098594e114d4702.html . Und hier gebraucht 60 EUR: www.ordikaz.com/ordikaz/detail/192357.htm?format=1 . Bei eBay Kanada kostet sie 36 USD als Sofortkauf-Artikel. Die »IBM UltraPort Camera II« kann problemlos auch an den USB-Port (Version 1.1) angeschlossen werden, Adapter und Kabel liegen der Kamera bei ( www.hardware-corner.net/ibm/ibm_ultraport_camera_ii_webcam/ ). Die Kamera besitzt experimentellen Support für Linux, www.gutwin.org/cam/source/ informiert über den aktuellen Stand und stellt ein entsprechendes Kernel Patch zur Verfügung.

Genauere Installationen zum Installieren dieses Treibers unter Linux gibt www.karachinsky.com/roman/linux/a31p.html#10 und aoki.webmasters.gr.jp/diary/?200201a&to=200201091#200201010 .

Es ist bisher nicht möglich, die »IBM UltraPort Camera II« mit GnomeMeeting für Videoconferencing zu verwenden ( mail.gnome.org/archives/gnomemeeting-list/2002-July/msg00000.html ). Möglicherweise funktioniert das jedoch mit anderen Videoconferencing-Anwendungen für Linux.

Das passiert bei Verwendung des Pakets »tpb« (seit einer bestimmten Version), nicht aber bei Verwendung des Pakets »hotkey-setup«. Es zeigt dass es möglich ist, beide Lautstärken unabhängig voneinander zu regeln und stimmzuschalten, was z.B. Sinn macht wenn an der Docking-Station Lautsprecher und am Notebook Kopfhörer angeschlossen sind.

Der eingesteckte USB-Stick (hier: SanDisk Ultra II Plus USB) erscheint in der Liste der bootbaren Geräte im BIOS nicht unter »Removable Devices« (wie andere USB-Geräte) sondern als weiterer Eintrag unter »Harddisks« (wohl weil ein
»Massenspeicher«-Gerät; dieser Punkt »Harddisks« kann aufgeklappt werden). Diesen Eintrag bringt man mit F5/F6 nach oben so dass er in der Bootreihenfolge über der internen Festplatte steht, und startet neu. Das funktioniert. Diese Änderung der Bootreihenfolge mehrerer installierter Festplatten muss im BIOS gemacht werden und ist nicht über die F12-Bootoption möglich.

Das Audiosignal für den »PC-Speaker« wird nur über die internen Lautsprecher des Notebooks gespielt und
über Lautsprecher die am 3,5mm-Klinke-Ausgang des Notebooks angeschlossen sind, jedoch nicht über Lautsprecher die am 3,5mm-Klinke-Ausgang am Portreplikator angeschlossen sind.

Symptom: »gammu –identify« meldet »Keine Rückmeldung. Telefon möglicherweise nicht angeschlossen?«. Das tritt auf unabhängig davon ob irda0 in der Ausgabe von ifconfig erscheint.

In der Ausgabe von »dpkg-reconfigure irda-utils« wird erwähnt: »Wenn FIR benutzt werden soll, müssen auch die entsprechenden Treibermodule gebaut werden. Die hier angebotenen Module können sich von den im laufenden Kernel verfügbaren Modulen unterscheiden. In diesem Fall müssen /etc/modutils/irda-utils (2.4) oder /etc/modprobe.d/irda-utils (2.6) von Hand bearbeitet werden.«

In /etc/modprobe.d/irda-utils steht nach der (korrekten, ehemals funktionierenden) Konfiguration des Pakets irda-utils:

irda0 erscheint nur in der Ausgabe von ifconfig wenn die irda-utils (genauer: der Service irattach) laufen, also wenn »/etc/init.d/irda-utils restart« ausgeführt wurde. irattach verbraucht dabei nach dem Starten die gesamte Rechenzeit, was jedoch interessanterweise durch ein »gammu –identify« behoben wird, selbst wenn überhaupt kein Mobiltelefon über IrDA angeschlossen ist. Lässt man die Optionen »io=0×2f8 irq=3 dma=3« aus so ist die »Störung« nur kurz und behebt sich selbst.

Möglicher Fehler: »/etc/init.d/irda-setup start« führt zur Fehlermeldung
»/etc/init.d/irda-setup: line 76: echo: write error: Device or resource busy
/etc/init.d/irda-setup: line 77: echo: write error: Device or resource busy«
Das betrifft jedoch nur ein (eventuell nicht erforderliches) Schreiben auf das BIOS-Device o.ä..

Führt man irdadump aus während »/etc/init.d/irda-utils restart« so erkennt man dass die IrDA-Schnittstelle tatsächlich Pakete sendet. Die Ausgabe enthält etwas wie:

oder

Die Konfiguration funktioniert wenn man ausführt:

Siehe die Beispiele in »man irattach«.
Das erzeugt ein Netzwerk-Gerät irda0, sichtbar in der Ausgabe von ifconfig.

Es funktioniert auch wenn man »irattach irda0 -s« oder »irattach irda0« ausführt und /etc/modprobe.d/irda-utils den korrekten Inhalt hat. Das ist also die korrekte Art den Daemon irattach zu starten. Nichts anderes müsste also in
/etc/init.d/irda-utils geschehen. Dort wird ausgeführt:

Das ist korrekt und funktioniert nun auch (warum aber nicht auch vorher?). Auch »/etc/init.d/irda-setup start« funktioniert. Ein Symptom des Fehlers scheint zu sein wenn »/etc/init.d/irda-utils restart« alle Rechenzeit aufbraucht – das trat nun nämlich nicht mehr auf und auch nicht beim manuellen Ausführen von irattach.

Eventuell hat ein »irattach /dev/ttyS0« (zum Betreiben der IR-Schnittstelle im SIR-Modus) das Problem behoben. Wohl dadurch entstand dauerhaft ein irda1-Netzwerkgerät.

Das Problem liegt nicht an Suspend-to-RAM denn irda0 funktioniert danach weiter wenn es davor funktionierte.

• Man installiere die Pakete linux-image-2.6.17-*-686, irda-utils, iproute; den Kernel 2.6.17 gibt es noch von snapshot.debian.net/archive/2006/09/14/debian/pool/main/l/linux-2.6/linux-image-2.6.17-2-686_2.6.17-8_i386.deb .
• vorgehen nach lists.ubuntu.com/archives/ubuntu-users/2006-February/067007.html
• wenn udev aktiviert ist werden die Devices nicht in /dev erzeugt sondern in /dev/.static/dev; korrekt ist also etwas wie: ls -x1 /dev/.static/dev/ir* /dev/.static/dev/ircomm0 /dev/.static/dev/ircomm1 /dev/.static/dev/irlpt0 /dev/.static/dev/irlpt1 /dev/.static/dev/irnet
• In »dpkg-reconfigure irda-utils« Discover-Modus einschalten, dann sollte »irdadump« entspr. regelmäßig versandte Identifikationspakete auflisten.
• gute Anleitung auch auf thinkwiki.org/ ; www.mobilforum.de/forum/showthread.php?p=155098
• Verwendung: nach jedem Suspend/Resume-Zyklus »/etc/init.d/irda-utils restart« notwendig.

»sudo /etc/init.d/console-setup restart« auf der Konsole ausführen, oder ein einfaches
»/etc/init.d/console-setup restart«, wodurch jedoch das Speichern der Keymap nicht funktioniert. Evtl. kann man diese Befehle auch über /etc/apm/scripts.d/ automatisieren.

Der Fehler liegt tatsächlich an Suspend mit ACPI, denn USB funktioniert nach einem Neustart stets einwandfrei. Um solche Probleme zu beheben wird vorgeschlagen in www.thinkwiki.org/wiki/How_to_configure_acpid : vor Suspend-to-RAM führe man aus »rmmod uhci_hcd«, danach »modprobe uhci_hcd«. »rmmod uhci_hcd« wirkt zwar tatsächlich so dass z.B. eine USB-Maus nicht mehr funktioniert, dieses Verfahren beugt aber nicht dem Fehler stromloser USB-Anschlüsse nach Resume vor und kann diesen Fehler auch nicht beheben nachdem er einmal aufgetreten ist.

Der Fehler könnte evtl. behoben werden indem man Hotplugging neu startet. »/etc/init.d/hotplug restart« ist in Ubuntu Feisty jedoch nicht mehr der Weg dazu. Das liegt an der Umstellung von hotplug auf udev. Aber ein »/etc/init.d/udev restart« bringt keine USB-Geräte zum Funktionieren obwohl es jetzt der Weg ist, Hotplugging neu zu starten, auch für USB ( ubuntuforums.org/showthread.php?t=404801&highlight=USB ). Es liegt also nicht an fehlerhafter Erkennung sondern wohl einfach daran dass den USB-Ports der Strom fehlt während alles andere normal ist.

usbmodules, lsusb, lspci -vvnn, dmesg helfen nicht (alle Meldungen scheinen normal, USB-Hubs werden erkannt trotz dass USB-Ports ohne Strom sind). lsusb listet nur die Hubs, nicht aber die Geräte wie es der Fall sein sollte. Links zu Bugs die keine Duplikate dieses Bugs sind:

bugs.launchpad.net/ubuntu/+bug/99267

bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-savage/+bug/37328

Lösung derzeit: APM verwenden, d.h. die Kerneloptionen »noacpi acpi=off apm=on«. Damit kann USB auch nach einem Suspend-to-RAM/Resume-Zyklus verwendet werden. Notwendig sind aber: »rmmod uhci_hcd; modprobe uhci_hcd« nach Resume, sonst reagiert die Maus nicht sehr zögerlich; Auswerfen einer PCMCIA-Netzwerkkarte vor Suspend-to-RAM, sonst geht das System nur in einen Standby-Zustand; Korrektur des Sounds.

Das Problem besteht bei Kernel 2.6.22 nicht mehr.

Interessanterweise funktionieren ACPI-Funktionen nur wenn X vollständig gestartet ist (nur KDM ohne Login oder ein Terminal helfen nicht).

Fehler: das Notebook geht normal in Suspend, wacht aber nach einer Sekunde von selbst auf und verbleibt in einem unansprechbaren Zustand (Standy-LED blinkt, Bildschirm schwarz; Koma?). Der hier beschriebene Fehler liegt nicht an einer veralteten BIOS-Version (denn er tritt auch mit BIOS 1.20 und Embedded Controller 1.06a auf).

Der Fehler liegt nicht daran dass eine eingesteckte WLAN-Karte per ifup konfiguriert ist.

Der Fehler liegt auch nicht an Problemen mit USB-Modulen: USB funktioniert nach jedem Neustart problemlos, und ein Suspend/Resume-Zyklus von diesem Zustand aus funktioniert ohne den beschriebenen Absturz (USB ist danach ohne weiteres noch nicht verwendbar, aber das ist ein anderes Problem).

Der Fehler tritt entweder beim ersten Suspend/Resume-Zyklus nach einem Neustart auf (was einen weiteren Neustart nötig macht) oder über beliebig viele Resume-Zyklen überhaupt nicht.

Weitere Hilfen:

www.google.de/search?hl=en&q=site%3Alinux-thinkpad.org+T23+acpi+suspend&btnG=Google+Search

Manchmal ist das über Fn+F3 korrigierbar, aber immer über Fn+F7 (Umschalten zwischen internem und externem Monitor). Workaround: stets Paralleldarstellung auf internem und externem Monitor verwenden (so lange Fn+F7 drücken bis der interne Bildschirm schwarz wird, danach noch zweimal). Dann tritt der Fehler bei Resume nie auf.

Siehe auch: www.thinkwiki.org/wiki/Problem_with_display_remaining_black_after_resume