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

[Henning Meier-Geinitz]

Hi,

On Sun, May 29, 2005 at 04:08:27PM +0300, amth@suomi24.fi wrote:
> >> The only thing that needs to be changes to see that it actually is GL660+GL646
> >> is to take away only the very last of the tests (tools/check-usb-chip.c
> >> "if (val != 0x15)... reg 0x4e != reg 0x38"-test) after that other tests
> >> seem to pass just fine and 'sane-find scanner -v -v' reports:
> >However, that means that the test for setting and reading a register
> >fails. That means that it doesn't behave like a gl646. At least
> >according to my docs, a value written to register 0x38 should be
> >readable in register 0x4e.
> 
> OK, dunno about that so can't say anything about that.
> 
> By the way changing the (val != 0x15) -> (val == 0x15) doesn't mean 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 (=exposure).
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.

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.

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

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.


> >Could you try to modify the test so it works like the gl841 test? Just
> >exchange the 0x4e by 0x38. So it reads from the same register to which
> >it has also written.
> 
> That makes the result being the standard one (can't identify any chipset).

Looks like gl660 has only 0x1f registers. I'm surprised that
reading/writing higher register numbers doesn't result in errors.

> Yep, too bad I don't have access to such scanner, but artificially looking
> thru the Net just suggests that the only thing difference is that 3000(F)
> is 1200x2400dpi and 5000F is 2400x4800dpi scanner.

That's also what the sane-find-scanner output looks like.
 
> >> And if you look at ><http://www.sane-project.org/unsupported/canon-5000f.html>,
> >> <http://www.sane-project.org/unsupported/umax-astra-4700.html> that are
> >> based on exactly similar chipsets and ><http://www.sane-project.org/unsupported/umax-astra-4500.html>
> >> that only differs mildly, at least those should be workable with >genesys/genesys-new.
> >The UMAX Astra 4500 uses only a GL646 (no GL660) and was used for
> >developping the base for the genesys backend. At the moment it does
> >not work but I hope that can be fixed later.
> 
> 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.

> <snip note="changed backends/genesys.devices.c
> 
> static Genesys_USB_Device_Entry genesys_usb_device_list[] = {
>   {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?

> <snip note="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.

Bye,
  Henning