On Thu, May 18, 2000 at 10:53:22PM +0200, Gunther Mayer wrote:
> Your patch is obsolete for "lp.c" in 2.3.99 as the functionality is included
> in "parport/ieee_ops.c":parport_ieee1284_write_compat;
No it isn't --- read the code more carefully. write_compat stops when
it looks like the printer might be upset (even if it isn't) only after
it has printed stuff already.
So the way it works is: lp checks the status lines and applies its own
'careful' policy to decide if the printer is upset. If it is okay to
print, it hands it to parport. Things go okay and it starts
printing. After that, the printer changes status and parport notices
-- at that point, parport stops and hands control back to lp. This
isn't saying 'the printer is upset now', it's saying 'the printer
might be upset, could you check please'. Do you see the difference?
The problem was that lp wasn't checking the status lines first, it
was just handing the data to parport straight off.
> There your hint"Assume the peripheral received it" can be found too...
Yes.
> In parport_ieee1284_write_compat are two catches:
> - Is the peripheral ready yet?
> - Is the peripheral upset?
> These happen to handle all sorts of printer's behaviour well.
> I think this sort of policy is probably wrong at this generic place,
> as IEEE1284 does not mandate this behaviour.
Centronics does, and IEEE 1284 says 'Yeah, whatever Centronics says',
right at the beginning. Also, check in the appendix that talks about
Centronics standards.
> Only after disconnecting the printer cable you get the "normal" conditions,
> that other printers show when switched-off (e.g. LJ1100):
> lp0 printer-not-ready ack-active out-of-paper (0x7f)
Yes. You might even come across a printer that, in the off state,
leaves the status lines saying that everything is just fine, please
send me data. There's very little we can sensibly do to detect that,
and it isn't worth bothering.
> Indeed we could easily miss BUSY or ACK as their deassertion is not
> handshaked.
Read the code some more. We get an interrupt, so we won't miss an ack.
> So the port is deliberately slowed down by many obsolete
> "udelay(1)"s in the code (just for ISA-ZWS or PCI you would need
> "nanodelay(375)" or "nanodelay(whatever-for-PCI)") !
Yes, this could be done better. I wonder if it's worth it though.
Maybe I guess.
> But beware of even older printers that have arbitrary timings
> (e.g. Centronics Standard Timing in Annex C of IEEE1284 prefers
> 1000ns, ...)
It would be nice to be able to twiddle the parameters of the IEEE 1284
implementation's protocol functions, basically.
> So LP_CAREFUL is indeed obsolete for 2.3.99, and I will redo my
> patch...
No, LP_CAREFUL is needed. There are some printers that wave things
like paper-out all over the place during normal, non-fault operation,
and for those printers we have to be wreckless (!LP_CAREFUL) in order
to be able to print at all.
There are some people who want to print to printers that are sometimes
off and don't want to lose jobs. In order not to lose jobs we have to
be careful (LP_CAREFUL).
We need both behaviours.
Tim.
*/
-- 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 May 18 2000 - 17:26:43 EDT