Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 95019 - >=media-gfx/sane-backends-1.0.15 - scanimage + umax_pp: scanner initializes but does not scan
Summary: >=media-gfx/sane-backends-1.0.15 - scanimage + umax_pp: scanner initializes b...
Status: RESOLVED UPSTREAM
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: [OLD] Library (show other bugs)
Hardware: x86 Linux
: High normal (vote)
Assignee: Patrick Kursawe (RETIRED)
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-06-04 06:35 UTC by SarahB
Modified: 2005-06-04 12:30 UTC (History)
0 users

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description SarahB 2005-06-04 06:35:33 UTC
I have a HP Precision Scanjet 3200C. This device works well with the sane 
umax_pp backend since years (and distributions). After a new gentoo install, 
the scanner behaves abnormal. The scanner init works (scanimale -L) but when I 
want to do a scan, then scanimage (and xscanimage,xsane,kooka,...) waits for 
the data from the scanner and don't get them. The scanner dont scan. The device 
works well through vmware with win98 and on other windows OS.  
 
I searched for the reasons of that behaviour. I found out that the umax_pp test 
tool (included in sane-backends) works as expected. Then I merged an older 
version 1.0.13-r3 and there are no problems. I think some code in the new 
umax_pp backend (1.0.15) is messed up. 
 
have a nice day, 
sarah 

Reproducible: Always
Steps to Reproduce:
1.emerge ">=media-gfx/sane-backends-1.0.15" 
2.setup umax_pp scanner with use of ppdev 
3.scanimage -d umax_pp:/dev/parport0 
 
Actual Results:  
scanimage waits for data, but it doesn't get them and the scanner don't move. 

Expected Results:  
do the scan :-D
Comment 1 Patrick Kursawe (RETIRED) gentoo-dev 2005-06-04 12:30:28 UTC
This problem has to be addressed upstream (if it's broken in their sources and
not in our ebuild). Looks like they are already aware of the problem, see
https://alioth.debian.org/tracker/index.php?func=detail&aid=301578&group_id=30186&atid=410366
Thanks for reporting, anyway.