The only way to _assume_ a printer is online is to attempt a dummy poll for
information. Again note that this is a strong assumption as only some new printers
return data for a poll, and legacy printers control of the data port are undefined.
The poll btw needs to be done in userspace because printers respond differently with
different polls. Thus a 'printer driver' interface needs developed. Oddly enough,
WinPrinters won't suffer this problem simply because of their bidirectional design
:(
-d
Jesse Pollard wrote:
> --------- Received message begins Here ---------
> Tim Waugh <twaugh@redhat.com>:
> > On Thu, Jan 04, 2001 at 03:39:10PM +0100, Andrea Arcangeli wrote:
> >
> > > As noted yesterday falling into parport_write will silenty lose data when the
> > > printer is off.
> >
> > (Actually it depends; I think FIFO/DMA paths are fine, but yes, the
> > software implementation can lose data.)
> >
> > > If it's not feasible to make parport_write reliable against
> > > power-off printer, then I recommend to loop in interruptible mode
> > > before entering the main loop (waiting the printer to power-on) like
> > > in latest patch from Peter.
> >
> > Have I missed a patch? How do you know whether or not the printer is
> > on yet?
> >
> > As I understand it, you can't guarantee anything about any of the
> > signals when the printer is off, so all you can do is look for
> > 'suspicous' things (like 'no error' and 'paper out'). But some
> > printers do this during normal operation, and hence the LP_CAREFUL
> > switch.
> >
> > Return -EIO when the printer is on and off-line is a bug, sure enough.
> > That's what the -EAGAIN patch was for, and Peter's patch fixes this
> > too.
> >
> > But if you want to avoid losing data when your printer is off you need
> > to use LP_CAREFUL, and hope printing still works at all (depends on
> > your printer).
> >
> > If this goes away:
> >
> > if ((status & LP_PERRORP) && !(LP_F(minor) & LP_CAREFUL))
> > /* No error. */
> > last = 0;
> >
> > then some people might not be able to print at all.
>
> I don't believe this is a problem that CAN be fixe, either by hardware
> or software.
>
> Originally, (wayback machine on) this was handled by a pull-up resistor
> in the parallel interface, on the "off-line" signal. ANY time the printer
> was powered off, set offline, or cable unplugged, the "off-line" signal
> was raised by the pull-up. No data lost.
>
> Now the parallel interface is bidirectional, and can have multiple devices
> attached - this "fix" cannot be used. The interface is now more of a
> buss than a single attached interface, and signals from a missing device
> (powered off or disconnected) are floating. They may float high or low,
> and depending on the environment (and which end of the cable is unplugged)
> any thing in between.
>
> Yes, I've lost printouts this way, but there's nothing I can really do
> about it other than than tell the users "don't do that - make sure the
> printer is turned on before you print".
>
> -------------------------------------------------------------------------
> Jesse I Pollard, II
> Email: pollard@navo.hpc.mil
>
> Any opinions expressed are solely my own.
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> Please read the FAQ at http://www.tux.org/lkml/
--------------08A43E183C6824DE740BB2A8
Content-Type: text/x-vcard; charset=us-ascii;
name="david.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for David Ford
Content-Disposition: attachment;
filename="david.vcf"
begin:vcard
n:Ford;David
x-mozilla-html:TRUE
url:www.blue-labs.org
adr:;;;;;;
version:2.1
email;internet:david@blue-labs.org
title:Blue Labs Developer
note;quoted-printable:GPG key: http://www.blue-labs.org/david@nifty.key=0D=0A
x-mozilla-cpt:;9952
fn:David Ford
end:vcard
--------------08A43E183C6824DE740BB2A8--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/