Messages in this thread Patch in this message | | | Date | Sun, 9 May 1999 23:18:21 +0200 (MET DST) | From | Andries.Brouwer@cwi ... | Subject | tunelp - was: Re: Maintainers |
| |
From johnsonm@nigel.redhat.com Sun May 9 19:25:25 1999 ...
Yes.
So, now we all have made our points of view clear, let us return to kernel and tunelp itself.
2.0.36 has #define LPSTRICT 0x060f 2.1.131 (and 2.2.*) has #define LPTRUSTIRQ 0x060f
This is a bug. It makes it a bit awkward to release an improved tunelp, entirely regardless of who does the releasing, since tunelp would have to check for the version of the running kernel, and the man page would need a lengthy explanation.
Both ioctls are not precisely what seems to be needed, but discussion of what is needed may take time, while resolution of the ioctl conflict should happen as soon as possible. As far as I know no software exists that uses LPSTRICT (while Andrea's tunelp uses LPTRUSTIRQ) so probably no bad things happen if we apply this patch to 2.0.36:
-------------------------------------------------------------------- --- lp.h~ Tue Nov 17 17:31:10 1998 +++ lp.h Sun May 9 22:53:43 1999 @@ -71,7 +71,7 @@ #define LPRESET 0x060c /* reset printer */ #define LPGETSTATS 0x060d /* get statistics (struct lp_stats) */ #define LPGETFLAGS 0x060e /* get status flags */ -#define LPSTRICT 0x060f /* enable/disable strict compliance */ +#define LPSTRICT 0x0610 /* enable/disable strict compliance */ /* timeout for printk'ing a timeout, in jiffies (100ths of a second). This is also used for re-checking error conditions if LP_ABORT is --------------------------------------------------------------------
So far the immediate fix. (If it is applied then a corresponding comment should be added to the 2.2.8 lp.h so that nobody will take 0x0610 later.)
In 2.0.35 some code was inserted to replace a waiting loop by some code waiting for NBSY=0. People complained that the Epson 800 printer became terribly slow and in 2.0.36 the patch was reverted, with an ioctl LPSTRICT to select the 2.0.35 behaviour.
The first question is: this 2.0.35 behaviour - is it strictly according to the specs? Not according to my notes, which say:
------------------------------------------------------------------- /* Parallel port timing: 1. wait for NBSY=1 2. outb(data byte, data port) 3. wait for at least 0.5us 4. read control port, OR with STR=0x1, output to control port - purpose: generate strobe pulse; this will make the busy line go high 5. wait for at least 0.5us 6. read control port, AND with !STR, output to control port 7. wait for at least 0.5us 8. in a loop: read status register until NACK bit is 0 or NBSY=1 (the printer will keep NACK=0 for at least 0.5us, then NACK=NBSY=1). */ ------------------------------------------------------------------- In the 2.0.36 code I do not see any waiting for a definite period of time - just strange loops like wait = 1000; while(wait) wait--; with an execution time very much dependent on processor and alignment. Andrea's code in 2.2.* looks much better.
Andries
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |