Replying to myself:
[About mustek backend and xsane/xscanimage hang]
> I'm not very good at reading C source, so the following could be quite
> wrong: I looked into the source (mustek.c) and I think the problem is related
> to sane_read and especially sane_read returning SANE_STATUS_GOOD with a len
> of 0. That shouldn't happen in the blocking case (if I understand the SANE
> standard correctly) but it does.
It doesn't. If I disable sane_set_io_mode (only blocking possible) I can
scan without any problems. Only non blocking mode hangs.
I'm not sure if it's the fault of mustek.c or xsane (or mine). The sane
standard says that the filedescriptor that is returned by sane_get_select_fd
should be closed when the next sane_read would get eof. I think mustek.c
does this correctly (the reader_process is closed). For non blocking mode
xsane uses a gdk_input_add watching the file descriptor it got from
sane_get_select_fd for readable data. If there is data it will start
xsane_read_image_data (which does sane_read) until there is no more data.
The next call to sane_read would result in eof so the filedescriptor is
closed. But I couldn't find any code in xsane checking for the closed fd.
--> deadlock. A simple change in xsane did it for me, I just added the
GDK_INPUT_EXCEPTION to gdk_input_add so xsane_read_image_data is called on
error conditions, too (xsane-preview.c and xsane-scan.c):
xsane.input_tag = gdk_input_add(fd, GDK_INPUT_READ|GDK_INPUT_EXCEPTION,
xsane_read_image_data, 0);
Would this be a fix or a new bug? I haven't looked into xscanimage.
I really don't know why it works with kernel 2.0.
Ciao,
Henning
-- 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 19 2000 - 15:27:57 PST