|Oliver Fromme||Jan 25, 2006 12:51 am|
|Matthias Andree||Jan 25, 2006 1:15 am|
|Oliver Fromme||Jan 25, 2006 1:59 am|
|Matthias Andree||Jan 25, 2006 2:26 am|
|Oliver Fromme||Jan 25, 2006 6:22 am|
|Matthias Andree||Jan 25, 2006 4:37 pm|
|Stefan Esser||Jan 30, 2006 8:28 am|
|Matthias Andree||Jan 30, 2006 8:38 am|
|Joerg Wunsch||Mar 20, 2006 9:29 pm|
|Subject:||SCSI scanner, sym/ncr driver, pt(4)|
|From:||Oliver Fromme (ol...@lurza.secnetix.de)|
|Date:||Jan 25, 2006 1:59:59 am|
Matthias Andree <matt...@gmx.de> wrote:
Oliver Fromme <ol...@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