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? |
|
I believe it could be at most platform-specific guarantee. On Windows devices with different serial numbers would have different paths even when connected to the same port, but on linux/libusb I believe it will be the same (by default) unless we add explicit additiona logic to distinguish devices (e.g. by serial number). But I don't believe any of that is needed. I suggest abandining this PR/approach, and instead of caching anything on HIDAPI side - instead rely on OS caching, as implemented by libusb: That implementation should probably be optional (in case HIDAPI is attempted to compile/link/run against older version of libusb, where this is not available), but totally covers what this PR suggests (at least logically). |
I don't believe the OS implements caching, which is the problem. Also note this comment on the PR: "While the read can be fast, it can also take seconds." |
HIDAPI doesn't try to open/read HUBs, that is not an issue.
That's the thing - it does. That's one of the reasons why this API is allowed and works w/o actually opening the device (which requires elevated permissions sometime) - it only reads the information available from USB descriptor which automatically opened and parsed by the OS once, when the device just been attached (and even before it appeared as an available USB device thru OS API). |
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.