On Thu, 16 Aug 2001 18:24:48 +0100, Philip Blundell <philb@gnu.org> wrote:
>
> >Second problem: the original patch leaves the parallel port in ECP
> >mode permanently. My experience with working on printers of various
> >sorts is that this is in general a Bad Thing; the 1284 protocol is
> >easily broken if either side gets out of sync with the other, and the
> >longer the port is left in ECP mode the easier it is for this to
> >happen. Also, if other drivers want to use the port in other modes
> >(or in other ways) this could cause problems.
>
> I guess maybe switching back to compatibility mode on close might
> be the right thing to do. Flipping into and out of ECP mode on
> every write seems like a bit too much of an overhead. Other
> drivers wanting to change the mode of the port shouldn't cause a
> problem, I don't think: they can negotiate to whatever mode they
> want, and parport_write will reselect its favourite next time it's
> called.
>
I think I agree with Tim on this one. As long as the lp driver has
parport claimed it can put the parallel port into whatever mode it
wants, but it should leave it in a known state when it's not using the
port.
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()? This would
effectively lock any other drivers out from using parport; is this a
Bad Thing? Are there any paths which could leave parport claimed by
lp permanently? Can more that one process at a time have lp[x] open?
BTW, as far as I can tell Windows printer drivers effectively do this;
they claim the parallel port for the duration of the data transfer and
so are able to be somewhat more efficient in how and when they
negotiate to ECP mode.
> As to your other three issues, I'm not sure what to make of those.
> I got the same low data rate as you, but I don't know why.
>
> Does anybody know how other operating systems handle retrieving
> "ready" status when using ECP mode?
>
> p.
>
I believe that as long as the channel is in ECP mode the peripheral is
essentially always "ready". The host is always allowed to try to send
a byte to the peripheral and the only thing the peripheral can do is
not read it. 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.
-- Dave Strauss
-- 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:08:37 EDT