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

[Ralph Little]

Hi,
Thanks! I will review it.

Cheers,
Ralph

On 2026-08-25 09:26, Tero Kankaanperä wrote:
> 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.
>