From: Eric Caruso <[email protected]>
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".
+
uint16 Appearance [readonly, optional]
External appearance of device, as found on GAP service.
diff --git a/src/device.c b/src/device.c
index 8693eb826..14c62e127 100644
--- a/src/device.c
+++ b/src/device.c
@@ -788,6 +788,35 @@ static gboolean dev_property_get_class(const GDBusPropertyTable *property,
return TRUE;
}
+static gboolean dev_property_exists_type(const GDBusPropertyTable *property,
+ void *data)
+{
+ struct btd_device *device = data;
+
+ return device->bredr || device->le;
+}
+
+static gboolean dev_property_get_type(const GDBusPropertyTable *property,
+ DBusMessageIter *iter, void *data)
+{
+ struct btd_device *device = data;
+ const char *type;
+
+ if (!device->bredr && !device->le)
+ return FALSE;
+
+ if (!device->bredr)
+ type = "LE";
+ else if (!device->le)
+ type = "BR/EDR";
+ else
+ type = "DUAL";
+
+ dbus_message_iter_append_basic(iter, DBUS_TYPE_STRING, &type);
+
+ return TRUE;
+}
+
static gboolean get_appearance(const GDBusPropertyTable *property, void *data,
uint16_t *appearance)
{
@@ -2541,6 +2570,8 @@ static const GDBusPropertyTable device_properties[] = {
{ "Alias", "s", dev_property_get_alias, dev_property_set_alias },
{ "Class", "u", dev_property_get_class, NULL,
dev_property_exists_class },
+ { "Type", "s", dev_property_get_type, NULL,
+ dev_property_exists_type },
{ "Appearance", "q", dev_property_get_appearance, NULL,
dev_property_exists_appearance },
{ "Icon", "s", dev_property_get_icon, NULL,
--
2.11.0.483.g087da7b7c-goog
Hi Szymon,
On Thu, Feb 9, 2017 at 10:07 AM, Szymon Janc <[email protected]> wrot=
e:
> Hi,
>
> On 9 February 2017 at 08:37, Marcel Holtmann <[email protected]> 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 dev=
ice,
>>> using:
>>> # dbus-send --print-reply --system --dest=3Dorg.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=3Dorg.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 devic=
e.
>>>
>>> + 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=E2=80=99t like upper-case for values of this type. We have kept th=
em normally all lower-case.
>>
>> Anyhow, actually you can deduct this information already from existing C=
lass 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 migh=
t be that Appearance is optional, but we could just fill it in with some ge=
neric 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.
--=20
Luiz Augusto von Dentz
Hi,
On 9 February 2017 at 08:37, Marcel Holtmann <[email protected]> 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 devi=
ce,
>> using:
>> # dbus-send --print-reply --system --dest=3Dorg.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=3Dorg.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 i=
t
>> + exists, it can be one of "BR/EDR", "LE", or "DUAL"=
.
>> +
>
> I don=E2=80=99t like upper-case for values of this type. We have kept the=
m normally all lower-case.
>
> Anyhow, actually you can deduct this information already from existing Cl=
ass and Appearance values. If Class exists it is BR/EDR and if Appearance e=
xists 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 gen=
eric 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 ?).
--=20
pozdrawiam
Szymon K. Janc
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.
Regards
Marcel