Linux Step By Steps
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:

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


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