On Thu, 04 Jan 2001, Gunther Mayer wrote:
>Jesse Pollard wrote:
>> 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
Tim Waugh <[EMAIL PROTECTED]> writes:
> On Thu, Jan 04, 2001 at 08:07:19PM +0100, Peter Osterlund wrote:
>
> > If you do this, you should probably also return -EAGAIN if the printer
> > is out of paper, otherwise I would still lose data when the printer
> > goes out of paper. Currently it return
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 pr
On Thu, Jan 04, 2001 at 08:07:19PM +0100, Peter Osterlund wrote:
> If you do this, you should probably also return -EAGAIN if the printer
> is out of paper, otherwise I would still lose data when the printer
> goes out of paper. Currently it returns -ENOSPC in this situation. I
> suppose the diff
Tim Waugh <[EMAIL PROTECTED]> writes:
> --8SdtHY/0P4yzaavF
> Content-Type: text/plain; charset=us-ascii
> Content-Disposition: inline
>
> 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
> > pri
Tim Waugh <[EMAIL PROTECTED]> writes:
> On Thu, Jan 04, 2001 at 02:52:29PM +0100, Andrea Arcangeli wrote:
>
> > I think lp_check_status.
>
> Okay. So what about this patch instead? If the printer is off-line
> to start with, fall into parport_write anyway (it will just time out
> and return 0
Jesse Pollard wrote:
> 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 t
- Received message begins Here -
Tim Waugh <[EMAIL PROTECTED]>:
> 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
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
On Thu, Jan 04, 2001 at 02:20:43PM +, Tim Waugh wrote:
> to start with, fall into parport_write anyway (it will just time out
As noted yesterday falling into parport_write will silenty lose data when the
printer is off.
If it's not feasible to make parport_write reliable against power-off
pr
On Thu, Jan 04, 2001 at 02:52:29PM +0100, Andrea Arcangeli wrote:
> I think lp_check_status.
Okay. So what about this patch instead? If the printer is off-line
to start with, fall into parport_write anyway (it will just time out
and return 0). If LP_ABORT is set, we return -EAGAIN.
Tim.
*/
On Thu, Jan 04, 2001 at 09:27:51AM +, Tim Waugh wrote:
> Believe it or not, there are some printers out there that wave
> LP_POUTPA all over the place even when they're happy: they set
> LP_PERRORP to mean 'happy', which is what the check is for.
I remeber that too, that's why we still have L
On Thu, Jan 04, 2001 at 11:20:27AM +, Tim Waugh wrote:
> I wonder where the EIO is coming from though. Grep only shows up
I think lp_check_status.
} else if (!(status & LP_PSELECD)) {
if (last != LP_PSELECD) {
last = LP_PSELECD;
On Wed, Jan 03, 2001 at 07:44:19PM +0100, Peter Osterlund wrote:
> When trying to print to an off-line printer with 2.4 kernels, the
> "write" system call to /dev/lp0 stalls for 10 seconds and then returns
> EIO.
I wonder where the EIO is coming from though. Grep only shows up
ieee1284.c (in pa
On Thu, Jan 04, 2001 at 02:39:21AM +0100, Andrea Arcangeli wrote:
> On Thu, Jan 04, 2001 at 02:09:56AM +0100, Peter Osterlund wrote:
> > should say that it is obsolete. I think obsolete means "you should never
> > ever have to use this stuff".
>
> Agreed.
I think that LP_CAREFUL is still needed
On Thu, Jan 04, 2001 at 01:08:01AM +0100, Peter Osterlund wrote:
> The tunelp man-page seems to think there are printers that need the
> LP_CAREFUL handling. I also noted that if I disconnect my printer from
> the computer, the data will no longer be lost. Apparently the printer
> confuses the pa
On Thu, Jan 04, 2001 at 02:09:56AM +0100, Peter Osterlund wrote:
> should say that it is obsolete. I think obsolete means "you should never
> ever have to use this stuff".
Agreed.
Andrea
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL
On Thu, Jan 04, 2001 at 01:08:01AM +0100, Peter Osterlund wrote:
> What do you think about the following patch? It also works for all the
> tests mentioned in my previous message.
I'm worried somebody needed to disable LP_CAREFUL to print, probably it's not a
big deal to keep it. About the lp_wai
On Thu, 4 Jan 2001, Andrea Arcangeli wrote:
: I'm worried somebody needed to disable LP_CAREFUL to print, probably
: it's not a big deal to keep it.
I removed it because otherwise I would have had to do twice as many tests
to convince myself that all combinations of flags and printer states
work
Andrea Arcangeli <[EMAIL PROTECTED]> writes:
> On Wed, Jan 03, 2001 at 10:00:59PM +0100, Peter Osterlund wrote:
> > off. Apparently the printer tells the computer it is OK to send data
> > to it when it is off.
>
> So then parport_write is probably buggy because it's losing data silenty while
>
On Wed, Jan 03, 2001 at 10:00:59PM +0100, Peter Osterlund wrote:
> off. Apparently the printer tells the computer it is OK to send data
> to it when it is off.
So then parport_write is probably buggy because it's losing data silenty while
the printer is off. So the below is probably a band aid.
Andrea Arcangeli <[EMAIL PROTECTED]> writes:
> On Wed, Jan 03, 2001 at 07:44:19PM +0100, Peter Osterlund wrote:
> > Is there a better way to fix this problem?
>
> It looks the simpler fix to me (main loop needs someway to handle errors
> anyways) but ask Tim too.
>
> Another way to fix it is to
On Wed, Jan 03, 2001 at 07:44:19PM +0100, Peter Osterlund wrote:
> Is there a better way to fix this problem?
It looks the simpler fix to me (main loop needs someway to handle errors
anyways) but ask Tim too.
Another way to fix it is to loop in interruptible mode inside lp_error waiting
the erro
Hello,
When trying to print to an off-line printer with 2.4 kernels, the
"write" system call to /dev/lp0 stalls for 10 seconds and then returns
EIO. This has the unfortunate effect that the printout will be lost,
because the redhat print filters (in rh7) use "cat" to send data to
the printer dev
24 matches
Mail list logo
