plustek@linuxhacker.org

Gerhard Jaeger wrote:

<snip>
> The problem with these devices is their hardware limitation and so the
> driver always has to keep track on the steps of the motor. IF you have a
> multitasking OS, this is not guaranteed and so you might loose some data.
> But I agree, if the scan speed can be slowed down, it migh be possible to
> keep track...


Hi again.
I did some more investigation, and here are my findings:

I put in a second parallel port (cheap PCI noname lpt card) in this 
computer, and hooked up the scanner to that port and then insmodded the
pt_drv driver with the parameter port=0xd400 (cat /proc/ioports showed 
d400-d402 : parport1). The driver loaded ok, and the correct scanner was 
identified.

Then I tried to scan, and believe it or not, the scanner works with this 
parallel port! I scanned a full A4 page in color and 300 dpi at the same 
time as I readed news with knode, and there was not a single error in the 
whole picture. Ok I _had_ to close xmms :) (was playing an ~160 kbps .ogg 
file), before scanning, but that is acceptable, at least the scanner is 
fully useable now.

So, what changed?
I had no printer hooked up to the scanner either before or after.
Nothing else of any relevance to the scan process have changed.
The only thing is the new lpt port.
The parallel port on my motherboard is working ok with my laser printer, 
and it is set to EPP in the BIOS. (It was also working ok with the scanner 
when I tried to scan in Win95.)

One interesting thing is that it takes 2x longer to scan with the new 
parallel port. I measured the scan time (this time with a clock :)), and 
the CD cover scanned with 300 dpi and color takes ~59 seconds to scan with 
the new lpt card and ~28 seconds with the parallel port on the motherboard.

Why? :)

It looks like the motor is running in 2x speed when hooked up to the MB 
paralled port...(?)


Anyway, I thought that this may be of interest.


Tomas