Bug 56917

Summary: SANE backend bug?
Product: [Retired] Red Hat Linux Reporter: Michal Jaegermann <michal>
Component: sane-backendsAssignee: Tim Waugh <twaugh>
Status: CLOSED UPSTREAM QA Contact: David Lawrence <dkl>
Severity: medium Docs Contact:
Priority: medium    
Version: 7.2   
Target Milestone: ---   
Target Release: ---   
Hardware: i386   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2004-12-08 15:13:33 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
patch to replace i/o error from ADF with "scanned ..." message none

Description Michal Jaegermann 2001-11-30 03:52:26 UTC
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-30 03:54:05 UTC
Created attachment 39126 [details]
patch to replace i/o error from ADF with "scanned ..." message

Comment 2 Tim Waugh 2001-12-14 09:42:21 UTC
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 15:54:45 UTC
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 16:02:16 UTC
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 18:02:04 UTC
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 18:13:07 UTC
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.