Hi stef schrieb: > On Sat, Aug 27, 2005 at 12:43:38AM +0200, Pierre Willenbrock wrote: > ... >>Currently known bugs: >> 1 You need to replug the scanner every other retry >> 2 Sometimes the calibration process hangs ... > > > Hello, > > I got the same "1 an 2" issue. I don't know if you have the same > problem, > but it appeared that the backend has to read 1 more data line than indicated > in > the LINCNT register. Before I figured this out, the first scan for > calibration > succeeded, but not the in following runs, and it hanged in shading calibration > while reading data. > > Regards, > Stef
That is not quite the problem i am having. The scanner does not send any extra lines. For #1 i am plugging in the scanner, use scanimage. The next try of scanimage succeeds in 50% of all cases. If it does not succeed, scanimage simply hangs on first read. From the debugging output i see that the scanner should be willing to send data(VALIDWORD != 0), but the bulk read never finishes. I also experience this with my test program, but that will recover on a third try, while scanimage does not. When #2 occurs the scan should theoretical begin, the MOVE register is written to, but the scanner does not do anything, and VALIDWORD never changes from 0. Either the scanner does not receive the write, or the transmitted data is corrupt. >From the logs i guess there are two usb operations which report the state of the register interface and the bulk interface. But the returned data of these operations is always the same, and the scanner can operate without them, so i don't know how to use them. I will try to find out whether the data changes when starting my test program multiple times. I was hoping someone could provide more information about the usb interface. The chip documentation does not tell anything on how to actually access a register on the control message level. There is another bug(just to extend the bug list): When the scan buffer runs full and the scanner moves back there will be errors in the following line. I don't know if this is because the scan buffer runs full, or because the scan buffer runs empty shortly after(the scanner does not go forward fast enough to reach the last scanning position before the buffer runs empty). Regards, Pierre
