From owner-freebsd-usb@FreeBSD.ORG Thu Jan 10 22:13:12 2008 Return-Path: Delivered-To: usb@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9157E16A421 for ; Thu, 10 Jan 2008 22:13:12 +0000 (UTC) (envelope-from Duane.Hesser@gmail.com) Received: from mail.odessaoffice.com (mail.odessaoffice.com [64.146.146.8]) by mx1.freebsd.org (Postfix) with ESMTP id 7180913C457 for ; Thu, 10 Jan 2008 22:13:12 +0000 (UTC) (envelope-from Duane.Hesser@gmail.com) Received: from chevy.androcles.org ([::ffff:64.146.146.203]) (AUTH: CRAM-MD5 dhesser@accima.com, TLS: TLSv1/SSLv3, 256bits, AES256-SHA) by mail.odessaoffice.com with esmtp; Thu, 10 Jan 2008 14:03:08 -0800 id 002EC03C.4786961C.00001EE2 Received: from chevy.androcles.org (localhost [127.0.0.1]) by chevy.androcles.org (8.13.8/8.13.3/8.13.3/1) with SMTP id m0AM33dF091080; Thu, 10 Jan 2008 14:03:04 -0800 (PST) (envelope-from Duane.Hesser@gmail.com) Message-Id: <200801102203.m0AM33dF091080@chevy.androcles.org> Date: Thu, 10 Jan 2008 14:03:03 -0800 From: Duane H Hesser To: Mikhail Teterin , usb@freebsd.org In-Reply-To: <200801091015.17730@aldan> References: <200801090114.56195@aldan> <200801091015.17730@aldan> X-Mailer: Sylpheed version 2.2.6 (GTK+ 2.8.19; i386-portbld-freebsd4.11) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: Subject: Re: BlackBerry (Re: using libusb) X-BeenThere: freebsd-usb@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Duane.Hesser@gmail.com List-Id: FreeBSD support for USB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jan 2008 22:13:12 -0000 On Wed, 9 Jan 2008 10:15:16 -0500 Mikhail Teterin wrote: > = I'm trying to port a suit called "barry", which provides a library > and some = utilities to work with RIM's BlackBerry devices. > > = It compiles cleanly, but fails to find a connected device at run > time. In = fact, it fails to find _any_ devices, even though > ``usbdevs -v'' lists = several including the BlackBerry > > Ok, I see, what's happening... The current implementation of libusb's > BSD support (bsd.c) ignores all devices other than ``ugen'': > > if (strncmp(di.udi_devnames[0], "ugen", 4) != 0) { > /* best not to play with things we don't understand */ > continue; > > And BlackBerry is identified as ``umass'' here :( > > Not sure, how best to solve this -- commenting out the above-quoted > "if" simply leads to a failure later, because the code will look > for /dev/umassX, which simply would not exist -- umass0 is da3 here. It is not difficult to modify the code to which you refer; you must *add* branches for the other drivers, and make sure that ugen-specific code later in the function (and in the calling function) is exercised only for ugen. > But it might be da0 somewhere else, and there is no way to know, > which is which :-( > It might be da0 tomorrow. Devfs has a mind of its own. > But even if one could figure this out and specify the device to the > tool explicitly, daX will not understand ugen's ioctls anyway... > Exactly. Modifying libusb as I described above is an exercise in futility (at least on FreeBSD). I made such modifications a few weeks ago, while attempting to deal with similar problems, but finally allowed csup to overwrite them. All you get is a list of device driver names, and you really don't need libusb for that. In fact, libusb is old and krufty, especially the BSD code, and is intended for Linux, which tends to eschew the Unix I/O model (devices as files). They tell us quite clearly that "GNU's not Unix...is not Unix...is not...[insert infinity symbol here]". If you need to scan for devices, much simpler code will do that. > What a retarded mess... > > We really need the low-level (ugen?) interfaces available for all > USB-devices -- even those, which are /also/ handled by higher-level > interfaces (like ulpt, uscan, umass). As things stand, the > higher-level ones are "greedy" and will prevent ugen from appearing, > even if one wanted to. > I agree completely. It seems to me that, so long as we continue to use (and need) so much Linux application code, which almost always wants ugen, we need some way to allow ugen to attach to *every* device, but withut trashing the Unix-style drivers. Just as you said. The current usb code allows devices which advertise multiple function interfaces to attach to drivers for all of them, but if any one of them attaches, the generic driver is excluded. I have an HP C5240 printer which hooks up as ulpt0, umass0, and would also hook up as uscanner0 if the interface info were added to uscanner.c. It has four interfaces, with class, subclass and protocol ids for each of those items. The fourth interface has class 0xff, subclass 0xff, and protocol 0xff, (vendor defined class) which suggests to me that it might be allowed to also hook up as ugen. The problem is that the ugen driver appears to move in with plow and dozer blade and won't play nice with the other interfaces. I don't know enough about the usb code yet to tame it (or even know if it can be tamed). Does anyonw (Hans?) know whether the ugen driver can be altered to attach to a single interface, just like any other driver, leaving other interface setups alone? > Their names may reflect their additional capabilities (ulpt may also > print, uscan may also scan) but they must all understand ugen's > ioctls. > > The only work-around is to not have umass, etcetera in your kernel, > but that sucks, because one may want to be able to access /some/ > devices as mass-storage, and some others as merely generics... > A similar problem occurs to many of us who have HP printers which hook up (quite properly, it seems to me) on ulpt0. Mine also hooks up on umass0 (to service the flash memory card slots), and would hook up on uscanner0, too, if uscanner.c were modified to recognize it. If we want to use HP's software (HPLIP) to drive the printer we must arrange arrange for it to be ugen. It's easy to leave ulpt out of the kernel config, and apparently some people have solved their HPLIP problems that way, but also leaving umass out and loading it as a module later (which works to connect the printer via ugen). You could try leaving umass out of your config, and loading it as a module, but when I do that, devfs refuses to notice the "hardwired" USB flash memory reader on the computer, and the one on the printer doesn't exist anymore; I lose them both. I am currently using a modifed quirk system which allows a device to be named UGEN_ONLY; all specific interfaces will be ignored and the device will attach as ugen. It is also necessary to add an option (UGEN_ONLY_QUIRKS) to the kernel config to enable this. You're right, this sucks, but at least I can use my printer. I can use the computer-based flash memory slots, too, if if leave cards in the slots at boot time. (That's another issue). > Hans, any hope? Thank you! > > -mi > --------- dhh