Date: Sat, 25 Dec 2004 20:29:52 -0700 (MST) From: "M. Warner Losh" <imp@bsdimp.com> To: freebsd-misuser@NOSPAM.dyndns.dk, freebsd-misuser@remove-NOSPAM-to-reply.NOSPAM.dyndns.dk Cc: lennart@augustsson.net Subject: Re: getting vendor IDs Message-ID: <20041225.202952.80502292.imp@bsdimp.com> In-Reply-To: <200412250207.iBP27mQ40936@Mail.NOSPAM.DynDNS.dK> References: <200412242236.iBOMaig32845@Mail.NOSPAM.DynDNS.dK> <20041224.155218.123609434.imp@bsdimp.com> <200412250207.iBP27mQ40936@Mail.NOSPAM.DynDNS.dK>
next in thread | previous in thread | raw e-mail | index | archive | help
In message: <200412250207.iBP27mQ40936@Mail.NOSPAM.DynDNS.dK>
Barry Bouwsma <freebsd-misuser@remove-NOSPAM-to-reply.NOSPAM.dyndns.dk> writes:
:
: 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.
But NetBSD only uses these strings if there's no driver to claim the
device. Otherwise, it uses the same method as FreeBSD.
: 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.
Yes. It is better to know and understand where NetBSD uses things
before going off on assumptions.
: 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.
I think I made my point badly: NetBSD developers do not coordinate
things well, so there tends to be a lot of different conventions in
place.
: 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
That code is already in place. Please, go look at the code before
speculating.
Warner
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20041225.202952.80502292.imp>