SCSI scanner, sym/ncr driver, pt(4)

[Oliver Fromme]

Matthias Andree <matthias.andree at gmx.de> wrote:
 > Oliver Fromme <olli at lurza.secnetix.de> writes:
 > > First I noticed that the NCR810 host adapter seems to be
 > > supported both by ncr(4) and sym(4).  I was unable to find
 > > any documentation about the advantages of each.
 > 
 > Try reading the man pages carefully.
 > 
 > The differences have melted down somewhat in the past.
 > 
 > There was a time when sym(4) didn't support the more efficient
 > LOAD/STORE uncapable 810, 815, 825 chips (the A variants, where they
 > exist, support LOAD/STORE). sym(4) has learned to use MEMMOVE on these,
 > however.
 > 
 > ncr(4) has never used LOAD/STORE, and lacks support for the 897 chip and
 > the 1010 family.

I've read about that LOAD/STORE and MEMMOVE stuff in the
manpage, but I'm not a SCSI expert, so that's really only
gibberish to me, I'm afraid.  Hell, I do not even know if
my "810" card is an "early NCR 810" which sym(4) keeps
talking about.

If you're just a user, the manpages fail to tell whether
the sym(4) or ncr(4) driver is preferred for an 810 host
adapter.

 > > The man pages don't mention when to prefer one over the other.  I
 > > tried sym(4) first because it seems to be newer, and it works fine.
 > 
 > So stick with it.

I will.  Thanks for the advice and explanation.

 > > But I wonder if the ncr(4) driver offered any advantages.
 > 
 > It doesn't. There used to be a time when it worked with the old 810 and
 > sym(4) didn't, but this no longer holds.

OK, so the ncr(4) should be regarded obsolete, right?  In
that case, the manpage should say so, at least.

The sym(4) manpage explains in great length how to configure
a preference between stm(4) and ncr(4), so that differnt
chip types are attached to different drivers (using the
SYM_SETUP_LP_PROBE_MAP setting).  That made me think that
there must be a reason why you would want to use the ncr(4)
driver for certain chips.

I think that all of that is pretty confusing.

Anyway, thanks for the clarification, Matthias.

 > > pt0 at sym0 bus 0 target 4 lun 0
 > > pt0: <EPSON SC ANNER GT-9000 1.11> Fixed Processor SCSI-CCS device 
 > > pt0: 3.300MB/s transfers
 > > 
 > > However, the SANE back-end driver (man pages sane-epson(5)
 > > and sane-sscsi(5)) doesn't want to use /dev/pt0.  When I
 > > try to access it, I get "invalid argument".  The device
 > > node does exist, of course.  But when I tell SANE to use
 > > the pass device, it works.
 > 
 > Sane now accesses devices through more generic access schemes, libusb
 > for USB scanners, and pass for SCSI scanners. It was found that adding
 > scanner drivers to the kernel is unnecessary bloat.

I certainly agree with that.  But pt(4) is not a scanner
driver, but a generic SCSI processing target driver, right?
Do you know if there's a reason why SANE doesn't want to
use it?  I mean, what _purpose_ does pt(4) serve?

Sorry if that's a dumb question.  :-)

So I assume I can remove "device pt" from my kernel, and
SANE would still work.

 > > The problem with that is that the number of the pass
 > > device is not always the same.  It can be /dev/pass0 or
 > > /dev/pass1, depending on whether the scanner was on
 > > during boot, or switched on later and detected by re-
 > > scanning the SCSI bus.  That's somewhat annoying, because
 > > I have to change the device setting all the time.
 > 
 > Does it work if you list both devices (pass0 and pass1) in the SANE
 > configuration (sane.d/epson.conf), or if you don't list explicit devices
 > at all?

In fact, I don't list them.  My epson.conf just contains
this line:

scsi "EPSON SC"

so the scanner is identified by the vendor string.  That
works fine.  scanimage(1) reports that it finds the scanner
"epson:/dev/pass0" or "epson:/dev/pass1".

However, gimp and the xscanimage plugin use the full SANE
scanner device string for identifying it and storing their
configuration.  From the view point of gimp/xscanimage,
I have two scanners.  When I change the configuration of
my pass0 scanner (e.g. resolution, color correction,
whatever), it doesn't affect the "other" scanner, and vice
versa.  That's annoying.

Hm.  I've just got an idea.  Is it possible to use devd(8)
to create a symlink /dev/scanner whenever the scanner is
detected, pointing to either pass0 or pass1?  Then I could
tell SANE to always use /dev/scanner.  I've never fiddled
with /etc/devd.conf, but it seems to be what I need.
I guess I need to read a few more manpages.  :-)

Best regards
   Oliver

-- 
Oliver Fromme,  secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing
Dienstleistungen mit Schwerpunkt FreeBSD: http://www.secnetix.de/bsd
Any opinions expressed in this message may be personal to the author
and may not necessarily reflect the opinions of secnetix in any way.

"To this day, many C programmers believe that 'strong typing'
just means pounding extra hard on the keyboard."
        -- Peter van der Linden