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"

    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
    



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