[sane-devel] Plustek OpticPro A320E (07b3:1826): working GL128 support in genesys - offered as-is, AI-written, unmaintained

Tue Aug 25 17:26:23 BST 2026

Hello Ralph, and the list,

Following your reply in message 040366, where you said "please feel
free to publish it and I will take a look" - it is published.

   https://terokankaanpera.fi/a320e/

The patch is also attached, gzipped, so that the archive has a copy that 
does
not depend on my web host staying up.

LICENCE

Taking your point about relicensing first, since it conditions everything
else:

   This patch modifies files in backend/genesys/, which are 
GPL-2.0-or-later.
   The contribution is therefore offered under the same terms. To whatever
   extent copyright subsists in it, I license it under GPL-2.0-or-later and
   consent to relicensing under SANE's terms as applied to the genesys 
backend;
   to whatever extent it does not, I assert no rights over it. The empirical
   work (measurements, captures, analysis) is mine; the C++ was written 
by an
   AI assistant under my direction.

The two-part wording is deliberate. My working assumption has been that
AI-generated output may not attract copyright at all, in which case there
would be nothing to license. Rather than take a legal position I do not 
hold,
the statement covers both readings. It commits me to nothing further and, I
hope, leaves you free to do whatever you decide to do.

WHAT IS IN THE PACKAGE

   README.md            provenance, licence, build and install, repro 
recipes,
                        and the known limitations, unvarnished
   a320e-genesys.patch  15 files, +1787 / -15, against master fcaa30a7
   code-quality.md      static analysis: method, results, and the 
reasoning for
                        every warning left unaddressed
   hardware-gl128.md    the chip-level findings
   hardware-a320e.md    the device-specific findings

You asked for detailed review, including review by other AI tools. That is
what code-quality.md is for, and I would rather you judged the method 
than the
headline: findings are classified per line, not per file, because the
file-level rule gives a badly wrong answer on a patch of this shape - 10 
of 18
"ours" instead of the correct 0 of 18. cppcheck reports nothing on the lines
the patch adds; upstream's own tools/style-check.sh passes on all 15 files;
clang-tidy's 157 warnings on added lines are style rules that conflict with
the genesys backend's own conventions, and each category is listed with the
reason it was left alone.

clang-format was deliberately not run, and the document explains why: 
with no
.clang-format in the tree it falls back to the LLVM style and rewrites
genesys's style into a different one. When it was tried here it touched 83
files and 33 000 lines.

WHAT HAS CHANGED SINCE MY FIRST MESSAGE

Three things, two of them corrections to what I told you in August:

1. The origin offset is implemented, not merely intended. 
x-origin-offset and
    y-origin-offset, in mm, range +-5, default 0, advanced, enabled only for
    this model. It exists because model->x_offset and y_offset are 
measured on
    the single unit I own. The vendor's driver has the same control 
under the
    name AdjustOrigin.

2. The odd/even column ripple I described as a cosmetic artifact of about
    15 DN was not cosmetic and not confined to the origin edge. It is a
    period-2 ripple caused by the parity of the shading coefficients: the
    calibration strip sits under the frame, where the staggered sensor 
rows see
    different light, and that parity is absent on the glass. Filtering 
it out
    of the coefficients fixes 100-600 dpi. At 800 dpi it remains, and the
    evidence now points at the ASIC registers rather than at the 
calibration.
    That is the open item.

3. My guess that StaggeredLine = -4 was the cause was wrong. It is still
    unimplemented, but it is not the explanation.

WHAT I HAVE NOT DONE

The patch still contains six A320E_* environment-variable switches. They are
diagnostic instruments for the 800 dpi question above, each is marked in the
code as not intended for upstream, and each defaults to the production
behaviour. If the code goes anywhere near your tree they should come out; I
have kept them because the work they serve is not finished.

There is no man page entry and there are no testsuite cases. Colour 
management
is unfinished: the nominal white level sits at roughly half scale by design,
because the shading divider needs the headroom to avoid wrapping, so images
are linearly darker than they should be. The black level runs 11 to 32 times
the vendor's, because scanner_offset_calibration only searches the positive
side of the AD9822's sign-and-magnitude offset while the vendor ends up
negative at 800 dpi.

None of this is hidden in the code. Every item is commented where it lives.

ON GL128 AND THE NEIGHBOURS

I want to correct something I implied earlier. I said the OpticFilm 8100
(07b3:1824) and 8200i (07b3:1825) are GL128. Your genesys.desc does say 
"GL128
based" for 1825, and Alessandro Coan's April report concerned a new revision
of 1824 - but the vendor's own macOS device definitions for both of those
product IDs show no registers at or above 0x100, which is the marker that
separates the GL124/GL128 family from the older one. The same file also 
lists
an 8200i at 07b3:130d as :status :complete, and that one does test as the
older family.

The reading that fits all of it is that those product IDs cover more 
than one
revision and the definitions I have describe the older silicon - which would
also explain why a new-revision 8100 goes undetected. I cannot settle it 
from
here. It needs bcdDevice read off an actual unit, which is one line of
lsusb -v for anyone who owns one.

Alessandro, if you are still reading: that is the line I would want, and the
chip-level findings in hardware-gl128.md are yours to use either way.

WHAT I AM ASKING

Unchanged from previous message, smallest first, and any of them would be
welcome:

   1. A doc/descriptions-external/ entry so that A320E owners can 
discover that
      Linux support exists. If you take this route, please point :url at the
      directory rather than at a versioned filename, so that an update 
does not
      have to come back through you.

   2. The same, plus the A320E in doc/descriptions/genesys.desc as a known
      device.

   3. If anyone wants the code itself, in whole or as a starting point for a
      rewrite, it is yours.

The standing caveat from my first message still holds and I will not soften
it: I cannot maintain this. I will answer factual questions about the
measurements for as long as I have the device, and I will not be offended if
the answer is no. And of course: test the code on your device at your own
risk, I give no assurances of any kind.

Thank you for looking.

-- 
---
Tero Kankaanperä
https://terokankaanpera.fi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: a320e-genesys.patch.gz
Type: application/gzip
Size: 36802 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/sane-devel/attachments/20260825/99497bd8/attachment-0001.gz>