[sane-devel] On CONFIG_USB_SUSPEND and black scans

[Julien BLACHE]

JKD <jkdsoft at gmail.com> wrote:

Hi,

> 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.

OK, thanks. I hardly see how it could have changed anyway, given that
the device ID is used at the bus level to address the device too. That
would have been funny. So that one's ruled out for good.

> 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

Enumerating the devices wakes them up, that's what you see.

> 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.

Connections remain ? Is the connection still open when the device goes
to sleep, or is it closed before that ?

Could we be failing to catch an error here ?

> 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

Actually there are no issues with libusb; the auto suspend feature is
all handled by the kernel and is transparent as far as libusb is
concerned (that's the theory, obviously).

> compiling SANE, some inline usb functions from kernel sources are included
> which conflict with current kernel version. (Could be?)

The backends (sanei_usb, really) use only the header provided by
libusb, and there are no inline functions nor macros in this header
(and it doesn't include a usb-specific kernel header).

There's no reason for a rebuild to fix this problem -- I've even got
Aurélien Jarno (Debian libusb maintainer) to check that the other day.

JB.

-- 
Julien BLACHE                                   <http://www.jblache.org> 
<jb at jblache.org>                                  GPG KeyID 0xF5D65169