Re: Sane on NeXT/OpenStep - a plea for help

David Mosberger-Tang (davidm@azstarnet.com)
Mon, 16 Jun 1997 15:02:44 -0700

>>>>> On Mon, 16 Jun 1997 15:49:37 -0400 (EDT), " Raymond A. Ingles" <inglesra@frc.com> said:

Raymond> On Sun, 15 Jun 1997, Neville Wilford wrote:

>> My scanner is an OEM version Mustek 600 II CD single-pass. After
>> some difficulty it can now be persuaded to work with either Win'95 or
>> NT using an Adaptec 2940UW or a Symbios/NCR 810 card. NeXTStep
>> support would be far preferable.
>>
>> The OEM feature means that its SCSI-ID string is "SCANNER" rather
>> than "MUSTEK".

Raymond> I think I've got one of those. It was labeled as a
Raymond> "TwainScan II SP".

Raymond> Doing 'cat /proc/scsi/scsi' gives:
Raymond> -----------------
Raymond> Host: scsi0 Channel: 00 Id: 06 Lun: 00
Raymond> Vendor: SCANNER Model: Rev: 2.01
Raymond> Type: Scanner ANSI SCSI revision: 01 CCS
Raymond> -----------------

Hacking around this problem is not too hard ASSUMING there is only one
scanner model exists and that no other scanner vendor will be crazy
enough to call themselves "SCANNER".

If you want to fix this, just look in backend/mustek.c around line
294. That's where the backend checks the vendor name. You'll also
have to make up an appropriate `model_name' (e.g., set it to
"MFC-6000CZ" if it is a 600 dpi scanner).

There is a chance that the scanner has the vendor/model name stored in
a strange place. Normally, the vendor string starts at byte 8 of the
inquiry result and the model string at byte 16. There seem to be some
Mustek scanners that store the vendor string at byte 36 and the model
at byte 44. The backend already checks for both cases, but you may
want to look at the inquiry result with gdb at the off-chance that a
model string might be hiding somewhere in that inquiry result.

--david

--
Source code, list archive, and docs: http://www.azstarnet.com/~axplinux/sane/
To unsubscribe: mail -s unsubscribe sane-devel-request@listserv.azstarnet.com