On Tuesday 09 May 2006 19:44, Henning Meier-Geinitz wrote:
> [...]
> Why not just kill the reader process in sane_cancel? Do you think the
> way this is done in the existing backends (e.g. mustek) is wrong?
I've implemented a reader process like mustek.c in my backend. Everything
seems to work an
Hi,
On Tuesday 09 May 2006 19:44, Henning Meier-Geinitz wrote:
>[...]
> Why not just kill the reader process in sane_cancel? Do you think the
> way this is done in the existing backends (e.g. mustek) is wrong?
No, not at all. I was a little bit confused because I've designed my driver
before I r
Hi,
On 2006-04-25 15:07, Wittawat Yamwong wrote:
> Should/must/may a frontend call sane_read after sane_cancel?
I think it may but it doesn't need to.
I can't find an explicit statement in the standard that it's forbidden
to do so. In fact, there is even a status code for sane_read for this
case.
Hi Wittawat,
On Tuesday 25 April 2006 14:07, Wittawat Yamwong wrote:
> Should/must/may a frontend call sane_read after sane_cancel?
> [...]
> This is important to my backend (pixma). It would be much more complex if
> frontends are not required to call sane_read after sane_cancel [...]
I don't k
Hi!
Should/must/may a frontend call sane_read after sane_cancel?
Case I: sane_cancel was called in a signal handler or in other thread. The
reader thread still keeps calling sane_read until it returns an error or EOF.
That's clear for me.
Case II: The frontend has read a block of image data fr
