[sane-devel] Plustek OpticPro 1212U / HP ScanJet 4200C
Wed, 26 Nov 2003 12:51:37 +0100
Le mer 26/11/2003 à 11:48, Gerhard Jaeger a écrit :
> > 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
Uhm. OK. :( How about reverse engineering the connections between the
98003 and the GL640? My brother is not a software guy indeed, but he can
use an ohmmeter and help sort out things there.
> 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...
An outside eye might be helpful. Could you send me the logs together
with an indication of what the scanner was asked to do at that time?
> > 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...
Well, it's not a promising option anyway; these are legacy devices, I'm
afraid. So let's forget that idea.
> Not very good news, I know ;-)
I'be seen worse. :)
Albert ARIBAUD <firstname.lastname@example.org>