-
Notifications
You must be signed in to change notification settings - Fork 669
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
Feature request: Support names from the usb.ids database. #331
Comments
First, I think there would be value in being able to reliably access the USB IDs database from Python. That said, there are two major sources of USB ID -> name mappings:
PyUSB, for instance, only returns the string descriptors; So I think we need to answer:
|
@jonasmalacofilho I dig some digging, it looks like the usb.ids database is consistently available on most *nix like systems (excluding Darwin) via userspace tooling at one or more of these paths -
As an example Debian's
There is a similar pattern in other distributions. It doesn't look like the kernel necessarily includes this data, the only references I can find to it are in the USB over IP tooling, here and here where it's an optional parameter I can't find a built-in way to access the same data on Darwin or Windows. For ease of cross-platform compatibility I suggest that we include it in this project. We could -
As to an interface, as we've discussed in #330 I'm comfortable with a public As to including this in PyUSB, before version 1.0 it would have been out of scope but now the project has grown into "...an API rich, backend neutral Python USB module..." I think this is an appropriate feature. However we decide to implement this I'm happy to own it, I'd submit a pull request on the same schedule as #330. |
@Gestas thanks for looking into this, I'll take a look at what you gathered. |
FYI, right now we use a snapshot version of usb.ids file in libusbk project (Windows). But it is a good idea to allow users to update by themselves if possible. |
I think we can include a copy of the data, but prefer the system provided copy on Linux (on the possible paths we have collected). Regarding the API, I think a mixed approach would be useful: a low level DB lookup module plus some convenience methods or properties on |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
I have some cycles to work on this. @jonasmalacofilho, I can implement this per your suggestion ^^^. The outstanding question is where to source the data on Darwin and Windows. I can't find a path forward beyond including the usb.ids database in this package as per my comment, #331 (comment). I am open to other options, suggestions? |
I can't either, although @mcuee is probably right that there should be some way for our API users to specify their own databases. So, we read the database from:
One remaining question is whether the end users should be allowed to influence the path (and thus use a possibly more up-to-date database), perhaps through an environment variable. For now I don't think that's necessary: the USB database isn't updated that often (my personal inclusions took quite a while to be integrated), and there should be a new PyUSB release every 6 months anyway. |
I think the above should be good enough, especially since the idea is to have regular pyusb release. For macOS, I use homebrew and it does have a formulae for usb.ids. Same for Mac Ports. |
In order of default priority -
I'll provide a way for a user to override the defaults. For 1; Any preferences on environment variable name? Should we fail forward or exit if a path is specified but there isn't a valid file there? |
I think the order should be:
But it seems that mcuee agrees with me that 0 is not necessary, at least not yet. Additionally, I don't think we should ship the database on platforms where we assume the database will be available at the system level. It would be useless (the system version would have priority) and potentially confusing. Regarding any explicitly passed in paths, I think that if the path is invalid we should just log the problem and, like you called it, "fail forward". In fact, this entire API should only provide a "a best effort" guarantee: if neither the supplied path, nor the system or the shipped data is available (or, more commonly, if there simply isn't an entry for the desired |
@jonasmalacofilho got it, I'll work on this. |
I agree. Thanks. |
Just reading through this and there is something that needs clarification about the original post: The values from udev or usb.ids are used to "pretty-print" the idVendor and idProduct values (e.g. 0bda and 0316). This is what you see e.g. when you run "lsusb" without any verbose options. It would be wrong to mix this up and transparently fall back to usb.ids values when device strings are missing. The premise of the original post with "Incorrect" or "Missing" values, and using usb.ids to remedy this, is wrong. Displaying device strings and displaying human-readable IDs are two different things and should be kept separate. BTW, I remember there was a bug in usbutils (or was it in libusb?) some years ago, I think it was present in e.g. Ubuntu 16.04, where the output from lsusb would be messed up and idVendor/idProduct strings from one device would be printed for another device. This came to my mind when I saw the description here, but I don't think it is related. |
Especially (but not only) in relation to:
I absolutely agree with you. And I don't think I was clear as you about this on my previous comments in this thread, so thank you!
Do you remember anything else about that issue? I saw it as recently as last year (in bug reports, IIRC on liquidctl), but wasn't able to track down the problem with the limited information I had at the time. |
Here is my summary in one of the upstream PRs: gregkh/usbutils#103 (comment) Funny enough, the bug was introduced when someone added such a "fallback" as I recommend against here. |
Thanks again! |
Feature: Export vendor and product names as described in the usb.ids file. Slightly related to #330.
The usb.ids file is the the canonical mapping of vendor and product names to ids. It is used by almost all USB related tooling that return vendor and product names.
libusb
support here is limited and inconsistent, I'm not sure what's going on. On my Ubuntu 20.04 system it doesn't return vendor names for ids [0bda, 8087] but it does for [1d6b, 13d3]. 13d3 is incorrect. All of these devices are included in the usb.ids file.There are several implementation options. If you think this is something that belongs in
pyusb
let me know and we can figure something out.The text was updated successfully, but these errors were encountered: