Initial import of sane-backends version 1.0.24-1.2

1 files changed, 267 insertions, 0 deletions

diff --git a/doc/teco/teco2.txt b/doc/teco/teco2.txt
new file mode 100644
index 0000000..5b64a83
--- /dev/null
+++ b/doc/teco/teco2.txt
@@ -0,0 +1,267 @@
+
+          BACKEND TECO2
+
+INQUIRY
+
+TECO VM3564 (1)
+000: 06 00 02 02 43 00 00 10 52 45 4c 49 53 59 53 20    ....C...RELISYS 
+016: 41 56 45 43 20 49 49 20 53 33 20 20 20 20 20 20    AVEC II S3      
+032: 31 2e 30 37 31 2e 30 37 00 01 54 45 43 4f 20 56    1.071.07..TECO V
+048: 4d 33 35 36 34 20 00 01 01 2c 00 01 02 58 09 f6    M3564 ...,...X..
+064: 0d af 01 2c 00 08 01 00                            ...,....
+
+TECO VM3564 (2)
+000: 06 00 02 02 43 00 00 10 52 45 4c 49 53 59 53 20    ....C...RELISYS 
+016: 41 56 45 43 20 49 49 20 53 33 20 20 20 20 20 20    AVEC II S3      
+032: 31 2e 30 39 31 2e 30 39 00 01 54 45 43 4f 20 56    1.091.09..TECO V
+048: 4d 33 35 36 34 20 00 01 01 2c 00 01 02 58 09 f6    M3564 ...,...X..
+064: 0d af 01 2c 00 08 01 00                            ...,....
+
+TECO VM356A (1)
+000: 06 00 02 02 43 00 00 00 52 45 4c 49 53 59 53 20    ....C...RELISYS
+016: 41 50 4f 4c 4c 4f 20 45 78 70 72 65 73 73 20 33    APOLLO Express 3
+032: 31 2e 30 33 31 2e 30 33 00 01 54 45 43 4f 20 56    1.031.03..TECO V
+048: 4d 33 35 36 41 20 00 01 01 2c 00 01 02 58 09 f6    M356A ...,...X..
+064: 0d af 01 2c 00 08 01 00                            ...,....
+
+TECO VM356A (2)
+000: 06 00 02 02 43 00 00 10 50 72 69 6d 61 78 20 20    ....C...Primax  
+016: 4a 65 77 65 6c 20 20 20 20 20 20 20 20 20 20 20    Jewel           
+032: 31 2e 30 31 31 2e 30 31 00 01 54 45 43 4f 20 56    1.011.01..TECO V
+048: 4d 33 35 36 41 20 00 01 01 2c 00 01 02 58 09 f6    M356A ...,...X..
+064: 0d af 01 2c 00 08 01 00                            ...,....
+
+TECO VM3575
+000: 06 00 02 02 43 00 00 00 20 20 20 20 20 20 20 20    ....C...        
+016: 46 6c 61 74 62 65 64 20 53 63 61 6e 6e 65 72 20    Flatbed Scanner 
+032: 31 2e 30 33 31 2e 30 33 00 01 54 45 43 4f 20 56    1.031.03..TECO V
+048: 4d 33 35 37 35 20 00 01 01 2c 00 01 02 58 09 f6    M3575 ...,...X..
+064: 0d af 01 2c 00 08 01 00                            ...,....
+
+TECO VM656A
+000: 06 00 02 02 43 00 00 00 52 45 4c 49 53 59 53 20    ....C...RELISYS 
+016: 41 50 4f 4c 4c 4f 20 45 78 70 72 65 73 73 20 36    APOLLO Express 6
+032: 31 2e 30 33 31 2e 30 33 00 01 54 45 43 4f 20 56    1.031.03..TECO V
+048: 4d 36 35 36 41 00 01 01 2c 00 01 02 58 09 f6 0d    M656A...,...X...
+064: af 01 2c 00 08 01 00 00                            ..,.....
+
+TECO VM6575
+000: 06 00 02 02 43 00 00 10 52 45 4c 49 53 59 53 20    ....C...RELISYS
+016: 53 43 4f 52 50 49 4f 20 50 72 6f 20 20 20 20 20    SCORPIO Pro
+032: 31 2e 30 31 31 2e 30 31 00 01 54 45 43 4f 20 56    1.011.01..TECO V
+048: 4d 36 35 37 35 20 00 01 01 2c 00 01 02 58 09 f6    M6575 ...,...X..
+064: 0d af 01 2c 00 08 01 00                            ...,....
+
+TECO VM6586
+000: 06 00 02 02 43 00 00 00 20 20 20 20 20 20 20 20    ....C...        
+016: 46 6c 61 74 62 65 64 20 53 63 61 6e 6e 65 72 20    Flatbed Scanner 
+032: 33 2e 30 31 33 2e 30 31 00 01 54 45 43 4f 20 56    3.013.01..TECO V
+048: 4d 36 35 38 36 20 00 01 01 2c 00 01 02 58 09 f6    M6586 ...,...X..
+064: 0d af 01 2c 00 08 01 00                            ...,....
+
+/*--------------------------------------------------------------------------*/
+
+
+
+SCSI Commands supported by the TECO VM3575:
+
+
+
+REQUEST SENSE
+03 00 00 00 12 00
+
+
+VENDOR-06
+???
+Receives 4 bytes of data
+
+
+VENDOR-9
+Get calibration lines - 12 lines
+  2 = ?
+     0x00 color scan
+     0x01 grayscal scan
+     0x02 b&w scan
+  Returns 6 bytes per pixel, probably 2 bytes per color in little endian order.    (2550 * 6 = 15300)
+
+VENDOR-0C
+??? Unsupported?
+
+
+VENDOR-0E
+Set calibration. Apparently the line is computed from the calibration lines. It is not an average though.
+
+
+INQUIRY
+12 00 00 00 48 00 
+  standard inquiry
+    72 bytes
+    32-39: firmware version
+    42-52: real scanner name
+	54-55: min X resolution
+    56-57: max X resolution
+    58-59: min Y resolution
+    60-61: max Y resolution
+    62-63: scan area length
+    64-65: scan area width
+    66-67: unit for scan area (eg 300th of inch)
+
+    eg if 62-63 = 2550 and 66-67 = 300, the length is 2550/300=8.5 inches.
+
+
+SCAN
+1B 00 00 00 00 00
+
+
+VENDOR-1C
+1c 00 00 00 00 00
+(Same opcode as RECEIVE DIAGNOSTIC RESULTS)
+  sends 4 bytes of data.
+
+
+SET WINDOW
+24 00 00 00 00 00 00 00 35 00 (VM3575)
+24 00 00 00 00 00 00 00 38 00 (VM6586)
+
+Total length is 
+  07 = length 
+       VM3575 53-8 = 45
+	   VM6586 56-8 = 48
+	   VM3552 69-8 = 61
+  10-11 = X Resolution
+  12-13 = Y resolution
+  14-17 = X top left corner
+  18-21 = Y top left corner
+  22-25 = width  (size in inches * 300)
+  26-29 = length (size in inches * 300)
+  31 = 0x80 ?
+  33 = scan mode
+        0x00 = black & white
+        0x02 = grayscale
+		0x05 = color
+  34 = bit depth? - invariant, always 8
+  36 = (vm6586 only ?) halftone pattern ?
+         1 = type 1 dithering
+  37 = 
+     0x80 = RIF?
+  48 = color channel to use
+     if scan mode is 0 or 2:
+       0x00 = red 
+       0x01 = green
+       0x02 = blue
+     if scan mode is 05 -> ignored
+       TWAIN leaves 0x02
+  50 = ?
+
+  VM6585 only:
+    52-53 = size of a line expected?
+    54-55 = number of lines expected?
+
+
+READ
+28 00 00 00 00 19 00 1f 0e 00
+  5 = number of lines to read
+  7-8 = buffer size. 
+       Always number of lines to read * size of a line.
+       0x2000 appears to be the upper limit
+  
+
+SEND
+2A 00 03 00 00 04 00 0C 00 00
+  2 = data type code
+       0x03 = gamma
+  4-5 = data type qualifier (?)
+  6-8 = length (0xc00 = 3276 = 3*2^10)
+  or:
+  5-6: length of each gamma
+  7-8: length of all gamma
+
+
+OBJECT POSITION
+31 00 00 00 00 00 00 00 00 00
+Park the CCD.
+
+
+GET DATA BUFFER STATUS
+34 01 00 00 00 00 00 00 12 00
+
+  1   = bit 1 is wait
+  7-8 = allocation length
+
+  returned buffer is 0x12 bytes long.
+  00 00 0f 00 00 00 00 14 00 00 00 80 1b 6c 09 f6 05 05
+    0-2 = additional length (0x12-3 = 0x0F)
+      7 = ? always 0x14
+     11 = bit 7 - (maybe) scanner is ready to send data
+  12-13 = number of lines (constant during a scan)
+  14-15 = bytes per line (constant during a scan)  
+  16-17 = garbage (the command only returns 0x10 bytes)
+
+
+/*--------------------------------------------------------------------------*/
+
+Scan sequence
+
+Get some info:
+  INQUIRY
+
+Setup the scan:
+  REQUEST SENSE
+  TUR
+  SET WINDOWS
+  GET BUFFER STATUS
+  VENDOR-0C
+  VENDOR-09 (read calibration)
+  VENDOR-0E (send new calibration)
+  REQUEST SENSE
+  SEND(10)
+  SET WINDOWS (same as the first one)
+  COMMAND 06
+  RECEIVE DIAGNOSTIC RESULTS
+  SCAN
+  GET BUFFER STATUS
+
+loop until all data read:
+  READ(10)
+
+park the CCD:
+  OBJECT POSITION
+
+/*--------------------------------------------------------------------------*/
+
+calibration
+
+TECO VM3575 reads 12 lines of calibration
+TECO VM656A reads 8 lines of calibration
+TECO VM6586 ??
+
+Algorithms used (text from Alex Wulms):
+The old algorithm was based on the assumption that the calibration value needs 
+to be an offset, to go from the value obtained during input to the average 
+value (0x800).
+
+E.g., if the input value is 0x800, the calibration value must be 0x800 (0x1000 
+- 0x800).
+Likewise, if the input value is 0x700, the calibration value must be 0x900 
+(0x1000 - 0x700)
+And if the input value is 0x600, the calibration value must be 0xA00
+
+The new algorithm is based on the assumption that the calibration needs to be 
+a multiplication factor, to compensate for the too strong or too weak pixel 
+in the sensor. Again, we want to obtain the average value (approximately 
+0x800) for every pixel read during calibration.
+
+E.g., if the input value is 0x800, the calibration value must be 0x800 
+(0x800*0x800 / 0x800).
+Likewise, if the input value is 0x700, the calibration value must be 0x924 
+(0x800*0x800 / 0x700).
+And if the input value is 0x600, the calibration value must 0xAAA (0x800*0x800 
+/ 0x600)
+
+Though, carefull comparison with scans done under windows has shown that the 
+factor is slightly different from 0x800*0x800(=0x400000) but in stead it 
+seems to be approximately 0x40302f (which would mean that the average value 
+is approximately 0x803 in stead of 0x800).
+
+Hope this is clarifies the new algorithm.
+