Re: [PATCH] device: Add device type property

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

 



Hi Szymon,

On Thu, Feb 9, 2017 at 10:07 AM, Szymon Janc <szymon.janc@xxxxxxxxxxx> wrote:
> Hi,
>
> On 9 February 2017 at 08:37, Marcel Holtmann <marcel@xxxxxxxxxxxx> wrote:
>> Hi Eric,
>>
>>> This allows us to gather information about whether a device
>>> supports BR/EDR, BLE, or both. It appears as DBus Property
>>> "Type" on the org.bluez.Device1 interface.
>>>
>>> This is tested with the following steps:
>>> Scan for devices and request the type property of a specific remote device,
>>> using:
>>>  # dbus-send --print-reply --system --dest=org.bluez <obj path> \
>>>    org.freedesktop.DBus.Properties.Get \
>>>      string:org.bluez.Device1 string:Type
>>> or request the type of all remote devices, using:
>>>  # dbus-send --print-reply --system --dest=org.bluez / \
>>>    org.freedesktop.DBus.ObjectManager.GetManagedObjects | \
>>>      grep -B1 -A2 Type
>>> and check for "BR/EDR", "LE", and "DUAL"
>>> ---
>>> doc/device-api.txt |  5 +++++
>>> src/device.c       | 31 +++++++++++++++++++++++++++++++
>>> 2 files changed, 36 insertions(+)
>>>
>>> diff --git a/doc/device-api.txt b/doc/device-api.txt
>>> index 13b28818e..2f3100cd5 100644
>>> --- a/doc/device-api.txt
>>> +++ b/doc/device-api.txt
>>> @@ -141,6 +141,11 @@ Properties       string Address [readonly]
>>>
>>>                       The Bluetooth class of device of the remote device.
>>>
>>> +             string Type [readonly, optional]
>>> +
>>> +                     The carriers supported by this remote device. If it
>>> +                     exists, it can be one of "BR/EDR", "LE", or "DUAL".
>>> +
>>
>> I don’t like upper-case for values of this type. We have kept them normally all lower-case.
>>
>> Anyhow, actually you can deduct this information already from existing Class and Appearance values. If Class exists it is BR/EDR and if Appearance exists it is LE. If both exist it is dual-mode device. Only trick part might be that Appearance is optional, but we could just fill it in with some generic value. Would need to look that up.
>
> I think that if we decide to go with dedicated prop for this, it
> should rather be an array of strings of supported technologies
> eg [LE, BR/EDR] instead of string for device type. That way we could
> leave room for extending those easily if needed in
> the future (eg with AMP ?).

+1, although Im not sure about AMP there might be some other bearers
coming that could use it. Btw, in the long term this should really be
different interfaces for each bearer so the client would be able to
detect the supported bearers by checking what interfaces as available.

-- 
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