==============================================================================
A4 Tech AC 4096 handheld scanner driver  version 0.1
==============================================================================

This is a driver for the A4 Tech AC 4096 (A4 Color) scanner driven thru its
own interface board.


How to install:
------------------------------------------------------------------------------

	0) If you have a machine with more than 16M of memory,
	   please DON'T USE this version (or restrict your kernel
	   to 16M). Wait for the next release or mail me if you want
	   get a test version (I cannot test this, I have only 8M).

	1) The driver is a kernel loadable module, so obviously the first 
           step in getting this thing to work is to obtain and install 
           the `modutils' package if you don't have it already.
	
	2) Now go to the src directory and have a look at the top of ac4096.h.
	   Edit the defines to reflect your needs/hardware settings.
	   Please note, that only IOBASE must reflect your jumper
           settings, DMA will be software-selected.
	   Please use a DMA-channel not used by any other hardware.
	   (DMA 1 is likely to be used, if you have a SoundBlaster installed
	    ...)
	   However, if you use DMA 1 you can either use your scanner
	   or the SoundBlaster at a given moment.
	   Available DMAs are 1 or 3, IOBASEs are 256, 296 (default), 316
	   and 356.

	3) Move scanner.h to some decent place - I suggest usr/local/include
	   Please make sure, that scanner.h is present in ONLY ONE VERSION
	   on your system. I've heard of lots of trouble when the driver was
	   compiled with another scanner.h than the scan-software.

	   Type `make' to compile the driver.
           Type `insmod ac4096.o'.

           If the loader complains about missing symbols, add them to
	   kernel/ksyms.c.
	   The loader will probably complain about the following symbols:
	   request_dma
	   free_dma
	   You will have to #include <asm/dma.h> at the beginning and add
	   the missing symbols to the symbol_table[] using the X-macro
	   (look at the file and you will see what I mean ...).
	   
	   If kernel/ksyms.c had to be modified, you have to recompile your 
	   kernel and reboot to reflect the changes.
	   (For 1.0.x kernels, you need to modify kernel/ksyms.S).

	4) create the device special file:
	   type `mknod -m 444 /dev/ac4096 c 26 0'

	   and a symlink
	   `ln -sf ac4096 /dev/scan'

	   Note: the `26' above is the major device number.
	   	 If that one is already used on your machine
		 (the driver complains "cannot register major number" when
		 attempting to load it)
		 pick another free one and change the definition
		 of AC4096_SCANNER_MAJOR in `ac4096.h' accordingly.

	5) Copy `ac4096.o' to wherever you keep your kernel modules.

	6) try it out:

		If you have a working (s)vgalib,
		build gifscan in ./demo . If you have no svgalib, you
		lost, as the script scan.sh is no longer included with
		this package. You will have to be content with something
		like cat </dev/scan >file, until you find a nice guy who
		writes a little scanning program for you (or you'll have
		to remove all the vga stuff from gifscan to be able to
		"blind-scan" into a GIF-file).


Some notes for programmers:
------------------------------------------------------------------------------

The driver uses DMA transfers to communicate with the scanner.
The DMA channel is settable thru software (see ac4096.h for details). Since
the scanner doesn't issue an interrupt every scanline, a timer checks every
1/50 sec if the transfer is ready.
The driver keeps an internal (dynamically allocated) buffer. The size of this
buffer defaults to 25 scanlines (see ac4096.h) but is adjustable thru an ioctl
call (see below). Note that data transfers from the scanner stay enabled until
the buffer is full, no matter whether the process using /dev/scan is currently
running or not. That means that no data gets dropped, as long as there's some
buffer space, even if your process is stopped or currently swapped out.

The driver allows you to read an arbitrary number of bytes within a single 
read(2) call, but note that the internal buffer doesn't benefit you anything
anymore if you request more bytes than fit into the buffer with a single
read(2). Normally you would read one scanline at a time when scanning in
b/w mode and maybe some few scanlines when in halftone mode. If the read(2)
call is interrupted by a signal, read(2) returns the number of bytes read
so far. I know that this differs from the `standard' behaviour of returning
-EINTR, but with a scanner it makes more sense this way (you would lose some
data already in the internal buffer otherwise). If you select(2) on the
scanner device, the device is recognized as `ready' if at least one scanline
is available in the buffer, but this can be changed also (see below).

For the supported ioctl functions please read README.ioctl - but be careful
the ioctl-interface is still under development and therefore likely to
change.


Some notes on bug-reports:
------------------------------------------------------------------------------

If you experience a bug, please let me know. Your bug report should include
a recipe on how to reproduce it, or at least an exact description of the
circumstances that led to it. If the bug results in a message like

	general protection: xxxx
	EIP:    0010:xxxxxxxx
	EFLAGS: xxxxxxxx
	eax: xxxxxxxx   ebx: xxxxxxxx   ecx: xxxxxxxx   edx: xxxxxxxx
	esi: xxxxxxxx   edi: xxxxxxxx   ebp: xxxxxxxx
	ds: xxxx  es: xxxx  fs: xxxx  gs: xxxx
	Pid: xx, process nr: xx
	xx xx xx xx xx xx xx xx xx xx

on your screen and/or in your system log, please duplicate it exactly,
and see,if it is in the range of the scanner-driver by comparing it to the
location where it is loaded.This is shown when doing insmod :

module `ac4096' (2 pages @ 0x0080c000) created
			   ^^^^^^^^^^ that's what I need ...

If it is NOT in that range (somewhere else in the kernel),please look up the 
EIP value (without the leading `0010:') in your zSystem.map and include the 
relevant part of your zSystem.map.
If it is,please create a map of the driver using the command 
'nm -n ac4096.o >ac4096.map' and include this in your report.
Please note that your bug report is worthless to me if either one of these 
two pieces of information is missing.


Bye

--
Michael Beck		beck@informatik.hu-berlin.de
Germany

**************************************************************************
Many thanks go to
Andreas Beck		becka@hp.rz.uni-duesseldorf.de
who wrote the Logitech driver and design the ioctl-interface

and

Thomas Faehnle		Thomas.Faehnle@student.uni-ulm.de
who wrote the M105-scanner-driver on which this one is heavily based.
**************************************************************************
