cvs commit: src/sys/dev/usb usbdevs uscanner.c

[Luigi Rizzo]

On Mon, Oct 22, 2007 at 10:17:49PM -0600, M. Warner Losh wrote:
> In message: <471D576C.30601 at FreeBSD.org>
>             "Bruce M. Simpson" <bms at FreeBSD.org> writes:
> : Luigi Rizzo wrote:
> : >   Log:
> : >   Add entries for Epson multifunction scanner/printer/card readers,
> : >   with all functions supported.
> : 
> : Thanks for doing this. Any plans to MFC?

asap - in fact i have been running this code on 6.2 since late august.
 
> : I will try to test this change on 6.2 with my Epson CX-3650. Currently I 
> : have to unload uscanner and/or ulpt, and physically replug the usb cable 
> : into a different port, to switch between ulpt and uscanner functions on 
> : the device.
> 
> I've been debating a doing a mass MFC.  I've been using FreeBSD
> current's usb stack, with a couple of hacks, in -stable for a few
> weeks now.

that's also an interesting thing as it would also clean up the
codebase a bit. If re@ agrees this might be a good thing to do,
even though it might require a bit more time for code to stabilize
before 6.3 is released.

One difference that we found (not sure where it was introduced)
between -current and RELENG_6 is with the handling of usb transfers
shorter than expected - these happens e.g. with some webcams supported
by the linux-gspca driver (built using linux-kmod-compat - i know
that one doesn't build as is on -current but we have some local changes
to make it work).

Fabio Checconi (in Cc, fabio at gandalf.sssup.it) should have more details,
but in summary the situation should be as follows:
on RELENG_6, these short transfers are handled same as regular ones,
i.e. data is transfered and the caller gets a success return code;
on -current the usb stack returns an error in case it sees them
(the data phase is correct though).

cheers
luigi