Hi Marcel, > do me favor and read the Bluetooth specification, because periodic > inquiry is a low-level HCI command. I believe you may have misunderstood my earlier post. I do know about the HCI Period Inquiry Mode command, but this is a large, multi-person project, and I am in charge of writing a library that provides an Inquiry() and InquiryCancel() methods. Someone else writes the application that uses those methods, and so it happens that some of the time they are using them to periodically launch inquiries, but then not always. I cannot use the above mentioned HCI command because I do not receive anything resembling a period as a parameter, since my API only allows the application to start and stop inquiries, no to provide periodicity information to the underlying library implementation. Unfortunately I cannot change the API requirements nor have control over what the application does with my library. > With btusb we were trying to send as less URBs as possible, but it could > be that not having bulk URB running the chips behave funny. At least > that is what we have seen with some hardware. So that could be an issue > here. Nobody knows for sure. So if I understand this correctly, at some point (apparently when BlueZ transitioned from hci_usb to btusb?) you removed support for bulk URBs and that causes problems with some chipsets. I will try the bluetooth-testing.git repository, but could you confirm what I just stated and let me know at which point did the transition you are talking about happened? Thanks very much again! Regards, Carles -- 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
