[sane-devel] Epson Perfection 1250/Photo 64-bit

[Ralph Little]

Hi,

On 2020-10-17 12:37 p.m., Charles Lindsey wrote:
>
> I downloaded and compiled the source code for xsane. It is in a messy
> state, and maintained (in a desultory manner) by some guys at Debian.
> Gcc complained of many casts from pointer to int. I changes these to
> long, but it made no difference.

I wouldn't bother compiling xsane. It is very unlikely to be the issue.

>
> Simple-scan runs a calibration (both Course and Fine) om every startup.
> Xsane has a setting "calibration cache" which can be set in the
> Standard Options window, and which I had set (because it seemed like a
> good idea). When set, it causes the result of the calibration to be
> set in
>  ~/.sane/Epson_Perfection_1250_Photo-coarse.cal
> and in
>  ~/.sane/Epson_Perfection_1250_Photo-fine.cal
> If it sees these in a later run, it uses them and omits the
> calibration process entirely. In the backend code there ia a variable
> 'dev->adj.cacheCalData' but nowhere could I find where it gets set,
> though I see now it can be set in /etc /sand.d/plustek.conf, which is
> presumably where simple-scan picks it up.
>
> Anyway, when I first used Xsane in Ubuntu 18.04 (where sane 1.0.27 was
> used), it created these cache files (which suffered from the original
> bug), and when I switched to sane 1.0.31 (both the binary package and
> my locally compiled one) it still used these buggy cache files
> (simple-scan followed the new code, of course). So when I deleted them
> and let xsane re-create them, it all started to work correctly (not
> even any sign of Ralph's yellow stripe).

Yayy!
>
> I also found a few oddities:
> in plustek.c, it declares:
>      struct SIGACTION act;
> However, that struct is nowhere defined. I had to change it to
>      struct sigaction act;
> and also
>  #include <signal.h>
>
Not sure about that. SIGACTION of probably generated by autoconf and so
customized for the platform.
> Also, when running xsane and even simple-scan, it produced massive
> warnings of the form:
> MIB search path:
> /home/chl/.snmp/mibs:/usr/share/snmp/mibs:/usr/share/snmp/mibs/iana:/usr/share/snmp/mibs/ietf:/usr/share/mibs/site:/usr/share/snmp/mibs:/usr/share/mibs/iana:/usr/share/mibs/ietf:/usr/share/mibs/netsnmp
> Cannot find module (SNMPv2-MIB): At line 1 in (none)
> Cannot find module (IF-MIB): At line 1 in (none)
> Cannot find module (IP-MIB): At line 1 in (none)
> Cannot find module (TCP-MIB): At line 1 in (none)
> Cannot find module (UDP-MIB): At line 1 in (none)
> Cannot find module (HOST-RESOURCES-MIB): At line 1 in (none)
> Cannot find module (NOTIFICATION-LOG-MIB): At line 1 in (none)
> Cannot find module (DISMAN-EVENT-MIB): At line 1 in (none)
> Cannot find module (DISMAN-SCHEDULE-MIB): At line 1 in (none)
> Cannot find module (HOST-RESOURCES-TYPES): At line 1 in (none)
> Cannot find module (MTA-MIB): At line 1 in (none)
> Cannot find module (NETWORK-SERVICES-MIB): At line 1 in (none)
> Cannot find module (SNMPv2-TC): At line 15 in
> /usr/share/snmp/mibs/UCD-DISKIO-MI
> and much more. But I did not see them when using my own compiled
> backend-plustek.
>
Sorry, don't know about that.

Regarding the original problem in the cached files, it seems to me that
it might be worthwhile version stamping these files so that we can
change their format and flush out buggy ones with a version bump.

Something to consider in future I guess.

Cheers,
Ralph