State interaction with usb.ids

[chrysn]

The database Linux-based desktop systems use to describe USB devices in lsusb is accessed (through the detour of udev's database maintained at systemd but updated from there) as usb.ids and maintained at https://usb-ids.gowdy.us/.

Is there a regular batch process (possibly automated using mail submit) that is run on the pidcodes data? If so, that could be stated somewhere (if only in this ticket), and if not too, for then applicants can know to just submit their items to https://usb-ids.gowdy.us/ once they're allocated, without fear of upsetting some process.

[tannewt]

I don't know of any process to move the USB IDs over. This is the first I've heard of usb.ids. Where is usb.ids used? I see my USB device with a proper name in lsusb because it provides it.

[chrysn]

The regular lsusb (at least on Debian sid) does not look up the provided strings because that'd need active intervention and the executing user may lack the privileges. For example, my RIOT development board shows as "Bus 001 Device 105: ID 1209:7d00 Generic USB device" even though my user does have the privileges and lsusb -v -d 1209:7d00 | grep '^ i' shows:

  idVendor           0x1209 Generic
  idProduct          0x7d00 
  iManufacturer           3 RIOT-os.org
  iProduct                2 USB device
  iSerial                 4 E53FFAFE15F5FF46

Altering the usb.ids file (as installed using the usb.ids package) does not have an immediate effect, but an upstream change would, as I understand, propagate in there through the database.

---

As no mechanism is active from this side and no notes to that effect are in the usb.ids database from the other, it stands to reason to assume that the entries there are currently maintained manually, and that thus no harm comes from registrants to enter their devices over there once registered.

(If every anyone takes the time to automate that, owners of any entries whose descriptions diverge between the two databases would likely be notified; I currently don't have the resources to start up such synchronization).

[Solartraveler]

It looks like the entries from pidcodes were synchronized to the usbids by someone 2008. I just took 3h wrote a converter :P
Looks like half of the pidcodes entries are missing there. Most are added in the format name - product. The converter will fail at some entries because
https://usb-ids.gowdy.us/ (or the same site at http://www.linux-usb.org/usb-ids.html)
uses iso-8859-1 whereas pidcodes uses utf-8.
Should I submit the patch generated to usb-ids?
usb.ids.patch.zip
pidcodes2usbids.py.zip

[peternewman]

Paging @rohieb I think, I'm guessing that's the same person that did the push on 2018-08-10.

As no mechanism is active from this side and no notes to that effect are in the usb.ids database from the other, it stands to reason to assume that the entries there are currently maintained manually, and that thus no harm comes from registrants to enter their devices over there once registered.

I don't think you need to worry, the run that happened only did some minor formatting tweaks from what we initially submitted, see for example:
https://usb-ids.gowdy.us/read/UD/1209/aced

It looks like the entries from pidcodes were synchronized to the usbids by someone 2008. I just took 3h wrote a converter :P
Looks like half of the pidcodes entries are missing there. Most are added in the format name - product.

Awesome work @Solartraveler . I'd say the ideal thing would be to setup something in GitHub Actions so it automatically pushes any changes whenever commits are made! I think I started looking at this once but never got very far.

Should I submit the patch generated to usb-ids?

I would say so, assuming you're skipping any updates where the codespace of the file upsets things (but additions are probably better than nothing).

pidcodes2usbids.py.zip

In the short term, there should probably be a PR to add this to the repo, until it's (hopefully) automated.

[Solartraveler]

I would say so, assuming you're skipping any updates where the codespace of the file upsets things (but additions are probably better than nothing).
You mean with codespace the iso-8859-1 utf-8 thing?
By default, I would only add missing entries. Entries already at usb-ids would not be touched.

In the short term, there should probably be a PR to add this to the repo, until it's (hopefully) automated.
If someone tells me the folder where to place such a script, I would like to do a pull request :)
I think I can automate it as far as having a patch file as build artifact. Then someone just needs to send the file to usb-ids from time to time.

[rohieb]

Hmm yes, I remember that I once submitted data to http://www.linux-usb.org/usb-ids.html, but other than that I have no memory of the process …

[Solartraveler]

Does anyone know which format their bot at http://www.linux-usb.org/usb-ids.html
wants?

1. Try with my entire patch from usb.ids -> answer "malformed patch"
2. Try with a single entry -> answer "Unable to find any version of usb.ids the patch applies to."
3. Try incrementing their version and date in line 12 and 13 and adding this as part of the patch -> answer "No patch found"

[nickray]

I've recently tried adding a PID, but I'm not clear at all what needs to happen to first merge it beyond "discussion" and then into http://www.linux-usb.org/usb-ids.html, which for instance Arch Linux uses in lsusb via a packaged https://github.com/vcrhonek/hwdata... Maybe we need to talk to Mr Gowdy? :)