Best vendor/product info

[David Zeuthen]

On Fri, 2007-06-08 at 23:48 -0400, Jeff Mitchell wrote:
> I've got a best-practices question.
> 
> Although the info namespace is specified as the location for metadata for all 
> devices, info.vendor and info.product often seem to return results that are 
> very...empty...or very generic.  While 
> value_of(linux.subsystem).vendor/product often (in my experience, always) 
> return far more useful and correct information.
> 
> So what is best practices here?  Determine the subsystem, then get .vendor 
> and .product from that?  Someone I'm working with thinks that this is 
> something that should be fixed on the HAL end -- that info.product and/or 
> info.vendor should be populated with the best available information.  But I 
> presume there's a reason that things are how they are (maybe "best available" 
> is hard to really determine or something).
> 
> Advice would be appreciated!

There's a couple of problems with using info.vendor and info.product

 - for some devices there's s sub-vendor and sub-product as well
   example: http://people.freedesktop.org/~david/gdm-pci-subvendor.png

 - typically in the UI you may primarily want to use textual strings
   that describe _what the device_ is and secondarily only use 
   make/model - that's the policy I've been adopting in gnome-device-
   manager anyway. It kinda depends though.

 - no way to know whether the string originates from the hardware
   itself or form a look-up table such as pci.ids or usb.ids. For
   example, for USB interfaces there _may_ be a textual string
   originating from the metal itself that describes the device; this
   is useful for doing policy things, e.g.
   http://gitweb.freedesktop.org/?p=hal.git;a=commit;h=8e00f386dd4af855116cb1082c0ae6fd8db7ce5e

So I think the answer is that you shouldn't rely on info.vendor and
info.product - we should still keep them around (and fix bugs where
applicable); but if possible you should use properties on the name space
of the device you're interested in. I'm guessing this has to do with the
portable_audio_player name space?

      David