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

Luigi Rizzo rizzo at
Mon Oct 22 23:17:20 PDT 2007

On Mon, Oct 22, 2007 at 10:17:49PM -0600, M. Warner Losh wrote:
> In message: <471D576C.30601 at>
>             "Bruce M. Simpson" <bms at> 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 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).


More information about the cvs-src mailing list