Open Slion opened 1 month ago
I would have thought we only query the needed attributes, but it looks like all attributes are queried currently.
What do you need the additional attributes for? They are usually not displayed in Bluetooth UIs.
I would have thought we only query the needed attributes, but it looks like all attributes are queried currently.
It did not know it was possible to query specific attributes, but yes btstack just does:
sdp_client_query_uuid16(&hid_host_handle_sdp_client_query_result, (uint8_t *) connection->remote_addr, BLUETOOTH_SERVICE_CLASS_HUMAN_INTERFACE_DEVICE_SERVICE);
which will return a bunch of stuff never used in btstack including the three attributes mentioned above. Maybe we could add a query for specific attributes in the examples.
Not sure what makes more sense, restrict the SDP query to specific attributes or provide access to the currently queried and discarded attributes. The SDP quey can be quite slow depending on the device your are talking to it seems. It's notably very slow with Logitech K810 and rather fast with Samsung Galaxy Tab S8 Ultra.
What do you need the additional attributes for?
To accurately describe the connected device to the user.
They are usually not displayed in Bluetooth UIs.
Which ones are usually displayed? This is an interesting point because I'm pretty sure Windows and Android displays "Logitech K810" which is not matching any of the attributes above.
For some reasons those are not defined in the assigned numbers and they are also missing from
bluetooth_sdp.h
Though they are define in the SDP specifications.They look like that when fetched from the
sdp_general_query
.We could also make them available through the APIs much like the report descriptor since we do fetch them already. That would save application to have to make another redundant SDP query.
I reckon we should be able to fetch them from
hid_host_handle_sdp_client_query_result
and store them either in thehid_host_connection_t
structure or as external storage like the report descriptor.