[sane-devel] [plustek] follow-up for Epson Perfection 1250/Photo 64-bit issue
paulepanter at users.sourceforge.net
Mon Feb 11 09:35:26 UTC 2013
thank you for following up on the sane-devel mailing list.
Could you please make sure not to send any HTML message, and just plain
text, as this is what the netiquette suggests .
Am Sonntag, den 10.02.2013, 10:55 +0100 schrieb Gérard van der Veen:
> I entered a bug in the tracker
please always mention the bugs right away. Ǵerard means issue #314019
 in the Alioth bug tracker.
> and got a comment by Paul Menzel
> "I think the tracker is not used a lot anymore by the current developers.
> Please bring your issue up to the sane-devel list"
As Allan commented in the tracker issue (Alioth unfortunately does not
offer to reference certain comments.), my statement was incorrect. The
tracker is still used. But as Stef wrote to the sane-devel list,
bringing issues up to the list is fine too.
> As the problem is absent in sane 32-bit, and permanent in 64-bit, it
> could well be a development issue.
> in the tracker it reads:
> [#314019] my scanner has a problem in the 64-bit systems but works
> fine with the same systems in 32 bit
> Scanning several pages with my flatbed scanner works fine for the first
> two pages; the subsequent pages will have wide coloured vertical bands
> in the background (black for a grayscale scan).
> This is true for the 64-bit versions of Fedora 16, 17 and 18; with the
> 32-bit versions of the mentioned distributions there is no problem.
> Scanning using xsane or simple-scan produce both the misbehaviour.
In Simple Scan does that happen also when clicking on »New« after every
Simple Scan stores a log file under `~/.cache/simple-scan/`. Do you see
any interesting in there?
> After leaving the graphical fronted and it's restart one can again scan
> two pages properly.
What is the behavior using `scanimage` (`man scanimage`)?
$ scanimage >image.pnm # repeat three times
> Version details are (here with Fedora 17):
> Linux 3.7.3-101.fc17.x86_64
> idem libs and drivers-scanners
As you only tested Fedora stuff, could you use a 32-bit and 64-bit live
image of a different distribution like Debian  and try to reproduce
the issue there? That would be awesome.
> scanimage -L
> device `plustek:libusb:003:003' is a Epson Perfection 1250/Photo flatbed
> joined the scan of an empty, white but not very clean, A4 sheet, scanned
> as n° 3 after startup of xsane.
> The workaround is to stay in a 32-bit OS
> submitted also at bugzilla.redhat.com for fedora with the id 909551
Please always add URLs too. In this case the URL is .
> comparing the joined file with the one joined with 304296 (08/04/2007 -
> not solved yet)
The URL is .
> and the problem description there with this one, the similarity is
> 1. the coloured bands are similar
> 2. OK with the 32 bit OS Gentoo, problem with the same OS in 64 bit
Ok, sorry for the suggestion of using a different distribution above. It
looks like it is an upstream problem and no packaging problem.
> but the scanners are of different models (but may use the same chip)
Hmm, the SANE Web site should provide that information. Anyway you have
an Epson Perfection 1250/Photo and the reporter using Gentoo uses an
Epson Perfection 1260/Photo, so they probably have the same chip. And
indeed, from the supported scanners page  going to the Plustek
backend page , the table there shows, that both use the chip LM9832.
> the OS's are different distributions
By the way, nice work for digging up that old bug #304296.
Gérard, I am not sure how to proceed. I smells like a Plustek backend
Besides looking through the code, I have only the following suggestion.
Could you try to run Simple Scan or, if issue is reproducible with
`scanimage`, `scanimage` under Valgrind? You have to install all the
debugging packages for that. I think Fedora has a command for installing
these, but I am not sure as I am not using it.
Please run the following under 32-bit and 64-bit and attach it to your
G_SLICE=always-malloc G_DEBUG=gc-friendly valgrind -v --tool=memcheck --leak-check=full --num-callers=50 --track-origins=yes --log-file=`date +%Y%m%d-%H%M%S`--simple-scan--valgrind.log simple-scan
Maybe Valgrind can find something or give a hint.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 198 bytes
Desc: This is a digitally signed message part
More information about the sane-devel