Bug 18184

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?