You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
Especially in the context of multiple HID connections the storage of report descriptors in a single buffer is problematic.
Say if you want up to 8 connections you should have like a 4KB buffer with each device having up to a 512KB descriptor.
Then your app still need to copy those descriptors anyway as they are moved around the buffer when devices a disconnecting.
See: #633 (comment)
On top of that the app may need to do the exact same SDP query to fetch other attributes anyway.
So being able to disable that SDP query would prevent a redundant query, see: #618
Adding documentations to hid_host_init would be great too.
Describe the solution you'd like
Do not fetch report descriptor when hid_host_init is passed a NULL pointer and/or a size of zero.
Describe alternatives you've considered
None
Possible solution
staticvoidhid_host_handle_start_sdp_client_query(void*context){
UNUSED(context);
btstack_linked_list_iterator_tit;
btstack_linked_list_iterator_init(&it, &hid_host_connections);
while (btstack_linked_list_iterator_has_next(&it)){
hid_host_connection_t*connection= (hid_host_connection_t*)btstack_linked_list_iterator_next(&it);
switch (connection->state){
caseHID_HOST_W2_SEND_SDP_QUERY:
connection->state=HID_HOST_W4_SDP_QUERY_RESULT;
connection->hid_descriptor_status=ERROR_CODE_UNSUPPORTED_FEATURE_OR_PARAMETER_VALUE;
break;
default:
continue;
}
/* Don't fetch report descriptor if no storage for it */if (hid_host_descriptor_storage_len==0||hid_host_descriptor_storage=NULL){
return;
}
/* Issue SDP query to fetch report descriptor */hid_descriptor_storage_init(connection);
hid_host_sdp_context_control_cid=connection->hid_cid;
sdp_client_query_uuid16(&hid_host_handle_sdp_client_query_result, (uint8_t*) connection->remote_addr, BLUETOOTH_SERVICE_CLASS_HUMAN_INTERFACE_DEVICE_SERVICE);
return;
}
}
The text was updated successfully, but these errors were encountered:
HID report descriptor is wasting even more memory if you want to support both BLE and Classic devices you also need to provide BLE a large 4K buffer through hids_client_init. This design really does not scale well as far as memory consumption goes.
Adding that extra 4K buffer actually tripped me over on Pico W got OOM panic. I'm planning to switch to Pico 2 W and it should be fine there. Still we should really come up with a design that does not require such large static buffers we still need to copy anyway.
Thanks for the suggestion. Not fetching the HID Descriptor would be easy to implement, as in your suggestion. However, HID Host still needs to query SDP to get the L2CAP PSM and a few other values.
I'd like to better understand your reasoning. Why do you want/need to store the HID descriptor in the application?
The idea had been to access the one stored in HID Host with with hid_descriptor_storage_get_descriptor_len() and hid_descriptor_storage_get_descriptor_data()
Is your feature request related to a problem? Please describe.
Especially in the context of multiple HID connections the storage of report descriptors in a single buffer is problematic.
Say if you want up to 8 connections you should have like a 4KB buffer with each device having up to a 512KB descriptor.
Then your app still need to copy those descriptors anyway as they are moved around the buffer when devices a disconnecting.
See: #633 (comment)
On top of that the app may need to do the exact same SDP query to fetch other attributes anyway.
So being able to disable that SDP query would prevent a redundant query, see: #618
Adding documentations to
hid_host_init
would be great too.Describe the solution you'd like
Do not fetch report descriptor when
hid_host_init
is passed a NULL pointer and/or a size of zero.Describe alternatives you've considered
None
Possible solution
The text was updated successfully, but these errors were encountered: