Keyboard - how?

[Iain Hibbert]

On Tue, 29 Dec 2009, M. Warner Losh wrote:
> : yep, the whole thing is "ugly" because pairing basically requires some
> : form of (graphical) user interface. its an interactive process. i have
> : a patch somewhere that teaches hcsecd(8) how to execute external
> : program and pass requester and pin info back and forth. with this, one
> : can use something like xdialog and get prompted when pairing is
> : happening.
>
> Exactly...  That would be cool.  Wanna pass them over to me?

If you are working on something, please look at the NetBSD implementation
as I think having a system daemon execute an external program to request
input from the user is wrong.  What I did is to have the daemon[1] open a
socket and accept client connections. When it sees a PIN request it offers
it out to the clients to see if any of them can provide a PIN. When users
log in, they can run a PIN application[2] that registers on the socket and
will put up a requester when required. Alternatively, I can use the base
application[3] to set a PIN before trying to pair.

[1] http://cvsweb.netbsd.org/bsdweb.cgi/src/usr.sbin/bthcid
[2] http://homepages.rya-online.net/plunky/btpin-qt-1.4.tar.gz
[3] http://cvsweb.netbsd.org/bsdweb.cgi/src/usr.bin/btpin

As said, I don't think its ideal (and Qt4 takes way too long to build!)
but it does work ok for my purposes.

> BTW, after the big hammers, the newer apple keyboard and mouse (2008)
> are working just fine[*] with my FreeBSD box and it they seem to wake
> up better than OS X does (or maybe they just never go to sleep).

I'm not sure if having things like 'Sniff', 'Park' and 'Hold' modes
enabled will make a difference to this. Certainly enabling sniff mode
keeps the batteries going for longer (many weeks vs some days) but I think
hold and park require active OS support to be effective.

> Is there some way to find out what the battery level in these devices
> is?

I investigated this somewhat. The HID descriptor (of the Mighty Mouse, not
my older keyboard or mouse) shows a feature report:

  Feature id=71
   size=8
   count=1
   page=Device_Controls
   usage=Battery_Strength
   Variable NoPref Volatile
   logical range 0..100

and I think this means that the host can poll the device by sending the
feature report and getting a return value with battery strength.  I never
tried it though.. (the keyboard descriptor you posted earlier also shows
this, except the logical range is 0..255)

Also, my mouse (and keyboard) both send an undocumented input report with
id#42 containing a single byte (0x01 or 0x02) just before the batteries
finally shut down. No idea what this should be interpreted as, but I use
NiMH batteries and the voltage remains constant until they run out of
power, so perhaps the 'strength' would not be a very useful value anyway.

If you have OSX there is a way to capture bluetooth packets and you could
investigate more there. I think something like hold down 'option' key
while opening the bluetooth menu and you should see it listed. Not sure if
it shows a live stream but hcidump can interpret the packet capture files.

regards,
iain