[sane-devel] Plustek OpticPro 1212U / HP ScanJet 4200C

Gerhard Jaeger gerhard@gjaeger.de
Wed, 26 Nov 2003 11:48:36 +0100


Hi Albert,

On Mittwoch, 26. November 2003 10:23, Albert ARIBAUD wrote:
[SNIPSNAP]
> I see that the canon fb630u backend is divided in two source files : one
> for the backend as such, and one for driving the GL640, providing basic
> EPP instructions plus scanner-specific data transfer sequences. Makes me
> wonder whether this backend was built by splitting the corresponding EPP
> backend into scanner-level and port-level operations, the modifying the
> port-level part.

That's where I started too.

> So maybe a solution for the OpticPro 1212U would be to i) adapt the
> scanner-specific sequences using traces from Twain scans under windows,
> and ii) integrate the adapted GL640 file with the existing 98003-based
> backend.

So was my idea ;-)
BUT - now it comes:
I simply turned the IO operations in the parport backend, and hoped, that
the scanner will work. The major problem is, that the GL640 allows various
ways on how a parport-ASIC can be connected, and therefore it is almost
impossible to directly "map" the former parport I/O functions to USB I/O
functions...
After all of these trials had no or minor success, I made some USB-snoop
loggings and noticed, that for this scanner almost only bulk-read and -writes
are used and so the whole parport-driver code needs to be rewritten there.
There are currently also some parts of the log, that I do not understand...

> Another choice I see is taking the GL640 code and turning it into a
> pseudo ieee1284 kernel module or an extension to the ieee1284 lib. Then
> we could use the genuine 98003-based backend. But this seems not to be
> design choice for the fb630, so it might be a more bug-attracting
> choice.

See my statements above. It might be a good idea to have a generic 
parport-USB bridge library, where we can simply add more of these
bridges and where we have some functions like write_control, write_data,
but I doubt that this will help much in simply porting existing parport-code
to some USB-parport code, as we almost never know how the ASIC is 
connected to the bridge...

Not very good news, I know ;-)

Ciao,
  Gerhard