Hi Andre, > By using periodic inquiry command we're not able to detect correctly > when the controller has started inquiry. > > Today we have this workaround in inquiry result event handler to set > the HCI_INQUIRY flag when it sees the first inquiry result event. > This workaround isn't enough because the device may be performing > an inquiry but the HCI_INQUIRY flag is not set. For instance, if > there is no device in range, no inquiry result event is generated, > consequently, the HCI_INQUIRY flags isn't set when it should so. > > We rely on HCI_INQUIRY flag to implement the discovery procedure > properly. So, as we aren't able to clear/set the HCI_INQUIRY flag in > a reliable manner, periodic inquiry events shouldn't change the > HCI_INQUIRY flag. In future, if needed, we might add a new flag (e.g. > HCI_PINQUIRY) to know if the controller is performing periodic > inquiry. > > Thus, due to that issue and in order to keep compatibility with > userspace, periodic inquiry events shouldn't send mgmt discovering > events. I spend some time thinking about this and yes, we need to clean this mess up right now. So intermixing inquiry with periodic inquiry was a bad idea and we should split this. So I think internally hci_dev needs a variable to track if we have enabled periodic inquiry or not. So it should express if periodic inquiry is on or off. Nothing else since we should not bother with trying to match periodic inquiry result to inquiry results. I would actually go this far that we should ignore inquiry result events from periodic inquiry. Lets start creating some hci_dev internal state flags variable to track certain states/modes of the controller. As I said earlier, overloading a public API/ABI is not a good idea at all. For tracking periodic inquiry state/mode we just need to be careful and take an inquiry result outside of start inquiry and inquiry complete as indication that periodic inquiry is active. There is still a potential false positive as you mentioned, but that also should not matter since periodic inquiry is suspending itself anyway. Important is just that we track inquiry and periodic inquiry states separately. Another assumption is that periodic inquiry is only used by special applications and it is essentially triggered by 3rd party daemons doing something special for their needs. If periodic inquiry is enabled, I am even fine failing the mgmt_start_discovery command with an error. So in conclusion, I wanna have us tracking if the controller is currently doing periodic inquiry. And if you wanna export that state, then lets do it via debugfs. Regards Marcel -- 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
