Bug 431658
| Summary: | hwdata-0.215-1 breaks identification of Palm handhelds for pilot-link | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Kevin R. Page <redhat-bugzilla> | ||||
| Component: | hwdata | Assignee: | Karsten Hopp <karsten> | ||||
| Status: | CLOSED CURRENTRELEASE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||
| Severity: | low | Docs Contact: | |||||
| Priority: | low | ||||||
| Version: | 8 | CC: | bdm, sebi | ||||
| Target Milestone: | --- | Keywords: | Reopened | ||||
| Target Release: | --- | ||||||
| Hardware: | All | ||||||
| OS: | Linux | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | 0.216-1 | Doc Type: | Bug Fix | ||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2008-04-01 12:51:01 UTC | Type: | --- | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Embargoed: | |||||||
| Attachments: |
|
||||||
|
Description
Kevin R. Page
2008-02-06 08:28:37 UTC
hwdata uses the upstream file http://www.linux-usb.org/usb.ids without any patches and I won't start adding patches to it. Any changes need to be commited upstream before they get into the hwdata package. Looking at the pilot-link package I don't see anything that parses "Palm Handheld" so I'm not sure why you think this change is required at all. Programs shouldn't rely on the device strings and should use the vid/pid instead. using p.e. ATTRS{idVendor}=="0830", ATTRS{idProduct}=="0061" in the udev rules would be much better than hoping that the strings never change. Karsten, thanks for your reply. (In reply to comment #1) > hwdata uses the upstream file http://www.linux-usb.org/usb.ids without any > patches Is it best to contact the maintainer referenced in this file directly, or is it generated from http://www.qbik.ch/usb/devices/ as you implied in bug #280251 (i.e. will it be repeatedly broken as people amend the database for different devices because Palm use the same ID for difference handhelds?) I'll do whichever of these is best to fix the problem upstream. > Looking at the pilot-link package I don't see anything that parses "Palm > Handheld" This was from Harald Hoyer's initial udev/polkit solution (bug #280251 comment #17). The pilot-link package containing these rules unfortunately hit updates at the same time as the updated hwdata. > Programs shouldn't rely on the device strings and should use the vid/pid instead. > using p.e. ATTRS{idVendor}=="0830", ATTRS{idProduct}=="0061" in the udev rules > would be much better than hoping that the strings never change. That's very useful, and confirms what we've concluded ourselves - if you've any further comments on the proposed way forward (bug #280251 comment #92 onwards) they'd be appreciated. Brian: I see from bug #280251 comment #95 and pilot-link-general that you've sent a patch upstream to fix http://www.linux-usb.org/usb.ids Could you update us here when you hear back from the maintainer, please? Thanks. Out of interest, did you ask to revert the file (a single vid/pid mapping to a generic "Palm Handheld" string) or to somehow have multiple entries for a single vid/pid, each with a different string? In bug #280251 comment #100 I've gone through the .fdi file so that it matches the vid/pids pilot-link works with; hopefully this will match what you've sent upstream for usb.ids. Created attachment 294552 [details]
DIff for usb.ids
This was submitted to the usb.ids maintainer a few days ago. It adds the known
devices to each ID, some of them have quite a few!
I see that Brian's patch has made it upstream into http://www.linux-usb.org/usb.ids We need a rebuild of Fedora hwdata to pull this in, though. Bug #280251 no longer depends on this to work, but it's still confusing for users when using e.g. lsusb (well, actually the current pilot-link is still broken by this, but the proposed version is more robust!). fixed in 0.216-1 and newer |