A diversion in Linux Bluetooth and Apple wireless keyboards

Okay. I type this on my dull new Apple Wireless Keyboard [Amazon.com] inside Xorg [X.org] with HAL [Wikipedia.org] and evdev. I kid you not. I am going to run down the list of things that got my combination of hardware working. I have poured over just about everything written on Bluetooth setup and configuration in Gentoo Linux. I feel fairly comfortable in offering up advice on getting things going from scratch.

I run all of these commands as a normal user unless specified by a leading # (hash) or if the command somehow fails with a "Cannot create..." error. In that case sudo kung fu it.

Alright. My USB adapter is a Targus ACB10US. Here is the output of lsmod:

[egon@sixtyfour ~ ]$ lsmod
Module Size Used by
ipv6 264208 8
hid_apple 7192 0
hidp 15848 1
sco 10748 2
rfcomm 36408 5
bnep 13608 2
l2cap 20552 21 hidp,rfcomm,bnep
nvidia 8112312 36
btusb 12716 11
fan 3976 0
button 7224 0


I would have hcidump -X running at all times so you can see what is actually happening behind the scenes. lshal will be useful later, but that is a whole 'nother can of worms.

Next up is hciconfig. You're going to have to run this as root.

Bluetooth adapter settings

[egon@sixtyfour ~ ]$ sudo hciconfig -a
hci0: Type: USB
BD Address: 00:0A:3A:88:BB:24 ACL MTU: 1021:8 SCO MTU: 64:1
UP RUNNING ISCAN
RX bytes:79789 acl:3485 sco:0 events:799 errors:0
TX bytes:12553 acl:261 sco:0 commands:357 errors:0
Features: 0xff 0xff 0x8f 0xfe 0x9b 0xff 0x79 0x83
Packet type: DM1 DM3 DM5 DH1 DH3 DH5 HV1 HV2 HV3
Link policy: RSWITCH HOLD SNIFF PARK
Link mode: SLAVE ACCEPT
Name: 'sixtyfour-0'
Class: 0x4a0104
Service Classes: Networking, Capturing, Telephony
Device Class: Computer, Desktop workstation
HCI Ver: 2.1 (0x4) HCI Rev: 0x50fa LMP Ver: 2.1 (0x4) LMP Subver: 0x420e
Manufacturer: Broadcom Corporation (15)


The key settings here are ISCAN and SLAVE ACCEPT (I think). To set these:

# hciconfig hci0 reset
# hciconfig hci0 up
# hciconfig hci0 lm slave,accept


-----------------------------------------------------------------------------------

I've found that as long as you are receiving data packets from hcidump -X that look like the example below, you should be connected. I just ran into a problem with my keyboard being now recognized as "Apple Inc. Keyboard" instead of "Apple Wireless Keyboard". Not sure why this happened, but it killed my hal rules.

Connected packet example

> ACL data: handle 11 flags 0x02 dlen 14
L2CAP(d): cid 0x0041 len 10 [psm 0]
0000: a1 01 00 00 00 00 00 00 00 00 ..........


Right now I am in a tangle with dbus and making sure the keyboard wakes up after an idle period. I'm stuck on the first step with dbus.exceptions.DBusException: org.freedesktop.DBus.Error.UnknownMethod: Method "ActivateService" with signature "s" on interface "org.bluez.Manager" doesn't exist

to be continued...