[sane-devel] Genesys GL846/847 trying to add new scanner
stef.dev at free.fr
Sat Nov 3 08:36:31 UTC 2012
On 02/11/2012 21:13, Radoslav Kolev wrote:
> we are trying to get a GL846 based scanner to work - Canon Image
> Formula Flatbed Scanner Unit 101.
> I'm new to sane and scanners, so please excuse me if I'm asking some
> simple/stupid questions.
> Any pointers to documentation of any sort will be appreciated.
> So, I've captured a scan under windows. The raw log can be found here:
> I have run the following utility
> (web.media.mit.edu/~mhirsch/lide100/usbsnoop-gl847.pl) to get a more
> human readable version, the results are here:
> The above log file with some note's I've written trying to figure out
> what's happening:
> The usbsnoop-gl847.pl spits out a lot of "unknown8e(33) = 0x00,
> Unknown in register value 138, Unknown out buffer value 139"
> messages. I looked at the raw USB data and then after checking the
> section /* USB control message values */ in genesys_low.h it seems
> that some of these might be GPIO_READ requests, and I suspect another
> part might be connected with talking to the FE.
> Where did the defines in the /* USB control message values */ in
> genesys_low.h come from? It's easy to find the GL846 datasheet online,
> but there's nothing in there about the USB protocol. Was all this
> reverse engineered or there's some document/source I've not found yet?
> I can see in the source that register access is handled differently
> for GL847 vs others, but I have no idea which of these defines are
> relevant for which chip.
> When loaded with the gl847 backend there is some communication with
> the scanner (lamp blinks during calibration) but no motor movement.
> From the usbsnoop logs I see that a motor phase table is loaded into
> RAM and then the MPENB bit (Enable motor generating function which is
> stored in memory) is set to high in register 0x08, which is not used
> in any of the other scanners. Is this something gl846/7 specific and
> should I try to replicate this, or there's a better approach without
> using a phase table in RAM?
> Other things that seem interesting from the snoop log file is that a
> lot of GPIO toggling is going on, and also in higher GPIO numbers 25,
> 26 27.
> Also, there are some bulk writes to address 0x10014000 and 4008 which
> I can't figure out the reason for.
> Before the actual scan begins there is a pattern of setting some
> registers and RAM, then reading RAM contents (image data?). My current
> guess is this may be hunting for the page start on the scanner bed.
> So, that's about as far as we are now. Any ideas, suggestions or
> pointers to information will be greatly appreciated.
> Best regards,
> Radoslav Kolev
the only public documentation from genesys logic is the register
description you already found. Firmware functions have been reversed
engineered. When there are many reads and writes, it could be hardware
setting and polling and so GPIO related.
The MPENB use is a new feature that I haven't implemented in the
genesys backend, and will have to be added. Unless you create proper
slope tables and make this model work like the others.
Sometimes it is safe to drop some unidentified reads. For instance
I have found writes that could be image watermark with the CCD sensor
name. Sometimes you don't really find what they are for, but you have to
implement them to get the scanner working.
I have learned that a lot of experimenting and testing is needed to
get these scanner work. For instance I was blocked by an undocumented
register (or buggy write to a register) that was required to get correct
More information about the sane-devel