* G.J.M. KLAVER <gerard at gkall.hobby.nl> [071207 21:10]: > Quoting Gerhard Jaeger <gerhard at gjaeger.de>: > > >On Thursday 06 December 2007 09:18:36 Johannes Ranke wrote: > >>Hi Gerhard and Gerard, > >>(replying to Gerard because I didn't receive Gerhards mail since I am > >>not on the list) > >> > >>Thanks for the suggestion with CONFIG_USB_SUSPEND! I just booted a > >>self-compiled kernel without this option, and scanning works again from > >>the graphical frontends. What I don't understand is why it works from > >>the command line with scanimage, but not with the graphical frontends. > >> > > > >The GUI frontends are checking for the device and the release it. > >This is the point, where the USB subsystem waits some time and decides > >to go to the suspend mode - which the scanners don't like. > > > >scanimage itself, opens the device and scans without giving the USB > >subsystem the chance to go to sleep... > > > >AFAIK, there's a workaround in more recent kernels, but I don't > >recall - maybe Julien? > > > >Another workaround came to my mind: use the scanbutton daemon, > >which checks each 200ms for a pressed scanner button. That way, > >the USB won't also fell asleep... > > > >Ciao, > >Gerhard > > > >-- > >sane-devel mailing list: sane-devel at lists.alioth.debian.org > >http://lists.alioth.debian.org/mailman/listinfo/sane-devel > >Unsubscribe: Send mail with subject "unsubscribe your_password" > > to sane-devel-request at lists.alioth.debian.org > > > > IIRC in SANE CVS there is also a patch for the suspend mode problem
Ah, would this have worked with kernel 2.6.20 with USB_SUSPEND though? I am sure there are still people using such kernels (as I was), and when they occasionally want to scan they will not know how to work around their problem. I am a little hesitant to file bug reports against all the graphical frontends from xscanimage via quiteinsane, kooka and whoknowswhatelse in the Debian BTS. Johannes > > m.vr.gr. > Gerard Klaver
