# Re: Backtracking in color scanning

Rogier Wolff (R.E.Wolff@BitWizard.nl)
Mon, 1 Sep 1997 13:55:42 +0200 (MET DST)

- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
- Next message: Jonathan A. Buzzard: "Re: umax-backend"
- Previous message: Rogier Wolff: "Re: umax-backend"
- In reply to: Rainer Krienke: "Re: Backtracking in color scanning"
- Next in thread: David Mosberger-Tang: "Re: Backtracking in color scanning"
- Reply: David Mosberger-Tang: "Re: Backtracking in color scanning"

Rainer Krienke wrote:
>
> | From fnevgeny@plasma-gate.weizmann.ac.il Sun Aug 31 23:45:11 1997
> | From: Evgeny Stambulchik <fnevgeny@plasma-gate.weizmann.ac.il>
> | Date: Mon, 1 Sep 1997 00:39:30 +0300 (IDT)
> | To: krienke@informatik.uni-koblenz.de
> | Subject: Re: Backtracking in color scanning
> | MIME-Version: 1.0
> |
> | Rainer krienke <krienke@mailhost.uni-koblenz.de> wrote:
> | >
> | > I use sane0.62 with my mustek 1200spro (connected to an ADAPTEC 2940
> | > scsi adapter).
> |
> | Do you mean Paragon 1200SP Pro? How did you manage to make it work with
> sane??
> |
>
> Oh sorry I was "some letters" wrong. I did'nt mean 1200 Spro but mustek 1200 SP.

> Because of the assumption of Roger (R.E.Wolff@BitWizard.nl ) who
> said the backtracking problem might be due to the kernel buffer that
> has to be copied in user space, I thought that if this is true
> something should change if I reduce the buffer from 127K to half the

I just use a 1Mb buffer for my scanner. However I had to change a few
lines in sg.c ...... Ah. I nowadays have the patch ready. Attached.

Your "kernel data segment" does grow by a megabyte using this
patch.... I'm going to submit a slightly more generic patch one
day......

Using half the size, or even a quarter (32k, default) doesn't help.

We could try to issue the next "read" AS FAST AS POSSIBLE, discarding
the data just read. This probably requires some serious hacking.

> size. I recompiled sane and my kernel but the effect when scanning
> colour images stayed the same. Moreover I think because of the fact
> that other people (running Pentium 200 pro maschines) have the same
> problem this cannot be due to lack of speed.

A pentium PRO is not much faster on memory limited copies than a
pentium. (Both use a 64bit main memory link.)

Roger.

--------------------------------------------------------------------------

--- linux-2.0.28/include/scsi/sg.h Thu May 2 06:48:55 1996
+++ linux-2.0.28.posix6/include/scsi/sg.h Thu Jan 23 00:10:40 1997
@@ -36,6 +36,10 @@
#define SG_MAX_QUEUE 4 /* maximum outstanding request, arbitrary, may be
changed if sufficient DMA buffer room available */
+#if 0
#define SG_BIG_BUFF 32768
+#else
+#define SG_BIG_BUFF 0x100000
+#endif
#endif
--- linux-2.0.28/drivers/scsi/sg.c Sun Sep 1 08:15:33 1996
+++ linux-2.0.28.posix6/drivers/scsi/sg.c Thu Jan 23 00:12:52 1997
@@ -39,7 +39,11 @@
NULL, sg_attach, sg_detach};
#ifdef SG_BIG_BUFF
+#if SG_BIG_BUFF < 0x10000
static char *big_buff = NULL;
+#else
+static char big_buff[SG_BIG_BUFF];
+#endif
static struct wait_queue *big_wait; /* wait for buffer available */
static int big_inuse=0;
#endif
@@ -565,8 +569,10 @@
#endif
#ifdef SG_BIG_BUFF
+#if SG_BIG_BUFF < 0x10000
big_buff= (char *) scsi_init_malloc(SG_BIG_BUFF, GFP_ATOMIC | GFP_DMA);
#endif
+#endif
scsi_generics = (struct scsi_generic *)
scsi_init_malloc((sg_template.dev_noticed + SG_EXTRA_DEVS)
@@ -648,8 +654,10 @@
}
sg_template.dev_max = 0;
#ifdef SG_BIG_BUFF
+#if SG_BIG_BUFF < 0x10000
if(big_buff != NULL)
scsi_init_free(big_buff, SG_BIG_BUFF);
+#endif
#endif
}
#endif /* MODULE */

    --
    Source code, list archive, and docs: http://www.azstarnet.com/~axplinux/sane/
    To unsubscribe: mail -s unsubscribe sane-devel-request@listserv.azstarnet.com

- Next message: Jonathan A. Buzzard: "Re: umax-backend"
- Previous message: Rogier Wolff: "Re: umax-backend"
- In reply to: Rainer Krienke: "Re: Backtracking in color scanning"
- Next in thread: David Mosberger-Tang: "Re: Backtracking in color scanning"
- Reply: David Mosberger-Tang: "Re: Backtracking in color scanning"