Date: Sat, 12 Jan 2008 01:51:02 +0100 From: Marcin Cieslak <saper@system.pl> To: freebsd-usb@freebsd.org Cc: Duane H Hesser <Duane.Hesser@gmail.com> Subject: Re: uscanner and ulpt over the same connection (Re: BlackBerry) Message-ID: <47880EF6.40804@system.pl> In-Reply-To: <200801101800.26311.mi%2Bmill@aldan.algebra.com> References: <200801090114.56195@aldan> <200801091015.17730@aldan> <200801102203.m0AM33dF091080@chevy.androcles.org> <200801101800.26311.mi%2Bmill@aldan.algebra.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Mikhail Teterin wrote: > четвер 10 січень 2008 05:03 по, Duane H Hesser Ви написали: >> 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. I think "must arrange to be ugen" is I think too much - shouldn't we say "should we make this interface think it is talking via libusb to the proper endpoint"? I guess there are two problems with getting libusb-only applications to work on whatever shiny new USB stack we come up: 1. Get the scanning and device detection properly 2. Provide nice way to use control and interrupt endpoints using FreeBSD syscalls. I've had a quick look at sane, libgphoto2 and hplip they don't really use all very complicated logic - they just plain write to the pipes. For sane it is a matter of getting sanei_usb interface right - for libgphoto2 everything is in one file only (libgphoto2_port/usb/libusb.c), hplip has interesting stuff in io/hpmud/musb.c. I think those above are two different problems - solving #1 in a nice way - for example by doing bus enumeration usb(4) controller interface and then access provided via FreeBSD devices - will allow us to keep existing /dev/umassX naming scheme without the need to provide raw /dev/usbX.Y.Z access. I think it is realistic to have our own "libusb" (API-compatible but does not have to be related to the original project). > If both are currently available via the same USB cable, then it is already a > good improvement /and/ it should be easy to add ugen to the mix too -- we > might not need to wait for Hans' full and comprehensive rework to get > this... I have looked at the berry code and what I see is that most of the controller.cc and usbwrap.cc job is already done by the FreeBSD kernel and actually we probably might need a tiny Blackberry driver doing something like probe.cc and plug this easily into the application. A real test how nice is C++ object encapsulation :-) Can you send the udesc_dump (in ports/sysutils) output of a Blackberry and multifunction HP devices? My dream solution for control/interface would be if we could provide chipset-specific interface on top of our stack like ECP (/dev/uprinter0.ecp or whatever) or chipset support (/dev/uniash0), providing just "write register" and "read register" like operations. --Marcin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?47880EF6.40804>