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
