uscanner and ulpt over the same connection (Re: BlackBerry)

[Marcin Cieslak]

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