Dear Bluetooth experts,
I think I am probably the bazillionth person to ask here about how to
get the Apple wireless keyboard to work properly with Linux. Some of
the people who've solved the problem before have posted how-to pages
with recipes that worked for them, but unfortunately without really
understanding what was going on, or containing distribution-specific or
out-of-date information. My keyboard is basically working now, but I'm
hoping that you can help me to understand what is really going on and
what is the right way to do it.
Firstly, I understand that some USB Bluetooth dongles have a "HID Mode"
where they appear as USB HID devices and all of the Bluetooth
complexity is avoided. That would be ideal for me, but I suspect that
my dongle doesn't support that mode of operation; this page:
http://times.usefulinc.com/2004/06/12-hidproxy says that (in 2004) only
the CSR chips had this feature; is this still true? My dongle is
(lsusb) "1131:1004 Integrated System Solution Corp." which doesn't look
like CSR. I bought it cheapo on Ebay. Is there a reliable way to
obtain a USB dongle with a CSR chip with this feature? And how does
pairing work in this HID mode? (Is it secure?)
Anyway, for the time being I have set it up the "hard way" as a real
Bluetooth keyboard. I did this by
- Installing a kernel with the bluetooth modules.
- Installing bluez-utils.
- Starting hidd and hcid (enabling them in /etc/default/bluetooth on
this Debian box)
- Running passkey-agent --default 1234 (Debian ships this source for this)
- Running hcitool scan to get the keyboard address (which I've now
written on the back)
- Running hidd --connect <addr> and typing 1234RET on the keyboard
Now, if I understand things correctly, this PIN pairing should be a
one-off thing; there is now a file in /var/lib/bluetooth/..../linkkeys
which I presume is a key that can be used subsequently instead of the
PIN procedure - right? (BTW, the .... in the pathname above is not the
keyboard's address; it has lots of 0s at the end. What is it?) So
after I reboot the keyboard should be able to connect without user
interaction. But so far I have failed to make this happen. I have
only been able to reconnect by deleting various things and starting
from fresh. What do I need to do? Do I need to add it to a
configuration file somewhere? Do I need to arrange for hidd --connect
to be run?
Many thanks for any suggestions.
Phil.
-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
_______________________________________________
Bluez-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-users
Hi Phil,
On Apr 24, 2008, at 18:49, Phil Endecott wrote:
>>> - Running hcitool scan to get the keyboard address (which I've now
>>> written on the back)
>>> - Running hidd --connect <addr> and typing 1234RET on the keyboard
>>
>> Both of these are fine but instead of using hidd you'd use the
>> Connect
>> method that the input service provides (I think there's an example of
>> that too in the wiki).
>
> Hmm. So rather than running "hcitool scan" and "hidd --conect
> <addr>",
> I have to write a few lines of python (a language I've never used) to
> communicate over dbus (a protocol that I've never used) to this "input
> service" thing? If that's the case, then I can't say this looks like
> an improvement in usability.
If you take a look at the wiki page you'll see that this can be
accomplished with a couple of dbus-send commands which isn't that
different from using hcitool and hidd (though the parameter list to
dbus-send is certainly longer compared to the legacy commands). On the
other hand, this D-Bus interface is of course something that an end
user should never see. Instead, his environment of choice (be it
GNOME, KDE, or something else) should provide a proper UI to do all
this, and a D-Bus interface is a much cleaner solution compared to
e.g. a GUI calling the legacy command line tools whose parameter lists
and outputs have never been defined as a stable API.
What is a valid criticism of the current situation though is that
compared to the legacy command line tools there doesn't exist as
simple (or simpler) counterparts for the D-Bus API. This is mostly
because using dbus-send or hacking together a quick python scrip
hasn't been that big of a trouble for developers. However, while it is
the responsibility of the different GUI environments to provide a
proper GUI for using BlueZ (accessing it's D-Bus API) I do agree that
BlueZ should continue providing easy to use command line tools for the
D-Bus API's and hopefully there will be improvement in this area in
the future.
Johan
-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
_______________________________________________
Bluez-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-users
Hi Johan,
Johan Hedberg wrote:
>> - Installing a kernel with the bluetooth modules.
>> - Installing bluez-utils.
>> - Starting hidd and hcid (enabling them in /etc/default/bluetooth on
>> this Debian box)
>
> This might have been the first step that went wrong. hidd has been
> superseded by the input service already some time ago.
I'm using the Debian package of bluez-utils version 3.30-3, following
their instructions in /usr/share/doc/bluez-utils/README.Debian.gz.
I've already submitted some suggested changes to this document, so if
there are some more things that they need to update, let me know and
I'll file a report.
> You can check
> whether it's enabled e.g. with the bluetooth-properties app that comes
> with bluez-gnome (assuming you use Gnome).
I'm not using Gnome.
> You will need to tell the
> input service about your keyboard using the CreateDevice D-Bus method
> call (maybe bluetooth-properties even supports doing this through its
> GUI). Some python examples can nevertheless be found in the BlueZ
> wiki: http://wiki.bluez.org/wiki/HOWTO/InputDevices
>> - Running hcitool scan to get the keyboard address (which I've now
>> written on the back)
>> - Running hidd --connect <addr> and typing 1234RET on the keyboard
>
> Both of these are fine but instead of using hidd you'd use the Connect
> method that the input service provides (I think there's an example of
> that too in the wiki).
Hmm. So rather than running "hcitool scan" and "hidd --conect <addr>",
I have to write a few lines of python (a language I've never used) to
communicate over dbus (a protocol that I've never used) to this "input
service" thing? If that's the case, then I can't say this looks like
an improvement in usability.
>> So
>> after I reboot the keyboard should be able to connect without user
>> interaction. But so far I have failed to make this happen.
>
> Probably because you don't have a HID server to accept the incoming
> connection request.
hidd --master --server is started by the Debian init.d script.
See my other messages for my further thoughts about why this is not
working; I think it's a lower-level problem.
Regards, Phil.
-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
_______________________________________________
Bluez-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-users
Odysseus Flappington wrote:
> I was also getting "UP RUNNING PSCAN ISCAN", unlike the initial bug-reporter
> but the 'hciconfig hci0 reset' command on reboot fixed the problem with my
> Apple keyboard. Have you actually tried it?
Yes, see below. On more investigation it's less like the bug that you
linked to than I initially suggested; it's time-consuming to work out
exactly what makes it fail since some long timeouts seem to be
involved. Today I booted the PC and switched on the keyboard and it
all worked for a few hours; I was then out for most of the afternoon
and this is what happened:
Apr 24 13:29:42 egypt hcid[2850]: link_key_request
(sba=00:11:67:00:00:00, dba=00:1E:52:F9:60:2C)
Apr 24 13:29:43 egypt hidd[2859]: New HID device 00:1E:52:F9:60:2C
(Apple Inc. Keyboard)
Apr 24 13:29:43 egypt kernel: input: Apple Inc. Keyboard as /class/input/input8
Apr 24 13:46:48 egypt -- MARK --
Apr 24 13:59:54 egypt hcid[2850]: link_key_request
(sba=00:11:67:00:00:00, dba=00:1E:52:F9:60:2C)
Apr 24 13:59:54 egypt hidd[2859]: New HID device 00:1E:52:F9:60:2C
(Apple Inc. Keyboard)
Apr 24 13:59:54 egypt kernel: input: Apple Inc. Keyboard as /class/input/input9
Apr 24 14:30:06 egypt hcid[2850]: link_key_request
(sba=00:11:67:00:00:00, dba=00:1E:52:F9:60:2C)
Apr 24 14:30:07 egypt hidd[2859]: New HID device 00:1E:52:F9:60:2C
(Apple Inc. Keyboard)
Apr 24 14:30:07 egypt kernel: input: Apple Inc. Keyboard as /class/input/input10
Apr 24 14:46:48 egypt -- MARK --
Apr 24 15:00:19 egypt hcid[2850]: link_key_request
(sba=00:11:67:00:00:00, dba=00:1E:52:F9:60:2C)
Apr 24 15:00:19 egypt hidd[2859]: New HID device 00:1E:52:F9:60:2C
(Apple Inc. Keyboard)
Apr 24 15:00:19 egypt kernel: input: Apple Inc. Keyboard as /class/input/input11
Apr 24 15:17:01 egypt /USR/SBIN/CRON[17207]: (root) CMD ( run-parts
--report /etc/cron.hourly)
Apr 24 15:30:32 egypt hcid[2850]: link_key_request
(sba=00:11:67:00:00:00, dba=00:1E:52:F9:60:2C)
Apr 24 15:30:32 egypt hidd[2859]: New HID device 00:1E:52:F9:60:2C
(Apple Inc. Keyboard)
Apr 24 15:30:32 egypt kernel: input: Apple Inc. Keyboard as /class/input/input12
Apr 24 15:46:48 egypt -- MARK --
Apr 24 16:00:32 egypt kernel: hci_acl_tx_to: hci0 ACL tx timeout
Apr 24 16:00:32 egypt kernel: hci_acl_tx_to: hci0 killing stalled ACL
connection 2C:60:F9:52:1E:00
Apr 24 16:00:32 egypt kernel: hci_acl_tx_to: hci0 ACL tx timeout
Apr 24 16:00:32 egypt kernel: hci_acl_tx_to: hci0 killing stalled ACL
connection 2C:60:F9:52:1E:00
So it looks like there is some sort of keep-alive that re-connects it
every 30 mins (curiously almost exactly on the half-hours), until at
16:00 it failed with those timeout messages. It's now 16:21 and the
keyboard isn't working (though it is still on). If I power-cycle it,
it tries to reconnect (flashing LED) but I see nothing in the syslog.
If I then hciconfig hci0 reset I get this:
Apr 24 16:23:37 egypt hcid[2850]: HCI dev 0 down
Apr 24 16:23:37 egypt hcid[2850]: Stopping security manager 0
Apr 24 16:23:37 egypt hcid[2850]: Device hci0 has been disabled
Apr 24 16:23:37 egypt kernel: uhci_hcd 0000:00:10.2: release dev 2
ep83-ISO, period 1, phase 0, 22 us
Apr 24 16:23:37 egypt kernel: uhci_hcd 0000:00:10.2: release dev 2
ep81-INT, period 1, phase 0, 23 us
Apr 24 16:23:37 egypt kernel: uhci_hcd 0000:00:10.2: reserve dev 2
ep81-INT, period 1, phase 0, 23 us
Apr 24 16:23:37 egypt kernel: uhci_hcd 0000:00:10.2: reserve dev 2
ep83-ISO, period 1, phase 0, 22 us
Apr 24 16:23:47 egypt kernel: uhci_hcd 0000:00:10.2: release dev 2
ep83-ISO, period 1, phase 0, 22 us
Apr 24 16:23:47 egypt kernel: uhci_hcd 0000:00:10.2: release dev 2
ep81-INT, period 1, phase 0, 23 us
and the keyboard still doesn't work. If I replug the USB dongle, it
all starts working again.
So I think this is a lower-level problem with this USB dongle. I
noticed that there was a quirks entry in the kernel - HCI_RESET - for a
device with a similar but not identical USB id (1131:1001 rather than
1131:1004). Maybe this is related.
Anyway, I have ordered a different dongle that might have the CSR chip
with the HID proxy mode. With luck that will make it all much simpler.
Regards, Phil
-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
_______________________________________________
Bluez-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-users
I was also getting "UP RUNNING PSCAN ISCAN", unlike the initial bug-reporter
but the 'hciconfig hci0 reset' command on reboot fixed the problem with my
Apple keyboard. Have you actually tried it?
Alex
On 23/04/2008, Phil Endecott <[email protected]> wrote:
>
> Odysseus Flappington wrote:
> > You're probably suffering from the following bug:
> >
> > https://bugs.launchpad.net/ubuntu/+source/bluez-utils/+bug/79394
> >
> > Try a 'hciconfig hci0 reset' after restarting and then your keyboard
> should
> > reconnect again.
>
>
> Thanks for the suggestion. That bug reporter was seeing "UP RUNNING"
> but not scanning in the hciconfig output; I am getting "UP RUNNING
> PSCAN ISCAN", so I don't think it's the same thing.
>
> On more investigation, it seems that the failure happens after the
> keyboard has gone to sleep and I wake it up; I then see this in syslog:
>
> Apr 23 18:09:37 egypt hidd[2856]: New HID device 00:1E:52:F9:60:2C
> (Apple Inc. Keyboard)
> Apr 23 18:09:37 egypt kernel: input: Apple Inc. Keyboard as
> /class/input/input13
> Apr 23 18:09:37 egypt kernel: usb 3-2: uhci_result_common: failed with
> status 440000
> Apr 23 18:09:37 egypt kernel: usb 3-2: uhci_result_common: failed with
> status 440000
>
> Does anyone know what "status 440000" is? It makes me think that it's
> a lower level problem with the USB dongle.
>
> After 30 mins I get this, which is presumably related:
> Apr 23 18:39:37 egypt kernel: hci_acl_tx_to: hci0 ACL tx timeout
> Apr 23 18:39:37 egypt kernel: hci_acl_tx_to: hci0 killing stalled ACL
> connection 2C:60:F9:52:1E:00
> Apr 23 18:39:37 egypt kernel: hci_acl_tx_to: hci0 ACL tx timeout
> Apr 23 18:39:37 egypt kernel: hci_acl_tx_to: hci0 killing stalled ACL
> connection 2C:60:F9:52:1E:00
>
> I can make the keyboard work again by re-plugging the USB dongle and
> waking up the keyboard.
>
> Anyway, I am going to try to get a USB bluetooth dongle that has a HID
> proxy mode, and hopefully this can all be avoided. If anyone can
> suggest a particular brand/model that is known to work in HID proxy
> mode, please let me know! Thanks.
>
>
>
> Phil.
>
>
>
>
>
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
> Don't miss this year's exciting event. There's still time to save $100.
> Use priority code J8TL2D2.
>
> http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
> _______________________________________________
> Bluez-users mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/bluez-users
>
Odysseus Flappington wrote:
> You're probably suffering from the following bug:
>
> https://bugs.launchpad.net/ubuntu/+source/bluez-utils/+bug/79394
>
> Try a 'hciconfig hci0 reset' after restarting and then your keyboard should
> reconnect again.
Thanks for the suggestion. That bug reporter was seeing "UP RUNNING"
but not scanning in the hciconfig output; I am getting "UP RUNNING
PSCAN ISCAN", so I don't think it's the same thing.
On more investigation, it seems that the failure happens after the
keyboard has gone to sleep and I wake it up; I then see this in syslog:
Apr 23 18:09:37 egypt hidd[2856]: New HID device 00:1E:52:F9:60:2C
(Apple Inc. Keyboard)
Apr 23 18:09:37 egypt kernel: input: Apple Inc. Keyboard as /class/input/input13
Apr 23 18:09:37 egypt kernel: usb 3-2: uhci_result_common: failed with
status 440000
Apr 23 18:09:37 egypt kernel: usb 3-2: uhci_result_common: failed with
status 440000
Does anyone know what "status 440000" is? It makes me think that it's
a lower level problem with the USB dongle.
After 30 mins I get this, which is presumably related:
Apr 23 18:39:37 egypt kernel: hci_acl_tx_to: hci0 ACL tx timeout
Apr 23 18:39:37 egypt kernel: hci_acl_tx_to: hci0 killing stalled ACL
connection 2C:60:F9:52:1E:00
Apr 23 18:39:37 egypt kernel: hci_acl_tx_to: hci0 ACL tx timeout
Apr 23 18:39:37 egypt kernel: hci_acl_tx_to: hci0 killing stalled ACL
connection 2C:60:F9:52:1E:00
I can make the keyboard work again by re-plugging the USB dongle and
waking up the keyboard.
Anyway, I am going to try to get a USB bluetooth dongle that has a HID
proxy mode, and hopefully this can all be avoided. If anyone can
suggest a particular brand/model that is known to work in HID proxy
mode, please let me know! Thanks.
Phil.
-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
_______________________________________________
Bluez-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-users
Hi Phil,
Any further success with your issue? Below are some answers to your
questions:
On Apr 22, 2008, at 17:58, Phil Endecott wrote:
> Is there a reliable way to
> obtain a USB dongle with a CSR chip with this feature?
Don't think so. Usually you can't even be sure that there's a CSR chip
inside the dongle since sometimes manufacturers use different chipsets
for the same dongle model. The only way to be completely sure is to
take your laptop to the store and convince the sales clerk to let you
plug-in the dongle to your laptop before buying it.
> And how does
> pairing work in this HID mode? (Is it secure?)
No idea about this actually, sorry.
> - Installing a kernel with the bluetooth modules.
> - Installing bluez-utils.
> - Starting hidd and hcid (enabling them in /etc/default/bluetooth on
> this Debian box)
This might have been the first step that went wrong. hidd has been
superseded by the input service already some time ago. You can check
whether it's enabled e.g. with the bluetooth-properties app that comes
with bluez-gnome (assuming you use Gnome). You will need to tell the
input service about your keyboard using the CreateDevice D-Bus method
call (maybe bluetooth-properties even supports doing this through its
GUI). Some python examples can nevertheless be found in the BlueZ
wiki: http://wiki.bluez.org/wiki/HOWTO/InputDevices
> - Running passkey-agent --default 1234 (Debian ships this source for
> this)
This is fine, except that if you run a graphical environment it might
already provide a passkey agent for you. In Gnome this is provided by
the bluetooth-applet program that's part of bluez-gnome.
> - Running hcitool scan to get the keyboard address (which I've now
> written on the back)
> - Running hidd --connect <addr> and typing 1234RET on the keyboard
Both of these are fine but instead of using hidd you'd use the Connect
method that the input service provides (I think there's an example of
that too in the wiki).
> Now, if I understand things correctly, this PIN pairing should be a
> one-off thing; there is now a file in /var/lib/bluetooth/..../linkkeys
> which I presume is a key that can be used subsequently instead of the
> PIN procedure - right?
That's right.
> (BTW, the .... in the pathname above is not the
> keyboard's address; it has lots of 0s at the end. What is it?)
It's the address of your local bluetooth adapter (so if you have
multiple adapters their settings don't get mixed up).
> So
> after I reboot the keyboard should be able to connect without user
> interaction. But so far I have failed to make this happen.
Probably because you don't have a HID server to accept the incoming
connection request. hidd has a server mode which I don't right now
remember, but the correct thing to do with recent bluez versions is to
have the input service running (note that you can't run the input
service and hidd at the same time, that would be like trying to run
two webservers that both try to bind to tcp port 80).
Remember that you need to first tell the input service about your
keyboard using the CreateDevice method call. IIRC it will reject
connections by default from any unknown device.
> I have
> only been able to reconnect by deleting various things and starting
> from fresh. What do I need to do? Do I need to add it to a
> configuration file somewhere? Do I need to arrange for hidd --connect
> to be run?
If possible don't touch hidd anymore since it's deprecated. The input
service will permanently store info about the keyboard once you've
configured it through CreateDevice and it should be able to connect to
your PC after that. You'll also need an authorization agent running (I
think both bluetooth-applet and passkey-agent implement one), or then
you need to tell bluez that the device is trusted using the SetTrusted
method call (e.g. bluetooth-properties provides a GUI to do this).
In general for debuging bluez issues the most helpful info is often a
HCI trace which you can get by running the hcidump tool. "hcidump -X -
V" will produce human-readable output and attaching it to a problem
report on bluez-devel or bluez-users will often get developers to
analyze your issue more quickly. E.g. if your problems persist after
trying out the suggestions in this email I suggest you attach a
hcidump log of the failure to your next email. Another good source of
debug information is what the different bluez daemons print to the
syslog.
Johan
-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
_______________________________________________
Bluez-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-users
You're probably suffering from the following bug:
https://bugs.launchpad.net/ubuntu/+source/bluez-utils/+bug/79394
Try a 'hciconfig hci0 reset' after restarting and then your keyboard should
reconnect again.
Alex
On 22/04/2008, Phil Endecott <[email protected]> wrote:
>
> Dear Bluetooth experts,
>
> I think I am probably the bazillionth person to ask here about how to
> get the Apple wireless keyboard to work properly with Linux. Some of
> the people who've solved the problem before have posted how-to pages
> with recipes that worked for them, but unfortunately without really
> understanding what was going on, or containing distribution-specific or
> out-of-date information. My keyboard is basically working now, but I'm
> hoping that you can help me to understand what is really going on and
> what is the right way to do it.
>
> Firstly, I understand that some USB Bluetooth dongles have a "HID Mode"
> where they appear as USB HID devices and all of the Bluetooth
> complexity is avoided. That would be ideal for me, but I suspect that
> my dongle doesn't support that mode of operation; this page:
> http://times.usefulinc.com/2004/06/12-hidproxy says that (in 2004) only
> the CSR chips had this feature; is this still true? My dongle is
> (lsusb) "1131:1004 Integrated System Solution Corp." which doesn't look
> like CSR. I bought it cheapo on Ebay. Is there a reliable way to
> obtain a USB dongle with a CSR chip with this feature? And how does
> pairing work in this HID mode? (Is it secure?)
>
> Anyway, for the time being I have set it up the "hard way" as a real
> Bluetooth keyboard. I did this by
>
> - Installing a kernel with the bluetooth modules.
> - Installing bluez-utils.
> - Starting hidd and hcid (enabling them in /etc/default/bluetooth on
> this Debian box)
> - Running passkey-agent --default 1234 (Debian ships this source for this)
> - Running hcitool scan to get the keyboard address (which I've now
> written on the back)
> - Running hidd --connect <addr> and typing 1234RET on the keyboard
>
> Now, if I understand things correctly, this PIN pairing should be a
> one-off thing; there is now a file in /var/lib/bluetooth/..../linkkeys
> which I presume is a key that can be used subsequently instead of the
> PIN procedure - right? (BTW, the .... in the pathname above is not the
> keyboard's address; it has lots of 0s at the end. What is it?) So
> after I reboot the keyboard should be able to connect without user
> interaction. But so far I have failed to make this happen. I have
> only been able to reconnect by deleting various things and starting
> from fresh. What do I need to do? Do I need to add it to a
> configuration file somewhere? Do I need to arrange for hidd --connect
> to be run?
>
> Many thanks for any suggestions.
>
> Phil.
>
>
>
>
>
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
> Don't miss this year's exciting event. There's still time to save $100.
> Use priority code J8TL2D2.
>
> http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
> _______________________________________________
> Bluez-users mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/bluez-users
>