Re: Keyboard - how?
Milan Obuch
> OK. I must be pathologically dense...
>
> I've tried to get my apple mini keyboard working with my machine. I'm
> so close. I'm getting the following messages on the console:
>
> kbd2 at vkbd16
> kbd2 at vkbd17
> kbd2 at vkbd18
> kbd2 at vkbd19
> kbd2 at vkbd20
> kbd2 at vkbd21
> kbd2 at vkbd22
> kbd2 at vkbd23
> kbd2 at vkbd24
>
> but don't know what to do next. Typing on the keyboard doesn't do a
> dang thing. Oh, while typing this message, I have a few more:
>
> kbd2 at vkbd25
> kbd2 at vkbd26
> kbd2 at vkbd27
> kbd2 at vkbd28
> kbd2 at vkbd29
>
> What's up?
>
> Warner
>
Could you describe what you did to get this far? In my case, I have a Logitech
Cordless MediaBoard Pro keyboard (details could be found at
http://www.logitech.com/index.cfm/gaming/playstation_3/keyboards/devices/3616&cl=za,en).
I see similar behavior, but only in connection with keyboard being switched
off and on. I did report this problem here at 08:46, 22.05.2009, but no
response.
This does not help you probably, but you are not alone, at least :) I can try
it again, if it works for me, still - I did at least in 7.2 then.
Regards,
Milan
Milan Obuch
> In message: <20091226.231514.519...@bsdimp.com>
>
> M. Warner Losh <i...@bsdimp.com> writes:
> : OK. I must be pathologically dense...
> :
> : I've tried to get my apple mini keyboard working with my machine. I'm
> : so close. I'm getting the following messages on the console:
> :
> : kbd2 at vkbd16
> : kbd2 at vkbd17
[ snip ]
>
> /var/log/messages is telling me:
>
> Dec 26 23:29:02 lighthouse bthidd[638]: Opening outbound session for
> 00:1d:4f:a6:ce:b1 (new_device=1, reconnect_initiate=1) Dec 26 23:29:02
> lighthouse kernel: kbd2 at vkbd68
> Dec 26 23:29:07 lighthouse bthidd[638]: Could not connect to
> 00:1d:4f:a6:ce:b1. Host is down (64) Dec 26 23:29:15 lighthouse sudo:
> imp : TTY=pts/0 ; PWD=/hp/imp ; USER=root ; COMMAND=/usr/bin/vi
> /etc/bluetooth/hcsecd.conf Dec 26 23:29:22 lighthouse bthidd[638]: Opening
> outbound session for 00:1d:4f:a6:ce:b1 (new_device=1, reconnect_initiate=1)
> Dec 26 23:29:22 lighthouse kernel: kbd2 at vkbd69
> Dec 26 23:29:37 lighthouse sudo: imp : TTY=pts/0 ; PWD=/hp/imp ;
> USER=root ; COMMAND=/usr/bin/killall hcsecd Dec 26 23:29:37 lighthouse
> hcsecd[1559]: Could not remove PID file /var/run/hcsecd.pid. No such file
> or directory (2) Dec 26 23:29:46 lighthouse sudo: imp : TTY=pts/0 ;
> PWD=/hp/imp ; USER=root ; COMMAND=/usr/sbin/hcsecd -f
> /etc/bluetooth/hcsecd.conf Dec 26 23:30:34 lighthouse wpa_supplicant[1209]:
> CTRL-EVENT-SCAN-RESULTS Dec 26 23:30:44 lighthouse bthidd[638]: Could not
> connect to 00:1d:4f:a6:ce:b1. Operation timed out (60) Dec 26 23:31:02
> lighthouse bthidd[638]: Opening outbound session for 00:1d:4f:a6:ce:b1
> (new_device=1, reconnect_initiate=1) Dec 26 23:31:02 lighthouse kernel:
> kbd2 at vkbd70
> Dec 26 23:31:07 lighthouse bthidd[638]: Could not connect to
> 00:1d:4f:a6:ce:b1. Host is down (64) Dec 26 23:31:22 lighthouse
> bthidd[638]: Opening outbound session for 00:1d:4f:a6:ce:b1 (new_device=1,
> reconnect_initiate=1) Dec 26 23:31:22 lighthouse kernel: kbd2 at vkbd71
> Dec 26 23:31:27 lighthouse bthidd[638]: Could not connect to
> 00:1d:4f:a6:ce:b1. Host is down (64)
>
> how can I know if I've properly authenticated?
>
> Warner
>
Could you try pairing under The other OS :) eventually? I am not sure, but I
tested my keyboard this way first, it worked, then I follow with FreeBSD
tests.
Milan
Iain Hibbert
> What finally made it work was stupidly simple...
>
> On my apple keyboard, I turned it on, typed 9 8 7 6 return and then
> things started working. I'm typing this right now from the keyboard.
Heh, I've been away but was just going to suggest that reading your
mails..
btw a few words on security (though the scenario where somebody uses this
information and tracks you down to interfere with your system seems pretty
unlikely :)
- now that you have posted the PIN you used and bdaddr of your device, you
might want to re-pair with a different (more secure) PIN as I think the
link key may be derivable
- Not sure but I think that the keyboard will probably force auth and
encryption when making connections. The FreeBSD stack does not have a
way to do this except globally so unless you have the auth or
encrypt flags set (see hccontrol(8)) then a remote device can
break right in
- IMO the PIN should be ephemeral and use-once so when you are paired you
should remove it from the config file or at least comment it out
> Now, I guess the next step would be to find the bt mouse I have and
> try to get it going as well...
that is probably fixed pin 0000 if not in the documentation
> This is my second favorite keyboard ever.
How is the keypress feel? I've not had a go on one of those, but I have
an original apple bluetooth keyboard (white with clear undershell, full
sized with num keypad) that works well though a smaller one might be
interesting.
iain
M. Warner Losh
Iain Hibbert <plu...@rya-online.net> writes:
: On Sun, 27 Dec 2009, M. Warner Losh wrote:
:
: > What finally made it work was stupidly simple...
: >
: > On my apple keyboard, I turned it on, typed 9 8 7 6 return and then
: > things started working. I'm typing this right now from the keyboard.
:
: Heh, I've been away but was just going to suggest that reading your
: mails..
:
: btw a few words on security (though the scenario where somebody uses this
: information and tracks you down to interfere with your system seems pretty
: unlikely :)
:
: - now that you have posted the PIN you used and bdaddr of your device, you
: might want to re-pair with a different (more secure) PIN as I think the
: link key may be derivable
Actually I faked both when I posted it. Most devices don't have c0:ed
at the end, and my certainly don't :)
: - Not sure but I think that the keyboard will probably force auth and
: encryption when making connections. The FreeBSD stack does not have a
: way to do this except globally so unless you have the auth or
: encrypt flags set (see hccontrol(8)) then a remote device can
: break right in
That's good to know. I think that I have these set...
: - IMO the PIN should be ephemeral and use-once so when you are paired you
: should remove it from the config file or at least comment it out
The whole pairing thing is kind of ugly atm in FreeBSD. I used big
hammers, I think, to make it work. In other OSes, I just see what is
discoverable, click a couple of times, maybe enter a PIN and I then
promptly forget about it until I have to 'unpair'.
: > Now, I guess the next step would be to find the bt mouse I have and
: > try to get it going as well...
:
: that is probably fixed pin 0000 if not in the documentation
Yes, it is :) The default is to no pin, so it wasn't authenticating.
: > This is my second favorite keyboard ever.
:
: How is the keypress feel? I've not had a go on one of those, but I have
: an original apple bluetooth keyboard (white with clear undershell, full
: sized with num keypad) that works well though a smaller one might be
: interesting.
It is ok. Not as good as the happy hacking keyboard, but certainly
nice enough to use. Better than most to my feel, but ymmv.
btw, is there some way I can easily list the paired devices?
Warner
Iain Hibbert
> In message: <1261935364.50166...@galant.ukfsn.org>
> Iain Hibbert <plu...@rya-online.net> writes:
> : - IMO the PIN should be ephemeral and use-once so when you are paired you
> : should remove it from the config file or at least comment it out
>
> The whole pairing thing is kind of ugly atm in FreeBSD. I used big
> hammers, I think, to make it work. In other OSes, I just see what is
> discoverable, click a couple of times, maybe enter a PIN and I then
> promptly forget about it until I have to 'unpair'.
I have had complaints about it in NetBSD too and while I think I improved
on Max's start it still needs further work and should be graphical. I'm
not sure about the whole dbus thing that BlueZ is moving to now though it
does work well as you say with the GNOME application. I thought about
working something lightweight up with (eg) tcl/tk but haven't got around
to it yet..
> : > Now, I guess the next step would be to find the bt mouse I have and
> : > try to get it going as well...
> :
> : that is probably fixed pin 0000 if not in the documentation
>
> Yes, it is :) The default is to no pin, so it wasn't authenticating.
Some devices that I noticed will only enforce the auth on making or
accepting the connection. Even the Linux stack used to do this (on the
accept path only) but I think they fixed it now.
> : > This is my second favorite keyboard ever.
> :
> : How is the keypress feel? I've not had a go on one of those, but I have
> : an original apple bluetooth keyboard (white with clear undershell, full
> : sized with num keypad) that works well though a smaller one might be
> : interesting.
>
> It is ok. Not as good as the happy hacking keyboard, but certainly
> nice enough to use. Better than most to my feel, but ymmv.
I will have to take a trip to the Apple store as it looks a bit rubbery, I
want to play with a magic mouse too and I saw that they had some of them
last week. (it will not be easy to support properly, I have seen some
connection logs and it does some private internal feature back and forth
conversation first - we thought that probably enables the touch pad
feature which might not be too hard to do, but the driver must then
interpret all the swipes itself)
> btw, is there some way I can easily list the paired devices?
'easily' not really, but /var/db/hcsecd.keys should contain keys for all
paired devices. Actually, there can be more keys stored in the device
itself (if you paired with another OS that might happen or you can do it
manually). I think you can check/change/remove those with hccontrol but
must edit the hcsecd.keys file manually.
iain
Maksim Yevmenkin
> On Sun, 27 Dec 2009, M. Warner Losh wrote:
>
>> In message: <1261935364.50166...@galant.ukfsn.org>
>> Iain Hibbert <plu...@rya-online.net> writes:
>> : - IMO the PIN should be ephemeral and use-once so when you are paired you
>> : should remove it from the config file or at least comment it out
>>
>> The whole pairing thing is kind of ugly atm in FreeBSD. I used big
>> hammers, I think, to make it work. In other OSes, I just see what is
>> discoverable, click a couple of times, maybe enter a PIN and I then
>> promptly forget about it until I have to 'unpair'.
>
> I have had complaints about it in NetBSD too and while I think I improved
> on Max's start it still needs further work and should be graphical. I'm
> not sure about the whole dbus thing that BlueZ is moving to now though it
> does work well as you say with the GNOME application. I thought about
> working something lightweight up with (eg) tcl/tk but haven't got around
> to it yet..
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.
apple keyboard is not giving you any indication that it wants
pairing. basically, user supposed to follow instructions on screen --
and it makes perfect sense. we don't have the luxury of uniform
graphical user interface, so, you had to use "big hammers". i guess,
it would be possible to write text based guided 'pair bluetooth
device' tool, that would work together with hcsecd(8) and basically
instruct it to do the pairing and then, on successful completion,
update config/keys file.
>> : > Now, I guess the next step would be to find the bt mouse I have and
>> : > try to get it going as well...
>> :
>> : that is probably fixed pin 0000 if not in the documentation
>>
>> Yes, it is :) The default is to no pin, so it wasn't authenticating.
>
> Some devices that I noticed will only enforce the auth on making or
> accepting the connection. Even the Linux stack used to do this (on the
> accept path only) but I think they fixed it now.
i know for a fact that both apple mouse (older version) and apple
keyboard (older version) work just fine with freebsd. be warned that
bthidd(8) is not really tracking mouse buttons' state and relies on os
to do so. bthidd(8) simply translates hid events into
ioctl(CONS_MOUSECTL), i.e. things like double-click, etc. will not
work in console, but will work in X.
[...]
>> btw, is there some way I can easily list the paired devices?
>
> 'easily' not really, but /var/db/hcsecd.keys should contain keys for all
> paired devices. Actually, there can be more keys stored in the device
> itself (if you paired with another OS that might happen or you can do it
> manually). I think you can check/change/remove those with hccontrol but
> must edit the hcsecd.keys file manually.
yes, edit /var/db/hcsecd.keys and hup/restart hcsecd(8)
thanks,
max
Maksim Yevmenkin
> In message: <200912270746.59264...@dino.sk>
> Milan Obuch <freebsd-...@dino.sk> writes:
> : On Sunday 27 December 2009 07:15:14 M. Warner Losh wrote:
> : > OK. I must be pathologically dense...
> : >
> : > I've tried to get my apple mini keyboard working with my machine. I'm
> : > so close. I'm getting the following messages on the console:
[...]
> sure hope that vkbd290 isn't going to run me out of memory :)
well, that is how "auto cloning" apparently works. bthidd(8) opens
/dev/vkbdctl basically asking for the first available instance of
/dev/vkbdctl. however, cloning "gets there first" and always gives new
clone. same as if_tun(4), if_tap(4) etc. i never liked that. seems
like something is missing in clone_xxxx api.
thanks,
max
M. Warner Losh
Maksim Yevmenkin <maksim.y...@gmail.com> writes:
: On Sun, Dec 27, 2009 at 10:59 AM, Iain Hibbert <plu...@rya-online.net> wrote:
: > On Sun, 27 Dec 2009, M. Warner Losh wrote:
: >
: >> In message: <1261935364.50166...@galant.ukfsn.org>
: >> Iain Hibbert <plu...@rya-online.net> writes:
: >> : - IMO the PIN should be ephemeral and use-once so when you are paired you
: >> : should remove it from the config file or at least comment it out
: >>
: >> The whole pairing thing is kind of ugly atm in FreeBSD. I used big
: >> hammers, I think, to make it work. In other OSes, I just see what is
: >> discoverable, click a couple of times, maybe enter a PIN and I then
: >> promptly forget about it until I have to 'unpair'.
: >
: > I have had complaints about it in NetBSD too and while I think I improved
: > on Max's start it still needs further work and should be graphical. I'm
: > not sure about the whole dbus thing that BlueZ is moving to now though it
: > does work well as you say with the GNOME application. I thought about
: > working something lightweight up with (eg) tcl/tk but haven't got around
: > to it yet..
:
: 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?
: apple keyboard is not giving you any indication that it wants
: pairing. basically, user supposed to follow instructions on screen --
: and it makes perfect sense. we don't have the luxury of uniform
: graphical user interface, so, you had to use "big hammers". i guess,
: it would be possible to write text based guided 'pair bluetooth
: device' tool, that would work together with hcsecd(8) and basically
: instruct it to do the pairing and then, on successful completion,
: update config/keys file.
Yes. That's annoying, but enough googling showed me that others have
to do this on OS X even...
I wonder how hard that would be to write?
Is there any way to get the details of what devices hcsecd is
tracking? In the IP world, things like ifconfig, arp, netstat -r, etc
show you the different aspects of the state of the device. I don't
see anything equivalent in bluetooth land. Did I miss them?
: >> : > Now, I guess the next step would be to find the bt mouse I have and
: >> : > try to get it going as well...
: >> :
: >> : that is probably fixed pin 0000 if not in the documentation
: >>
: >> Yes, it is :) The default is to no pin, so it wasn't authenticating.
: >
: > Some devices that I noticed will only enforce the auth on making or
: > accepting the connection. Even the Linux stack used to do this (on the
: > accept path only) but I think they fixed it now.
:
: i know for a fact that both apple mouse (older version) and apple
: keyboard (older version) work just fine with freebsd. be warned that
: bthidd(8) is not really tracking mouse buttons' state and relies on os
: to do so. bthidd(8) simply translates hid events into
: ioctl(CONS_MOUSECTL), i.e. things like double-click, etc. will not
: work in console, but will work in X.
Makes sense...
: [...]
:
: >> btw, is there some way I can easily list the paired devices?
: >
: > 'easily' not really, but /var/db/hcsecd.keys should contain keys for all
: > paired devices. Actually, there can be more keys stored in the device
: > itself (if you paired with another OS that might happen or you can do it
: > manually). I think you can check/change/remove those with hccontrol but
: > must edit the hcsecd.keys file manually.
:
: yes, edit /var/db/hcsecd.keys and hup/restart hcsecd(8)
How do I know what the key is for a given device?
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). Is
there some way to find out what the battery level in these devices is?
Thanks a bunch... If I had a phone that would do internet over ip,
that would be my next set of questions...
Warner
[*] the keyboard doesn't always register pressing the caps lock key
quite right. I have it mapped to control and 10% of the time I get
the character instead of the control character (eg, a gets inserted in
emacs, rather than going to the start of the line). But I had similar
issues under OS X on an old MacBook Pro I used to have...
Iain Hibbert
> : 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
Maksim Yevmenkin
> 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
Iain Hibbert
> 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.
I would like some of that but I think its a bit complex to handle
properly. I wanted to associate user credentials with sockets, so that for
example a user could have their own PIN/key daemon running and keep their
own keys for their own devices private (also, piggybacking onto another
users baseband connection would be prevented) but, I never did really work
out how and where incoming connections would be dealt with.
One associated thing I thought of which I forgot to mention at the time,
do you think it would be useful to extend the bluetooth(3) host lookup
routines (eg bt_gethostbyname()) to search in a user file (eg
~/.bluetooth/hosts ?) in addition to the system /etc/bluetooth/hosts so
that users did not need root privileges to add an alias for their
favourite device? That might be a fairly simple addition..
> having said all that, i do not see why executing external pin program
> from hcsecd(8) is a bad idea.
If the daemon runs an external program, the daemon must run as root or the
logged in user otherwise it won't be able to write anything to the screen,
and I think its a bit scary to have root daemons running X programs (ok
I'm a coward :). Also, I'm not sure about this, but root might not
actually have permission to write on the display which could be on another
machine entirely. Then, if a machine has several displays, what do you
set DISPLAY env variable to, and when? Its much easier I think to just
have the user who wants to do PIN entering just run her own daemon..
> > 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!
btw if you don't find the magic key combo, the program should be in
/Developer/Applications/Utilities/Bluetooth
iain