Re: [PATCH] doc/adapter-api.txt: StartServiceDiscovery method.

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Marcel, Jakub,

On Mon, Dec 8, 2014 at 4:07 PM, Marcel Holtmann <marcel@xxxxxxxxxxxx> wrote:
> Hi Jakub,
>
>> This patch proposes new method, StartServiceDiscovery to D-Bus Adapter API for
>> desktop bluetoothd. It will allow for rapid discovery of nearby devices that
>> advertise services.
>>
>> Signed-off-by: Jakub Pawlowski <jpawlowski@xxxxxxxxxx>
>> ---
>> doc/adapter-api.txt | 20 ++++++++++++++++++++
>> 1 file changed, 20 insertions(+)
>>
>> diff --git a/doc/adapter-api.txt b/doc/adapter-api.txt
>> index 74d235a..88533ed 100644
>> --- a/doc/adapter-api.txt
>> +++ b/doc/adapter-api.txt
>> @@ -22,6 +22,26 @@ Methods            void StartDiscovery()
>>                       Possible errors: org.bluez.Error.NotReady
>>                                        org.bluez.Error.Failed
>>
>> +             void StartServiceDiscovery(uint8 rssi, array{string} uuids)
>> +
>> +                     This method starts the device discovery session with
>> +                     filtering by uuids, and rssi value. Use StopDiscovery to
>> +                     release the sessions acquired.
>> +
>> +                     This method will use LE scan only.
>> +
>> +                     Device that have RSSI bigger than rssi parameter, and
>> +                     advertise at least one service from uuids array, is
>> +                     conseidered filter match.
>> +
>> +                     This process will start creating Device objects as new
>> +                     devices matching criteria are discovered. It will also
>> +                     emit PropertiesChanged signal for already existing
>> +                     Device objects, with updated RSSI value.
>> +
>> +                     Possible errors: org.bluez.Error.NotReady
>> +                                      org.bluez.Error.Failed
>> +
>
> I think we want to use an dictionary of filter properties here. Clearly the D-Bus API should provide the possibilities to filter out pathloss if we choose to. Additionally you might need an option to restrict this to only LE devices.

+1, btw have you guys discussed how to handle discovery started by
different processes? It would be good to allow but then we need to
resolve RSSI conflicts for the same UUIDs, anyway I guess it is fine
to receive signals from UUIDs not on its own list but perhaps it is a
good idea to document the behavior we want in such case so client
don't assume there could be only one session.



-- 
Luiz Augusto von Dentz
--
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




[Index of Archives]     [Bluez Devel]     [Linux Wireless Networking]     [Linux Wireless Personal Area Networking]     [Linux ATH6KL]     [Linux USB Devel]     [Linux Media Drivers]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Big List of Linux Books]

  Powered by Linux