[hpoj-devel] more code changes

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

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.

Also, I added an optional remote debug console capability to ptal-mlcd.  If
you invoke it with "-remconsole", you can use a command like "ptal-connect
mlc:par:0 -socket -1" to access the console, even if you started ptal-mlcd
in the background (without the "-nofork" switch).  It's best to enable this
for debugging on systems with only trusted users, since any local user (not
just root) can connect to this service.

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.

David