On Mon, 2002-10-28 at 13:04, Jon Wikne wrote:
> In terms of source code, I can not. If I could, I would probably
> have suggested a fix and posted a patch.
In the discussion during your absence, the conclusion was:
a) The "funky result: -75" messages are causes when the *application*
issues read
On Sat, 2002-10-12 at 01:09, Stephan Feder wrote:
> Asking for more
> than one scanline (= one logical transfer) in one call to read_scanner
> _must_ fail (as you found out). So simply fix your application and
> everything should work fine.
I shall notify the author of the app.
It still seems th
Pieter Nagel wrote:
>
> On Sat, 2002-10-05 at 09:26, Stephan Feder wrote:
>
> > The scanner module does blocking IO. You cannot change it to any kind of
> > nonblocking IO without breaking applications.
>
> The intent of the patch was not to do nonblocking IO. The issue is that,
> as man read(2)
Pieter Nagel wrote:
>
> Here is the syslog of what happens (produced with scanner.c compiled
> with DEBUG on):
>
> Oct 1 01:31:35 basilisk kernel: scanner.c: read stats(0): result:0 this_read:32768
>partial:22960 count:45920
> Oct 1 01:31:35 basilisk kernel: usb-uhci.c: interrupt, status 3, fr
Here is the syslog of what happens (produced with scanner.c compiled
with DEBUG on):
Oct 1 01:31:35 basilisk kernel: scanner.c: read stats(0): result:0 this_read:32768
partial:22960 count:45920
Oct 1 01:31:35 basilisk kernel: usb-uhci.c: interrupt, status 3, frame# 1749
Oct 1 01:31:35 basilis
On Sat, 2002-10-05 at 09:26, Stephan Feder wrote:
> The scanner module does blocking IO. You cannot change it to any kind of
> nonblocking IO without breaking applications.
The intent of the patch was not to do nonblocking IO. The issue is that,
as man read(2) says, a read from a filedescriptor
