Hi folks,
I'd like to receive opinions of how we should implement the General
Discovery procedure aligned to UI/API and Bluetooth Qualification.
The current implementation reports all found devices using the D-Bus
signal DeviceFound(), Flags AD Type is ignored at the moment, meaning
that Broadcaster and Peripheral are reported.
>From Bluetooth SPEC: General Discovery Procedure - page 1704
"The Host shall check for the Flags AD type in the advertising data.
If the Flags AD type is present and either the LE General Discoverable
Mode flag is set to one or the LE Limited Discoverable Mode flag is
set to one then the Host shall consider the device as a discovered
device, otherwise the advertising data shall be ignored."
GAP Test Requirement document says that "General Discovery Procedure
Does not find Broadcast device"
We may need to represent the Broadcaster devices creating a D-Bus
device object, it is still unclear to me at the moment. So I have
three suggestions(I prefer the first):
1. Report Peripheral and Broadcaster using DeviceFound() signal and
add an property to identify the role. eg: Broadcaster=false/true
2. Ignore the Broadcaster devices. Means that it will not be possible
to call CreateDevice for these devices.
3. Add a config option to change the discovery behavior to ignore
Broadcaster devices. For qualification test only.
If we choose the first, for qualification test I guess it will be
enough to add an extra filter to ignore the broadcaster devices in the
BlueZ test script.
Regards,
Claudio
Hi Claudio,
On Tue, 2010-12-21 at 17:12 -0300, Claudio Takahasi wrote:
> Hi folks,
>
[snip]
> We may need to represent the Broadcaster devices creating a D-Bus
> device object, it is still unclear to me at the moment. So I have
> three suggestions(I prefer the first):
> 1. Report Peripheral and Broadcaster using DeviceFound() signal and
> add an property to identify the role. eg: Broadcaster=false/true
I also prefer this solution. The higher layer app or entity should then
filter out any devices that it is not interested in, and should be
examining the properties of all the devices reported to it. Along with
a Broadcaster property, there should be other properties that indicate
other details such as Pubic/Private addresses, etc.
> 2. Ignore the Broadcaster devices. Means that it will not be possible
> to call CreateDevice for these devices.
Don't like this idea, because at some point BlueZ we be used in a device
which *will* need to be aware of the existence of Broadcaster devices.
And the CreateDevice paradigm is probably to best way to represent these
remote devices.
> 3. Add a config option to change the discovery behavior to ignore
> Broadcaster devices. For qualification test only.
Not a good idea. At the end of the day, a device should be qualifiable
regardless of it's configuration.
>
> If we choose the first, for qualification test I guess it will be
> enough to add an extra filter to ignore the broadcaster devices in the
> BlueZ test script.
I agree.
>
> Regards,
> Claudio
--
Brian Gix
[email protected]
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum