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
