[sane-devel] Re: strange problems LIDE30

[Chris McKeever]

On Wed, 6 Oct 2004 23:19:27 +0200, Henning Meier-Geinitz
<henning@meier-geinitz.de> wrote:
> Hi,
> 
> On Wed, Oct 06, 2004 at 05:07:46PM -0400, Brian K. White wrote:
> > The manufacturer says that it does 1200x2400 optically, but xsane only
> > offers a listbox that says a single value from 0 to 2400, no XXXxYYY
> > choices, so I picked 2400 just to go for a worst case scenario but I have
> > no idea what it's actually going to do.
> > A lie, only actualy produce 1200x1200? a distorted image? silently double
> > every pixel in one direction? silently double every pixel in both
> > directions? or maybe the scanner will do the doubling in one direction in
> > firmware and present sane with 2400x2400 data?
> 
> As it doesn't make sense to crete distorted images SANE backends
> usually either duplicate pixels or interpolate them.
> 
> I've seen several Windows drivers that interpolate even if it's not
> necessary: E.g. harware resolution 100 and 200 dpi, driver uses 100
> dpi when asked for 200.
> 
> Also some scanners are advertized to make 600x1200 dpi but can't do
> (and don't do) 1200 dpi even vertically. It looks like nobody ever
> checked what the Windows driver really scans.
> 
> I don't know what's the case with the LiDEs, however.
> 
> > It's only at about 10 or 15% progress after 20 minutes so I'll send another
> > post when it's done, or when it crashes.
> 


Thanks for the input thus far - I have some new results/information


I did some remote scanning tests with the scanner hooked up to a
mandrake10 box (2.6.xx kernel).  The delay in starting to scan was not
as intrusive as it is on the RH7.3 box (2.4.18 kernel).

In fact - it was able to scan at 1200 DPI, whereas when using the
RH7.3 box it just would timeout

I upped the memory in the RH box - and still the same result.  SO now
there are three main differences with the MDK and RH box - the kernel
and the CPU:

1 - the RH box has 1.0.14 and the MDK box 1.0.13
2 - the kernel - 2.4 uses scanner.o and 2.6 uses libusb
3 - the RH box is a 500Mhz and the MDK box is an 800

would any of these be a direct reason for the delay in starting the
scan?  I understand that there are 3 variables - but if libusb is the
main key - that would be good to know


I am going to try to revert to 1.0.13 and see what happens
I can then try rolling out a more CPU equivalent box

so the real variable is the LIBUSB - does anyone know if that is a
module in 2.4.xx?

thanks





> At least with the scanners supported by the gt68xx backend, a low scan
> width is important for higher speed at high resolutions. As you
> usually use high resolutions for smaller sections of photos or slides
> that's not that unreasonable.
> 
> > This box has a gig of ram so hopefully it's enough for this worst-case
> > scenario if sane doesn't open a file and work with smaller chunks in ram.
> > This is a dual 1gig p3 too. That might be relevant by making it more likely
> > that there is always a cpu available to service the usb interrups? Or
> > rather, that the one cpu that seems to be the only one that even sees
> > interrupts, is more likely to be able to keep up.
> 
> One of the problems is that libusb doesn't allow async i/o. So you
> can't send some buffers to be filled and wait for their completion.
> 
> Bye,
>   Henning
> 
> 
> 
> --
> sane-devel mailing list: sane-devel@lists.alioth.debian.org
> http://lists.alioth.debian.org/mailman/listinfo/sane-devel
> Unsubscribe: Send mail with subject "unsubscribe your_password"
>              to sane-devel-request@lists.alioth.debian.org
>