[sane-devel] Canon LIDE 220
stef.dev at free.fr
Tue Jun 23 04:40:11 UTC 2015
On 21/06/2015 23:04, John S. Weber wrote:
> 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.
> It was not found by the sane shipped with Ubuntu 15.04, so I installed
> this ppa:
> 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.
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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the sane-devel