[sane-devel] [Q] Cancelling scans from hardware side
Olaf Meeuwissen
olaf.meeuwissen at avasys.jp
Fri May 11 04:48:30 UTC 2007
Hi,
I'm working with a (TCP/IP networked) device that supports cancelling
of scans from the hardware side. The device signals the client (i.e.
my backend) that the scan is cancelled.
I figured that I would just return SANE_STATUS_CANCELLED but the SANE
spec says that sane_start() and sane_read() return this status after
sane_cancel() was called. That notwithstanding my backend returns a
SANE_STATUS_CANCELLED whenever somebody pushes the *device*'s cancel
button.
I've checked how some of the frontends deal with (Debian GNU/Linux,
testing/unstable) this but it seems every frontend has its own idea of
what to do :-(
scanimage calls sane_cancel() after it gets SANE_STATUS_CANCELLED
back from sane_read() --> all's well
(sane-backends-1.0.18)
xscanimage does the same as scanimage based on source code review
(sane-frontends-1.0.14)
xsane pops up a message dialog to inform the user that the
scan was cancelled. After closing the dialog, nothing
in particular seems to be done and you need to quit the
application before the device becomes usable again
(xsane-0.991)
kooka spins into an infinite loop (because of incompleteness
of the implementation, kdegraphics-3.5.5)
Questions:
1) Is SANE_STATUS_CANCELLED the right thing to return? If not, what
is?
# FWIW, SANE_STATUS_EOF looks like the best alternative but will
# probably lead to broken images ...
2) How should frontends behave when they get SANE_STATUS_CANCELLED
when sane_cancel() was *not* called?
Looking forward to your feedback,
--
Olaf Meeuwissen FLOSS Engineer -- EPSON AVASYS Corporation
FSF Associate Member #1962 sign up at http://member.fsf.org/
GnuPG key: 6BE37D90/AB6B 0D1F 99E7 1BF5 EB97 976A 16C7 F27D 6BE3 7D90
Penguin's lib! -- I hack, therefore I am -- LPIC-2
More information about the sane-devel
mailing list