SCANNERS.
These notes apply to kernel 2.4.x series, Sane Version 1.03,
and were written Mid year 2001. All other bets are
off.
Sane is a scanning application backed by awful
documentation. If you're not prepared to read the following
blurb, give up now, and reboot windows. Without some background
you are garanteed failure and frustration.
Putting it all together. Orientation 101:
*The* buzzword for scanner anything in Linux is SANE. Scanner Access Not Easy.
Roughly speaking, Sane is the equivalent of TWAIN in the Windoze world. Sane 'connects' to
similar items, such as cameras, such as scanners. Sane is
not Linux-centric, it works on
NextStep, Sun. BSD, and of course, OS/2. Therefore, the
documentation can be misleading.
Unlike Twain, where the 'display' is tightly coupled to the
scan-driver, SANE distinguishes three separate
responsibilities.
Guis are whatever application is requesting
scanned items. The most popular of which would be the
Gimp. Or, any other image
manipulation program that gives you a thrill (Xsane ).
It is the responsibility of 'the
gui' to be 'sane aware'. To that end, Sane 'Frontends' are, or can be, a "plugin" to the Gimp.
Guis as such, are not part of the Sane package, the other two
are.
Frontends in Sane are the
front door to all scanning devices that Sane supports. Other
applications, including humans, access the frontend, not the
driver itself.
The most used Frontend is
scanimage, and it's gui equivalent,
xscanimage.
scanimage is invoked from the command line. Bare in
mind, that in Unix, the pipes into and out of a 'command line'
mean this program is normally invoked by a higher level
application that simply recieves the output.
scanimage pumps out tiff or pnm image data. The man page for
scanimage explains this well enough.
What is not explained, is how the hell scanimage (or
any other frontend) gets it's data.
Sane is a work in progress. ALL of the documentation
relating to it's configuration is WRONG. Including (no
surprise) the latest and greatest tarball. Typical of command
line class applications, the programmers have not kept
up with their documentation.
In short, the configuration files are in a mess, and never
work as advertised. Whatever you read in man pages is mostly
and very, WRONG.
scanimage looks in /etc/sane.d/dll.conf
The contents of dll.conf is as follows (highly
paraphrased by me)
epson # a parallel scanner
hp # a scsi scanner
dc25 # a kodak digital
.........
snapscan # a usb flatbed
v4l # a webcam
These
entries point to specific config files for specific Backends. It is,
or should be, a complete list of all supported drivers
in the sane package. The corresponding configuration file is
also in the /etc/sane.d/ folder, the driver for that
scanner, or more correctly, that scanner oem, is in
/usr/lib/sane/ , and, the man page for that driver
is man sane-driver
We thus have the following topology
dll.conf -> epson.conf
->
->
/usr/lib/sane/libsane- epson.so.1 ->
libsane-epson.so.1.0.3
-> man
sane-epson
Note that so.1 is a symlink to the current sane
revision level.
From lack of other informatiion on the command line, scanimage
will iterate though dll.conf until it finds a response.
Thus:
scanimage -T
will test the first found image device.
To test a specific image device such as a usb webcam
scanimage -T -d
v4l:/dev/video
I have emphasised the device name to indicate the colon
syntax
Backends are drivers
for specific scanners.
Things to note:
- There is NO
standard for scanning devices. There is NO standard
protocol.
- Oem's jealously
guard information about their scanners. They are garanteed to
be different to any other Oem, and they are mostly
garanteed to be different and incompatible with succeeding
models.
- Some, very few,
(hp in particlar) publish documented protocol and standards,
most don't.
- This leaves the
Linux community resorting to reverse engineering the majority
of scan devices.
Therefore, the list of 'supported' scanners in Linux is
quite small. Fortunately, a great many scanners all come
from the same factory, with a diferent badge. The trick
is to discover what YOUR scanner actually is, under the covers,
and with USB at least, you can find out, quickly (details
later) .
The xxxx.conf files
The conf file as such is simply passed to the relevant driver.
How it interprets the information is solely dependent on what
the programmer of _that_ driver ate for breakast on
friday. You are advised to read the man page.
However the following verbs tends
to be a rule of thumb.
/dev/somewhere
tells the driver which device to use (but not it's type or
interface) simple where it is in the scheme of things for
purposes of addressing, and is, naturally, a mandatory
entry.
You really do need to take notice of the usb mknod /dev
entries detailed later.
scsi MUSTEK
the driver will look on the scsi interface specifically for a
device that identifies itself as MUSTEK.
pio nnn
will tell the driver to look on a specific parallel port
(epson driver eg)
serial /dev/somewhere
tells the driver to look at serial devices
usb /dev/somehwere
will tell the driver to look on the usb interface.
These verbs have no meaning to single interface dirvers. Eg
defining usb for a scsi only driver (of which, the majority of
drivers are scsi only) is meaningless. Furthermore, the
entries
usb /dev/somewhere
and
usb AGFA
/dev/somewhere
have entirely different meanings, depending on the driver
employed. It's a mess, get used to it, read the man page, and
cat the dirver.conf file to see WHAT to enable for YOUR
driver.
A list of (currently) supported usb scanners can be found here
You can
expect this list to grow quickly.
The reason is that 'popular' scsi scanner drivers already
exist in Sane (Mustek eg). In general, the same scsi command
set has been used by that Oem, superimposed on a USB interface
and the same model sold with an xxxU designator. It only takes
time, for the standard usb mechanism (yes, there is one), to be
patched into each existing scsi-driver. The current state of
play is, however, that these patches are destructive. Once
patched, the driver will not work on scsi. This is
changing.
Two examples of scanner devices are illustrated here
- a
webcam
- a flatbed
scanner
ONE:
The first thing to understand about usb is that, just like
PCI, every usb device has a vendor AND a
product id. (This singular fact will become
exceptionally important in your desperate attempts to get YOUR,
not Sane's, scanner working).
Unlike PCI, the core usb driver makes a very good job of
identifying what type of animal it is dealing with and
automatically loading the appropriate transport driver
for that device. This is very different to the bad old days of
configuring rc.local and /etc/modules.conf. The usb interface
already knows what to do.
TWO:
The second thing to understand about usb, and indeed, any
driver, is that it will attach itself, or become responsible
for a hard-wired file-node.
What this technobable means is the the /dev file system *must*
contain an entry pointing to THE file node
Thus, for video devices
/dev/video0 points to char major 81-0
/dev/usb/scanner0 points to char major 108-48
If these entries don't exist in your /dev folder, do something
about it by reading man mknod.
Whether you choose to symlink
/dev/video-> /dev/video0
and
/dev/scanner-> /dev/usb/scanner0
or
/dev/elephants -> /dev/usb/scanner0
is entirely up to you. The nodes *must* exist, and the
corresponding /dev/name *must* be specififed in
/etc/sane.d/driver.conf
THREE:
The usb file system has important proc entries. The one of
specific interest to you is
cat /proc/bus/usb/devices
This lists the truth. Whatever's "out there" is "in here"
here's the snippet you need
P: Vendor=04a5 ProdID=2060 Rev= 1.00
S: Manufacturer=Acer
S: Product=Prisma 640U
It so happens that the scanner on my desk is from a very large
Australian distributor, Diamond Data Model 638X. It is a badge
engineered clone from Mitsubishi Electric. Who, it so happens
simply licenced the technology from ? Artec
So, no matter how many pages I surf through the net, nor
newsgroups I look at, NOTHING but nothing will tell me faster
what I really have under the covers. Mopral of the story, don't
despair that your scanner isn't "listed", check with cat
/proc......
USB WEBCAM
I have a Puretek PT6007 webcam. Plugging it in causes
ov511 (the device specific driver) and videodev
(the transport driver) to load.
From there, I can use xawtv or a host of other webcam,
kde / gnome based visuals.
However, typing
scanimage -d v4l:/dev/video >output.pnm
creates a snapshot of what the camera sees.
It is as simple as that.
There are some underlying pointers to help you set up your own
'device'.
v4l.conf must exist. It's contents are NOT used in the above
command line, but it must exist (that's how alpha, Sane devel
is)
/dev/video must (of course) exist.
video for linux (V4L) must be compiled in your kernel (most
are)
What's important here is that the responsibility of a device
driver has been removed from Sane and passed to the usb
interface. If a driver exists for usb, sane works.
USB
FLATBED Diamond Data
Armed with the above information from
cat /proc/bus/usb/devices
I was in a position to hunt for an ACER driver
If this isn't enough information, the
bestest of best sources is
/usr/src/linux/drivers/usb/scanner.h
It contains the definitive list of all usb scanners currently
known to man and beast.
Sure enough,
snapscan turned out to be the animal, and I found that
out by clicking here
scanimage -d snapscan:/dev/usb/scanner0
>output.pnm
Should (and would have) produced the desired results.
Unfortunately, these scanners require initialising prior to
first use after a power on.
the data required is from the windows cd driver for that
scanner (u96v112.bin) and the program to load it
(written in perl) is generic for acer and agfa scanners
requiring this initialisation.
I have subsequently entererd
acerfirm /dev/usb/usbscanner0 <u96v112.bin
in /etc/rc.d/rc.local
so that it is done on any reboot.
You can obtain the source, the bin file and the write up here
