On 2/27/08, Ilia Sotnikov <hostcc at gmail.com> wrote: > On Tue, Feb 26, 2008 at 9:41 PM, m. allan noah <kitno455 at gmail.com> wrote: > > sane_cancel is meant to be called asynchronously, so it probably > > should not send any commands to the scanner. > > sane_read should probably check a 'no longer scanning' flag, and do > > whatever cleanup is required. > > > > take it away Ilia :) > > > I agree, the sane_cancel() function from the backend doesn't fully > conform to SANE standard - it tries to send cancel command to the > scanner IMMEDIATELY. > > > > > I am trying to cancel a page scan. so i call sane_cancel while > > > scanning is in progress > > > but the application get stuck on the next sane_read, > > > instead of return SANE_STATUS_CANCELLED > > > > > > Fixing the synchronous nature of the backend's sane_cancel() function > could make the whole picture cleaner and should be done to follow the > SANE standard. However, while experimenting with the scanner I noticed > that it's very sensitive to data reading. When only partial data was > read from the device and a command > then sent to it the device was hanging in most cases. > > At this moment, you should avoid calls to sane_cancel() while working > with such a scanner. Or, if that's somewhat urgent for you, I could > prepare the patch. > > I think that device internals is rather simple in terms of > functionality to reduce production prices. The same decision could be > made from looking to the command set and to the absence of paper > sensor on the ADF unit. That said, office / workgroup HP scanning > devices are not perfect from technical point of view. >
this is not unusual for cheap scanners. it is probably ok to have the next sane_read call block and loop, sending image to /dev/null until the end of page, stop the batch, and return CANCELED. allan -- "The truth is an offense, but not a sin"
