epsonds: fix --adf-crp on FF-680W (and other ADFPEDT-capable scanners)
This series fixes two independent issues in the epsonds backend that together prevented --adf-crp=yes from working on the Epson FF-680W (FastFoto). After applying both, scans of Letter pages come out actual letter-size instead of the full 8.5"×15.5" ADF travel.
1/2 — epsonds: don't silently disable adf-crp on geometry change
Whenever any of OPT_TL_X/Y or OPT_BR_X/Y was set, the backend unconditionally reset OPT_ADF_CRP to 0. That reset lives in the geometry case of setvalue(), which scanimage (and other frontends) trigger during option negotiation when initializing geometry to device defaults — so user-set --adf-crp=yes was silently overwritten before reaching sane_start. Removing the reset; users who explicitly want auto-crop off can pass --adf-crp=no.
2/2 — epsonds: wire ADFPEDT capability into the ADF scan command
The ADFPEDT (paper-end detection) capability token was parsed only as a debug print — no device-struct flag, never appended to the #ADFDPLX[SKEW][CRP ] command sent at scan time. Without it, scanners advertising the capability still echo back the requested geometry in their pen reply, defeating the existing --adf-crp height-override path. New behavior: when the scanner advertises ADFPEDT and the user requested adf-crp, append PEDT to the ADF command. Gated on both, so it's inert for scanners that don't advertise the capability and for scans without --adf-crp.
Test evidence (FF-680W, sane-backends 1.3.1 + master)
Before:
esci2_para: #ADFDPLXSKEW#COLM008...#ACQi0000000i0000000i0002544i0004642
img_cb: pen width: 2544, height: 4642
PNM: 2544 × 4642 (8.5" × 15.47")After:
esci2_para: #ADFDPLXSKEWCRP PEDT#COLM008...#ACQi0000000i0000000i0002544i0004642
img_cb: pen width: 2530, height: 3325
PNM: 2530 × 3325 (8.43" × 11.08")Tested on
- Epson FF-680W (FastFoto, USB) on Debian Trixie aarch64 / Raspberry Pi 3B — both commits.
Not tested on
Any other scanner. The PEDT-wiring change in 2/2 is gated by the scanner's own capability advertisement, so it should be a no-op on scanners that don't advertise ADFPEDT. The reset removal in 1/2 is broader-impact — anyone who was passing --adf-crp=yes was already getting silently 0'd, so the change is "honor the user's flag." If a frontend was relying on the reset to undo auto-crop after the user touched geometry, this could surprise — but that's an unusual frontend pattern and the explicit --adf-crp=no is available.