Date: Thu, 10 Jan 2008 14:03:03 -0800 From: Duane H Hesser <Duane.Hesser@gmail.com> To: Mikhail Teterin <mi+kde@aldan.algebra.com>, usb@freebsd.org Subject: Re: BlackBerry (Re: using libusb) Message-ID: <200801102203.m0AM33dF091080@chevy.androcles.org> In-Reply-To: <200801091015.17730@aldan> References: <200801090114.56195@aldan> <200801091015.17730@aldan>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 9 Jan 2008 10:15:16 -0500
Mikhail Teterin <mi+kde@aldan.algebra.com> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200801102203.m0AM33dF091080>