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
--
To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
