Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

hidapi/libusb: maintain in-memory cache of vendor/product strings #571

Open
wants to merge 2 commits into
base: master
Choose a base branch
from

Conversation

slouken
Copy link
Contributor

@slouken slouken commented May 26, 2023

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.

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 <[email protected]>
Signed-off-by: Sam Lantinga <[email protected]>
@mcuee mcuee added the libusb Related to libusb backend label May 27, 2023
@Youw
Copy link
Member

Youw commented Jun 1, 2023

What about serial_number? Shouldn't it be cached as well?

@Youw
Copy link
Member

Youw commented Jun 1, 2023

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).

@Youw
Copy link
Member

Youw commented Jun 1, 2023

I also think none of it would be required when libusb/libusb#1258 is completed.

@slouken
Copy link
Contributor Author

slouken commented Jun 1, 2023

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).

Good point.

@mcuee
Copy link
Member

mcuee commented Mar 6, 2024

Unfortunately libusb/libusb#1258 is closed without being merged, due to some API discussions.

@Youw
Copy link
Member

Youw commented Mar 6, 2024

But the idea to get is done is still alive.
It is just a matter of getting it done.
I'd rather spend time making that than improving the change in this PR.

@mcuee
Copy link
Member

mcuee commented Mar 6, 2024

But the idea to get is done is still alive. It is just a matter of getting it done. I'd rather spend time making that than improving the change in this PR.

Good point. I agree with you here.

In that case, do you want to close this PR as not planned?

@Youw Youw added the don't_merge Don't merge this PR as is label Mar 6, 2024
@Youw
Copy link
Member

Youw commented Mar 6, 2024

I don't have a strong oppinion.
It doesn't bother me having it open.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
don't_merge Don't merge this PR as is libusb Related to libusb backend
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants