Comments below...
On Tue, 28 Dec 1999, Adrian Perez Jorge wrote:
> Dear Mat,
> Dear David,
>
> I would be very pleased if you, Mat, could tell me who are you trying
> to read/write `lm9830' registers. Initialy, I was confused and I
> thought HP4200C was using `lm9831'---because it has an USB interface---
> and I was trying to read/write <reg address>+<value> to the
> `/dev/usbscanner' file. Now, I know I was wrong. I can't believe my
> HP4200C scanner is really a parallel port scanner hacked with some USB
> interface... (but it's quick!)
Funky ain't it....
> Well.. the main problem is: then how this interface works?
>
> I have been tracing (debugger) the Windowze driver (`hpad32.dll').
> I have the initial values of `lm9830' registers that this driver
> writes (from 08-5f), and I have seen the driver sending the '99 66 cc
> 33' sequence (switching transparent mode).
Good. The lm9830 docs support this.
> Now, I think write/read operations to lm930 registers doesn't use bulk
> transfers; the Windoze driver uses `control vendor requests' (note
> that I'm not an USB expert at all.), and I think (David, correct me)
> Linux usbscanner driver uses bulk transfers to communicate with the
> scanner.
Hmmmm...control xfers. This could be interesting. Yes, scanner.c uses
bulk in/out devices when xfering the images.
If control xfers are in fact being used, I could send those chars when the
4200 is detected and configured. I wonder if this would take the 9830 out
of transparency mode and allow the bulk pipes to be accessible. Sounds
like an experiment for this evening. Why else would the device report two
bulk endpoints (one each for input and output). Besides, ctrl endpoints
aren't designed for large data xfers.
> Well... as far as I have read in the SANE Standard Version (1.01), yes
> you can switch sane backends using dynamic linking (See `Attaching to a
> SANE backend', Section 3.1).
>
> I don't know if you mean, for example, that developing a sane backend
> for `lm9830', using an USB interface like the HP4200C, should also work
> with a `lm9830-based' scanner but with a parallel port interface.
>
> If the above is what you mean, I think the best/normal way to do this
> is to separate the device communication protocol implementing a kernel
> device driver, like the `scanner.o' module. This device driver should
> supply a `/dev/<iface>' file, and then the SANE backend would
> write/read to this file in an uniform way. This file should be
> supplied to the backend as an option. For example, using a parallel
> port interface, a module called `ppscanner.o' could support a
> `/dev/ppscanner' file, and then, a parameter in `lm9830.conf' for the
> `lm9830.so' SANE backend could point to this file. If we were using
> an USB inteface, this option should then point to `/dev/usbscanner'.
>
> What do you (all) think about this?
I think that when the 4200 is plugged in, the device driver should take it
out of transparency mode (if the above works w/ regards to taking it out
of xparency mode). The only difference between the 9830 and 9831 is the
interface method so the backend should not care. If a backend were to be
developed, this difference should be hidden, don't you think?
Regards,
/\/elson
-- Source code, list archive, and docs: http://www.mostang.com/sane/ To unsubscribe: echo unsubscribe sane-devel | mail majordomo@mostang.com