# Re: Correct Network Scanner Syntax? (a question)

From: abel deuring (a.deuring@satzbau-gmbh.de)
Date: Sat May 27 2000 - 12:00:37 PDT

- Next message: Timothy Reaves: "Re: Xsane & no devices"
  - Previous message: Steve Sheriff: "Re: Xsane & no devices"
  - In reply to: John Fremlin: "Re: Correct Network Scanner Syntax? (a question)"
  - Next in thread: John Fremlin: "Re: Correct Network Scanner Syntax? (a question)"
  - Next in thread: Petter Reinholdtsen: "Re: Correct Network Scanner Syntax?"
  - Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

  John Fremlin wrote:

  > Hmm. I don't know if Oliver added anything to my version, but here is
  > what I sent him (relative to sane-cvs). The patch to
  > sanei/sanei_scsi.c should not be necessary if sane is setup properly,
  > and is probably incorrect wrt other sane backends.
  >
  > Index: sanei/sanei_scsi.c
  > ===================================================================
  > RCS file: /cvsroot/external/sane/sanei/sanei_scsi.c,v
  > retrieving revision 1.2
  > diff -u -r1.2 sanei_scsi.c
  > --- sanei_scsi.c 2000/03/05 13:57:15 1.2
  > +++ sanei_scsi.c 2000/05/19 17:25:19
  > @@ -1302,13 +1302,15 @@
  > /* make sure that we got as much memory as we wanted, otherwise
  > the backend might be confused
  > */
  > - if (real_buffersize != wanted_buffersize)
  > + /*
  > + if (real_buffersize != wanted_buffersize)
  > {
  > DBG(1, "sanei_scsi_open: could not allocate SG buffer memory "
  > "wanted: %i got: %i\n", wanted_buffersize, real_buffersize);
  > sanei_scsi_close(*fdp);
  > return SANE_STATUS_NO_MEM;
  > }
  > + */

  If this patch to sanei_scsi.c works for your setup (Microtek USB
  scanner, if my memory is right), it's fine. But it might break the
  memory management for other backends which use the function
  sanei_scsi_open. Most backends open the device file for scanner access
  more than once, and with newer versions of the Linux SG driver there is
  no guaraantee that the driver is able to allocate as much memory as
  requested. A backend may allocate some buffers based on the value of
  sanei_scsi_max_request_size during initialisation (function attach, for
  example). If the value of sanei_scsi_max_request_size increases during
  another call to sanei_scsi_open, the backend might write beyond the end
  of those buffers.

  Therefore, it would be better to work with the environment variable
  SANE_SG_BUFFERSIZE, or to use the configure-option
  --enable-scsibuffersize.

  But even this will cause conflicts, if somebody tries to use Sane "out
  of the box" from one of the big Linux distributions. Either
  --enable-scsibuffersize is set to a small value like 32k, so that the
  microtek USB scanners work. In this case people would get a serious
  performance degradation for some scanners without setting
  SANE_SG_BUFFERSIZE. Or the default buffer size is useful for most
  scanners. Then, users of a USB scanner _must_ set the enviroment
  variable. Some of them will forget to do so, I'm afraid.

  To remove this conflict, I suggest to use sanei_scsi_open_extended
  instead of sanei_scsi_open in those backends which support USB scanners.
  Practically, this means to get rid of sanei_scsi_max_request_size, and
  to check all buffer sizes after each call to sanei_scsi_open_extended,
  or to allocate all buffers after this call. The Umax, Mustek and Sharp
  backends show how this can be done.

  Abel

      --
      Source code, list archive, and docs: http://www.mostang.com/sane/
      To unsubscribe: echo unsubscribe sane-devel | mail majordomo@mostang.com

  - Next message: Timothy Reaves: "Re: Xsane & no devices"
  - Previous message: Steve Sheriff: "Re: Xsane & no devices"
  - In reply to: John Fremlin: "Re: Correct Network Scanner Syntax? (a question)"
  - Next in thread: John Fremlin: "Re: Correct Network Scanner Syntax? (a question)"
  - Next in thread: Petter Reinholdtsen: "Re: Correct Network Scanner Syntax?"
  - Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

  This archive was generated by hypermail 2b29 : Sat May 27 2000 - 11:59:36 PDT