On Sat, Oct 02, 1999 at 02:27:52PM -0700, Levente NOVÁK wrote:
> Hi all,
>
> Some days ago, I posted a question in this newsgroup, but I was not
> subscibed to the sane-devel list at that time and did not receive any
> answer yet.
> I have a Microtek Phantom 636cx parallel-port scanner and would like to
> be able to scan from under Linux. I built a 2.2.10 kernel patched with
> ppSCSI v0.91, and Sane-1.0.1 (with the microtek2-pre0.8 driver).
> In the beginning, I got an I/O error when I was running "scanimage -d
> microtek2:/dev/sg0 --help" or wanted to do a scan, even if find-scanner
> seemed to recognise the hardware. Looking closer at the situation, I
> discovered that my scanner's model code (0x9a) was simply not recognised
> by the backend. Then I patched microtek2.c to include my scanner and
> tried again, setting the debug levels to 128. This time it was better,
> as the scanner got recognised, but something went wrong later on,
> producing the following debug code:
>
> ...snip...
>
> [microtek2] scsi_read_attributes: mi=0x804e484, device='/dev/sg0',
> source=3
> [sanei_init_debug]: Setting debug level of sanei_scsi to 128.
> [sanei_scsi] scsi_req_enter: entered 0x804ed20
> [sanei_scsi] sanei_scsi_req_wait: waiting for 0x804ed20
> [sanei_scsi] sanei_scsi.issue: 0x804ed20
> [sanei_scsi] sanei_scsi_req_wait: read 76 bytes
> [sanei_scsi] sanei_scsi_req_wait: SCSI command complained: Success
> [microtek2] scsi_sense_handler: fd=11, sense=0x804ed4c arg=(nil)
> [microtek2] dump_area: SenseBuffer
> 0: f00005ffffffe91f 0000000024000000 ........ ....$...
> 16: d29100025804b013 ec1b3002585d13ec ....X... ..0.X]..
> 32: 000080ffffff ......
> [microtek2] scsi_sense_handler: info: ' '
> [microtek2] scsi_sense_handler: Invalid field in CDB
> [microtek2] scsi_read_attributes: cmd 'Error during device I/O'
> [microtek2] attach_one: returning
> [sanei_scsi] searched device is /dev/sg0
> [microtek2] attach_one: name='/dev/sg0'
> [microtek2] add_device_list: device='/dev/sg0'
> [microtek2] add_device_list: device '/dev/sg0' already in list
> [microtek2] attach_one: returning
> [microtek2] sane_open: device='/dev/sg0'
> [microtek2] add_device_list: device='/dev/sg0'
> [microtek2] add_device_list: device '/dev/sg0' already in list
> [microtek2] attach: device='/dev/sg0'
> [microtek2] scsi_inquiry: mi=0x804e31c, device='/dev/sg0'
> [sanei_init_debug]: Setting debug level of sanei_scsi to 128.
> [sanei_scsi] scsi_req_enter: entered 0x804ed20
> [sanei_scsi] sanei_scsi_req_wait: waiting for 0x804ed20
> [sanei_scsi] sanei_scsi.issue: 0x804ed20
> [sanei_scsi] sanei_scsi_req_wait: read 41 bytes
> [sanei_scsi] scsi_req_enter: entered 0x804ed20
> [sanei_scsi] sanei_scsi_req_wait: waiting for 0x804ed20
> [sanei_scsi] sanei_scsi.issue: 0x804ed20
> [sanei_scsi] sanei_scsi_req_wait: read 132 bytes
> [microtek2] check_inquiry: mi=0x804e31c
> [microtek2] scsi_read_attributes: mi=0x804e31c, device='/dev/sg0',
> source=0
> [sanei_init_debug]: Setting debug level of sanei_scsi to 128.
> [sanei_scsi] scsi_req_enter: entered 0x804ed20
> [sanei_scsi] sanei_scsi_req_wait: waiting for 0x804ed20
> [sanei_scsi] sanei_scsi.issue: 0x804ed20
> [sanei_scsi] sanei_scsi_req_wait: read 76 bytes
> [microtek2] scsi_read_attributes: mi=0x804e484, device='/dev/sg0',
> source=3
Here the backend tries to inquire the attributes of a 'stripe' mode, but
I think, that this mode is not available for the Phantom 636cx. If you
look into the function attach() in microtek2.c, you can see that there
are several calls to the function scsi_read_attributes(). This function
inquires the values for the scanner attributes, such as resolution and
scan area for each scan mode like flatbed, transparency media adapter and
so on separately.
It will probably help to remove the calls to this function for all modes,
but for flatbed mode. If you have problems, please send me an email or
send another mail to this list.
Also, it would be interesting to see the scanner attributes, which are
printed to stderr, if 'option dump 1' is set in the microtek2.conf
file.
> [sanei_init_debug]: Setting debug level of sanei_scsi to 128.
> [sanei_scsi] scsi_req_enter: entered 0x804ed20
> [sanei_scsi] sanei_scsi_req_wait: waiting for 0x804ed20
> [sanei_scsi] sanei_scsi.issue: 0x804ed20
> [sanei_scsi] sanei_scsi_req_wait: read 76 bytes
> [sanei_scsi] sanei_scsi_req_wait: SCSI command complained: Success
> [microtek2] scsi_sense_handler: fd=8, sense=0x804ed4c arg=(nil)
> [microtek2] dump_area: SenseBuffer
> 0: f00005ffffffe91f 0000000024000000 ........ ....$...
> 16: d29100025804b013 ec1b3002585d13ec ....X... ..0.X]..
> 32: 000080ffffff ......
> [microtek2] scsi_sense_handler: info: ' '
> [microtek2] scsi_sense_handler: Invalid field in CDB
> [microtek2] scsi_read_attributes: cmd 'Error during device I/O'
> scanimage: open of device microtek2:/dev/sg0 failed: Error during device
> I/O
>
> ...snip...
>
> As I know some other people had success with Phantom 336cx, I am
> wondering whether there is somebody who could help me. In the June
> archive, Michele Bini posted a similar debug output, which differed
They have had more or less success. The major problem with these models is,
that they skip some lines at the beginning of the scan area and then try
to scan beyond the scan area, and thus the scan head hits the bottom of
the device.
I have contacted Microtek in Taiwan to help me solve this problem, and have
got an email response that they will look into this. However, in my
experience, this is not a guarantee, that something will happen in the
near future.
Bernd
-- Bernd Schroeder Email: mailto:bernd@aquila.muc.de PGP public key available: mailto:pgp@aquila.muc.de | Subject: send key
-- Source code, list archive, and docs: http://www.mostang.com/sane/ To unsubscribe: echo unsubscribe sane-devel | mail majordomo@mostang.com