[sane-devel] On CONFIG_USB_SUSPEND and black scans
Julien BLACHE
jb at jblache.org
Tue May 1 08:33:36 UTC 2007
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.
It might be that both 1 and 2 are completely off and there's something
else happening. Consider that a braindump after reading the bug logs.
Please add your ideas, observations and experiments so we can fix that
for good.
Thanks,
JB.
--
Julien BLACHE <http://www.jblache.org>
<jb at jblache.org> GPG KeyID 0xF5D65169
More information about the sane-devel
mailing list