hidapi/libusb: maintain in-memory cache of vendor/product strings#571
hidapi/libusb: maintain in-memory cache of vendor/product strings#571slouken wants to merge 2 commits into
Conversation
The get_usb_string call is rather expensive on some USB devices, so we cache the vendor/product strings for future lookups (e.g. when hid_enumerate is invoked again later). This way, we only need to ask libusb for strings for devices we haven't seen since before we started. Signed-off-by: Steven Noonan <steven@valvesoftware.com> Signed-off-by: Sam Lantinga <slouken@libsdl.org>
|
What about serial_number? Shouldn't it be cached as well? |
|
And the caching probably needs to be device-specific, not vid/pid-specific. I have two USB/HID devices on my table right now: both have the same vid/pid but different Manufacturer and Product Name (FW is localized for different countries). |
|
I also think none of it would be required when libusb/libusb#1258 is completed. |
Good point. |
|
Unfortunately libusb/libusb#1258 is closed without being merged, due to some API discussions. |
…e-of-vendor-pro.patch
|
But the idea to get is done is still alive. |
Good point. I agree with you here. In that case, do you want to close this PR as not planned? |
|
I don't have a strong oppinion. |
|
|
I was looking at this patch again, and you're right, it should be device specific. We can add the path to the hash key, but that isn't 100% guaranteed to be unique if you unplug and plug a different device with the same vid/pid to the same port. Is there another way to guarantee that it's device specific? |
3 participants
The get_usb_string call is rather expensive on some USB devices, so we cache the vendor/product strings for future lookups (e.g. when hid_enumerate is invoked again later).
This way, we only need to ask libusb for strings for devices we haven't seen since before we started.
This is an important performance improvement when frequently iterating devices using libusb.