[sane-devel] sane_cancel on HP 5590

[m. allan noah]

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"