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

Hello SANE developers,

I-ve been working on genesys backend for the Plustek OpticPro A320E, an 
A3 CCD flatbed (USB 07b3:1826). I am offering it to the project. Please 
read the provenance note below before the technical part, because it may 
determine whether you want to look at this at all.


PROVENANCE, STATED UP FRONT

I am not a programmer. The C++ in this patch was written by an AI 
assistant (Anthropic's Claude) under my direction. What is mine is the 
empirical work: over 200 instrumented runs on the physical device, USB 
traffic captures, and a comparison against the manufacturer's own 
ScanApi configuration file. Every claim below was measured on hardware 
and reproduced, not inferred - the project's working rule throughout has 
been that no single run establishes anything.

I am aware that several projects have adopted policies against 
LLM-derived contributions, and that SANE has not published one. I am not 
asking you to make an exception or to have that argument. If the answer 
is no, that is a legitimate answer and I will not press it.

I also cannot commit to maintaining this. I will finish it to my own 
standard - color management is the remaining work - and after that I am 
done. I say this now rather than letting you discover it from unanswered 
review comments.


WHY GL128 MAY BE WORTH YOUR ATTENTION

The device reports bcdDevice 0x702, which is GL128. SANE has no GL128 
command set: the AsicType enum ends at GL124, and the closest relative 
is gl124.cpp. All four existing GL124 devices in the tree are Canon LiDE 
CIS scanners; the A320E is CCD, which is why the patch touches shared 
code rather than only adding a table entry. Every shared-code change is 
ModelId-gated.

GL128 already appears in your tree and your archive as an unresolved item:

   - doc/descriptions/genesys.desc lists the OpticFilm 8200i (07b3:1825) 
as :status :unsupported with the comment "GL128 based".

   - In April 2026 Alessandro Coan reported a new revision of the 
OpticFilm 8100 (07b3:1824, GL128) that genesys does not detect. That 
message received no reply.

I make no claim that this patch supports either of those devices - both 
are film scanners with different optics and mechanics. What may transfer 
is the silicon-level findings, which are documented and measured.


CURRENT STATE

Color and gray produce geometrically accurate scans on Fedora 44 at 100, 
200, 300, 400, 600 and 800 dpi. Grid squares measure square in both 
axes; residual channel misalignment is 0 lines.

The resolution model follows the manufacturer's: the two axes have 
different native sets. Horizontal native is {800, 400, 200, 100}, 
vertical native is {800, 600, 400, 300, 200, 100}. 300 and 600 dpi are 
therefore scanned on 400 and 800 dpi hardware respectively and reduced 
horizontally in the image pipeline, while their vertical rate is native. 
100 dpi is achieved by the ASIC dropping every other line via the 
LINESEL register, not by software line dropping. 150 dpi is the only 
mode non-native on both axes and I dropped it. Measured accuracy across 
the six remaining modes is 0.991-0.994 vertical and 1.011-1.016 horizontal.

One finding may be of general interest: the AD9822 configuration 
register must follow the speed block. The manufacturer writes 0x00 = 
0x70 for 100-400 dpi and 0xf8 for 600/800 dpi; the differing bits set 
the ADC full scale from 2 V to 4 V. Running the Speed2 value at 600/800 
dpi drives the PGA to its ceiling and flattens the field, which is what 
blocked 800 dpi here for a long time.


KNOWN LIMITATIONS

   - Color accuracy is not finished; this is my remaining work.

   - x_offset and y_offset are measured from a single unit and 
hardcoded. Another A320E will have a different mechanical origin and 
currently no way to correct it. The manufacturer's driver has both an 
origin search (AreaFindOrigin) and a user-adjustable offset 
(AdjustOrigin). I intend to add a configurable offset before releasing 
this to users.

   - A known cosmetic artifact: odd/even column ripple of about 15 DN in 
roughly the first 66 columns at the origin edge. The manufacturer's ini 
specifies StaggeredLine = -4, which genesys has a structure for 
(StaggerConfig) that this sensor table does not set. Untested hypothesis.


WHAT I AM ASKING

Three options, smallest first, and I would be glad of any of them:

   1. A doc/descriptions-external/ entry with :version "unmaintained", 
pointing at the patch once I publish it, so that A320E owners can find 
out that Linux support exists. This costs you one small file and commits 
you to nothing.

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

   3. If anyone wants to take the code itself, in whole or as a starting 
point to rewrite, it is yours under GPL v2+. I will answer factual 
questions about the measurements for as long as I have the device.

I have not published the patch yet, and I would rather not do the 
packaging work if there is no interest. If any of the above is worth 
pursuing, say so and I will put it somewhere public together with the 
measurement notes and the USB capture analysis.

Alessandro, if you still read this list - the GL128 register findings 
above may be relevant to getting 07b3:1824 detected, and I am happy to 
share what I measured.

Thank you for SANE. I have used it for years and want to give back to 
the community.


-- 
---
Tero Kankaanperä
https://terokankaanpera.fi