[sane-devel] Canon LiDE 80 (2nd try)
On Wednesday 13 February 2008 15:42:12 Reinhard Biegel wrote: > On Tuesday, 12. February 2008, Stefan Lucke wrote: > > > Register 0x6b is very different between GL841/2 and GL843. But the > > > documentation around the pins controlled with 0x6b is a bit lacking. > > > > So we need to write reserved I/O bits, (0x6b) need to write to undefined > > gamma addresses (0x5b/5c - 0x0c00). Thats really magic. Both areas > > are defined for GL843 but not for GL841/2. > > Indeed, very strange. > > @Gerhard Jaeger: Were did you get the bcdValues from? Can we trust them? Yup, we can. Got that from the sources of a Windoze driver... > Is there a possibility that there is a "GL841b" revision of the chip with > lower bcdValue but being derived from GL843? I don't think so. - Gerhard
[sane-devel] Canon LiDE 80 (2nd try)
Quoting Pierre Willenbrock : > Stefan Lucke schrieb: > > On Monday 11 February 2008, Pierre Willenbrock wrote: > >> Reinhard Biegel schrieb: > >>> Am Monday, 11. February 2008 schrieb Stefan Lucke: > > > At that moment, I guess you'll see messages like: > new high speed USB device using ehci_hcd and address nn > via dmesg. > >>> Hi, > >>> Yes, thats right. > >>> > >>> Changing the write to reg 0x6b from 0x0c to 0x08 fixes that. > >>> Scanner is producing noisy image now. > >>> > >>> Do I see right that the two bits (0x04 and 0x08 of register 0x6b) affect > >>> two > >>> pins which are marked as 'reserved' in the datasheet? They are only > >>> documented for GL843. > >> Register 0x6b is very different between GL841/2 and GL843. But the > >> documentation around the pins controlled with 0x6b is a bit lacking. > > > > So we need to write reserved I/O bits, (0x6b) need to write to undefined > > gamma addresses (0x5b/5c - 0x0c00). Thats really magic. Both areas > > are defined for GL843 but not for GL841/2. > > > > I just tested that on my scanner. Gamma data written to 0xc000 ended up > in Gamma RAM, 0x. Can someone please play around with the actual > data transmitted and the address? It may be a dummy write. On the other > hand, the firmware may intercept that write(for whatever reasons it > could not use another usb vendor transfer). > > If you want to test that yourself, i attached my program. You will > probably need to fiddle with the initialisation code. > 1st intermediate result is it failed at register 6 write ;-) : fprintf(stderr,"SCANMOD_i\n"); res = set_SCANMOD_i(d, 0); ONERROUT(); fprintf(stderr,"RPWRBIT_b\n"); res = set_RPWRBIT_b(d, 1); ONERROUT(); fprintf(stderr,"GAIN4_b\n"); res = set_GAIN4_b(d, 1); ONERROUT(); fprintf(stderr,"OPTEST_i\n"); res = set_OPTEST_i(d, 0); ONERROUT(); Skipping GAIN4 write, it failed at OPTEST write. jarada gl842-memory # ./testprog Info: open_scanner: Success Unknown8E(0) = 00 SCANMOD_i RPWRBIT_b GAIN4_b Fatal: Could not set register: Protocol error (06) Info: close_scanner: Success jarada gl842-memory # dmesg -c [23696.699268] usb 1-7.2: new high speed USB device using ehci_hcd and address 33 [23696.787173] usb 1-7.2: OK: device descriptor read/64, error 0, mp 64 (0 0) [23696.809238] usb 1-7.2: configuration #1 chosen from 1 choice [23704.440983] usb 1-7.2: usbfs: USBDEVFS_CONTROL failed cmd testprog rqt 64 rq 12 len 1 ret -71 [23704.506662] usb 1-7.2: USB disconnect, address 33 [23704.722697] usb 1-7.2: new high speed USB device using ehci_hcd and address 34 [23704.810805] usb 1-7.2: OK: device descriptor read/64, error 0, mp 64 (0 0) [23704.832411] usb 1-7.2: configuration #1 chosen from 1 choice After inserting ahead of above code: res = usb_con_write_register_byte(d, 0x6b, 0x08); ONERROUT(); I got the attached out file. Stefan Lucke -- next part -- A non-text attachment was scrubbed... Name: test.out.bz2 Type: application/octet-stream Size: 778 bytes Desc: not available Url : http://lists.alioth.debian.org/pipermail/sane-devel/attachments/20080213/0b686f3f/attachment.obj
[sane-devel] Canon LiDE 80 (2nd try)
Stefan Lucke schrieb: > On Monday 11 February 2008, Pierre Willenbrock wrote: >> Reinhard Biegel schrieb: >>> Am Monday, 11. February 2008 schrieb Stefan Lucke: > At that moment, I guess you'll see messages like: new high speed USB device using ehci_hcd and address nn via dmesg. >>> Hi, >>> Yes, thats right. >>> >>> Changing the write to reg 0x6b from 0x0c to 0x08 fixes that. >>> Scanner is producing noisy image now. >>> >>> Do I see right that the two bits (0x04 and 0x08 of register 0x6b) affect >>> two >>> pins which are marked as 'reserved' in the datasheet? They are only >>> documented for GL843. >> Register 0x6b is very different between GL841/2 and GL843. But the >> documentation around the pins controlled with 0x6b is a bit lacking. > > So we need to write reserved I/O bits, (0x6b) need to write to undefined > gamma addresses (0x5b/5c - 0x0c00). Thats really magic. Both areas > are defined for GL843 but not for GL841/2. > I just tested that on my scanner. Gamma data written to 0xc000 ended up in Gamma RAM, 0x. Can someone please play around with the actual data transmitted and the address? It may be a dummy write. On the other hand, the firmware may intercept that write(for whatever reasons it could not use another usb vendor transfer). If you want to test that yourself, i attached my program. You will probably need to fiddle with the initialisation code. Regards, Pierre -- next part -- A non-text attachment was scrubbed... Name: gl842-memory.tbz2 Type: application/octet-stream Size: 7331 bytes Desc: not available Url : http://lists.alioth.debian.org/pipermail/sane-devel/attachments/20080213/4ae75f51/attachment.obj
[sane-devel] Canon LiDE 80 (2nd try)
On Tuesday, 12. February 2008, Stefan Lucke wrote: > > Register 0x6b is very different between GL841/2 and GL843. But the > > documentation around the pins controlled with 0x6b is a bit lacking. > > So we need to write reserved I/O bits, (0x6b) need to write to undefined > gamma addresses (0x5b/5c - 0x0c00). Thats really magic. Both areas > are defined for GL843 but not for GL841/2. Indeed, very strange. @Gerhard Jaeger: Were did you get the bcdValues from? Can we trust them? Is there a possibility that there is a "GL841b" revision of the chip with lower bcdValue but being derived from GL843? Regards, Reinhard
[sane-devel] Canon LiDE 80 (2nd try)
On Tuesday 12 February 2008 10:24:51 Pierre Willenbrock wrote: > Gerhard Jaeger schrieb: > > On Tuesday 12 February 2008 03:41:49 Reinhard Biegel wrote: > >> On Monday, 11. February 2008, Pierre Willenbrock wrote: > >>> Did someone post the bcdDevice value of a LiDE 80? GL841 goes up to > >>> 3.0.5, as someone said, and GL842 begins with 3.0.6 > > > > that was me. But it's not quite clear. got also some info that > > GK842 starts @ 303 > > > >> bcdDevice of mine is 0302. > > > > So probably it's a GL841. Any chance to disassemble the device? > > > No need to. i just meant to make sure that it is not a version on the > edge to GL843(if there is such an edge). My Canon LiDE 35 has 0305, and > is said to contain a GL842, according to [1], but the LiDE 50 there is > 0303 and GL841. Apart from that the two datasheets show suspiciously few > differences. > Okay, I just checked some sources I got and the major differences seem between 843 and 84[1,2]. 841 and 842 seem to be more or less the same. - Gerhard
[sane-devel] Canon LiDE 80 (2nd try)
On Monday 11 February 2008, Pierre Willenbrock wrote: > Reinhard Biegel schrieb: > > Am Monday, 11. February 2008 schrieb Stefan Lucke: > >> At that moment, I guess you'll see messages like: > >>new high speed USB device using ehci_hcd and address nn > >> via dmesg. > > > > Hi, > > Yes, thats right. > > > > Changing the write to reg 0x6b from 0x0c to 0x08 fixes that. > > Scanner is producing noisy image now. > > > > Do I see right that the two bits (0x04 and 0x08 of register 0x6b) affect > > two > > pins which are marked as 'reserved' in the datasheet? They are only > > documented for GL843. > > Register 0x6b is very different between GL841/2 and GL843. But the > documentation around the pins controlled with 0x6b is a bit lacking. So we need to write reserved I/O bits, (0x6b) need to write to undefined gamma addresses (0x5b/5c - 0x0c00). Thats really magic. Both areas are defined for GL843 but not for GL841/2. > > Did someone post the bcdDevice value of a LiDE 80? GL841 goes up to > 3.0.5, as someone said, and GL842 begins with 3.0.6 It is for my scanner: idVendor 0x04a9 Canon, Inc. idProduct 0x2214 bcdDevice3.02 as found on: http://www.sane-project.org/unsupported/canon-lide-80.html -- Stefan Lucke
[sane-devel] Canon LiDE 80 (2nd try)
Gerhard Jaeger schrieb: > On Tuesday 12 February 2008 03:41:49 Reinhard Biegel wrote: >> On Monday, 11. February 2008, Pierre Willenbrock wrote: >>> Did someone post the bcdDevice value of a LiDE 80? GL841 goes up to >>> 3.0.5, as someone said, and GL842 begins with 3.0.6 > > that was me. But it's not quite clear. got also some info that > GK842 starts @ 303 > >> bcdDevice of mine is 0302. > > So probably it's a GL841. Any chance to disassemble the device? > No need to. i just meant to make sure that it is not a version on the edge to GL843(if there is such an edge). My Canon LiDE 35 has 0305, and is said to contain a GL842, according to [1], but the LiDE 50 there is 0303 and GL841. Apart from that the two datasheets show suspiciously few differences. Regards, Pierre [1] http://www.sane-project.org/unsupported/canon-lide-50.html
[sane-devel] Canon LiDE 80 (2nd try)
On Tuesday 12 February 2008 03:41:49 Reinhard Biegel wrote: > On Monday, 11. February 2008, Pierre Willenbrock wrote: > > Did someone post the bcdDevice value of a LiDE 80? GL841 goes up to > > 3.0.5, as someone said, and GL842 begins with 3.0.6 that was me. But it's not quite clear. got also some info that GK842 starts @ 303 > bcdDevice of mine is 0302. So probably it's a GL841. Any chance to disassemble the device? - Gerhard
[sane-devel] Canon LiDE 80 (2nd try)
On Monday, 11. February 2008, Pierre Willenbrock wrote: > Did someone post the bcdDevice value of a LiDE 80? GL841 goes up to > 3.0.5, as someone said, and GL842 begins with 3.0.6 bcdDevice of mine is 0302. Reinhard
[sane-devel] Canon LiDE 80 (2nd try)
Reinhard Biegel schrieb: > Am Monday, 11. February 2008 schrieb Stefan Lucke: >>> ... >>> [genesys_gl841] reg[0x6b] = 0x02 >>> [genesys_gl841] reg[0x6e] = 0x6d >>> [genesys_gl841] gl841_bulk_write_register: failed while writing command: >>> Invalid argument >>> scanimage: open of device genesys:libusb:001:010 failed: Invalid argument >> At that moment, I guess you'll see messages like: >> new high speed USB device using ehci_hcd and address nn >> via dmesg. > > Hi, > Yes, thats right. > > Changing the write to reg 0x6b from 0x0c to 0x08 fixes that. > Scanner is producing noisy image now. > > Do I see right that the two bits (0x04 and 0x08 of register 0x6b) affect two > pins which are marked as 'reserved' in the datasheet? They are only > documented for GL843. Register 0x6b is very different between GL841/2 and GL843. But the documentation around the pins controlled with 0x6b is a bit lacking. Did someone post the bcdDevice value of a LiDE 80? GL841 goes up to 3.0.5, as someone said, and GL842 begins with 3.0.6 > After scanning I have to replug the scanner, otherwise I get an error message > telling me the document feeder is jammed. Curiously, if I set > SANE_DEBUG_GENESYS, there comes up another error about a failed bulk_write. The "feeder jammed" error happens when the backend thinks your scanning head is stuck. For example when someone forgot to open the lock. I guess we need SANE2 for more/better error messages. It is probably not really stuck, but the sensor input is incorrect. > > Also I noticed that the LED isn't continuously illuminated. In one half it's > continuous, but in the other there are small gaps (about 1mm) with about 4mm > spacing between. In the middle there are a few with bigger spacing. Sounds like it would normally be backtracking between the lighted areas, but does not for some reason. Just guessing. The LiDE 80 support is far from complete. > >> Which way is your scanner connected ? > Directly to the computer, no hubs. > > Regards, > Reinhard > Regards, Pierre
[sane-devel] Canon LiDE 80 (2nd try)
Am Monday, 11. February 2008 schrieb Stefan Lucke: > > ... > > [genesys_gl841] reg[0x6b] = 0x02 > > [genesys_gl841] reg[0x6e] = 0x6d > > [genesys_gl841] gl841_bulk_write_register: failed while writing command: > > Invalid argument > > scanimage: open of device genesys:libusb:001:010 failed: Invalid argument > > At that moment, I guess you'll see messages like: > new high speed USB device using ehci_hcd and address nn > via dmesg. Hi, Yes, thats right. Changing the write to reg 0x6b from 0x0c to 0x08 fixes that. Scanner is producing noisy image now. Do I see right that the two bits (0x04 and 0x08 of register 0x6b) affect two pins which are marked as 'reserved' in the datasheet? They are only documented for GL843. After scanning I have to replug the scanner, otherwise I get an error message telling me the document feeder is jammed. Curiously, if I set SANE_DEBUG_GENESYS, there comes up another error about a failed bulk_write. Also I noticed that the LED isn't continuously illuminated. In one half it's continuous, but in the other there are small gaps (about 1mm) with about 4mm spacing between. In the middle there are a few with bigger spacing. > Which way is your scanner connected ? Directly to the computer, no hubs. Regards, Reinhard
[sane-devel] Canon LiDE 80 (2nd try)
On Monday 11 February 2008, Reinhard Biegel wrote: > > > You are talking about writes like: > > > > I guess YES. > > Yes, I do. > > > Now I found the right one AND the right time: Before doing the reset ;-). > > > > So now I've the initial motor movement with LED blinking and a scan > > movement with green LED. > > > > But no (strange) data arrives. > > > I tried your diff, but I get the known 'invalid argument error'. > > Regards, > Reinhard > > Debug output of scanimage: > [genesys_gl841] genesys_bulk_write_data_gamma: completed > [genesys] sanei_genesys_write_register (0x0e, 0x00) completed > [genesys] sanei_genesys_write_register (0x6b, 0x0c) completed Writing value 0x08 is enough for me. Following 2 register writes can be skipped. That's around line 5166 in genesys_gl841.c Additional you may prevent register 0x6b from further writes by excluding it around line 409. In file genesys_devices.c you can change around line 585 the y start position from 7.9 mm to 4.9 mm, as my scan head reaches opposite of home position audible. > [genesys] sanei_genesys_write_register (0x6e, 0x6d) completed > [genesys] sanei_genesys_write_register (0x6c, 0x00) completed > [genesys_gl841] gl841_bulk_write_register (elems = 104) > [genesys_gl841] reg[0x01] = 0xa0 > [genesys_gl841] reg[0x02] = 0x38 > ... > [genesys_gl841] reg[0x6b] = 0x02 > [genesys_gl841] reg[0x6e] = 0x6d > [genesys_gl841] gl841_bulk_write_register: failed while writing command: > Invalid argument > scanimage: open of device genesys:libusb:001:010 failed: Invalid argument At that moment, I guess you'll see messages like: new high speed USB device using ehci_hcd and address nn via dmesg. Which way is your scanner connected ? Mine is connected via a self powered USB 2 hub. -- Stefan Lucke
[sane-devel] Canon LiDE 80 (2nd try)
> > You are talking about writes like: > > I guess YES. Yes, I do. > Now I found the right one AND the right time: Before doing the reset ;-). > > So now I've the initial motor movement with LED blinking and a scan > movement with green LED. > > But no (strange) data arrives. I tried your diff, but I get the known 'invalid argument error'. Regards, Reinhard Debug output of scanimage: [genesys_gl841] gl841_init [genesys_gl841] gl841_init_registers [genesys_gl841] gl841_setup_sensor [genesys_gl841] gl841_init_registers complete [genesys] sanei_genesys_write_register (0x60, 0x06) completed [genesys] sanei_genesys_write_register (0x61, 0x13) completed [genesys] sanei_genesys_write_register (0x62, 0x55) completed [genesys] sanei_genesys_write_register (0x63, 0x02) completed [genesys] sanei_genesys_write_register (0x64, 0x34) completed [genesys] sanei_genesys_write_register (0x65, 0x04) completed [genesys_gl841] gl841_set_buffer_address_gamma: setting address to 0x0c000 [genesys] sanei_genesys_write_register (0x5c, 0x00) completed [genesys] sanei_genesys_write_register (0x5b, 0x0c) completed [genesys_gl841] gl841_set_buffer_address_gamma: completed [genesys_gl841] gl841_bulk_write_data_gamma writing 128 bytes [genesys_gl841] genesys_bulk_write_data:gamma wrote 128 bytes, 0 remaining [genesys_gl841] genesys_bulk_write_data_gamma: completed [genesys] sanei_genesys_write_register (0x0e, 0x00) completed [genesys] sanei_genesys_write_register (0x6b, 0x0c) completed [genesys] sanei_genesys_write_register (0x6e, 0x6d) completed [genesys] sanei_genesys_write_register (0x6c, 0x00) completed [genesys_gl841] gl841_bulk_write_register (elems = 104) [genesys_gl841] reg[0x01] = 0xa0 [genesys_gl841] reg[0x02] = 0x38 ... [genesys_gl841] reg[0x6b] = 0x02 [genesys_gl841] reg[0x6e] = 0x6d [genesys_gl841] gl841_bulk_write_register: failed while writing command: Invalid argument scanimage: open of device genesys:libusb:001:010 failed: Invalid argument
[sane-devel] Canon LiDE 80 (2nd try)
On Saturday 09 February 2008, Stefan Lucke wrote:
> On Friday 08 February 2008, Reinhard Biegel wrote:
> > Am Wednesday, 6. February 2008 schrieb Reinhard Biegel:
> > > Ohi just remember there was something that had to be called at any
> > > price but didn't find any documentation about that. I'm going to look for
> > > that in my logs.
> >
> > Hi again,
> >
> > I wanted to capture some logs today. But I had to find out that Canon
> > doen't
> > even provide drivers for 64bit Vista, which i set up some days ago.
> > *goingcrazy*
> >
> > As far as I remember there was a bulk write to gamma address space during
> > initialisation which wrote data beyond the end of gamma table in the logs.
> > When saying 'beyond' I'm refering the GL841 datasheet.
>
> You are talking about writes like:
I guess YES.
> set_write_register(0x5b, 0x0c)
> set_write_register(0x5c, 0x00)
> set_register(0x28)
> buf_prepaccess(0x0080,BULK_OUT)
> Data: 01 00 82 00 80 00 00 00
> Index: 0
> BULK>(128)
> 0x18, 0x36, 0x18, 0x36, 0x18, 0x36, 0x18, 0x36,
> 0x18, 0x76, 0x18, 0x76, 0x18, 0x76, 0x18, 0x76,
Thats not the right one, see attached diff.
>
> 5b/5c build address 0x0c 00, whereas gamma address is defined as 10bit.
> I tried a few of them, but without luck.
Now I found the right one AND the right time: Before doing the reset ;-).
So now I've the initial motor movement with LED blinking and a scan
movement with green LED.
But no (strange) data arrives.
--
Stefan Lucke
-- next part --
? backend/genesys_low.c
Index: backend/genesys_devices.c
===
RCS file: /cvsroot/sane/sane-backends/backend/genesys_devices.c,v
retrieving revision 1.11
diff -p -U 3 -r1.11 genesys_devices.c
--- backend/genesys_devices.c 22 Nov 2007 14:05:12 - 1.11
+++ backend/genesys_devices.c 10 Feb 2008 21:00:49 -
@@ -218,6 +218,29 @@ static Genesys_Sensor Sensor[] = {
,
1.0, 1.0, 1.0,
NULL, NULL, NULL}
+ ,
+ /* CANOLIDE80 */
+ {600,
+/*TODO: find a good reason for keeping all three following variables*/
+ 87, /*(black) */
+ 87, /* (dummy) */
+ 0, /* (startxoffset) */
+ 10400, /*sensor_pixels */
+ 210,
+ 200,
+ {0x00, 0x00, 0x00, 0x00},
+ {0x06, 0x13, 0x55, 0x02, 0x32, 0x04, 0x32, 0x14, 0x00,
+0x00, 0x00, 0x00, 0x00, 0x04
+},
+ {0x05, 0x07,
+0x00, 0x00, 0x00, 0x00,/*[GB](HI|LOW) not needed for cis */
+0x3a, 0x03,
+0x40, /*TODO: bit7 */
+0x00, 0x00, 0x00, 0x00 /*TODO (these do no harm, but may be neccessery
for CCD) */
+}
+ ,
+ 1.0, 1.0, 1.0,
+ NULL, NULL, NULL}
};
/** for General Purpose Output specific settings:
@@ -280,6 +303,13 @@ static Genesys_Gpo Gpo[] = {
{0xef, 0x80}
,
}
+ ,
+ /* CANONLIDE80 */
+ {
+ {0x00, 0x8f}
+ ,
+ {0x6d, 0x80}
+ }
};
#define MOTOR_ST24 2
@@ -393,6 +423,17 @@ static Genesys_Motor Motor[] = {
0.8,
},},},
},
+ {/* Canon LiDE 80 */
+ 2400, 2400, 1, 2,
+ {
+{{4687, 937, 128, 0.8, },
+ {4687, 937, 128, 0.8, }, /* {4200, 3800, 30, 0.8, },*/
+},
+{{9375, 1875, 128, 0.8, }, /* {3500, 1300, 60, 0.8, }, */
+ {9375, 1875, 128, 0.8, }, /* {3500, 1400, 60, 0.8, }, */
+},
+ },
+ },
};
/* here we have the various device settings...
@@ -521,6 +562,53 @@ static Genesys_Model canon_lide_60_model
400
}; /* this is completely untested -- hmg */
+static Genesys_Model canon_lide_80_model = {
+ "canon-lide-80", /* Name */
+ "Canon", /* Device vendor string */
+ "LiDE 80", /* Device model name */
+ GENESYS_GL841,
+ NULL,
+
+ {2400, 1200, 600, 300, 150, 75, 0}, /* possible x-resolutions */
+ {4800, 2400, 1200, 600, 300, 150, 75, 0},/* possible y-resolutions */
+ {16, 8, 0}, /* possible depths in gray mode */
+ {16, 8, 0}, /* possible depths in color mode */
+
+ SANE_FIX (0.42), /* Start of scan area in mm (x) */
+ SANE_FIX (7.9), /* Start of scan area in mm (y) */
+ SANE_FIX (218.0),/* Size of scan area in mm (x) */
+ SANE_FIX (299.0),/* Size of scan area in mm (y) */
+
+ SANE_FIX (3.0), /* Start of white strip in mm (y) */
+ SANE_FIX (0.0), /* Start of black mark in mm (x) */
+
+ SANE_FIX (0.0), /* Start of scan area in TA mode in mm (x) */
+ SANE_FIX (0.0), /* Start of scan area in TA mode in mm (y) */
+ SANE_FIX (100.0),/* Size of scan area in TA mode in mm (x) */
+ SANE_FIX (100.0),/* Size of scan area in TA mode in mm (y) */
+
+ SANE_FIX (0.0), /* Start of white strip in TA mode in mm (y) */
+
+ 0, 0, 0, /* RGB CCD Line-distanc
[sane-devel] Canon LiDE 80 (2nd try)
On Friday 08 February 2008, Reinhard Biegel wrote: > Am Wednesday, 6. February 2008 schrieb Reinhard Biegel: > > Ohi just remember there was something that had to be called at any > > price but didn't find any documentation about that. I'm going to look for > > that in my logs. > > Hi again, > > I wanted to capture some logs today. But I had to find out that Canon doen't > even provide drivers for 64bit Vista, which i set up some days ago. > *goingcrazy* > > As far as I remember there was a bulk write to gamma address space during > initialisation which wrote data beyond the end of gamma table in the logs. > When saying 'beyond' I'm refering the GL841 datasheet. You are talking about writes like: set_write_register(0x5b, 0x0c) set_write_register(0x5c, 0x00) set_register(0x28) buf_prepaccess(0x0080,BULK_OUT) Data: 01 00 82 00 80 00 00 00 Index: 0 BULK>(128) 0x18, 0x36, 0x18, 0x36, 0x18, 0x36, 0x18, 0x36, 0x18, 0x36, 0x18, 0x36, 0x18, 0x36, 0x18, 0x36, 0x18, 0x36, 0x18, 0x36, 0x18, 0x36, 0x18, 0x36, 0x18, 0x36, 0x18, 0x36, 0x18, 0x36, 0x18, 0x36, 0x18, 0xb6, 0x18, 0xb6, 0x18, 0xb6, 0x18, 0xb6, 0x18, 0xb6, 0x18, 0xb6, 0x18, 0xb6, 0x18, 0xb6, 0x18, 0xb6, 0x18, 0xb6, 0x18, 0xb6, 0x18, 0xb6, 0x18, 0xb6, 0x18, 0xb6, 0x18, 0xb6, 0x18, 0xb6, 0x18, 0xf6, 0x18, 0xf6, 0x18, 0xf6, 0x18, 0xf6, 0x18, 0xf6, 0x18, 0xf6, 0x18, 0xf6, 0x18, 0xf6, 0x18, 0xf6, 0x18, 0xf6, 0x18, 0xf6, 0x18, 0xf6, 0x18, 0xf6, 0x18, 0xf6, 0x18, 0xf6, 0x18, 0xf6, 0x18, 0x76, 0x18, 0x76, 0x18, 0x76, 0x18, 0x76, 0x18, 0x76, 0x18, 0x76, 0x18, 0x76, 0x18, 0x76, 0x18, 0x76, 0x18, 0x76, 0x18, 0x76, 0x18, 0x76, 0x18, 0x76, 0x18, 0x76, 0x18, 0x76, 0x18, 0x76, 5b/5c build address 0x0c 00, whereas gamma address is defined as 10bit. I tried a few of them, but without luck. > > Without writing beyond the end the motors only made ugly noise, but when > writing there the initial motor movement (forward-backward-forward...) took > place (not the same speed as with windows drivers, either little bit slower > or faster, don't remember). Running scanimage alone still produces the ugly motor sound. When I use "testprog" (mentioned earlier) ahead, scanimage is moving scanhead a back and forward and starts (now with LED on [green]) moving for a complete scan. The only thing which works (standalone) is recognition of home position (thats a hand polished diff): Index: backend/genesys_gl841.c === RCS file: /cvsroot/sane/sane-backends/backend/genesys_gl841.c,v retrieving revision 1.19 diff -p -U 3 -r1.19 genesys_gl841.c --- backend/genesys_gl841.c 3 Feb 2008 10:34:20 - 1.19 +++ backend/genesys_gl841.c 8 Feb 2008 19:51:09 - @@ -2023,6 +2076,9 @@ HOME_FREE: 3 r = sanei_genesys_get_address (reg, 0x69); r->value = 0; +r = sanei_genesys_get_address (reg, 0x6b); +r->value |= 1; /* LiDE 80: turn on motor home sensor */ + r = sanei_genesys_get_address (reg, 0x6a); r->value = (fast_slope_steps >> 1) + (fast_slope_steps & 1); @@ -3475,6 +3552,12 @@ gl841_slow_back_home (Genesys_Device * d wait_until_home); memset (local_reg, 0, sizeof (local_reg)); + + /* LiDE 80: ensure that home sensor is powered on for reading ;-) */ + sanei_genesys_read_register (dev, 0x6b, &val); + val |= 1; + sanei_genesys_write_register (dev, 0x6b, val); + val = 0; status = sanei_genesys_get_status (dev, &val); if (status != SANE_STATUS_GOOD) -- Stefan Lucke
[sane-devel] Canon LiDE 80 (2nd try)
Am Wednesday, 6. February 2008 schrieb Reinhard Biegel: > Ohi just remember there was something that had to be called at any > price but didn't find any documentation about that. I'm going to look for > that in my logs. Hi again, I wanted to capture some logs today. But I had to find out that Canon doen't even provide drivers for 64bit Vista, which i set up some days ago. *goingcrazy* As far as I remember there was a bulk write to gamma address space during initialisation which wrote data beyond the end of gamma table in the logs. When saying 'beyond' I'm refering the GL841 datasheet. Without writing beyond the end the motors only made ugly noise, but when writing there the initial motor movement (forward-backward-forward...) took place (not the same speed as with windows drivers, either little bit slower or faster, don't remember). Note that I changed the base resolution of the motor as I mentioned in another post. I hope my observations aren't bogus. Some times I apparently re-plugged the scanner too fast, so that the registers could not reset to undefined values and stored the setup of the windows driver. (I used to replay the USB commands under linux). As I mentioned I hope I don't mislead you with my beyond-gamma-writing idea, but maybe someone can verify that. Regards, Reinhard
[sane-devel] Canon LiDE 80 (2nd try)
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
[sane-devel] Canon LiDE 80 (2nd try)
Am Wednesday, 6. February 2008 schrieb Stefan Lucke: > Do you have some old sources of your changes ? > > Playing with motor settings doesn't make a difference (at the moment). Sorry, I trashed the sources because I messed something up and then nothing was working any more. I planed to start over again but had no time to do so. As far as I remember I simply set the registers as it is done by the windows driver after pluggin in the scanner and then I replaced them step by step with existing sane calls. Ohi just remember there was something that had to be called at any price but didn't find any documentation about that. I'm going to look for that in my logs. Regards, Reinhard
[sane-devel] Canon LiDE 80 (2nd try)
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 ;-) . -- Stefan Lucke
[sane-devel] Canon LiDE 80 (2nd try)
On Wednesday 06 February 2008, Reinhard Biegel wrote: > > Am Wednesday, 6. February 2008 schrieb Stefan Lucke: > > Even with turned off LED and some motor sound (movement in the wrong > > direction ??), scanimage produced some pnm files. > > > > To be continued, but I really need some help, as I've no idea > > about scanner hardware. > > Hi, > > I played around some time ago with the LiDE 80. IIRC I got the motor working > by adjusting its base resolution (2400 instead of 1200 or something). But I'm > not shure it it was the only thing. > Thanks for your reply. Do you have some old sources of your changes ? Playing with motor settings doesn't make a difference (at the moment). -- Stefan Lucke
[sane-devel] Canon LiDE 80 (2nd try)
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. Regards, Pierre > -- snip -- > > Both lines are required! > (Note: disconnect has timestamp earlier than USBDEVFS message). > > Even with turned off LED and some motor sound (movement in the wrong > direction ??), scanimage produced some pnm files. > > To be continued, but I really need some help, as I've no idea > about scanner hardware. > >> -- dmesg output (kernel 2.6.23.13): -- >> [ 5298.424302] usb 1-7: new high speed USB device using ehci_hcd and address >> 17 >> [ 5298.480244] usb 1-7: OK: device descriptor read/64, error 0, mp 64 (0 0) >> [ 5298.491202] usb 1-7: configuration #1 chosen from 1 choice >> [ 5312.035169] usb 1-7: usbfs: USBDEVFS_CONTROL failed cmd scanimage rqt 64 >> rq 4 len 2 ret -71 >> [ 5312.035148] usb 1-7: USB disconnect, address 17 >> [ 5312.188163] usb 1-7: new high speed USB device using ehci_hcd and address >> 18 >> [ 5312.244105] usb 1-7: OK: device descriptor read/64, error 0, mp 64 (0 0) >> [ 5312.255079] usb 1-7: configuration #1 chosen from 1 choice >
[sane-devel] Canon LiDE 80 (2nd try)
Am Wednesday, 6. February 2008 schrieb Stefan Lucke: > Even with turned off LED and some motor sound (movement in the wrong > direction ??), scanimage produced some pnm files. > > To be continued, but I really need some help, as I've no idea > about scanner hardware. Hi, I played around some time ago with the LiDE 80. IIRC I got the motor working by adjusting its base resolution (2400 instead of 1200 or something). But I'm not shure it it was the only thing. Regards, Reinhard Biegel
[sane-devel] Canon LiDE 80 (2nd try)
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 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); -- snip -- Both lines are required! (Note: disconnect has timestamp earlier than USBDEVFS message). Even with turned off LED and some motor sound (movement in the wrong direction ??), scanimage produced some pnm files. To be continued, but I really need some help, as I've no idea about scanner hardware. > > -- dmesg output (kernel 2.6.23.13): -- > [ 5298.424302] usb 1-7: new high speed USB device using ehci_hcd and address > 17 > [ 5298.480244] usb 1-7: OK: device descriptor read/64, error 0, mp 64 (0 0) > [ 5298.491202] usb 1-7: configuration #1 chosen from 1 choice > [ 5312.035169] usb 1-7: usbfs: USBDEVFS_CONTROL failed cmd scanimage rqt 64 > rq 4 len 2 ret -71 > [ 5312.035148] usb 1-7: USB disconnect, address 17 > [ 5312.188163] usb 1-7: new high speed USB device using ehci_hcd and address > 18 > [ 5312.244105] usb 1-7: OK: device descriptor read/64, error 0, mp 64 (0 0) > [ 5312.255079] usb 1-7: configuration #1 chosen from 1 choice -- Stefan Lucke
[sane-devel] Canon LiDE 80 (2nd try)
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] attach: start: devp != NULL, may_wait = 0 [genesys] attach: trying to open device `libusb:001:017' [genesys] attach: device `libusb:001:017' successfully opened [genesys] attach: found Canon flatbed scanner LiDE 80 at libusb:001:017 [genesys] attach: exit [genesys] sane_init: exit [genesys] sane_get_devices: start: local_only = false [genesys] sane_get_devices: exit [genesys] sane_open: start (devicename = `libusb:001:017') [genesys] sane_open: found `canon-lide-80' in devlist [genesys] init_options: start [genesys] init_options: exit [sanei_debug] Setting debug level of genesys_gl841 to 255. [genesys_gl841] gl841_init [genesys_gl841] gl841_init_registers [genesys_gl841] gl841_setup_sensor [genesys_gl841] gl841_init_registers complete [genesys] sanei_genesys_write_register (0x0e, 0x00) completed [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 -- dmesg output (kernel 2.6.23.13): -- [ 5298.424302] usb 1-7: new high speed USB device using ehci_hcd and address 17 [ 5298.480244] usb 1-7: OK: device descriptor read/64, error 0, mp 64 (0 0) [ 5298.491202] usb 1-7: configuration #1 chosen from 1 choice [ 5312.035169] usb 1-7: usbfs: USBDEVFS_CONTROL failed cmd scanimage rqt 64 rq 4 len 2 ret -71 [ 5312.035148] usb 1-7: USB disconnect, address 17 [ 5312.188163] usb 1-7: new high speed USB device using ehci_hcd and address 18 [ 5312.244105] usb 1-7: OK: device descriptor read/64, error 0, mp 64 (0 0) [ 5312.255079] usb 1-7: configuration #1 chosen from 1 choice -- Stefan Lucke
