hpoj-devel

RE: [hpoj-devel] more code changes

[PASCHAL,DAVID (HP-Roseville,ex1) <dav...@hp...>]

Tim Waugh wrote in response to me:
> > I experimented with the interaction between ptal-mlcd and 
> the Linux parport
> > drivers.  It seems that parport_pc and parport_probe are 
> the ones that break
> > ptal-mlcd when they get insmoded.  Earlier I proposed 
> adding something to
> > ptal-mlcd to attempt to open /dev/lpX when communicating 
> with a parallel
> > peripheral.  This would cause all of the parport modules to 
> get loaded and
> > get their problematic initialization out of the way, and it 
> would force
> > parport_pc to stay loaded.
> 
> Why is the initialization problematic?

ptal-mlcd accesses the parallel-port registers directly, bypassing the
kernel parport drivers.  Once ptal-mlcd has initiated communication with the
peripheral, it is in ECP mode (nSelectIn=1).

parport_pc's initialization routine modifies the registers in an attempt to
detect the port type and to set the registers to a known state.
parport_probe attempts to retrieve a device ID string from the peripheral.
In both cases, the port is returned to compatibility mode (nSelectIn=0),
effectively pulling the rug out from under ptal-mlcd.

If /dev/lp0 is already open when parport_probe gets loaded, does that
prevent parport_probe from trying to probe on parport0?  If so, then maybe
that would be a good solution after all.  It would also prevent problems
from somebody's trying to open /dev/lp0 while ptal-mlcd is using that port.

David

Re: [hpoj-devel] more code changes

[<pa...@rc...>]

Joe Piolunek wrote:
> Printing works now on the 600 if ptal-printd is started without the '-nouel' 
> switch. I don't recall seeing a definition of 'uel'. Does it mean "Unix End 
> Line"? If so, would it have helped to remove the 'fix stair-stepping text' 
> option in printtool?
Hi, Joe.  UEL stands for Universal Exit Language and is part of PJL (Printer
Job Language).  Technically it refers to the specific escape sequence
"<Esc>%-12345X", and it provides a stronger and print-personality-independent
job delimiter than the <Esc>E sequence that gets sent when you tell printtool
to "Send EOF after job to eject page".  In ptal-printd I stretched the
definition a bit with uel1 and uel2 to refer generically to the strings sent
before and after the job.  The problem was that the <Esc>E before the UEL in
uel1 was confusing your printer.  In 0.7 the <Esc>E came second, but I swapped
them recently when I discovered the LaserJet 3200m didn't like that when
printing PostScript.  And as we saw, *that* change didn't go over very well
with your printer, so I took the <Esc>E out of uel1 altogether.  :-)

(regarding manually insmoding all the parport* modules):
> It's too bad there isn't a neater solution. If that's the best one available 
> though, I suppose people won't mind doing it very much.
Unfortunately, it looks like keeping /dev/lpX open doesn't prevent
parport_probe from re-probing that port when it gets reloaded.  Nevertheless,
I'm now leaning more towards this ptal-mlcd-assisted solution, which should
take care of the problem in the vast majority of cases (other than the case
of parport_probe unload and reload, which doesn't seem to happen anyway when
telling printtool to create another print queue).  It also has the added
benefit of preventing somebody else from opening the same /dev/lpX.  One
tradeoff will be that the user has to specify which /dev/lpX to use, in
addition to the I/O port base address(es), with a command line such as:
	ptal-mlcd par:1 -base 0x278 -device /dev/lp2
However, for a single-port box, it should be something pretty simple, like:
	ptal-mlcd par:0 -device /dev/lp0	# -base 0x378 implied.
The other obvious tradeoff will be that the parport*/lp modules will stay
loaded all the time while ptal-mlcd is activated, but this shouldn't be too
big of a problem.  I don't think there's a reliable way to probe for all of
the necessary information (low and high base addresses and /dev/lpX node),
so the user will have to figure this out by looking at /var/log/messages.

I'll try to code this up in the next few days and let people try to break
it.  :-)

David

Re: [hpoj-devel] more code changes

[Tim W. <tw...@re...>]

On Thu, Mar 22, 2001 at 04:18:21PM -0800, PASCHAL,DAVID (HP-Roseville,ex1) wrote:

> ptal-mlcd accesses the parallel-port registers directly, bypassing the
> kernel parport drivers.  Once ptal-mlcd has initiated communication with the
> peripheral, it is in ECP mode (nSelectIn=1).

Gotcha.  You can't reserve IO regions from user space, can you?

Using /dev/parport0, you can try to get exclusive access to the port,
which will (a) load parport_lowlevel, and (b) make sure no other
device drivers can touch it.  But that's for 2.4.x only at the moment.

But for the mean time, yes I think opening /dev/lp0 and keeping it
open is a 'good enough' way to prevent pulled rugs.  It doesn't stop
the user from doing 'modprobe -r parport_probe; modprobe
parport_probe', but the user is supposed to be on your side in this
application I think.

Tim.
*/

Re: [hpoj-devel] more code changes

[<pa...@rc...>]

Hi, Tim.

Tim Waugh wrote:
> Gotcha.  You can't reserve IO regions from user space, can you?
> 
> Using /dev/parport0, you can try to get exclusive access to the port,
> which will (a) load parport_lowlevel, and (b) make sure no other
> device drivers can touch it.  But that's for 2.4.x only at the moment.
I may look into this at some point if it becomes necessary, but for now I
want to be as kernel-independent as possible.  Any OS/version-specific
features like this would have to be optional and turned on or off by the
configure script, similar to how I detected and worked around the problem
with including <sys/io.h> in C++ code.

> But for the mean time, yes I think opening /dev/lp0 and keeping it
> open is a 'good enough' way to prevent pulled rugs.  It doesn't stop
> the user from doing 'modprobe -r parport_probe; modprobe
> parport_probe', but the user is supposed to be on your side in this
> application I think.
I agree now that I've thought about it some more.

On a related note, Tim, how familiar are you with using the hardware-assisted
ECP transfer modes (using the FIFOs)?  I attempted to code support for that
into my ParPort class but had trouble getting both forward and reverse ECP
transfers to work.  I'm thinking I may not be turning the bus around
correctly.  For now I'm doing all of the signalling in software, just the way
it was done in ieee12844pp.c, but eventually I'd like to start using the
FIFOs (no DMA or interrupts) to try to improve performance.

David

Re: [hpoj-devel] more code changes

[Tim W. <tw...@re...>]

On Fri, Mar 23, 2001 at 01:51:40AM -0800, David Paschal wrote:

> Hi, Tim.
>=20
> On a related note, Tim, how familiar are you with using the hardware-assi=
sted
> ECP transfer modes (using the FIFOs)?  I attempted to code support for th=
at
> into my ParPort class but had trouble getting both forward and reverse ECP
> transfers to work.  I'm thinking I may not be turning the bus around
> correctly.=20

There are lots of caveats in the datasheets.  I'm not convinced that
the parport_pc code gets it right either.

> For now I'm doing all of the signalling in software, just the way
> it was done in ieee12844pp.c, but eventually I'd like to start using the
> FIFOs (no DMA or interrupts) to try to improve performance.

Again, this is something that /dev/parport0 can supposedly help with,
but I guess it will be a while before applications do.

Tim.
*/