Re: SANE standard / get_select_fd / sane_read

From: Oliver Rauch (oliver.rauch@Wolfsburg.DE)
Date: Wed Jan 10 2001 - 09:16:39 PST

  • Next message: Ralf: "MICROTEK2 failure : out of memory with kernel 2.4"

    Hi Christian,

    Christian Nassau wrote:
    >
    > To be more concrete: I wonder if we could make the following
    > setup legal:
    >
    > - the file descriptor handed over by the backend signals
    > readable if raw data from the scanner is available to
    > the backend, but
    >
    > - the backend does some postprocessing and would rather
    > keep some of the data until more data is available
    >
    > (take chroma correction, for example, where the backend
    > doesn't want to send some lines at the beginning
    > which have incomplete color components. The initial
    > call to sane_read() might just put some lines into an
    > internal buffer, which will be (partially) transferred
    > when sane_read() is called the next time)

    sane_read is a command that shall read image data from a buffer.
    sane_read should not be used to get the image data from the scanner,
    the backend should start a second process (reader_process) for
    reading the image data from the scanner and put it into a buffer.

    Then you also can do postprocessing with the image data without
    that sane_read will see it.

    >
    > Basically, this is a question about the specification of
    > sane_read(). There seem to be two competing ideas of what a
    > successful call to sane_read() is:
    >
    > - The last line on page 29, allows sane_read() to transfer
    > 0 bytes but still return SANE_STATUS_GOOD
    Yes, this is allowed in non blocking mode.

    >
    > - On page 30 (blocking I/O mode) sane_read() has to transfer
    > at least one byte if it wants to return SANE_STATUS_GOOD
    >
    > Wouldn't it be better to allow a backend to transfer 0 bytes,
    > as long as it considers this a success for some internal reasons?

    Blocking mode means that sane_read has to wait until there is at
    least one byte of image data!

    >
    > Actually, I've got another question about sane_read():
    >
    > It might be convenient for a backend to internally store only
    > complete lines of image data (not fractions of a line). So:

    No. That is not allowed. The fronend may ask for any number
    of bytes.

    >
    > - Does it have to be legal (for the frontend) to request
    > less than bytes_per_line bytes?

    Yes.

    scanimage -T does test exactly that. The frontend may ask for any number
    of bytes it likes to do.

    >
    > This could easily lead to a deadlock if the backend transfers
    > 0 bytes successfully in such a case. (Which it may do in
    > non-blocking mode.)

    Wrong.
    Non Blocking mode means that the backend may return with 0 bytes
    transfered (because it has no data in the moment and it returns
    to give the frontend the chance to react to user action, refresh display
    etc.)

    -- 
    Homepage:	http://www.wolfsburg.de/~rauch
    sane-umax:	http://www.wolfsburg.de/~rauch/sane/sane-umax.html
    xsane:		http://www.wolfsburg.de/~rauch/sane/sane-xsane.html
    E-Mail:		mailto:Oliver.Rauch@Wolfsburg.DE
    

    -- 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 : Wed Jan 10 2001 - 08:57:28 PST