Hi Jakub, > Ok, new updated version - we do only passive scan, and we send Device > found event: > > > diff --git a/doc/mgmt-api.txt b/doc/mgmt-api.txt > index 11e2490..3d03617 100644 > --- a/doc/mgmt-api.txt > +++ b/doc/mgmt-api.txt > @@ -2135,6 +2135,29 @@ Set Public Address Command > Invalid Index > > > +Start Passive LE Filtered Device Scan > +======================= > + > + Command Code: 0x003A > + Controller Index: <controller id> > + Command Parameters: UUID (16 Octets) > + max_pathloss (1 octet) > + > + Return Parameters: > + > + This command starts passive LE scan, and filter received > advertisements: if AD contains both TX power level and Service > Solicitation, and UUID is contained in Service Solicitation and > computed pathloss is smaller than max_pathloss parameter, then a > Device Found event will be sent. generally we tried to avoid to specific LE only commands. Our attempts with the kernel APIs where to make them as generic as possible. So I think something along the lines of adding and removing UUID filters should be something we should target at. Add UUID Notification Filter ============================ Command Parameters: Address_Type (1 Octet) UUID (16 Octets) Max_Pathloss (1 Octet) Return Parameters: Address_Type (1 Octet) Remove UUID Notification Filter =============================== Command Parameters: Address_Type (1 Octet) UUID (16 Octets) Return Parameters: Address_Type (1 Octet) The Address_Type would be defined the same way as for Start Discovery command. Now we can discuss if on the mgmt level we want to use pathloss or rather a range of RSSI. I have seen that RSSI is preferred and that the translation from RSSI and advertising data with TX power level is done in the daemon. So for kernel API it might be better to expose RSSI range. Besides a RSSI range, we might also want to allow giving a RSSI threshold that defines how much the RSSI to change between events to be reported again. That said, the danger with a generic notification filter like this is that we can not implement it efficiently with current hardware without vendor commands. If you use duplicate filtering, then Broadcom and CSR chips behave fully different. Broadcom only filters on BD_ADDR and report devices once no matter what the RSSI, while CSR will report the same device again if the RSSI changes. With that in mind, it might be safer to introduce a one-shot mgmt API that needs to be repeatedly called to keep scanning for new devices. Start Service Discovery ======================= Command Parameters: Address_Type (1 Octet) Min_RSSI (1 Octet) Max_RSSI (1 Octet) Num_UUID (1 Octet) UUID[i] (16 Octets) Return Parameters: Address_Type (1 Octet) Stop Service Discovery ====================== Command Parameters: Address_Type (1 Octet) Return Parameters: Address_Type (1 Octet) Without having dedicated controller support for filtering, having such a dedicated discovery for services with a specific UUID seems to be more appropriate and more safe. Since we could always add controller based filtering for background scanning once there is controller support. 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
