[sane-devel] backend integration
Sun, 1 Sep 2002 21:33:15 +0200
On Sun, Sep 01, 2002 at 03:07:13PM -0400, Matto Marjanovic wrote:
> >* strictly speaking sane_set_io_mode() should return SANE_STATUS_GOOD
> > for non_blocking == SANE_FALSE, at least that's what the standard
> > says. I guess nobody will ever notice...
> A suggestion for a very tiny edit in the API docs:
> 4.3.12 sane_set_io_mode
> This function may fail with one of the following status codes:
> No image acquisition is pending.
> --- The backend does not support this operation.
> +++ The backend does not support the requested I/O mode.
Ok, I have added that to the TODO list. Looks like we can make a minor
change of the standard now. We shouldn't forget to forward-port that
to the 2.0-draft.
> Hmm... and the more I look at this, the less I understand what the
> SANE_STATUS_INVAL case is for. (The microtek backend is blocking-mode
> exclusively, so I've never really dealt with this....) What does
> "image acquistion is pending" mean? Is that before or after sane_start()
> has been called?
sane_set_io_mode must be used after sane_start (and before sane_cancel).
> It seems to me that the backend would want the frontend to call
> sane_set_io_mode() *before* sane_start() --- so that sane_start() can
> decide how to set up any data pipes, threads, etc. And then, after
> sane_start() has been called and the imaging process is under way,
> sane_set_io_mode() should return SANE_STATUS_INVAL, because "you can't
> change your mind after the scan has begun".
Oh, you can :-) What I do in the Mustek backend in sane_set_io_mode is:
if (fcntl (s->pipe, F_SETFL, non_blocking ? O_NONBLOCK : 0) < 0)
So that should work even after sane_read. However, if the backend does
buffering it may be more difficult.
> It certainly doesn't make sense to call sane_set_io_mode() after
I have never tried what happens in that case...
> (Maybe this has been gone-over before; I've been on another planet for the
> last year....)
I don't remember anyone talking about that.