From owner-freebsd-usb@FreeBSD.ORG Sun Dec 26 03:32:18 2004 Return-Path: Delivered-To: freebsd-usb@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 56A8C16A4CE for ; Sun, 26 Dec 2004 03:32:18 +0000 (GMT) Received: from harmony.village.org (rover.village.org [168.103.84.182]) by mx1.FreeBSD.org (Postfix) with ESMTP id 75B7043D45 for ; Sun, 26 Dec 2004 03:32:17 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.13.1/8.13.1) with ESMTP id iBQ3TL25071216; Sat, 25 Dec 2004 20:29:22 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Sat, 25 Dec 2004 20:29:52 -0700 (MST) Message-Id: <20041225.202952.80502292.imp@bsdimp.com> To: freebsd-misuser@NOSPAM.dyndns.dk, freebsd-misuser@remove-NOSPAM-to-reply.NOSPAM.dyndns.dk From: "M. Warner Losh" 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> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: usb@freebsd.org cc: lennart@augustsson.net Subject: Re: getting vendor IDs X-BeenThere: freebsd-usb@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: FreeBSD support for USB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Dec 2004 03:32:18 -0000 In message: <200412250207.iBP27mQ40936@Mail.NOSPAM.DynDNS.dK> Barry Bouwsma 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