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

Hi,
I'm not the project owner but I am a maintainer here so I will give my 
two cents' worth. (Apologies for top-posting, I believe it would be more 
helpful in this instance.)

I have no personal objection to the use of AI tools for analysis and 
code generation. Putting aside the copyright arguments, AI is here to 
stay and I am particularly interested in the ideas surrounding capture 
and reverse engineering analysis which I think could offer a massive 
boost potentially to our ability to support additional machines. Capture 
analysis is a difficult area and requires painstaking work by 
maintainers here, particularly in the genesys realm, because each 
machine requires its own analysis owing to the fact that the 
conversation is so low-level.

However, I am guarded against the trust that many people are placing in 
the assumed validity and correctness of generated code so I would 
caution anyone from using it without proper and detailed review, 
including review by other AI tools actually. Generated code is getting 
better and more reliable all the time but, like in self-driving cars, it 
does fail in certain weird and incomprehensible ways sometimes, even if 
in the main it is reliable. It also most be comprehensible by humans for 
maintenance purposes so some massaging is often necessary as well.

We got bombed just yesterday by an AI code review bot to one of our 
merge requests and it had some quite interesting things to say about the 
pixma backend code. Again, automated code review (as an assistant to 
human review) is something that is going to become very important.

Much of the objection that I have seen to AI generated code is 
ideological, but I am more pragmatic. So I will say that I am interested 
in seeing the code that you generated with a view to eventually working 
it into the genesys backend to help support GL128. So please feel free 
to publish it and I will take a look. If we were to use it, you would 
have to be happy for us to relicense it to the SANE license which is a 
permissive license with some additional provisions to allow business use 
I believe but the code will always be free for people to see and use.

Cheers,
Ralph

On 2026-08-21 22:46, Tero Kankaanperä wrote:
> 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.
>
>