[#315752] Sane 1.0.27 breaks canoscan lide 100

View Trackers | Bugs | Export CSV

2017-06-08 09:57
Submitted by:
Antonio Orefice (kokoko3k-guest)
Assigned to:
Gerhard Jaeger (gja-guest)
backends (drivers)
Sane 1.0.27 breaks canoscan lide 100

Detailed description
As i installed the new sane, my scanner, canoscan lide 100 (backend genesys), produces pages with a vertical black bar with inverted colors in the middle (on a white page the bar is just black, of course).
Reverting to sane 1.0.25 AND removing ~/.sane/, make things work again.

Followups: Sort comments antichronologically

Date: 2017-07-18 19:34
Sender: Erich Eckner

I have the same issue.
I did a 'git bisect' and it seems, commit bd0b0cd218504868f32962a5558449956c8ce242 is the bad guy:

bd0b0cd218504868f32962a5558449956c8ce242 is the first bad commit
commit bd0b0cd218504868f32962a5558449956c8ce242
Author: Stéphane Voltz <>
Date: Thu Mar 3 21:39:25 2016 +0100

use rewind instead of slow_back_home

- if required by flags, do a rewind instead a slow_back_home that pollutes
shading settings

I hope, this helps in resolving the issue :-)
Date: 2017-11-18 23:26
Sender: Juan Francisco Cantero Hurtado

I confirm the same problem with a Canon LiDE 200. Reverting the patch, the scanner works correctly again.
Date: 2017-12-29 18:31
Sender: Christoph Müller

I also got a canon lide 100 and have the same problem.

Is there another way to fix this? I got the problem on Arch and OpenSUSE Tumbleweed (both on .27). Since it seems that a new version takes some time (nearly 2 years from .25 to .27) my scanner would be basically broken for the foreseable future.

If only reverting a patch, which lies beyond my ability, is a viable solution i would have to get a new device.
Date: 2017-12-29 20:18
Sender: Juan Francisco Cantero Hurtado

Christoph, report to your distro maintainers. They could add a patch in the package. This is the offending patch;a=commitdiff;h=bd0b0cd218504868f32962a5558449956c8ce242
Date: 2017-12-30 12:29
Sender: Christoph Müller

Thanks for the hint Juan. I reported the issue for OpenSUSE Tumbleweed. After reading the Arch Guidelines i think reporting the Bug there is pointless because they specifically state that they do not deal with Upstream Bugs.
Date: 2017-12-30 22:45
Sender: Juan Francisco Cantero Hurtado

Arch also includes sometimes patches. The sane package includes a patch for a kodak scanner. Don't be afraid when you need to report a bug to the maintainer, they can always just close the bug.
Date: 2018-03-31 16:22
Sender: Richard Ash

I have just reproduced this bug on x86_64 Gentoo using the 1.0.27 release, CanoScan LIDE 200 scanner. For me the bar was not always black but sometimes blue or cyan, but always in the same place.

It didn't show up straight away - I got several good scans last night and this morning (turning PC off between sessions) and some this afternoon before the problem started, but once it started no way to make it work again, including trying the remove calibration button.

I can confirm that reversing;a=commitdiff;h=bd0b0cd218504868f32962a5558449956c8ce242 and deleting the calibration data makes the scanner work again without the vertical stripe in the middle of the image.

To me there seem to be two problems with this commit:
1. It changes some scanners from using dev->model->cmd_set->slow_back_home() to using dev->model->cmd_set->rewind() and they don't like it.
2. Previously scanners which did not have dev->model->cmd_set->rewind() would get dev->model->cmd_set->slow_back_home(), and now they don't get anything, because the case where dev->model->cmd_set->rewind() is false (null?) is not handled.
Both cases will change the system behaviour.

I added some debugging to see which the Canon LIDE 200 falls in to, and it is the first one - it has dev->model->cmd_set->rewind() defined, but using it results in a broken calibration. Unfortunately this means that I can't propose a fix to use slow_back_home() when rewind() is not implemented (although I think that might be a good idea for the benefit of gl646, gl841, gl843, gl846 users, who presently get neither rewind() (not implemented) nor slow_back_home() because of this change), because it doesn't happen on my hardware.

What I did notice is that rewind() was only added in the same run of commits (;a=commitdiff;h=de635a32f9638f5fad5806ab5de9498f5fa47ca9 and;a=commitdiff;h=3dee0f8d48e26e3aceb0243d03199af5870f30e2), and identically for the GL124 and GL847, so I wonder if this was actually tested on both chipsets? If someone has a GL124(Canoscan LIDE 110, 120, 210, 220) and that works (no stripe on calibrating) with 1.0.27 as it stands, then that is a good indication that the correct fix is to remove the implementation of rewind() for the GL847, and leave the code in sane_genesys alone.

I had a trawl of bug reports and I can only find this bug for LIDe 200 and LIDe 100 scanners, i.e. GL847 devices. I cannot find it reported for GL124(Canoscan LIDE 110, 120, 210, 220) devices.
This suggests to me the correct fix is for GL847 not to implement rewind?

Attached Files:

Size Name Date By Download
209 KiBsane-1.0.27.png2017-06-08 09:57kokoko3k-guestsane-1.0.27.png
207 KiBsane-1.0.25.png2017-06-08 09:57kokoko3k-guestsane-1.0.25.png


Field Old Value Date By
CategoryNone2017-06-08 13:35olaf-guest
assigned_tonone2017-06-08 13:35olaf-guest
File Added7487: sane-1.0.25.png2017-06-08 09:57kokoko3k-guest
File Added7488: sane-1.0.27.png2017-06-08 09:57kokoko3k-guest
Powered By FusionForge