[sane-devel] Canon LiDE 80 (2nd try)

[Pierre Willenbrock]

Stefan Lucke schrieb:
> On Wednesday 06 February 2008, Pierre Willenbrock wrote:
>> Hi Stefan,
>>
>> (more text inline)
>>
>> Stefan Lucke schrieb:
>>> On Tuesday 05 February 2008, Stefan Lucke wrote:
>>>> Hi,
>>>>
>>>> I've seen there is some progress on lide 90 and I want to step in and
>>>> like to ask if there could be done something for my LiDE 80 too.
>>>> I cloned the canon_lide_60_model entry
>>>>
>>>> -- scanimage with debug messages : --
>>>> [sanei_debug] Setting debug level of genesys to 255.
>>>> [genesys] SANE Genesys backend version 1.0 build 9 from sane-backends 1.0.18-cvs
>>>> [genesys] sane_init: authorize != null
>>>> [genesys] sane_init: little endian machine
>>>> [genesys] sane_init: reading config file `genesys.conf'
>>>> [genesys] sane_init: config file line 1: trying to attach `usb 0x04a9 0x2214'
>>> ..
>>>> [genesys_gl841] gl841_bulk_write_register (elems = 104)
>>>> [genesys_gl841] reg[0x01] = 0xa0
>>>> [genesys_gl841] reg[0x02] = 0x38
>>>> [genesys_gl841] reg[0x03] = 0x5f
>>>> [genesys_gl841] reg[0x04] = 0x10
>>>> [genesys_gl841] reg[0x05] = 0x40
>>>> [genesys_gl841] reg[0x06] = 0x18
>>>>
>>>> -- I modified this, debug message is written before ..bulk_write..() . --
>>>>
>>>> [genesys_gl841] gl841_bulk_write_register: failed while writing command: Invalid argument
>>>> scanimage: open of device genesys:libusb:001:017 failed: Invalid argument
>>>> [genesys] sane_exit: start
>>>> [genesys] sane_exit: exit
>>> Some further info:
>>> I placed some win98 logfiles at http://lucke.in-berlin.de/lide-80/ .
>>>
>>> During my search in the list history, I found a test program in this mail:
>>> http://lists.alioth.debian.org/pipermail/sane-devel/2006-October/017930.html
>> I must admit, i totally forgot about that.. lectures where starting at
>> that time at my university.
>>
>>> Using the following stripped down version of usbsnoop-300dpi_color.c,
>>> helped to get rid of the sudden disconnect from below.
>>> -- snip --
>>> set_write_register(0x6b, 0x0c);
>>> set_write_register(0x06, 0x10);
>> first, try if either of the following is enough to get past writing
>> register 0x06:
>> set_write_register(0x6b, 0x08);
>> set_write_register(0x6b, 0x04);
>>
>> put that write to 0x6b into gl841_init, before the /* Write initial
>> registers */, and make sure the other places where 0x6b is written
>> preserve the needed bits. That may get scanimage to o further with a
>> freshly plugged in scanner.
>>
> 
> A: set_write_register(0x6b, 0x08); with and without preserving reg_0x6b:
>     There is a small audible motor sound, but no movement.
>     Windows driver does a small forward , backward movement of scan head.
> 
> [genesys] sanei_genesys_write_register (0x0e, 0x00) completed
> [genesys] sanei_genesys_write_register (0x6b, 0x08) completed
> [genesys_gl841] gl841_bulk_write_register (size = 208)
> [genesys_gl841] reg[0x01] = 0xa0
> [genesys_gl841] reg[0x02] = 0x38
> [genesys_gl841] reg[0x03] = 0x5f
> [genesys_gl841] reg[0x04] = 0x10
> [genesys_gl841] reg[0x05] = 0x40
> [genesys_gl841] reg[0x06] = 0x18
> [genesys_gl841] reg[0x07] = 0x00
> [genesys_gl841] reg[0x08] = 0x00
> ..
> [genesys_gl841] reg[0x6a] = 0x00
> [genesys_gl841] reg[0x6c] = 0x00
> ..
> [genesys] sanei_genesys_write_register (0x0f, 0x01) completed
> [genesys] sanei_genesys_read_register (0x41, 0xd1) completed
> [genesys] sanei_genesys_read_register (0x41, 0xd1) completed
> 
> B: set_write_register(0x6b, 0x04); 
>   - one time with preserving 0x6b -> as A:
>   - one time  _bulk_write_ up to reg[0x06]
>   - this time:
> [genesys] sanei_genesys_write_register (0x6b, 0x04) completed
> [genesys_gl841] gl841_bulk_write_register (size = 208)
> ..
> [genesys_gl841] reg[0x06] = 0x18
> [genesys_gl841] reg[0x07] = 0x00
> [genesys_gl841] gl841_bulk_write_register: failed while writing command: Invalid argument
> 
> 
> I'm wondering of the effects of playing with bit 2 and 3 of register 0x6b.
> According to my spec of gl841 vers. 1.7 p 42,43 bit 0 and 1 and for GPO 17 & 18,
> bit 2 & 3 are reserved ;-) .
> 

It may be possible to control gpo19/20 there, which may map to
MT(R)_4/5, similar to how gpo17/18 map to MT(R)_6/7. I don't see how the
gl841/2 determines what function is to control the MT(R)_6/7, another
possible job for bit 2/3.

The behavior regarding these pins seems to be not very well documented
in the public datasheets.

Regards,
  Pierre