@@ -744,8 +744,8 @@ struct mgmt_rp_add_ext_adv_data {
uint8_t instance;
} __packed;
-#define MGMT_CAP_LE_TX_PWR_MIN 0x0001
-#define MGMT_CAP_LE_TX_PWR_MAX 0x0002
+#define MGMT_CAP_LE_TX_PWR_MIN 0x0000
+#define MGMT_CAP_LE_TX_PWR_MAX 0x0001
#define MGMT_OP_READ_CONTROLLER_CAP 0x0056
struct mgmt_rp_read_controller_cap {
@@ -1624,12 +1624,46 @@ static gboolean get_supported_secondary(const GDBusPropertyTable *property,
return TRUE;
}
+static gboolean get_supported_cap(const GDBusPropertyTable *property,
+ DBusMessageIter *iter, void *data)
+{
+ struct btd_adv_manager *manager = data;
+ DBusMessageIter dict;
+ int16_t min_tx_power = manager->min_tx_power;
+ int16_t max_tx_power = manager->max_tx_power;
+
+ dbus_message_iter_open_container(iter, DBUS_TYPE_ARRAY,
+ DBUS_DICT_ENTRY_BEGIN_CHAR_AS_STRING
+ DBUS_TYPE_STRING_AS_STRING
+ DBUS_TYPE_VARIANT_AS_STRING
+ DBUS_DICT_ENTRY_END_CHAR_AS_STRING,
+ &dict);
+
+ if (min_tx_power != ADV_TX_POWER_NO_PREFERENCE)
+ dict_append_entry(&dict, "MinTxPower", DBUS_TYPE_INT16,
+ &min_tx_power);
+
+ if (max_tx_power != ADV_TX_POWER_NO_PREFERENCE)
+ dict_append_entry(&dict, "MaxTxPower", DBUS_TYPE_INT16,
+ &max_tx_power);
+
+ dict_append_entry(&dict, "MaxAdvLen", DBUS_TYPE_BYTE,
+ &manager->max_adv_len);
+ dict_append_entry(&dict, "MaxScnRspLen", DBUS_TYPE_BYTE,
+ &manager->max_scan_rsp_len);
+
+ dbus_message_iter_close_container(iter, &dict);
+
+ return TRUE;
+}
+
static const GDBusPropertyTable properties[] = {
{ "ActiveInstances", "y", get_active_instances, NULL, NULL },
{ "SupportedInstances", "y", get_instances, NULL, NULL },
{ "SupportedIncludes", "as", get_supported_includes, NULL, NULL },
{ "SupportedSecondaryChannels", "as", get_supported_secondary, NULL,
secondary_exits },
+ { "SupportedCapabilities", "a{sv}", get_supported_cap, NULL, NULL},
{ }
};
To help our advertising clients understand the device capabilities, this patch adds a SupportedCapabilities dbus endpoint for the advertising manager. The primary reason behind this is to provide the valid LE tx power range the controller supports (populated if controller supports BT5), so a client can know the valid power range before requesting a tx power for their advertisement. I also thought it would be useful to indicate the max advertising data length and scan response length in this endpoint, since some clients will find it useful to set their advertising data (currently experimental feature) or scan response data (possible future feature) directly. This patch has been tested on Hatch (BT5 support) and Kukui (No BT5 support) chromebooks to verify that the dbus endpoint contains the correct data. Reviewed-by: Sonny Sasaka <sonnysasaka@chromium.org> --- lib/mgmt.h | 4 ++-- src/advertising.c | 34 ++++++++++++++++++++++++++++++++++ 2 files changed, 36 insertions(+), 2 deletions(-)