Date: Sat, 25 Dec 2004 03:07:48 +0100 (CET) From: Barry Bouwsma <freebsd-misuser@remove-NOSPAM-to-reply.NOSPAM.dyndns.dk> To: usb@freebsd.org, Lennart Augustsson <lennart@augustsson.net> Subject: Re: getting vendor IDs Message-ID: <200412250207.iBP27mQ40936@Mail.NOSPAM.DynDNS.dK> References: <41C78044.2050005@elischer.org> <200412242236.iBOMaig32845@Mail.NOSPAM.DynDNS.dK> <20041224.155218.123609434.imp@bsdimp.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 24 Dec 2004 15:52:18 -0700 (MST), "M. Warner Losh" wrote: > : In such a case, the only thing I can see doing is to provide the > : end-product description as part of the vendor product, for NetBSD. > : Which will be rather a lot of work, but when you have the case of > : some unfamiliar-to-consumer's chip in a well-known camera case, > : I don't see an easy way to keep the descriptions short yet clear. > I don't understand what you are saying at all. Sorry, I'll try again. Since NetBSD uses these strings, I want to make them match the device a bit more, especially for cases where the descriptor string is deficient. That's the case with my camera, which is just `CAMERA' according to the internal vendor string, if I remember. If the Vendor ID string (which NetBSD puts in the kernel) is SoundVision, then the product ID should have a description to match; say, in the case of the existing so-called ``JENOPTIK'' vendor, instead of the present product JENOPTIK JD350 0x5300 JD 350 Camera/mp3 player I'd have something like ``0x5300 Jenoptik JD 350 Camera/mp3 player'' although, as noted, for this case, two other camera products from a different manufacturer share this vendor/product ID combo. This is for the sake of NetBSD and the end user -- FreeBSD does not normally care about this string description. Since this specific example is the ID for more than one product, I'd probably choose a description like `Jenoptik/Pretec multimedia'. Although, with my luck, several camera vendors use this chip... Of course, I need to look where NetBSD uses the product's string, and where it refers to the table from usbdevs, to see where it matters. It's not in the boot-time messages for an attached device, though, as my uaudio vendor wasn't identified with uaudio present in my NetBSD kernel. No, it's not relevant to FreeBSD, but Lennart is cc:ed in these mails. > : Yeah, it's nitpicking. It doesn't matter to D/FBSD, but apparently > : does to NetBSD (and OpenBSD? Haven't checked), so I'd rather do this > : in a way agreeable to NetBSD... > You assume that there's more coordination in the file than there > really is. I'm hoping to introduce coordination, to reduce the differences between the files that make keeping up-to-date more of a hassle than it should be. As in this case, the BSDen share a common base (unlike, say, uaudio where there are significant differences, or more specifically, the audio infrastructure in general), I don't see a reason why all the BSDen can't draw from a single source that's synchronized between them, for the data within, that doesn't change between OSen. Pulling in new code from NetBSD often requires adding entries to usbdevs one or two at a time, and it's easier to just bring everything up-to-date in one swell foop. Apart from the possibly misleading impression given that having an entry means the product really is supported. Or that missing an entry means the opposite. > : Also, in the event that D/FBSD implement a pciconf-like command for > : USB that would search through a database for detailed vendor/product > That's much less needed for usb because you can get real strings from > the usb device, and you can't from the pci devices... I'm thinking of the two devices I showed earlier (mouse and uaudio device) that were missing vendor strings, and in part a product. If this information can't be pulled from the device itself, in hopefully relatively few cases, my feeling is it would be good to fall back on a database which provides more than just the vendor and product numbers. ums0: vendor 0x062a product 0x0000, rev 1.10/0.00, addr 4, iclass 3/1 barry bouwsma happy holidaze
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200412250207.iBP27mQ40936>