jmtd → computing → hardware → x40 → dock

Docks, aka docking stations, media slices, and port replicators, are devices which you can plug a laptop into and which expose extra ports. Read more about them here: http://en.wikipedia.org/wiki/Docking_station

Introduced in Linux 2.6.18 was CONFIG_ACPI_DOCK and CONFIG_ACPI_BAY at some other point. This is generic dock support infrastructure. Prior to this, thinkpad docking was handled by the separate thinkpad module.

If you have a dock, the acpi_dock module gives you a device such as /sys/devices/platform/dock.0. Inside the sysfs tree for this device are things such as undock:

echo 1 > /sys/devices/platform/dock.0/undock

...undocks your machine.

how many dock devices could we concievably have? Under what circumstances might we end up with dock.X where X != 0, or more than one dock device simulataneously, and how do we handle that?

Userspace code is needed to glue physical buttons / other actions that you might want to trigger docking/undocking with the action, and handle removing devices that are plugged into the dock (or bay inside the dock).

On the X40, you need to unmask the undock button. acpi-support versions >= 109-3 carries /etc/modprobe.d/ibm_acpi.modprobe which contains

options ibm_acpi hotkey=enable,0xff9f experimental=1

which I think unmasks the right key. (need to confirm: my mask after booting is 0x00fb89dc so something else might have prodded it too).

If you configure acpid to listen for the right event and prod the undock device above, pressing the button removes the USB devices, and then you can remove the dock, which promptly disconnects the display and ethernet.

the display is now internal only. geometry hasn't changed (so can only see top 1024x768 of virtual size 1280x1024). Some xrandr hook needed here?

Redocking and everything comes back.

This is all with 2.6.25-2-686.

undocking and bays

attempting undock with a mounted bay - bad

attempting detach bay with a mounted drive - bad

If the bay is present and it has been mounted at any time, you're SOL if you try to remove it, or try to undock.

Of interest perhaps is this commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=7efd52a407bed6a2b02015b8ebbff7beba155392

which includes the following comment

If acpi_install_notify_handler() for a bay device fails, the bay driver is superfluous. Most likely, another driver (like libata) is already caring about this device anyway. Furthermore, register_hotplug_dock_device(acpi_handle) from the dock driver must not be called twice with the same handler. This would result in an endless loop consuming 100% of CPU. So clean up and exit.

If I build bay.ko from this commit I get the following on insmod:

[ 2825.932731] ACPI Exception (evxface-0544): AE_BAD_PARAMETER, Removing notify handler [20070126]
[ 2835.821255] ACPI: \_SB_.PCI0.IDE0.SCND.MSTR: found ejectable bay
[ 2835.821266] ACPI: \_SB_.PCI0.IDE0.SCND.MSTR: Adding notify handler
[ 2835.821312] ACPI: Error installing bay notify handler

So... could another module be holding this? How to find out? What could it be? thinkpad-acpi? Hang on, there's a /dev/hdc present, hm.

There's some documents at http://www.thinkwiki.org/wiki/How_to_hotswap_UltraBay_devices about this, they look very suspect.

fixed in 2.6.26?

Apparently. Potential commits:

It seems that libata handles undocking properly but older ATA drivers do not. So what behaviour you get depends a lot on which driver binds first.

dock-specific ports

If I boot the X40 with the dock in place, I get a /dev/ttyS0, but if I hot-plug the dock, I don't.