Bug 56917 - SANE backend bug?
SANE backend bug?
Product: Red Hat Linux
Classification: Retired
Component: sane-backends (Show other bugs)
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Tim Waugh
David Lawrence
Depends On:
  Show dependency treegraph
Reported: 2001-11-29 22:52 EST by Michal Jaegermann
Modified: 2007-04-18 12:38 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2004-12-08 10:13:33 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
patch to replace i/o error from ADF with "scanned ..." message (664 bytes, patch)
2001-11-29 22:54 EST, Michal Jaegermann
no flags Details | Diff

  None (edit)
Description Michal Jaegermann 2001-11-29 22:52:26 EST
Description of Problem:

At least with microtek2 backend when using automatic document feeder
xsane informs that it does not have anymore a paper in a feeder
by popping out an alert with a text, roughly, "Failed to start scanner.
I/O error!".  Regular users are at least confused.

This may actually be an error in sane-backends which seem to have
a habit to signal any unusual condition by raising an I/O error.

I attach a gross workaround which makes xsane to come out with
an informational alert instead which says something like "Scanned
(so many) pages" instead.  A side effect is that if we will get
a real I/O error _after_ some pages from ADF were already scanned
then we will get "Scanned ..." as well.  In this application this
is vastly preferrable state of affairs.
Comment 1 Michal Jaegermann 2001-11-29 22:54:05 EST
Created attachment 39126 [details]
patch to replace i/o error from ADF with "scanned ..." message
Comment 2 Tim Waugh 2001-12-14 04:42:21 EST
From your debugging of this, can you confirm that the microtek2 backend is 
returning SANE_STATUS_NO_DOCS at this point? (If not it's a backend bug.)
Comment 3 Michal Jaegermann 2001-12-14 10:54:45 EST
I suggested in my original report that a simpicistic behaviour of
a backend (I do not know if this is limited to microtek2 or more widespread)
is actually responsible.  As I understand that code it just shouts
"I/O error" at every unusual situation.

Unfortunately I had an access to this scanner for a very limited time
(and to another scanner from HP which does not really work either with
Linux nor with a manufacturer provided Windows software).

A patch I included is just a workaround for a bad behaviour but it makes
the whole thing acceptable from a point of view of the end user and I do
not see how it really harms anything in this interactive by its nature
procedure of scanning.  Throwing at user "scanner failed to start" at the
end of every scan which was using ADF is not a good thing to do; it still
does that, rightly so, in most situations when errors are different that
"no more pages to scan".

An alternate, correct, fix would be to carefuly review the whole code and
ensure that all backends are smarter in their reporting but this is
a long range project.
Comment 4 Tim Waugh 2001-12-14 11:02:16 EST
Yes.  Well, since neither of us have the hardware to test out any potential 
fix (rather than work-around), I'm going to close this as WONTFIX for now.
Comment 5 Michal Jaegermann 2001-12-14 13:02:04 EST
Pity; because a reaction I got from "end users", which are not interested
in internals of SANE, to the current state of things was "absolutely 
unacceptable".  No amount of explanations and hand waving was good enough.
A long range solution is to pester SANE project to mend their ways but
there is a need for a short term resolution _right now_.
Comment 6 Tim Waugh 2001-12-14 13:13:07 EST
I've reported it to the SANE developers.  Reassigning to sane-backends, in 
hopes that the backend maintainer will produce a patch..

I'd rather not just apply the work-around, since it has the side-effect of 
masking real problems as well.

Note You need to log in before you can comment on or make changes to this bug.