Re: [hpoj-devel] more code changes

[Joe P. <joe...@sn...>]

On Thursday 22 March 2001 05:59 pm, PASCHAL,DAVID (HP-Roseville,ex1) wrote:
> Hi,
>
> Over the last several days I checked in some more ptal-mlcd, ptal-printd,
> and libptal changes, including some bug fixes and minor enhancements.  You
> can do a "cvs update" in your CVS sandboxes to pick up these changes.
>
> First and foremost, I made a change to ptal-printd to the "uel1" string
> sent before the job to try to fix the problem Joe reported on the OfficeJet
> 600. Joe, can you verify that you can now print without using the "-nouel"
> switch?  I still need to verify it on all the models I have.

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?


> 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.  However, there appears to be
> nothing I can do in ptal-mlcd to prevent parport_probe from being unloaded
> and reloaded and causing problems later.  It looks like the most reliable
> solution is to insmod each of these modules at startup such that they won't
> get
> "autocleaned" (unloaded after a timeout) later.  I'd be interested in
> hearing what others think about this solution.

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.

-- 
Joe