# Re: Mustek/Request-sense problems -> Solution?

David Mosberger-Tang (davidm@azstarnet.com)
Thu, 8 May 1997 13:33:23 -0700

- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
- Next message: David Mosberger-Tang: "Re: sane-0.56 and hp"
- Previous message: Thomas Blume: "Re: Mustek/Request-sense problems -> Solution?"

>>>>> On Thu, 8 May 1997 16:37:36 +0200, Thomas Blume <mblum1@tc9.uni-paderborn.de> said:

Thomas> The results I obtain show the same effects as were mentioned
Thomas> here with 3-pass scanning. But as lineart mode for faxing is
Thomas> currently my main application, I didn't try to track it down
Thomas> further.

Hmmh, the only problem with 3-pass scanning at this point is a
performance problem. The actual scanning works fine AFAIK. If you
get horizontal stripes in the scanned images, then maybe we need to
turn on the MUSTEK_FLAG_LD_MFS for your firmware revision as well.
There is the following if-statement in mustek.c:attach():

/* Revision 1.00 of the MFS-12000SP firmware is buggy and needs
this workaround. Maybe others need it too, but this one is
for sure. We know for certain that revision 1.02 or newer
has this bug fixed. */
if (fw_revision < 0x102)
dev->flags |= MUSTEK_FLAG_LD_MFS;

If you get horizontal strips, could you change the "< 0x102" into "<=
0x102" and let me know whether that fixes the problem (I'd recommend
to do a "make clean" in the SANE root directory and then "make" and
"make install" after making this change---just to be on the safe
side).

Thomas> I assume that all device independent sense keys are covered
Thomas> by the kernel correctly, so only device specific keys have
Thomas> to be checked. In case of sg_header all the information is
Thomas> provided in req->hdr.sense_buffer and could be checked in
Thomas> sanei_scsi_cmd. For
Thomas> ioctl I think that the sense buffer could also be obtained
Thomas> after the call, but I'm not sure. Perhaps one could call a
Thomas> backend specific function pointer for parsing if sense key
Thomas> != NO_SENSE && valid.

What I did is change the SANEI_SCSI interface so you can optionally
register a sense-handler callback that can be used to translate the
sense-buffer info into a reasonable SANE status-code. This enables
the Mustek backend to translate a pretty meaning less "MEDIA ERROR"
into "scanner cover open." So, I think this is a flexible solution
that doesn't burden backends that don't need/want to deal with sense
info (such as the HP backend).

Thomas> BTW: there exists another version of the bundled DTC3181.

Somehow, this doesn't surprise me at all...

Thomas> It
Thomas> has only 1 jumper for wait, the PNR/PNP jumper is missing.

Can somebody explain to me what Plug-and-Run is as opposed to
Plug-and-Play? I'm not really all that wired into the pc-world.

Thomas> I
Thomas> could not manage to get it to work with Linux, but this
Thomas> rubbish part is not worth any more efforts. With NT4.0
Thomas> finally Mustek provides a working driver for it, but this
Thomas> card effectively turns NT into a single tasking OS.

;-))

Yeah, I definitively think $50 for an ncr810 controller is money well
spent.

--david

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

- Next message: David Mosberger-Tang: "Re: sane-0.56 and hp"
- Previous message: Thomas Blume: "Re: Mustek/Request-sense problems -> Solution?"