On 21/06/2015 23:04, John S. Weber wrote:
Hi,
I recently purchased a Canon LIDE 220 as it was claimed to be support
by sane. I put the USB code (04a9:190f) into the Scanner Search
Engine at the sane.org <http://sane.org> and it yielded this page
which says support is complete.
http://www.sane-project.org/cgi-bin/driver.pl?manu=&model=&bus=any&v=04a9&p=190f
It was not found by the sane shipped with Ubuntu 15.04, so I installed
this ppa:
ppa:rolfbensch/sane-git
And updated. The scanned was then recognized by the xsane, et al. It
mostly gave errors alluding to an invalid device. When it did try to
scan, the head would go to the far end and required unplugging the USB
cable to get it to stop banging at the end. Sometimes, not often, it
would work fine. I did a bunch of reading and I was able to fix things
by setting sane debug variables. One site suggested this and it worked:
export SANE_DEBUG_GENESYS=255
export SANE_DEBUG_GENESYS_LOW=255
export SANE_DEBUG_GENESYS_GL124=255
scanimage -d genesys -l 0.0 -t 0.0 -x 90 -y 140 --resolution 1200
--mode Color >scan.pnm 2>scan.log
I've narrowed it down to just
export SANE_DEBUG_GENESYS_LOW=8
From my reading, I believe there is a race condition more exposed by
faster hardware. I have new, fast hardware. My libsane version
is 1.0.25-git20150612-vivid0 on Ubuntu 15.04.
Debug levels are defined like this for genesys_low:
genesys_low.h:#define DBG_io 6 /* io functions */
genesys_low.h:#define DBG_io2 7 /* io functions that are
called very often */
genesys_low.h:#define DBG_data 8 /* log image data */
So if you get the problem at log level below seven, we must look at
DBG_data usage in genesys_low.c . But here isn't on. So try 7 and 6 as
debug levels. Once we know the exact kind of logging level that fix this
timing issue, the next step is to remove this messages one by on until
you find the one that makes difference. I haven't seen nothing obvious,
so experimenting/testing is needed.
sanei_genesys_wait_for_home(), sanei_genesys_set_buffer_address()
and sanei_genesys_write_ahb functions() are printing messages in the
middle of the code and are first candidates to try, in this order.
At this point the scanner is working reliably with no bad behavior.
I am having one issue which seems like a driver bug. Using Xsane
through gimp, set to grayscale 300 and 1200 dpi, the scan is fine. At
600dpi the pixel dimension of the scan is correct, but the lengthwise
aspect ratio is stretched so that only maybe 2/3 of a letter size is
actually scanned and it's stretched to letter size. The scanner head
only moves across the top ~2/3 of the scanned page.
There is a flaw in the backend design regarding both gl124 an gl847
support. The supported models have a maximum motor speed higher (900
dpi) than the lowest optical resolution. I need to redesign things to
work around that. The less complicated would be to scan several lines at
900 dpi then crop down data. This involves quite some work.
Let me know what other info I can provide, or if there's already an
answer that I've missed, I'll be glad to be pointed in the right
direction.
Thanks,
John
Regards,
Stef
--
sane-devel mailing list: sane-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/sane-devel
Unsubscribe: Send mail with subject "unsubscribe your_password"
to sane-devel-requ...@lists.alioth.debian.org
