[sane-devel] On CONFIG_USB_SUSPEND and black scans

[JKD]

El Tue, 01 de May de 2007, a las 10:33:36AM +0200, Julien BLACHE dijo:
> Hi,
> 
> After looking at a couple of bug logs describing the issues users are
> having with SANE and CONFIG_USB_SUSPEND, I have 2 theories that need
> to be confirmed; it'd be nice if someone could take a look at the
> second one, as I don't have the hardware to test right now.
> 
>  1 - Scanners, like children, don't like to be put to sleep. Bad
>      scanners, bad bad bad ! No chocolate cake for them.
> 
>      Seriously though, might be that the scanner looses its settings
>      or something.
> 
>  2 - Seeing how scanimage always succeeds, it may be that the scanner
>      identifier on the bus changes every time it's put to sleep and
>      woken up again.
> 
>      scanimage identifies the scanner and then immediately proceeds
>      with the scan, leaving no time for the kernel to suspend the
>      scanner.
> 
>      The graphical frontends identify the scanner(s), getting back
>      their SANE device string (backend:libusb:bus:dev) and using this
>      device string to start a scan later on, once the user has choosen
>      the scanner he wants to use, defined the settings for the scan,
>      etc.
> 
>      This indeed leaves plenty of time for the kernel to suspend the
>      device. Once woken up, the scanner's identifier on the bus will
>      change, thus the device string isn't valid for referring to this
>      scanner anymore (the dev part isn't valid anymore).
> 
>      This looks odd because we should be getting an error back from
>      libusb if this is what happens, and this error should come back
>      to the frontend as SANE_STATUS_INVALID or SANE_STATUS_IO_ERROR.
> 

That means that typing lsusb two times in console we would get different
bus and dev values if there is a considerable amount of seconds between
each command. I've checked that possibility and these values don't
change.

I've realised that in last kernel versions lsusb command seems to reset
all listed devices "which aren't openned by a proccess" (heads start to
move and go back home). This happens every time usb_find_devices() is
called so it happens when typing scanimage -L or before choosing device
in xsane. Anyway, bus and dev values don't change unless usb cable is
replugged.

What I remember testing ubuntu feisty 7.04 is that usb control
transfers work but usb bulk transfers return zeroes. So connection to
the device remains but due to unknown reason retrieved bulk data is
null. That explains that in some scanners, chipset can be programmed
(through control transfers) making a real scan but image is totally black.

After upgrading my debian to kernel 2.6.21.1, I got a black image with
hp3900 backend included in libsane-extras package. So I merged backend
in the current SANE stable branch 1.0.18 and compiled it, fixing the
problem (at least with hp3900 backend). I fixed the same problem in
ubuntu feisty compiling backend with current kernel version.

What I find rare is that I didn't find any information in libusb project
referring to this issue in its version 1.1.12 so, I think that when
compiling SANE, some inline usb functions from kernel sources are included
which conflict with current kernel version. (Could be?)

That's my experience

May be other backends maintainers can check that making a new
compilation with kernel 2.6.21 the problem is fixed.

Jonathan Bravo Lopez