Keyboard - how?

[Maksim Yevmenkin]

On Wed, Dec 30, 2009 at 2:39 AM, Iain Hibbert <plunky at rya-online.net> wrote:
> 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?

sure, let me dig those out first :)

> 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.

ok, i guess, i can see the value of having dynamic pin/key
configuration, i.e. replace static /etc/bluetooht/hcsecd.conf with one
built dynamically based on client's request. i could even see how
generated link keys are stored in user's home directory together with
user's pins etc. having said all that, i do not see why executing
external pin program from hcsecd(8) is a bad idea. bluetooth is
essentially single user. there is no good way, imo, to basically share
multiple devices between multiple users on the same computer. what you
have in netbsd is a little bit more flexible, but, i bet, in 99.9%
cases it probably ends up the same way, i.e. only one user, uses only
only handful or remote devices connected to the same local device (or
computer).

>> 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.

it probably never goes to sleep :) freebsd will try to become 'master'
on link, and, we are not actively enforce any link policy, so, i'm
guessing link is always running with the default policy. 'sniff' mode
definitely helps to reduce power consumption, and, i'm guessing,
progressively (in|de)creasing 'sniff' interval based on keyboard's
(in)activity is the right thing to do.

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

yep, usually device has some sort of hid report. i think, but not 100%
sure, there also might be something that comes over hid control
channel. need to re-check the specs again.

> 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.

oh, neat-o! i did not know about this! i will try this today. thanks!

thanks
max