It wasn't until the SANE-1.01 release when the function names in the
snapscan backend were changed (e.g. sane_snapscan_start changed to
sane_start, etc) that I could make any meaningfull progress. Prior to that
I could not access the device even though Debug output would clearly show
the mini_inquiry and "add_device" happening properly. Apparently the
old naming convention was dispatching to the stubs instead of the actual
snapscan code! Anyway I can successfully scan Colour, BiLevelColour,
GreyScale and LineArt images quite well using xscanimage. I tried all of
the Twain supported DPI's of 75, 100, 150, 200, 300, 400, 600, 1200, 2400,
4800, 9600 and 19200. Aside from the increasing larger sizes of the images,
which made we wonder if I would have enough disk space while scanning, the
scans all look perfect when viewed using "xv".
There are still several minor problems that I would like to fix before
I submit my changes for inclusion into the next release of SANE.
First I had to completely disable the "send_diagnostic" function.
If I didn't the diagnostic opcode would hang the entire SCSI bus with all
of the disk access lights comming and staying on for 30 seconds or so. Not
a comforting thing to see on the root disk! I don't know if this is
a result of the scanner hanging the bus or the Sun SCSI controller getting
po'ed. Turning off the power to the scanner did not clear the hung bus.
I could not find ANY diagnostic codes in the TWAIN SCSI dumps.
Does anybody have a clue about this? I would especially want to hear from
someone using the VUEGO310 as it is very similar to the Acer 620S.
Second I had to disable the fork of the background child process or else
Solaris would crash with a "BAD TRAP occured in module "SCG" due to an
illegal access to a user address". The debug output showed a trail right
up to the scsi_read in the child process. I found a commented out
"return" just prior to the fork() in snapscan.c line 2876 and uncommented it.
The BAD TRAPs stopped and the scanner began working. Does any of the
"snapscan" backend authors know why that /*return;*/ was still there??
Third, I get an error right after I invoke an xscanimage "Preview" in a
dialog "Failed restore value of option resolution: Device Busy". I
suspect that whatever method is being used to determine when the Scanner is
busy is not applicable with the Prisa 620S and thus it is trying to restore
the scan parameters too soon after the Preview. The Preview operation works
just fine and suprisingly quick too! I would be interested in whether the
"Preview" works OK with other scanner types using the snapscan backend.
Finally the scanner seems to "go to sleep" after about 15 minutes as the
image lamp goes out but the power-on LED says on. On the PC the Twain
driver knows about the sleeping condition and puts up a dialog box telling
me to wait. It then invokes a scanner reset somehow. With SANE it doesn't
even see the scanner when it is sleeping. If a do a scanimage -L twice
the first one will stimulate the scanner to wake up and the second one will
see it. Not a big deal but it would be nice to fix this. I'll have to
reattach the scanner to the PC and take a TWAIN SCSI dump before and after
it goes to sleep to see what they are doing. But, again any clues or advice
would be appreciated.
Regards,
Gary M. Plewa
-- Source code, list archive, and docs: http://www.mostang.com/sane/ To unsubscribe: echo unsubscribe sane-devel | mail majordomo@mostang.com