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 -- 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
