I have a bluetooth mouse that I have tried to use with a notebook running
Kubuntu Jaunty, Kubuntu Karmic, and sidux 2009-03. With all three distros it
always takes about 5 to 6 seconds for the mouse to connect (or reconnect,
coming out of sleep mode). However, if I boot the notebook under Windows XP,
the same mouse always (re)connects in under one second. Having to wait for 5-6
seconds every time I bring the mouse out of sleep mode under Linux is quite
annoying!
I have opened an Ubuntu bug and posted to the Ubuntu and sidux forums about
this, but got exactly zero replies (the Ubuntu bug was opened back in May and
nobody has even touched it!) So now I come to see if I have better luck here on
this mailing list.
Specifically, I'd like to ask: is there some bluez configuration option I can
try to speed up the mouse (re)connection, or is this 5-6 second delay the norm
under Linux?
The notebook is an Asus A8Js with a built-in bluetooth module, and the mouse is
a Targus AMB02US. In my latest attempt, under sidux, I followed the directions
found in http://www.sidux.com/index.php?module=Wikula&tag=hwBluetooth to set it
up. Please let me know if there is any additional information I should provide
about my system to help diagnose this problem.
Hi Daniel,
On Wed, 23 Dec 2009 15:53:09 -0200
"Daniel T. Cobra" <[email protected]> wrote:
> If I don't use the mouse for some time (I haven't clocked it, but it is
> probably some 5 to 10 minutes), it goes into what I assume is sleep
> mode, i.e., the cursor stops responding to mouse movements. It only
> reconnects if I press a button,
Ok, that's clear.
> but it takes about 5 seconds for the
> cursor to start tracking the mouse movements again. Switching the mouse
> off, then on while it is connected has the same effect as bringing it
> out of sleep mode: it takes 5 seconds to start working again. I haven't
> tried switching it off, then on while it is asleep, to see if it makes
> any difference (I don't have it here with me now, but I'll do this test
> tonight).
No, it probably won't make a difference. Additionally, the bug I
remembered (where it would have made a difference) was different: the
mouse did not reconnect at all, unless it was completely disconnected
by either replugging the dongle or switching the mouse off and on. And
that bug is fixed since years anyway ;)
For the record: I tried the same (waiting until the mouse falls asleep
then pressing a button to reconnect) on an Acer Bluetooth Mouse and it
immediately reconnected and worked, in definitely under one second.
So it seems it is something a little bit specific to your device (I'm
not saying the mouse is doing something wrong, it might just be
behaving differently from what is expected by bluez, and this might
need to be fixed in bluez).
> Venu's suggestion of comparing the HCI dumps of reconnection under
> Windows and Linux will probably shed more light onto this problem.
Yes, probably. If this does not help, we could try to compare the dumps
of your mouse and mine.
> By
> the way, I had no luck googling for an hcidump equivalent for Windows.
> Can anybody suggest one?
I have no idea, sorry.
Good luck ;)
seife
--
Stefan Seyfried
"Any ideas, John?"
"Well, surrounding them's out."
Hi Stefan:
> David, "every time I bring the mouse out of sleep mode", does this mean
> the mouse went to sleep, you click the button (or move the mouse) and
> it takes 5 seconds to reconnect? If so, could you try if it makes a
> difference if you switch off the mouse instead? (wait until it falls
> asleep, then switch off and on and check if it reconnects faster. Might
> not be easy if this is a mouse that wakes up on movement, then you
> probably need to lay it upside down until it sleeps).
>
If I don't use the mouse for some time (I haven't clocked it, but it is
probably some 5 to 10 minutes), it goes into what I assume is sleep
mode, i.e., the cursor stops responding to mouse movements. It only
reconnects if I press a button, but it takes about 5 seconds for the
cursor to start tracking the mouse movements again. Switching the mouse
off, then on while it is connected has the same effect as bringing it
out of sleep mode: it takes 5 seconds to start working again. I haven't
tried switching it off, then on while it is asleep, to see if it makes
any difference (I don't have it here with me now, but I'll do this test
tonight).
Venu's suggestion of comparing the HCI dumps of reconnection under
Windows and Linux will probably shed more light onto this problem. By
the way, I had no luck googling for an hcidump equivalent for Windows.
Can anybody suggest one?
Regards,
Daniel
Hi Stefan,
Here is what happens with mouse,
1. When you use the mouse, they are in active mode, and after that they go
to sniff mode.
2. Now if continue not using mouse eventually it will disconnect (when it
disconnects depends on the sniff Interval, and sniff timeout).
3. When the mouse transitions to Sniff Mode from Active mode one would see
Mode change event along with Sniff Parameters which i told you about.
4. Now only after disconnect will you observe that the hid reconnects.
Please read section 8.7 in baseband specification of Bluetooth specs which
will throw more light into question which you are posing i.e. if you have
access to it.
Or else I can share it with you.
Cheers,
Venu
On Wed, Dec 23, 2009 at 9:18 PM, Stefan Seyfried <
[email protected]> wrote:
> On Fri, 18 Dec 2009 14:58:31 -0800
> Marcel Holtmann <[email protected]> wrote:
>
> > even if I use Bluetooth on a daily basis, I don't use any mouse or
> > keyboard devices anymore. So I have no idea on how many people are
> > actually using these.
>
> I'm still using it occasionally at home (when not sitting on the sofa
> with my notebook ;) and for the last few years they worked fine
> (actually since we worked out the reconnect problem of the
> Logitech mx1000, which looked similar, but probably was not).
>
> My collection of two bluetooth mice still work fine and reconnect
> quickly IIRC, but I will check this evening.
>
> David, "every time I bring the mouse out of sleep mode", does this mean
> the mouse went to sleep, you click the button (or move the mouse) and
> it takes 5 seconds to reconnect? If so, could you try if it makes a
> difference if you switch off the mouse instead? (wait until it falls
> asleep, then switch off and on and check if it reconnects faster. Might
> not be easy if this is a mouse that wakes up on movement, then you
> probably need to lay it upside down until it sleeps).
>
> > wouldn't be of much help until I am back at home and have my device
> > library at my disposal (and bought new batteries).
>
> I can recommend eneloop rechargeables for BT HID devices ;)
> --
> Stefan Seyfried
>
> "Any ideas, John?"
> "Well, surrounding them's out."
> --
> To unsubscribe from this list: send the line "unsubscribe linux-bluetooth"
> in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
- J. Venumadhav
On Fri, 18 Dec 2009 14:58:31 -0800
Marcel Holtmann <[email protected]> wrote:
> even if I use Bluetooth on a daily basis, I don't use any mouse or
> keyboard devices anymore. So I have no idea on how many people are
> actually using these.
I'm still using it occasionally at home (when not sitting on the sofa
with my notebook ;) and for the last few years they worked fine
(actually since we worked out the reconnect problem of the
Logitech mx1000, which looked similar, but probably was not).
My collection of two bluetooth mice still work fine and reconnect
quickly IIRC, but I will check this evening.
David, "every time I bring the mouse out of sleep mode", does this mean
the mouse went to sleep, you click the button (or move the mouse) and
it takes 5 seconds to reconnect? If so, could you try if it makes a
difference if you switch off the mouse instead? (wait until it falls
asleep, then switch off and on and check if it reconnects faster. Might
not be easy if this is a mouse that wakes up on movement, then you
probably need to lay it upside down until it sleeps).
> wouldn't be of much help until I am back at home and have my device
> library at my disposal (and bought new batteries).
I can recommend eneloop rechargeables for BT HID devices ;)
--
Stefan Seyfried
"Any ideas, John?"
"Well, surrounding them's out."
Sorry, Thunderbird is not handling the line breaks correctly. Here goes
the hcidump again, hopefully correctly formatted this time.
HCI sniffer - Bluetooth packet analyzer ver 1.42
device: hci0 snap_len: 1028 filter: 0xffffffff
1261183973.054875 > HCI Event: Connect Request (0x04) plen 10
1261183973.054911 < HCI Command: Accept Connection Request (0x01|0x0009)
plen 7
1261183973.062868 > HCI Event: Command Status (0x0f) plen 4
1261183973.255871 > HCI Event: Role Change (0x12) plen 8
1261183973.349870 > HCI Event: Connect Complete (0x03) plen 11
1261183973.349892 < HCI Command: Read Remote Supported Features
(0x01|0x001b) plen 2
1261183973.351861 > HCI Event: Page Scan Repetition Mode Change (0x20)
plen 7
1261183973.351870 > ACL data: handle 42 flags 0x02 dlen 12
L2CAP(s): Connect req: psm 17 scid 0x0060
1261183973.351932 < ACL data: handle 42 flags 0x02 dlen 16
L2CAP(s): Connect rsp: dcid 0x0040 scid 0x0060 result 1 status 0
Connection pending - No futher information available
1261183973.351937 < ACL data: handle 42 flags 0x02 dlen 10
L2CAP(s): Info req: type 2
1261183973.358863 > HCI Event: Number of Completed Packets (0x13) plen 5
1261183973.361860 > HCI Event: Number of Completed Packets (0x13) plen 5
1261183973.363865 > HCI Event: Command Status (0x0f) plen 4
1261183973.363881 < HCI Command: Remote Name Request (0x01|0x0019) plen 10
1261183973.373864 > HCI Event: Read Remote Supported Features (0x0b)
plen 11
1261183973.375857 > HCI Event: Command Status (0x0f) plen 4
1261183973.443867 > HCI Event: Remote Name Req Complete (0x07) plen 255
1261183977.351019 < ACL data: handle 42 flags 0x02 dlen 16
L2CAP(s): Connect rsp: dcid 0x0040 scid 0x0060 result 0 status 0
Connection successful
[...]
Hi everybody:
Following Marcel's hint, I used hcidump while the Bluetooth mouse was
reconnecting and got the results below (here I pasted the dump just up
to the point where the connection is established).
Could somebody take a quick look and say why there is a 4 second delay
between the last two lines? Is bluez receiving the mouse name during
that time? If that's what's causing the delay, is there a configuration
option to disable requesting the name of a device whose name is already
known because it was previously connected and is now just coming out of
sleep mode?
I downloaded and looked into bluez source code, but it would take me
weeks to begin to understand it. If anyone can give me a hint, I'd
really appreciate it.
Regards,
Daniel
HCI sniffer - Bluetooth packet analyzer ver 1.42
device: hci0 snap_len: 1028 filter: 0xffffffff
1261183973.054875 > HCI Event: Connect Request (0x04) plen 10
1261183973.054911 < HCI Command: Accept Connection Request (0x01|0x0009)
plen 7
1261183973.062868 > HCI Event: Command Status (0x0f) plen
4
1261183973.255871 > HCI Event: Role Change (0x12) plen
8
1261183973.349870 > HCI Event: Connect Complete (0x03) plen
11
1261183973.349892 < HCI Command: Read Remote Supported Features
(0x01|0x001b) plen
2
1261183973.351861 > HCI Event: Page Scan Repetition Mode Change (0x20)
plen 7
1261183973.351870 > ACL data: handle 42 flags 0x02 dlen
12
L2CAP(s): Connect req: psm 17 scid
0x0060
1261183973.351932 < ACL data: handle 42 flags 0x02 dlen
16
L2CAP(s): Connect rsp: dcid 0x0040 scid 0x0060 result 1 status
0
Connection pending - No futher information
available
1261183973.351937 < ACL data: handle 42 flags 0x02 dlen
10
L2CAP(s): Info req: type
2
1261183973.358863 > HCI Event: Number of Completed Packets (0x13) plen
5
1261183973.361860 > HCI Event: Number of Completed Packets (0x13) plen
5
1261183973.363865 > HCI Event: Command Status (0x0f) plen
4
1261183973.363881 < HCI Command: Remote Name Request (0x01|0x0019) plen 10
1261183973.373864 > HCI Event: Read Remote Supported Features (0x0b) plen 11
1261183973.375857 > HCI Event: Command Status (0x0f) plen
4
1261183973.443867 > HCI Event: Remote Name Req Complete (0x07) plen
255
1261183977.351019 < ACL data: handle 42 flags 0x02 dlen
16
L2CAP(s): Connect rsp: dcid 0x0040 scid 0x0060 result 0 status
0
Connection successful
[...]
Hi Marcel:
> even if I use Bluetooth on a daily basis, I don't use any mouse or
> keyboard devices anymore. So I have no idea on how many people are
> actually using these.
I'm getting the impression they are not very popular! To me it seemed like a
clear advantage to use a mouse with my notebook's built-in bluetooth module
without needing a dongle.
> I used to travel with a lot of HID devices to just
> be able to test and verify things, but I don't do that anymore. So I
> wouldn't be of much help until I am back at home and have my device
> library at my disposal (and bought new batteries).
O.k., if you find the time to look into this, I installed hcidump (didn't know
about it until you mentioned it), and here's the output with the "-t" flag (any
others I should use?) during a mouse reconnection:
HCI sniffer - Bluetooth packet analyzer ver 1.42
device: hci0 snap_len: 1028 filter: 0xffffffff
1261183973.054875 > HCI Event: Connect Request (0x04) plen 10
1261183973.054911 < HCI Command: Accept Connection Request (0x01|0x0009) plen 7
1261183973.062868 > HCI Event: Command Status (0x0f) plen 4
1261183973.255871 > HCI Event: Role Change (0x12) plen 8
1261183973.349870 > HCI Event: Connect Complete (0x03) plen 11
1261183973.349892 < HCI Command: Read Remote Supported Features (0x01|0x001b)
plen 2
1261183973.351861 > HCI Event: Page Scan Repetition Mode Change (0x20) plen 7
1261183973.351870 > ACL data: handle 42 flags 0x02 dlen 12
L2CAP(s): Connect req: psm 17 scid 0x0060
1261183973.351932 < ACL data: handle 42 flags 0x02 dlen 16
L2CAP(s): Connect rsp: dcid 0x0040 scid 0x0060 result 1 status 0
Connection pending - No futher information available
1261183973.351937 < ACL data: handle 42 flags 0x02 dlen 10
L2CAP(s): Info req: type 2
1261183973.358863 > HCI Event: Number of Completed Packets (0x13) plen 5
1261183973.361860 > HCI Event: Number of Completed Packets (0x13) plen 5
1261183973.363865 > HCI Event: Command Status (0x0f) plen 4
1261183973.363881 < HCI Command: Remote Name Request (0x01|0x0019) plen 10
1261183973.373864 > HCI Event: Read Remote Supported Features (0x0b) plen 11
1261183973.375857 > HCI Event: Command Status (0x0f) plen 4
1261183973.443867 > HCI Event: Remote Name Req Complete (0x07) plen 255
1261183977.351019 < ACL data: handle 42 flags 0x02 dlen 16
L2CAP(s): Connect rsp: dcid 0x0040 scid 0x0060 result 0 status 0
Connection successful
1261183977.361870 > HCI Event: Number of Completed Packets (0x13) plen 5
1261183977.383875 > ACL data: handle 42 flags 0x02 dlen 16
L2CAP(s): Config req: dcid 0x0040 flags 0x00 clen 4
MTU 133
1261183977.383896 < ACL data: handle 42 flags 0x02 dlen 18
L2CAP(s): Config rsp: scid 0x0060 flags 0x00 result 0 clen 4
MTU 133
1261183977.383901 < ACL data: handle 42 flags 0x02 dlen 12
L2CAP(s): Config req: dcid 0x0060 flags 0x00 clen 0
1261183977.391870 > HCI Event: Number of Completed Packets (0x13) plen 5
1261183977.393868 > HCI Event: Number of Completed Packets (0x13) plen 5
1261183977.403870 > ACL data: handle 42 flags 0x02 dlen 17
1261183977.405872 > ACL data: handle 42 flags 0x01 dlen 1
L2CAP(s): Config rsp: scid 0x0040 flags 0x00 result 0 clen 4
MTU 133
1261183977.407872 > ACL data: handle 42 flags 0x02 dlen 12
L2CAP(s): Connect req: psm 19 scid 0x0061
1261183977.407895 < ACL data: handle 42 flags 0x02 dlen 16
L2CAP(s): Connect rsp: dcid 0x0041 scid 0x0061 result 1 status 2
Connection pending - Authorization pending
1261183977.408042 < ACL data: handle 42 flags 0x02 dlen 16
L2CAP(s): Connect rsp: dcid 0x0041 scid 0x0061 result 0 status 0
Connection successful
1261183977.413868 > HCI Event: Number of Completed Packets (0x13) plen 5
1261183977.415868 > HCI Event: Number of Completed Packets (0x13) plen 5
1261183977.437867 > ACL data: handle 42 flags 0x02 dlen 16
L2CAP(s): Config req: dcid 0x0041 flags 0x00 clen 4
MTU 133
1261183977.437892 < ACL data: handle 42 flags 0x02 dlen 18
L2CAP(s): Config rsp: scid 0x0061 flags 0x00 result 0 clen 4
MTU 133
1261183977.437898 < ACL data: handle 42 flags 0x02 dlen 12
L2CAP(s): Config req: dcid 0x0061 flags 0x00 clen 0
1261183977.443870 > HCI Event: Number of Completed Packets (0x13) plen 5
1261183977.445866 > HCI Event: Number of Completed Packets (0x13) plen 5
1261183977.459875 > ACL data: handle 42 flags 0x02 dlen 18
L2CAP(s): Config rsp: scid 0x0041 flags 0x00 result 0 clen 4
MTU 133
1261183977.461865 > ACL data: handle 42 flags 0x02 dlen 14
L2CAP(d): cid 0x0041 len 10 [psm 19]
HIDP: Data: Input report
1261183977.464114 < ACL data: handle 42 flags 0x02 dlen 11
L2CAP(d): cid 0x0061 len 7 [psm 19]
HIDP: Data: Output report
1261183977.464180 < ACL data: handle 42 flags 0x02 dlen 7
L2CAP(d): cid 0x0061 len 3 [psm 19]
HIDP: Data: Output report
1261183977.464223 < ACL data: handle 42 flags 0x02 dlen 7
L2CAP(d): cid 0x0061 len 3 [psm 19]
HIDP: Data: Output report
1261183977.464294 < ACL data: handle 42 flags 0x02 dlen 14
L2CAP(d): cid 0x0061 len 10 [psm 19]
HIDP: Data: Output report
1261183977.464335 < ACL data: handle 42 flags 0x02 dlen 8
L2CAP(d): cid 0x0061 len 4 [psm 19]
HIDP: Data: Output report
1261183977.464375 < ACL data: handle 42 flags 0x02 dlen 11
L2CAP(d): cid 0x0061 len 7 [psm 19]
HIDP: Data: Output report
1261183977.464416 < ACL data: handle 42 flags 0x02 dlen 7
L2CAP(d): cid 0x0061 len 3 [psm 19]
HIDP: Data: Output report
1261183977.464455 < ACL data: handle 42 flags 0x02 dlen 14
L2CAP(d): cid 0x0061 len 10 [psm 19]
HIDP: Data: Output report
1261183977.466860 > HCI Event: QoS Setup Complete (0x0d) plen 21
1261183977.471858 > HCI Event: Number of Completed Packets (0x13) plen 5
1261183977.473858 > HCI Event: Number of Completed Packets (0x13) plen 5
1261183977.476859 > HCI Event: Number of Completed Packets (0x13) plen 5
1261183977.478862 > HCI Event: Number of Completed Packets (0x13) plen 5
1261183977.480857 > HCI Event: Number of Completed Packets (0x13) plen 5
1261183977.484866 > HCI Event: Mode Change (0x14) plen 6
1261183977.487865 > ACL data: handle 42 flags 0x02 dlen 11
L2CAP(d): cid 0x0041 len 7 [psm 19]
HIDP: Data: Input report
1261183977.697866 > ACL data: handle 42 flags 0x02 dlen 11
L2CAP(d): cid 0x0041 len 7 [psm 19]
HIDP: Data: Input report
This is all Greek to me. The whole process took 4.6 seconds (a little less than
the 5-6 seconds I had estimated without actually clocking it, but still
significantly longer than under Windows XP, where the mouse connects in under
one second every time). Most of the delay takes place between the "Remote Name
Req Complete" and reception of the next ACL data. Does that tell you
something?
As far as logs go, during reconnection the only lines that were logged into
/var/log/messages were (any other log files I should check?):
Dec 18 22:52:57 photon kernel: input: Targus Bluetooth Media Mouse for Notebook
as
/devices/pci0000:00/0000:00:1d.1/usb3/3-1/3-1:1.0/bluetooth/hci0/hci0:42/input14
Dec 18 22:52:57 photon kernel: generic-bluetooth 0005:0461:4B01.0004:
input,hidraw0: BLUETOOTH HID v1.08 Mouse [Targus Bluetooth Media Mouse for
Notebook] on 00:18:F3:8C:F7:73
Regards,
Daniel
Hi Daniel,
> Thanks so much for replying! It seems a little humor helped to get someone's
> attention, even though I'm not sure you fully appreciated it :-)
>
> > you do know that an open source community doesn't work like this.
>
> As I mentioned in my second post, I have interacted and made small contributions
> of code to the open source community several times in the past, and my
> experience this time around was atypical because I was having a hard time just
> getting someone to reply!
>
> > If someone would be able to make anything out of your posting or has
> > experienced the same, they would have spoken.
>
> Was it unreasonable to expect that someone would say: "Nobody is experiencing
> this kind of delay, maybe it's something in your setup"? Or even, "this is not
> the right forum for non-developers to ask for help, why don't you try such and
> such place?"
even if I use Bluetooth on a daily basis, I don't use any mouse or
keyboard devices anymore. So I have no idea on how many people are
actually using these. I used to travel with a lot of HID devices to just
be able to test and verify things, but I don't do that anymore. So I
wouldn't be of much help until I am back at home and have my device
library at my disposal (and bought new batteries).
Regards
Marcel
Hi Marcel:
Thanks so much for replying! It seems a little humor helped to get someone's
attention, even though I'm not sure you fully appreciated it :-)
> you do know that an open source community doesn't work like this.
As I mentioned in my second post, I have interacted and made small contributions
of code to the open source community several times in the past, and my
experience this time around was atypical because I was having a hard time just
getting someone to reply!
> If someone would be able to make anything out of your posting or has
> experienced the same, they would have spoken.
Was it unreasonable to expect that someone would say: "Nobody is experiencing
this kind of delay, maybe it's something in your setup"? Or even, "this is not
the right forum for non-developers to ask for help, why don't you try such and
such place?"
> Since you didn't even
> include any logs or hcidump details, you didn't even gave any person
> without the hardware to respond.
As I also made clear, I am not a developer, and I didn't know what kind of
information would be useful. I didn't want to post a long message with
information that might be irrelevant. I did ask in my first post what kind of
information I should provide to help diagnose the problem.
Sometimes one's attitude doesn't come accross as intended in e-mails. My tirade
about The Sixth Sense was meant to express amusement, and not resentment, at
the situation. I was sincere in my wishes to the bluez community of developers.
Without you folks there would be no bluetooth for Linux at all, and appreciate
your work.
Regards,
Daniel
Hi Daniel,
> Unbelievable! Here too my posts get zero replies!
>
> I fell like Bruce Willis in "The Sixth Sense". Maybe I died and just
> haven't realized it yet! Where is that kid that talks to the dead? Maybe
> he knows something about bluetooth mouse reconnection delays.
>
> But, seriously, I guess I'll just have to give up using my bluetooth
> mouse under Linux. Waiting 5 to 6 seconds for the mouse to reconnect
> every time it goes to sleep is too much of a nuisance!
>
> If anybody can read me, good luck with your work developing bluez and
> happy Holidays to all.
you do know that an open source community doesn't work like this. If
someone would be able to make anything out of your posting or has
experienced the same, they would have spoken. Since you didn't even
include any logs or hcidump details, you didn't even gave any person
without the hardware to respond.
Regards
Marcel
Unbelievable! Here too my posts get zero replies!
I fell like Bruce Willis in "The Sixth Sense". Maybe I died and just
haven't realized it yet! Where is that kid that talks to the dead? Maybe
he knows something about bluetooth mouse reconnection delays.
But, seriously, I guess I'll just have to give up using my bluetooth
mouse under Linux. Waiting 5 to 6 seconds for the mouse to reconnect
every time it goes to sleep is too much of a nuisance!
If anybody can read me, good luck with your work developing bluez and
happy Holidays to all.
Daniel
Not a single reply two days later! It seems nobody is interested in this
subject here or in the Ubuntu and sidux forums. Do so few people
actually use bluetooth mice? Folks, I'm starting to feel ignored!
I've been a Linux user for more than 15 years. I know nothing about the
bluetooth protocol and I'm not a developer, but over the years I have
made small contributions to the Open Sound System code, a couple of Gnu
applications and other open-source software. Never before have I
experienced such difficulty in finding someone with whom to discuss a
Linux-related issue as now with this problem of the bluetooth mouse
reconnection delay!
I'm sorry if this kind of discussion is not appropriate for this mailing
list. If so, will somebody please be kind enough to suggest a forum
where I could ask if there are any bluez configuration options I could
try out to speed up the mouse reconnection when it comes out of sleep
mode. As I mentioned in my first post, this same mouse reconnects very
fast when I boot my notebook under Windows XP, and I want to try to
achieve the same kind of performance under Linux.
Somebody please talk to me! :-)
Daniel
On Mon, 04 Jan 2010 16:48:54 -0200
"Daniel T. Cobra" <[email protected]> wrote:
> Hi Stefan:
>
> I'm back from the holidays.
>
> Since I was not able to find a free hcidump equivalent for Windows, I
> think we could at least compare the dumps for your mouse and mine, as
> you suggested. Could you please post yours (with timestamps)?
Sure. Here it is. I have put the mouse away at 11:21:27.262588 and
clicked on it at ~ 11:36:50.
HCI sniffer - Bluetooth packet analyzer ver 1.42
device: hci0 snap_len: 1028 filter: 0xffffffff
2010-01-05 11:21:24.021089 > ACL data: handle 11 flags 0x02 dlen 10
L2CAP(d): cid 0x0041 len 6 [psm 0]
0000: a1 02 00 ed 05 00 ......
2010-01-05 11:21:24.140076 > ACL data: handle 11 flags 0x02 dlen 10
L2CAP(d): cid 0x0041 len 6 [psm 0]
0000: a1 02 00 e6 06 00 ......
2010-01-05 11:21:24.141054 > ACL data: handle 11 flags 0x02 dlen 10
L2CAP(d): cid 0x0041 len 6 [psm 0]
0000: a1 02 00 f0 03 00 ......
2010-01-05 11:21:24.143056 > HCI Event: Mode Change (0x14) plen 6
status 0x00 handle 11 mode 0x00 interval 0
Mode: Active
2010-01-05 11:21:24.174052 > HCI Event: Mode Change (0x14) plen 6
status 0x00 handle 11 mode 0x02 interval 20
Mode: Sniff
2010-01-05 11:21:27.125620 > ACL data: handle 11 flags 0x02 dlen 10
L2CAP(d): cid 0x0041 len 6 [psm 0]
0000: a1 02 00 47 f9 00 ...G..
2010-01-05 11:21:27.127603 > ACL data: handle 11 flags 0x02 dlen 10
L2CAP(d): cid 0x0041 len 6 [psm 0]
0000: a1 02 00 00 ff 00 ......
2010-01-05 11:21:27.225596 > ACL data: handle 11 flags 0x02 dlen 10
L2CAP(d): cid 0x0041 len 6 [psm 0]
0000: a1 02 00 01 00 00 ......
2010-01-05 11:21:27.250605 > ACL data: handle 11 flags 0x02 dlen 10
L2CAP(d): cid 0x0041 len 6 [psm 0]
0000: a1 02 00 ff 00 00 ......
2010-01-05 11:21:27.262588 > ACL data: handle 11 flags 0x02 dlen 10
L2CAP(d): cid 0x0041 len 6 [psm 0]
0000: a1 02 00 01 00 00 ......
2010-01-05 11:21:37.289076 > HCI Event: Mode Change (0x14) plen 6
status 0x00 handle 11 mode 0x00 interval 0
Mode: Active
2010-01-05 11:21:37.320067 > HCI Event: Mode Change (0x14) plen 6
status 0x00 handle 11 mode 0x02 interval 96
Mode: Sniff
2010-01-05 11:31:37.161200 > ACL data: handle 11 flags 0x02 dlen 12
L2CAP(s): Disconn req: dcid 0x0040 scid 0x0040
2010-01-05 11:31:37.161265 < ACL data: handle 11 flags 0x02 dlen 12
L2CAP(s): Disconn rsp: dcid 0x0040 scid 0x0040
2010-01-05 11:31:37.162087 < ACL data: handle 11 flags 0x02 dlen 12
L2CAP(s): Disconn req: dcid 0x0041 scid 0x0041
2010-01-05 11:31:37.221188 > ACL data: handle 11 flags 0x02 dlen 12
L2CAP(s): Disconn req: dcid 0x0041 scid 0x0041
2010-01-05 11:31:37.221261 < ACL data: handle 11 flags 0x02 dlen 12
L2CAP(s): Disconn rsp: dcid 0x0041 scid 0x0041
2010-01-05 11:31:37.340173 > ACL data: handle 11 flags 0x02 dlen 12
L2CAP(s): Disconn rsp: dcid 0x0041 scid 0x0041
2010-01-05 11:31:37.521139 > HCI Event: Mode Change (0x14) plen 6
status 0x00 handle 11 mode 0x00 interval 0
Mode: Active
2010-01-05 11:31:37.538121 > HCI Event: Number of Completed Packets (0x13) plen 5
handle 11 packets 3
2010-01-05 11:31:37.651115 > HCI Event: Disconn Complete (0x05) plen 4
status 0x00 handle 11 reason 0x16
Reason: Connection Terminated by Local Host
2010-01-05 11:36:50.103021 > HCI Event: Connect Request (0x04) plen 10
bdaddr 00:0F:F6:60:44:0B class 0x002580 type ACL
2010-01-05 11:36:50.103084 < HCI Command: Accept Connection Request (0x01|0x0009) plen 7
bdaddr 00:0F:F6:60:44:0B role 0x00
Role: Master
2010-01-05 11:36:50.107013 > HCI Event: Command Status (0x0f) plen 4
Accept Connection Request (0x01|0x0009) status 0x00 ncmd 1
2010-01-05 11:36:50.278988 > HCI Event: Role Change (0x12) plen 8
status 0x35 bdaddr 00:0F:F6:60:44:0B role 0x01
Error: Role Switch Failed
2010-01-05 11:36:50.342981 > HCI Event: Connect Complete (0x03) plen 11
status 0x00 handle 11 bdaddr 00:0F:F6:60:44:0B type ACL encrypt 0x00
2010-01-05 11:36:50.343061 < HCI Command: Read Remote Supported Features (0x01|0x001b) plen 2
handle 11
2010-01-05 11:36:50.346967 > HCI Event: Command Status (0x0f) plen 4
Read Remote Supported Features (0x01|0x001b) status 0x00 ncmd 1
2010-01-05 11:36:50.348966 > HCI Event: Read Remote Supported Features (0x0b) plen 11
status 0x00 handle 11
Features: 0xbc 0x02 0x04 0x38 0x08 0x00 0x00 0x00
2010-01-05 11:36:50.362865 < HCI Command: Remote Name Request (0x01|0x0019) plen 10
bdaddr 00:0F:F6:60:44:0B mode 2 clkoffset 0x0000
2010-01-05 11:36:50.364963 > HCI Event: Command Status (0x0f) plen 4
Remote Name Request (0x01|0x0019) status 0x00 ncmd 1
2010-01-05 11:36:50.671937 > HCI Event: Role Change (0x12) plen 8
status 0x35 bdaddr 00:0F:F6:60:44:0B role 0x01
Error: Role Switch Failed
2010-01-05 11:36:50.773903 > HCI Event: Remote Name Req Complete (0x07) plen 255
status 0x00 bdaddr 00:0F:F6:60:44:0B name 'Acer Bluetooth Wireless Mouse'
2010-01-05 11:36:51.503812 > HCI Event: Role Change (0x12) plen 8
status 0x00 bdaddr 00:0F:F6:60:44:0B role 0x00
Role: Master
2010-01-05 11:36:51.517810 > ACL data: handle 11 flags 0x02 dlen 12
L2CAP(s): Connect req: psm 17 scid 0x0042
2010-01-05 11:36:51.517868 < ACL data: handle 11 flags 0x02 dlen 16
L2CAP(s): Connect rsp: dcid 0x0040 scid 0x0042 result 1 status 0
Connection pending - No futher information available
2010-01-05 11:36:51.517876 < ACL data: handle 11 flags 0x02 dlen 10
L2CAP(s): Info req: type 2
2010-01-05 11:36:51.525808 > ACL data: handle 11 flags 0x02 dlen 16
L2CAP(s): Info rsp: type 2 result 0
Extended feature mask 0x0004
Bi-directional QoS
2010-01-05 11:36:51.525853 < ACL data: handle 11 flags 0x02 dlen 16
L2CAP(s): Connect rsp: dcid 0x0040 scid 0x0042 result 0 status 0
Connection successful
2010-01-05 11:36:51.530806 > ACL data: handle 11 flags 0x02 dlen 16
L2CAP(s): Config req: dcid 0x0040 flags 0x00 clen 4
MTU 185
2010-01-05 11:36:51.530854 < ACL data: handle 11 flags 0x02 dlen 18
L2CAP(s): Config rsp: scid 0x0042 flags 0x00 result 0 clen 4
MTU 185
2010-01-05 11:36:51.530861 < ACL data: handle 11 flags 0x02 dlen 12
L2CAP(s): Config req: dcid 0x0042 flags 0x00 clen 0
2010-01-05 11:36:51.534794 > HCI Event: Number of Completed Packets (0x13) plen 5
handle 11 packets 4
2010-01-05 11:36:51.537805 > ACL data: handle 11 flags 0x02 dlen 18
L2CAP(s): Config rsp: scid 0x0040 flags 0x00 result 0 clen 4
MTU 185
2010-01-05 11:36:51.538802 > ACL data: handle 11 flags 0x02 dlen 12
L2CAP(s): Connect req: psm 19 scid 0x0043
2010-01-05 11:36:51.538852 < ACL data: handle 11 flags 0x02 dlen 16
L2CAP(s): Connect rsp: dcid 0x0041 scid 0x0043 result 1 status 2
Connection pending - Authorization pending
2010-01-05 11:36:51.539104 < ACL data: handle 11 flags 0x02 dlen 16
L2CAP(s): Connect rsp: dcid 0x0041 scid 0x0043 result 0 status 0
Connection successful
2010-01-05 11:36:51.546803 > ACL data: handle 11 flags 0x02 dlen 16
L2CAP(s): Config req: dcid 0x0041 flags 0x00 clen 4
MTU 185
2010-01-05 11:36:51.546849 < ACL data: handle 11 flags 0x02 dlen 18
L2CAP(s): Config rsp: scid 0x0043 flags 0x00 result 0 clen 4
MTU 185
2010-01-05 11:36:51.546856 < ACL data: handle 11 flags 0x02 dlen 12
L2CAP(s): Config req: dcid 0x0043 flags 0x00 clen 0
2010-01-05 11:36:51.557793 > HCI Event: Number of Completed Packets (0x13) plen 5
handle 11 packets 4
2010-01-05 11:36:51.562794 > ACL data: handle 11 flags 0x02 dlen 18
L2CAP(s): Config rsp: scid 0x0041 flags 0x00 result 0 clen 4
MTU 185
2010-01-05 11:36:51.566781 > HCI Event: QoS Setup Complete (0x0d) plen 21
status 0x00 handle 11 flags 0
Service type: 1
Token rate: 850
Peak bandwith: 0
Latency: 20000
Delay variation: -1
2010-01-05 11:36:51.568787 > ACL data: handle 11 flags 0x02 dlen 10
L2CAP(d): cid 0x0041 len 6 [psm 19]
HIDP: Data: Input report
0000: 02 01 00 00 00 .....
2010-01-05 11:36:51.574819 > ACL data: handle 11 flags 0x02 dlen 10
L2CAP(d): cid 0x0041 len 6 [psm 19]
HIDP: Data: Input report
0000: 02 00 00 00 00 .....
2010-01-05 11:36:51.575497 < ACL data: handle 11 flags 0x02 dlen 10
L2CAP(d): cid 0x0043 len 6 [psm 19]
HIDP: Data: Output report
0000: 02 00 00 00 00 .....
2010-01-05 11:36:51.575514 < ACL data: handle 11 flags 0x02 dlen 7
L2CAP(d): cid 0x0043 len 3 [psm 19]
HIDP: Data: Output report
0000: 03 00 ..
2010-01-05 11:36:51.581799 > ACL data: handle 11 flags 0x02 dlen 5
L2CAP(d): cid 0x0041 len 1 [psm 19]
HIDP: Handshake: Unsupported request
2010-01-05 11:36:51.583790 > ACL data: handle 11 flags 0x02 dlen 5
L2CAP(d): cid 0x0041 len 1 [psm 19]
HIDP: Handshake: Unsupported request
2010-01-05 11:36:51.594788 > HCI Event: Mode Change (0x14) plen 6
status 0x00 handle 11 mode 0x02 interval 20
Mode: Sniff
2010-01-05 11:36:51.788764 > HCI Event: Number of Completed Packets (0x13) plen 5
handle 11 packets 3
--
Stefan Seyfried
"Any ideas, John?"
"Well, surrounding them's out."
Hi Stefan:
I'm back from the holidays.
Since I was not able to find a free hcidump equivalent for Windows, I
think we could at least compare the dumps for your mouse and mine, as
you suggested. Could you please post yours (with timestamps)?
Regards,
Daniel
Iain:
> Unless you bought the dongle and mouse together as a pair though, it is
> unlikely that the dongle can operate in HID mode..
>
Yes. I didn't know much about HIDP. Looking further into it, it became
clear it doesn't apply in this case.
O.k., time to close this thread. Sorry to have bothered you guys with a
problem that turned out to be a non-compliant device.
Many thanks to Marcel and all the others for trying to help and for all
your work on bluez!
Goodbye,
Daniel
On Thu, 4 Feb 2010, Daniel T. Cobra wrote:
> One last question, though: would this L2CAP timeout happen if I use the
> BT module in HIDP mode, if the module supports it? I tried to do a test
> by setting HID2HCI_ENABLED to 0 in /etc/default/bluetooth (I'm using
> Debian), but I get this message from /etc/init.d/bluetooth saying this
> is deprecated and I should use a udev rule for that, so I'd have to look
> further into it to find out how to do it.
>From what I understand of your request, no this L2CAP timeout would
probably not happen in that case. If you could switch the dongle into HID
mode then the Bluetooth protocol stack in use would be entirely inside the
dongle (and probably not send Info requests) and the Linux kernel would
only see a USB Mouse.
Unless you bought the dongle and mouse together as a pair though, it is
unlikely that the dongle can operate in HID mode..
regards,
iain
Iain:
> I think the mouse is non-compliant, as the L2CAP Information request has
> been present since at least 1.1 of the specification which says that a
> valid response should be sent.
>
> Sending such a request is optional however, and probably the people who
> wrote that mouse stack never tested it against anything that sent one.
> Even if it didn't understand it, it should reply with a "command not
> understood" message..
>
O.k., from what you say, this is a quirk of this particular mouse model
and it is not justifiable to change bluez in any way to fix it. If this
had become clear earlier on, I wouldn't even have wasted you guys' time
with this problem!
One last question, though: would this L2CAP timeout happen if I use the
BT module in HIDP mode, if the module supports it? I tried to do a test
by setting HID2HCI_ENABLED to 0 in /etc/default/bluetooth (I'm using
Debian), but I get this message from /etc/init.d/bluetooth saying this
is deprecated and I should use a udev rule for that, so I'd have to look
further into it to find out how to do it.
Regards,
Daniel
On Wed, 3 Feb 2010, Daniel T. Cobra wrote:
> Basically, do you think the failure to reply to the L2CAP information
> request is a non-compliance to the protocol on the part of this
> particular mouse model, or does it implement an older version of the
> protocol, or something like that? (The delay does not happen under MS
> Windows, if it means anything.)
I think the mouse is non-compliant, as the L2CAP Information request has
been present since at least 1.1 of the specification which says that a
valid response should be sent.
Sending such a request is optional however, and probably the people who
wrote that mouse stack never tested it against anything that sent one.
Even if it didn't understand it, it should reply with a "command not
understood" message..
> From the hci dump, it seems the mouse replies to the HCI Read Remote
> Supported Features:
that is unrelated
regards,
iain
Hi Marcel:
> that is the wrong place. You need to look into net/bluetooth/l2cap.c.
> The LMP features are mandatory at all costs. Otherwise hell breaks loose
> if you don't do the right.
I looked into l2cap.c but I'd need to know the protocol better to make
sense of what's going on in there.
Basically, do you think the failure to reply to the L2CAP information
request is a non-compliance to the protocol on the part of this
particular mouse model, or does it implement an older version of the
protocol, or something like that? (The delay does not happen under MS
Windows, if it means anything.)
From the hci dump, it seems the mouse replies to the HCI Read Remote
Supported Features:
2010-01-08 00:15:03.144090 > HCI Event: Command Status (0x0f) plen 4
Read Remote Supported Features (0x01|0x001b) status 0x00 ncmd 1
2010-01-08 00:15:03.144103 < HCI Command: Remote Name Request
(0x01|0x0019) plen 10
bdaddr 00:16:38:E2:A5:57 mode 2 clkoffset 0x0000
2010-01-08 00:15:03.146089 > HCI Event: Number of Completed Packets
(0x13) plen 5
handle 42 packets 2
2010-01-08 00:15:03.149092 > HCI Event: Read Remote Supported Features
(0x0b) plen 11
status 0x00 handle 42
Features: 0xbc 0x02 0x04 0x28 0x08 0x08 0x00 0x00
Is this unrelated to the L2CAP information request? Why would one work
and not the other? Perhaps one is related to the device's features and
the other to the connection's features?
In short, can anything be done to avoid this L2CAP timeout on the
information request (something that, in addition to solving my problem,
would result in a small improvement to bluez, in terms of device
compatibility), or should I just forget about it and get a new BT mouse?
What do you think?
Regards,
Daniel
Hi Daniel,
> Great! It is starting to make sense. Next, let me ask two questions:
>
> 1) You say the information request is needed, but do you mean it is
> needed at every reconnection with the device or, as Stefan suggested,
> would it make sense to request it only when the connection is first
> established and cache the result?
>
> 2) Is there a way to know that the device does not support extended
> features, to avoid sending a request that is going to time out without a
> reply? In net/bluetooth/hci_event.c I found this:
>
> 1171 if (conn->state == BT_CONFIG) {
> 1172 if (!ev->status && lmp_ssp_capable(hdev) &&
> 1173 lmp_ssp_capable(conn)) {
> 1174 struct
> hci_cp_read_remote_ext_features cp;
> 1175 cp.handle = ev->handle;
> 1176 cp.page = 0x01;
> 1177 hci_send_cmd(hdev,
> 1178 HCI_OP_READ_REMOTE_EXT_FEATURES,
> 1179 sizeof(cp),
> &cp);
> 1180 } else {
> 1181 conn->state = BT_CONNECTED;
> 1182 hci_proto_connect_cfm(conn, ev->status);
> 1183 hci_conn_put(conn);
> 1184 }
> 1185 }
>
> Is this the right place to look? It seems SSP capability is used as a
> test for whether to read the device's extended features. Is this really
> the best way, or could there be a more suitable indicator of whether the
> device supports extended features, thus avoiding the timeout?
that is the wrong place. You need to look into net/bluetooth/l2cap.c.
The LMP features are mandatory at all costs. Otherwise hell breaks loose
if you don't do the right.
Regards
Marcel
Thanks, Marcel:
Great! It is starting to make sense. Next, let me ask two questions:
1) You say the information request is needed, but do you mean it is
needed at every reconnection with the device or, as Stefan suggested,
would it make sense to request it only when the connection is first
established and cache the result?
2) Is there a way to know that the device does not support extended
features, to avoid sending a request that is going to time out without a
reply? In net/bluetooth/hci_event.c I found this:
1171 if (conn->state == BT_CONFIG) {
1172 if (!ev->status && lmp_ssp_capable(hdev) &&
1173 lmp_ssp_capable(conn)) {
1174 struct
hci_cp_read_remote_ext_features cp;
1175 cp.handle = ev->handle;
1176 cp.page = 0x01;
1177 hci_send_cmd(hdev,
1178 HCI_OP_READ_REMOTE_EXT_FEATURES,
1179 sizeof(cp),
&cp);
1180 } else {
1181 conn->state = BT_CONNECTED;
1182 hci_proto_connect_cfm(conn, ev->status);
1183 hci_conn_put(conn);
1184 }
1185 }
Is this the right place to look? It seems SSP capability is used as a
test for whether to read the device's extended features. Is this really
the best way, or could there be a more suitable indicator of whether the
device supports extended features, thus avoiding the timeout?
Regards,
Daniel
Hi Daniel,
> For me, this is going to be a shot in the dark, not being familiar with
> the Bluetooth protocol, but could one of you developers please say if
> any of what follows makes sense?
>
> Comparing the hci dumps from my mouse's reconnection and Stefan's, I am
> suspicious of the first line below:
>
> [...]
> 2010-01-08 00:15:03.136170 < ACL data: handle 42 flags 0x02 dlen 10
> L2CAP(s): Info req: type 2
> 2010-01-08 00:15:03.144090 > HCI Event: Command Status (0x0f) plen 4
> Read Remote Supported Features (0x01|0x001b) status 0x00 ncmd 1
I totally missed this command. Yes, you are on the right track. We have
a timeout for devices not responding to information request.
#define L2CAP_INFO_TIMEOUT (4000) /* 4 seconds */
Problem here is that information request is actually needed to determine
the features of the remote L2CAP stack.
Regards
Marcel
On Wed, 03 Feb 2010 09:44:36 -0200
"Daniel T. Cobra" <[email protected]> wrote:
> For me, this is going to be a shot in the dark, not being familiar with
> the Bluetooth protocol, but could one of you developers please say if
> any of what follows makes sense?
[Disclaimer: I'm neither a bluez develper, nor am I familiar with the
protocols etc ;)]
Yee, I think this makes sense. Maybe we can make bluez just cache the
data instead of re-requesting it at wakeup (I'm not sure if it should
do that actually, because the spec says so, or if the mouse just has a
broken implementation and we just should do it for convenience). After
all I don't expect the extended features to change all the time while
the mouse is asleep ;)
>
> Comparing the hci dumps from my mouse's reconnection and Stefan's, I am
> suspicious of the first line below:
>
> [...]
> 2010-01-08 00:15:03.136170 < ACL data: handle 42 flags 0x02 dlen 10
> L2CAP(s): Info req: type 2
> 2010-01-08 00:15:03.144090 > HCI Event: Command Status (0x0f) plen 4
> Read Remote Supported Features (0x01|0x001b) status 0x00 ncmd 1
> 2010-01-08 00:15:03.144103 < HCI Command: Remote Name Request
> (0x01|0x0019) plen 10
> bdaddr 00:16:38:E2:A5:57 mode 2 clkoffset 0x0000
> 2010-01-08 00:15:03.146089 > HCI Event: Number of Completed Packets
> (0x13) plen 5
> handle 42 packets 2
> 2010-01-08 00:15:03.149092 > HCI Event: Read Remote Supported Features
> (0x0b) plen 11
> status 0x00 handle 42
> Features: 0xbc 0x02 0x04 0x28 0x08 0x08 0x00 0x00
> 2010-01-08 00:15:03.155089 > HCI Event: Command Status (0x0f) plen 4
> Remote Name Request (0x01|0x0019) status 0x00 ncmd 1
> 2010-01-08 00:15:03.227093 > HCI Event: Remote Name Req Complete (0x07)
> plen 255
> status 0x00 bdaddr 00:16:38:E2:A5:57 name 'Targus Bluetooth Media
> Mouse for Notebook'
> 2010-01-08 00:15:07.135253 < ACL data: handle 42 flags 0x02 dlen 16
> L2CAP(s): Connect rsp: dcid 0x0040 scid 0x0042 result 0 status 0
> Connection successful
> [...]
>
> In Stefan's hci dump we have:
>
> [...]
> 2010-01-05 11:36:51.517876 < ACL data: handle 11 flags 0x02 dlen 10
> L2CAP(s): Info req: type 2
> 2010-01-05 11:36:51.525808 > ACL data: handle 11 flags 0x02 dlen 16
> L2CAP(s): Info rsp: type 2 result 0
> Extended feature mask 0x0004
> Bi-directional QoS
> 2010-01-05 11:36:51.525853 < ACL data: handle 11 flags 0x02 dlen 16
> L2CAP(s): Connect rsp: dcid 0x0040 scid 0x0042 result 0 status 0
> Connection successful
> [...]
>
> What is happening here? Is bluez making a request to read the device's
> extended features and Stefan's mouse replies while mine doesn't (and the
> 4 sec delay I experience is bluez waiting for the reply until it times out)?
>
> If it helps, here's the output of "hcitool info" for my mouse:
>
> Requesting information ...
> BD Address: 00:16:38:A2:C5:56
> Device Name: Targus Bluetooth Media Mouse for Notebook
> LMP Version: 1.1 (0x1) LMP Subversion: 0x100
> Manufacturer: Broadcom Corporation (15)
> Features: 0xbc 0x02 0x04 0x28 0x08 0x08 0x00 0x00
> <encryption> <slot offset> <timing accuracy> <role switch>
> <sniff mode> <RSSI> <power control> <enhanced iscan>
> <interlaced pscan> <AFH cap. slave> <AFH cap. master>
>
> So, am I going in the right direction or am I totally off the mark? I'd
> really appreciate some comment from you guys who know how this works.
I don't know how it works, but your conclusion seems logical to me.
Which, of course, says nothing about its correctness ;)
Have fun,
seife
--
Stefan Seyfried
"Any ideas, John?"
"Well, surrounding them's out."
For me, this is going to be a shot in the dark, not being familiar with
the Bluetooth protocol, but could one of you developers please say if
any of what follows makes sense?
Comparing the hci dumps from my mouse's reconnection and Stefan's, I am
suspicious of the first line below:
[...]
2010-01-08 00:15:03.136170 < ACL data: handle 42 flags 0x02 dlen 10
L2CAP(s): Info req: type 2
2010-01-08 00:15:03.144090 > HCI Event: Command Status (0x0f) plen 4
Read Remote Supported Features (0x01|0x001b) status 0x00 ncmd 1
2010-01-08 00:15:03.144103 < HCI Command: Remote Name Request
(0x01|0x0019) plen 10
bdaddr 00:16:38:E2:A5:57 mode 2 clkoffset 0x0000
2010-01-08 00:15:03.146089 > HCI Event: Number of Completed Packets
(0x13) plen 5
handle 42 packets 2
2010-01-08 00:15:03.149092 > HCI Event: Read Remote Supported Features
(0x0b) plen 11
status 0x00 handle 42
Features: 0xbc 0x02 0x04 0x28 0x08 0x08 0x00 0x00
2010-01-08 00:15:03.155089 > HCI Event: Command Status (0x0f) plen 4
Remote Name Request (0x01|0x0019) status 0x00 ncmd 1
2010-01-08 00:15:03.227093 > HCI Event: Remote Name Req Complete (0x07)
plen 255
status 0x00 bdaddr 00:16:38:E2:A5:57 name 'Targus Bluetooth Media
Mouse for Notebook'
2010-01-08 00:15:07.135253 < ACL data: handle 42 flags 0x02 dlen 16
L2CAP(s): Connect rsp: dcid 0x0040 scid 0x0042 result 0 status 0
Connection successful
[...]
In Stefan's hci dump we have:
[...]
2010-01-05 11:36:51.517876 < ACL data: handle 11 flags 0x02 dlen 10
L2CAP(s): Info req: type 2
2010-01-05 11:36:51.525808 > ACL data: handle 11 flags 0x02 dlen 16
L2CAP(s): Info rsp: type 2 result 0
Extended feature mask 0x0004
Bi-directional QoS
2010-01-05 11:36:51.525853 < ACL data: handle 11 flags 0x02 dlen 16
L2CAP(s): Connect rsp: dcid 0x0040 scid 0x0042 result 0 status 0
Connection successful
[...]
What is happening here? Is bluez making a request to read the device's
extended features and Stefan's mouse replies while mine doesn't (and the
4 sec delay I experience is bluez waiting for the reply until it times out)?
If it helps, here's the output of "hcitool info" for my mouse:
Requesting information ...
BD Address: 00:16:38:A2:C5:56
Device Name: Targus Bluetooth Media Mouse for Notebook
LMP Version: 1.1 (0x1) LMP Subversion: 0x100
Manufacturer: Broadcom Corporation (15)
Features: 0xbc 0x02 0x04 0x28 0x08 0x08 0x00 0x00
<encryption> <slot offset> <timing accuracy> <role switch>
<sniff mode> <RSSI> <power control> <enhanced iscan>
<interlaced pscan> <AFH cap. slave> <AFH cap. master>
So, am I going in the right direction or am I totally off the mark? I'd
really appreciate some comment from you guys who know how this works.
Regards,
Daniel