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

["Daniel T. Cobra" <dcobra@videam.com.br>]

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