[sane-devel] GL660+GL646 (genesys/genesys-new) on CanoScan3000(F)?

amth@suomi24.fi amth@suomi24.fi
Sun, 29 May 2005 17:55:24 +0300


--=========4186B44D000C5E36/loggedin.posti.suomi24.fi
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable



--=========4186B44D000C5E36/loggedin.posti.suomi24.fi
Content-Type: message/rfc822
Content-Disposition: inline

Received: from [127.0.0.1] by loggedin.posti.suomi24.fi with HTTP; Sun, 29 May 2005 16:43:22 +0200
Date: Sun, 29 May 2005 17:43:22 +0300
Message-ID: <4186B44D000C5E1B@webmail-fi5.sol.no1.asap-asp.net>
In-Reply-To:  <20050529134741.GG11345@meier-geinitz.de>
From: amth@suomi24.fi
Subject: Re: [sane-devel] GL660+GL646 (genesys/genesys-new) on CanoScan3000(F)?
To: "Henning Meier-Geinitz" <henning@meier-geinitz.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Abuse: abuse@suomi24.fi
X-Postmaster: postmaster@suomi24.fi


>--Alkuper=E4inen viesti--
>From: Henning Meier-Geinitz <henning@meier-geinitz.de>
>To: sane-devel@lists.alioth.debian.org
>Subject: Re: [sane-devel] GL660+GL646 (genesys/genesys-new) on CanoScan3=
000(F)?
>Date: Sun, 29 May 2005 15:47:41 +0200
>> By the way changing the (val !=3D 0x15) -> (val =3D=3D 0x15) doesn't m=
ean anything
>> interesting? That was the way I disabled the test enabling the chipset=

>to
>> report as GL660+GL646...
>
>The test intends to set a register and read the value back. The gl646
>uses register 0x38 for setting the high byte of lperiod (=3Dexposure).
>For reading the same value, register 0x4e is used. So with a gl646,
>when you write something to 0x38 you should get the same value when
>reading from register 0x4e afterwards. The value itsself doesn't
>matter, you can use 0x01 or whatever instead of 0x15.

OK, understood it the same way.


>However, with gl660+gl646 the gl660 is used as interface chip
>USB2->USB1.1 I guess. So the way how to set the gl646 registers
>through the gl660 may be different. To find out how that works, a
>documentation for the gl660 or at least a log of the windows driver
>accesses would be necessary.

No, the GL660 interfaces directly to a block GenesysLogic calls "EPP" (En=
changed
Parallel Port? Data is transfered as EPP packets via the USB too?) that
not only interfaces to the GL660 (for actual 480Mbps transfer speed) and
internal USB1.1 PHY but also to blocks "Data Interface" (gamma corrected,=

compressed data packed on a block called "Data Packing", not sure what th=
at
block might do, maybe insert IEEE1394/USB headers/framing?) and "Register=

& Status Read" -block that interfaces to the external MPU.

I do have an WinXP dedicated for USB sniffing, but haven't been able to
have enought time to test it out, will today try it out.


>While I have a PDF about the gl660, it only contains a list of
>registers and no details.

Hope you got the pdf out of GL646, as it's Chapter 3. System Block Diagra=
m
has an 3.2 USB 2.0 System Block Diagram shows external component connecti=
ons
while the 4. Function Block Diagram shows internal connections within GL6=
46,
and of course 5 Hardware Description: 5.1 Pins Assigments & Mode Definiti=
ons
shows that the GL646 is working on Mode 4 (SC+ and AFE)... 7. Command Set=

Description has pretty clearcut register listing... :-)


>You could try to change sane-find-scanner to write to and read from
>register 0x1a. (exchange both 0x38 and 0x4e by 0x1a). The 0x1a
>register is named "TXFFDAT", maybe that's the data to be sent to the
>gl646.

Hmm, my doc describes 0x1a as:

CKH[4..0]

Check High? As 0x1b is CKL[4..0] that might then be Check Low?

Note, both regs have bits[7..5] unmarked (reserved?)...

Maybe we have different .pdf docs (I got it directly from GenesysLogic.co=
m)?

Reg lists 0x00 -> 0x71 with an note that Regs 0x4x and 0x7x are read port=
s,
other are write ports...

Anyways, tested that 0x1a-hack and:

sane-find-scanner can't again determine the USB chip...


>> >Could you try to modify the test so it works like the gl841 test? Jus=
t
>> >exchange the 0x4e by 0x38. So it reads from the same register to whic=
h
>> >it has also written.
>> 
>> That makes the result being the standard one (can't identify any chips=
et).
>
>Looks like gl660 has only 0x1f registers. I'm surprised that
>reading/writing higher register numbers doesn't result in errors.

Are directly passed thru to GL646?


>> Yeah, I based the suggestion of Astra 4500 being only mildly different=

>on
>
>While the hardware may be similar, the way to access these scanners
>(Astra 4500/4700) is different because with the gl660 you need one more
>layer of communication.

Or that 0x00 -> 0x1f interact with GL660 and 0x20+ go to GL646?


>> <snip note=3D"changed backends/genesys.devices.c
>> 
>> static Genesys_USB_Device_Entry genesys_usb_device_list[] =3D {
>>   {0x04a9, 0x2215, &umax_astra_4500_model},
>> /*  {0x0638, 0x0a10, &umax_astra_4500_model},*/
>> 
>> to trigger this below">
>
>Have you also added your ids to genesys.conf?

Yep, as:

# Canon CanoScan 3000F (amth)
usb 0x04a9 0x2215


>> <snip note=3D"notice the same thing lists twice below?!?">
>
>libusb is called by every backend, not only by genesys. So if there is
>anything else in dll.conf, you'll get debug logs from all the USB
>backends.

Ok, then that makes sense...


--
amth



--=========4186B44D000C5E36/loggedin.posti.suomi24.fi--