Hi Anderson
>
> Actually we check it, but on the BlueZ side (as you know, our host
> stack is composed of kernel+userspace). From
> adapter_emit_device_found() in src/adapter.c:
>
> if (dev->le) {
> gboolean broadcaster;
>
> if (dev->flags & (EIR_LIM_DISC | EIR_GEN_DISC))
> broadcaster = FALSE;
> else
> broadcaster = TRUE;
>
> emit_device_found(adapter->path, paddr,
> [...]
>
> But note that we still send the "DeviceFound" D-Bus signal, but with a
> "Broadcaster" property which UI can use to ignore the device.
>
> Filtering on the kernel requires parsing Adv. data, and may not allow
> us to implement Broadcaster role on BlueZ (and on external
> applications as well) in future.
>
> IMHO the kernel should still notify userspace of the device, then
> BlueZ can filter out the Broadcaster devices as necessary, *unless* we
> plan to parse all AD information on kernel, which is not a good idea
> IMHO.
>
I'm not so comfortable using the same Device Found event both for discovering devices and for observing.
In addition, maybe the 'broadcaster variable is the wrong name for this variable. The true meaning is 'discoverable'. A peripheral can broadcast services and other advertising information while broadcasting as discoverable, so this flag may be confusing.
This also means that the upper layer using this API should keep its own state, to differ between discovering devices (where discoverable devices are displayed as discoverable and broadcast data is collected) or just 'observing' advertising data, where the central device just searches for broadcast data, and has no intention of connecting to a device. In this case, a DEVICE_FOUND event is a bit confusing.
Do you know if anyone is working on extending the capabilities of the EIR parser for more advertising data types (such as services)? We need to think of a proper way to pass the EIR information to the user in the event.
Best regards,
Chen Ganir.
--
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
