On Tue, Oct 22, 2002 at 09:24:51PM +0100, Ryan Harkin wrote:
> Hi Tim,
>
> On Tuesday 22 October 2002 20:49, VOLTZ Stéphane wrote:
> > Tim Waugh wrote:
> > >How about if you set/unset O_NONBLOCK when using ppdev? The change in
> > >2.4.19 was to introduce O_NONBLOCK support.
>
> I have tried that and it seems to (partially) work! I added a call to fcntl,
> but realised I could just add the flag to the "open" call.
>
> From a hardware access point of view, yes, I can access my parallel port now.
> However, this doesn't solve the problem as such, as the code I am using is
> written with blocking calls in mind....
>
> Stef,
>
> I modified backend/umax_low_pp.c so that the "open" command in
> sanei_umax_pp_InitPort:
>
> fd = open (name, O_RDWR | O_NOCTTY);
>
> now reads:
>
> fd = open (name, O_RDWR | O_NOCTTY | O_NONBLOCK);
>
> I have tested using tools/umax_pp -p -t 1 -n /dev/parport0 as root, then as
> user. Then I installed the sane-backends and tested with "scanimage -L" as
> user followed by "scanimage > out.pnm", again as user.
>
> I build the frontends and have just run xscanimage to preview and then scan a
> small section of an image at 600dpi, followed by a larger scan (1976x1959:
> 11MB) at 600dpi.
>
> It all worked fine - all with EPP mode in the BIOS and kernel 2.4.18-14.
>
> However, a really large scan (4976x5904: 84.1MB) failed.
>
Really large scans at >= 600 dpi fail with ppdev. The backend doesn't
read the data fast enough from the scanner. It's a known limitation of the backend.
Such thing doesn't happen in windows since a VxD running in ring 0 take on the
whole CPU. Maybe setting highest priority to the scan process will help, but not
cure it.
> All the way though the scan with xscanimage, I saw this on the terminal
> repeated every few seconds:
>
> [umax_pp_low] Unexpected reg19=0xD0 (umax_pp_low.c:2932)
> [umax_pp_low] Unexpected reg19=0xC0 (umax_pp_low.c:2932)
> [umax_pp_low] Unexpected reg19=0xC0 (umax_pp_low.c:2932)
> [umax_pp_low] Unexpected reg19=0xC0 (umax_pp_low.c:2932)
> [umax_pp_low] Unexpected reg19=0xC0 (umax_pp_low.c:2932)
> [umax_pp_low] Unexpected reg19=0xC0 (umax_pp_low.c:2932)
> [umax_pp_low] SendLength retry success (retry 6 times) ...
> (umax_pp_low.c:3038)
>
The backend is too slow at getting data.
> When it started to fail, it produced the following output:
>
> [umax_pp_low] Time-out (4.00 s) waiting for scanner ... giving up on status
> 0xC8 ! (umax_pp_low.c:5972)
> [umax_pp_low] Unexpected reg19=0xD0 (umax_pp_low.c:2932)
> [umax_pp_low] Unexpected reg19=0xC0 (umax_pp_low.c:2932)
> [umax_pp_low] SendLength failed, expected reg & 0x10=0x10 , found 0x01
> (umax_pp_low.c:2910)
> [umax_pp_low] Retrying ...
> [umax_pp_low] Unexpected reg19=0xC0 (umax_pp_low.c:2932)
> [umax_pp_low] SendLength failed, expected reg & 0x10=0x10 , found 0xEC
> (umax_pp_low.c:2910)
> [umax_pp_low] Retrying ...
> [umax_pp_low] Unexpected reg19=0xC0 (umax_pp_low.c:2932)
> [umax_pp_low] SendLength retry success (retry 6 times) ...
> (umax_pp_low.c:3038)
> [umax_pp_low] Time-out (4.00 s) waiting for scanner ... giving up on status
> 0xC8 ! (umax_pp_low.c:5972)
> [umax_pp_low] CmdGetBlockBuffer(4,0,4308) failed (umax_pp_low.c:7377)
> [umax_pp_low] Unexpected reg19=0xD0 (umax_pp_low.c:2405)
> [umax_pp_low] Unexpected reg19=0xD0 (umax_pp_low.c:2405)
> [umax_pp_low] Unexpected reg19=0xD0 (umax_pp_low.c:2405)
> [umax_pp_low] Unexpected reg19=0xD0 (umax_pp_low.c:2405)
> [umax_pp_low] Unexpected reg19=0xD0 (umax_pp_low.c:2405)
> [umax_pp_low] Unexpected reg19=0xD0 (umax_pp_low.c:2405)
> [umax_pp_low] Unexpected reg19=0xD0 (umax_pp_low.c:2405)
> [umax_pp_low] Unexpected reg19=0xD0 (umax_pp_low.c:2405)
> [umax_pp_low] Unexpected reg19=0xD0 (umax_pp_low.c:2405)
> [umax_pp_low] Unexpected reg19=0xD0 (umax_pp_low.c:2405)
> [umax_pp_low] Unexpected reg19=0xD0 (umax_pp_low.c:2413)
> [umax_pp_low] Unexpected reg19=0xC0 (umax_pp_low.c:2405)
> [umax_pp_low] Unexpected reg19=0xC0 (umax_pp_low.c:2405)
> [umax_pp_low] Unexpected reg19=0xC0 (umax_pp_low.c:2405)
> [umax_pp_low] Unexpected reg19=0xC0 (umax_pp_low.c:2405)
> [umax_pp_low] Unexpected reg19=0xC0 (umax_pp_low.c:2405)
> [umax_pp_low] Unexpected reg19=0xC0 (umax_pp_low.c:2405)
> [umax_pp_low] Unexpected reg19=0xC0 (umax_pp_low.c:2405)
> [umax_pp_low] Unexpected reg19=0xC0 (umax_pp_low.c:2405)
> [umax_pp_low] Unexpected reg19=0xC0 (umax_pp_low.c:2405)
> [umax_pp_low] Unexpected reg19=0xC0 (umax_pp_low.c:2405)
> [umax_pp_low] SendWord failed (reg1C=0x01) (umax_pp_low.c:2395)
> [umax_pp_low] Unexpected reg19=0xC0 (umax_pp_low.c:2932)
> [umax_pp_low] SendLength failed, expected reg & 0x10=0x10 , found 0xEC
> (umax_pp_low.c:2910)
> [umax_pp_low] Retrying ...
> [umax_pp_low] Unexpected reg19=0xC0 (umax_pp_low.c:2932)
> [umax_pp_low] SendLength retry success (retry 3 times) ...
> (umax_pp_low.c:3038)
>
> So where do we go from here? Non Blocking sort of works, but the Umax backend
> to Sane isn't written to use it properly.
>
> Cheers,
> Ryan.
>
It really seems that ppdev with O_NONBLOCK works. I'm going to test it on my
PC, and add it as a workaround in case of success. But I agree it looks like a
parport bug.
Regards,
Stef
-- To unsubscribe, send mail to: linux-parport-request@torque.net --
-- with the single word "unsubscribe" in the body of the message. --
This archive was generated by hypermail 2b29 : Wed Oct 23 2002 - 01:16:08 EDT