Currently usb_device.vendor and usb_device.product strings are read from USB device database file on Linux and directly from the device on other OSs. I suggest simply reading them from the device in all cases - the USB device database file is out of date, and is redundant anyway, because the same information is supplied by the device itself. I can submit a patch for this. Also this would be needed for USB OBEX support in gvfs, because it relies on matching USB product and vendor strings supplied by Hal with those supplied by obex-data-server. I'm stuck - they mismatch because the former currently comes from usb database file, but the latter is read from the device.
Created attachment 19826 [details] [review] possible patch for HAL See attached patch. It would change HAL to try first to get the strings from sysfs instead of usb.ids and falls back if there are no info. Currently I'm not sure if it's the best idea to change the current behavior. Especially because of such changes after applying the patch: - usb_device.product = 'BT Mini-Receiver (HID proxy mode)' (string) + usb_device.product = 'Logitech BT Mini-Receiver' (string) The old string was really more descriptive since it tells me in which mode the device currently is. And also this change is not that good: - usb_device.product = 'MX-1000 Cordless Mouse Receiver' (string) + usb_device.product = 'USB RECEIVER' (string) Also such changes are not really useful, since it make matching the string really hard: - usb.vendor = 'Linux Foundation' (string) + usb.vendor = 'Linux 2.6.25.16-0.1-default ehci_hcd' (string) And this are only some examples. If hal get changed I expect more such problems.
I agree that information from USB id database could still be useful. How about adding properties 'usb_device.product_db' and 'usb_device.vendor_db' that always contain values from the database file and changing usb_device.product and .vendor so that they always contain strings from sysfs?
I think it's a bit late in the day to do things like that. You should probably make sure something similar gets into DeviceKit...
Bastien, this change is not a big deal in my opinion - those string properties are rarely if ever used (applications generally use numeric ids) and the change shouldn't break things. But it's needed for USB OBEX support in gvfs obexftp backend - the support is basically done and only depends on this one fix to hal that also improves consistency of the usb device information :) By the way, as far as I can see, DeviceKit is nowhere near ready and nothing from gvfs has been ported to it yet.
It can break every fdi matches in hal-info itself, and in third-party fdi files, if not carefully done.
How so? fdi matches in hal-info are done by comparing numeric properties usb_device.vendor_id and usb_device.product_id. Those will not be changed at all- the change only affects string properties usb_device.product and usb_device.vendor.
(In reply to comment #6) > How so? fdi matches in hal-info are done by comparing numeric properties > usb_device.vendor_id and usb_device.product_id. Those will not be changed at > all- the change only affects string properties usb_device.product and > usb_device.vendor. There are a good number of fdi files that use string comparisons instead of matches on vendor or product ids. Those fdi files would break.
(In reply to comment #7) > There are a good number of fdi files that use string comparisons instead of > matches on vendor or product ids. Those fdi files would break. You are right - info.vendor/product and storage.vendor/product are copied from usb_device and are used a lot. However, these fdi files can still break if a device that was previously missing from usb.ids database is added to it, changing the strings. And these fdi files are already broken on FreeBSD and Solaris, because there usb.ids file is not used at all. How about adding usb_device.dev_manufacturer and usb_device.dev_product then, that are always read from sysfs? Simple.
Created attachment 19930 [details] [review] adds usb_device.dev_product and dev_vendor, that are always read from device So here's the patch that implements the proposal in comment 8.
Can we reach some kind of resolution here? Any comments about my last patch?
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.