[sane-devel] Stuck somehow in porting to Win98/ASPI

[Richard Metzger]

Hello great sane-team!

first of all - thanks to all you developers for all the sane code and to Frank Zago for his Win-port.

Frank is right in one of his statements: "it may or may not work on Win95/98/me"..

Well, meanwhile I know, that it doesn't work on Win 98 - because of missing support for opening files like "\\.\Scsi0" and using subsequent DeviceIOCTL.
So I started to recode the pieces, that I could identify for using the ASPI interface.

After the first few iterations in changing sane-find-scanner.c and sanei_scsi.c I'm at a point, where sane-find-scanner works as well as scanimage -L.

However the first attempts to actually scan something fail at a certain point

I do 
set SANE_DEBUG_HP=255
scanimage > a.pmn
and capture a lengthy log, which shows several dozends of successful interactions with my old HPSJ IIcx until the point in time, where the scan should start

-- extracts from the log --
[hp] start: No request to mirror image vertically
[hp] start: 2550 pixels per line, 319 bytes per line, 4199 lines high
[hp] sanei_hp_scl_startScan: Start scan
[hp] scsi_flush: writing 5 bytes:
[hp]  0x0000  1B 2A 66 30 53                                   .*f0S
[hp] sanei_hp_device_info_get: searching h2b0t2l0
[hp] sanei_hp_device_info_get: check h2b0t2l0
[hp] hp_handle_startReader: parent closes write end of pipe
[hp] start_reader: reader process 16391851 started
[hp] scsi_close: closing fd 1
[hp] sanei_hp_device_info_get: searching h2b0t2l0
[hp] sanei_hp_device_info_get: check h2b0t2l0
[hp] hp_IsOpenFd: 1 not open
[hp] scsi_close: really closed
[hp] hp_RemoveOpenFd: 1 not removed
[hp] sane_start will finish with Success
[hp] sane_get_parameters called
[hp] sane_get_parameters will finish with Success
[hp] sane_read called
[hp] sanei_hp_handle_read: trying to read 32768 bytes
[hp] sanei_hp_device_info_get: searching h2b0t2l0
[hp] sanei_hp_device_info_get: check h2b0t2l0
[hp] sanei_hp_device_info_get: searching h2b0t2l0
[hp] sanei_hp_device_info_get: check h2b0t2l0
[hp] do_read: Start reading data from scanner
[hp] do_read: entering request to read 32768 bytes
                   I guess it looks ok until here, but the next line might indicate that something went wrong.
[hp] sanei_hp_handle_read: EOF from pipe. Stop scan
[hp] hp_handle_stopScan: killing child (16391851)
[hp] hp_handle_stopScan: child signalled, signal = 11
[hp] sanei_hp_device_info_get: searching h2b0t2l0
[hp] sanei_hp_device_info_get: check h2b0t2l0
[hp] hp_GetOpenDevice: device h2b0t2l0 not open
[hp] scsi_inquire: sending INQUIRE
[hp] vendor=HP      , model=C2500A          , rev=3332
[hp] scsi_new: sending TEST_UNIT_READY
[hp] hp_AddOpenDevice: h2b0t2l0 should not be kept open
[hp] scsi_flush: writing 2 bytes:
[hp]  0x0000  1B 45                                            .E
[hp] sanei_hp_device_info_get: searching h2b0t2l0
[hp] sanei_hp_device_info_get: check h2b0t2l0
[hp] scsi_flush: writing 7 bytes:
[hp]  0x0000  1B 2A 73 32 35 37 45                             .*s257E
[hp] sanei_hp_device_info_get: searching h2b0t2l0
[hp] sanei_hp_device_info_get: check h2b0t2l0
[hp] sanei_hp_device_info_get: searching h2b0t2l0
[hp] sanei_hp_device_info_get: check h2b0t2l0
[hp] sanei_hp_device_info_get: searching h2b0t2l0
[hp] sanei_hp_device_info_get: check h2b0t2l0
[hp] scsi_read:  16 bytes:
[hp]  0x0000  1B 2A 73 32 35 37 64 30 56 00 00 00 D0 6D 0F 61  .*s257d0V....m.a
[hp] scsi_close: closing fd 1
[hp] sanei_hp_device_info_get: searching h2b0t2l0
[hp] sanei_hp_device_info_get: check h2b0t2l0
[hp] hp_IsOpenFd: 1 not open
[hp] scsi_close: really closed
[hp] hp_RemoveOpenFd: 1 not removed
[hp] sane_read will finish with Error during device I/O
scanimage: sane_read: Error during device I/O
[hp] sane_close called
[hp] sanei_hp_handle_destroy: stop scan
----- end extract -------------------

I feel like I cant tell the wood from the trees.... the higher level architecture of the HP backend is not described very well and so far I haven't been able to reconstruct it from the low level code itself.

I have the suspicion, that there are two processes talking to each other via a pipe, which might not be set up correctly.

You might want to ignore the lines, that deal with fd (the file descriptor handling) - I'm not using a file descriptor really. I use a hard coded fd=1 so that the fd_info array is used as it should, but I've not had the time/nerves yet to clean up the related error messages.

If one of you thinks it's worth to persue this old-fashioned environment (I'm using Linux since quite some time and dislike Wintendo, but for several reasons it has to be Win98 in this case here) I'd appreciate any kind of insight into the backend's higher level structure  and/or pointers where to stick my nose in :-))

Thanks a lot in advance.

Richard.
______________________________________________________________
Verschicken Sie romantische, coole und witzige Bilder per SMS!
Jetzt bei WEB.DE FreeMail: http://f.web.de/?mc=021193