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