Re: Long delay to (re)connect a bluetooth mouse

[Stefan Seyfried <stefan.seyfried@googlemail.com>]

On Wed, 03 Feb 2010 09:44:36 -0200
"Daniel T. Cobra" <dcobra@videam.com.br> 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."