>We *could* put it back into compatibility mode only in lp_release(), I
>suppose, but wouldn't that imply we would have to claim parport in
>lp_open() and keep it claimed until lp_release()?
Yeah. (I thought this was how it worked already, but of course I was wrong.)
Keeping the port claimed all the time the lp device is open seems reasonable
enough on the face of it. Of course, then you get into potential deadlocks
when you are doing things like printing from a paride disk, so lp would
probably need to gain preempt/wakeup handlers.
Something also needs to be done about the parport_yield_blocking call in the
middle of lp_write, since that can cause another driver to get in and fiddle
with the port.
>Can more that one process at a time have lp[x] open?
Don't think so.
>In this case the protocol times out and the host is
>supposed to be smart enough to realize that it needs to resend the
>byte at some point. Wouldn't parport_write() just fail (not write all
>the bytes) in that case? Then, since lp_wait_ready() is essentially a
>null operation for ECP mode, we would just keep retrying the write.
Right. So, I guess lp_write needs to be augmented so that it drops back to
compatibility mode if parport_write returns failure. Then lp_wait_ready()
will be able to check the real status and tell the user to go put more paper
in, or whatever. Once the printer goes ready again the next call to
parport_write will negotiate back to ECP mode and on you go.
p.
-- 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 : Thu Aug 16 2001 - 15:06:44 EDT