Hi,
Steffen Kluge wrote:
> Hi,
> I've been playing a bit with my Acer Prisa 620ST and the new
> snapscan backend. This is what I found:
>
> [...]
> - Steve's new snapscan backend (snapscan-20000514) does a
> remarkable job, the transparency unit works well and the three
> channels are aligned perfectly without post-processing.
Good. I have only tried this software with my own Acer 610plus, so feedback about
any failures on other models (or even on a 610plus) would be appreciated.
> [a detailed description of some strange jerking behaviour during preview scans
> with xsane]
I get a number of problems using xsane, but I haven't yet investigated if these are
indeed xsane problems, or driver ones. I am using xsane 0.59.
-I've never had pauses during preview scans, but I get complete lock ups - I can
leave the machine for a while and it never seems to restart. These usually seem to
occur if I wave the mouse around, and provoke some activity in the xsane preview
window during scanning. If I don't touch the machine all is usually well.
- If I preview in B/W and then try again in colour the preview goes crazy. If I stop
and restart xsane, and select colour preview first, it previews just fine.
- If I abort a preview scan in mid scan and then zoom the preview window it goes
crazy.
I haven't really played with xscanimage. xsane is a superior product, even if it
currently has some some. I feel it is to be debugged, rather than avoided, so I have
only worked with xsane.
> 0.59, both versions behave this way. I also recompiled sane
> and xsane with no optimisations (I thought that might be a
> good idea since I'm using an Athlon), but it made no
> difference.
I'm using a 700MHz Athlon with 256MB RAM. I think the amount of free RAM is more
likely to be a significant factor between different machines than either speed or
processor type - I could be wrong, of course.
> - I can't for the heck of it scan at resolutions higher than
> 600dpi, although the scanner supports up to 19200dpi. The
> program (scanimage, xscanimage or xsane) just freezes (enters
> an endless loop) in function measure_transfer_rate. I can
> follow the loop in the debugger but I don't understand the
> program logic so I can't say what's going wrong. I believe
> (but am not sure) that I could use higher resolutions with
> previous versions of the backend.
I can reproduce this effect, but I have yet to investigate the cause. I don't get it
as a clean repeatable effect, the way you describe it, though. Only sometimes, and
seemingly only at the higher resolutions, does this happen. I think the logic for
sizing and handling the buffer for merging the chroma offsets falls over during the
small speed test operation, for some reason. The speed test is not performed over an
exact number of scan lines (I think it uses a nice round number of bytes, rather
than a whole number of scan lines). I think this is the cause of the problem, but I
should get some time to investigate next week.
> - I'm doing all this with sane-1.0.2, kernel-2.2.14, sg-3.0.15,
> and the host adapter/scanner look like this:
>
> scsi0 : Tekram DC395U/UW/F DC315/U V1.10, 1999/07/19
> scsi : 1 host.
> Vendor: Color Model: FlatbedScanner_9 Rev: 0117
> Type: Scanner ANSI SCSI revision: 02
> Detected scsi generic sg0 at scsi0, channel 0, id 2, lun 0, type 6
I'm using RH 6.2 with the latest kernel updates, and an Adaptec 2940. I think this
is a fairly stable driver, though I beleive it has seen some recent changes. It
seems to be working OK for me.
Steve
-- Source code, list archive, and docs: http://www.mostang.com/sane/ To unsubscribe: echo unsubscribe sane-devel | mail majordomo@mostang.com
This archive was generated by hypermail 2b29 : Sat May 27 2000 - 05:34:47 PDT