Have you looked at my driver?
http://www.cs.albany.edu/~jklaas/parswitch/parswitch.html
This is for an ATEN AS-152/154 switch. I also have some shell scripts
that didn't make it into this driver that produce the appropriate device
files. There is one device file for each port plus one for the broadcast
mode. It is a really simple driver, but it seems to work for me. Let me
know what you think. I even have a specific section for the codes to be
sent, so you could substitute your codes in there if only to see if your
switching would work.
If you use it, please let me know what you think. I would also be
interested in any improvements you might come up with.
James Klaas
On Sat, 17 Feb 2001, Mike Murphy wrote:
> Hi! I have a question that I think could be easily answered by the
> linux-parport readers.
>
> I have a non-IEEE1284 port multiplexor, and I have been able to obtain the
> byte sequences from the vendor that make the multiplexor switch. Although I
> could produce a modified lp.c that could perform the switching using custom
> /dev nodes, I was wondering if a better approach could be developed.
>
> Could I write a module that registers 'clones' of the existing 'real'
> parport, where access to any member of this set of 'cloned' parports would
> be serialized (serialized across the entire group). And when access was
> granted to one of these 'cloned' parports, my code to perform the 'switch'
> could be executed prior to the device driver doing its thing. My module
> would need to implement something like what is found in daisy.c:
>
> void clone_parport(struct parport *real, int muxport)
> {
> struct parport_operations *ops =
> some_kind_of_modification_of(real->ops);
>
> extra = parport_register_port(real->base, real->irq, real->dma, ops);
> if (extra) {
> extra->portnum = real->portnum;
> extra->physport = real;
> extra->muxport = muxport;
> parport_announce(extra);
> return;
> }
> }
>
> I could then do a 'insmod lp.o parport=0,1,2,3', and when stuff was written
> to, say /dev/lp2, the multiplexor would switch to port C and output to the
> printer would work as usual.
>
> My question is, does the parport facility support this kind of an
> arrangement? I won't bother pursuing it further if this isn't a good idea
> or will never have a chance of working. If this is workable, what types of
> 'conditioning' do I need to do on the parport_operations structure? I know
> I have to do SOMETHING to this structure to get my switching code to run,
> but I don't want to screw everything else up in the process.
>
> Any help or advice would be appreciated!
>
> Mike
>
>
>
> -- To unsubscribe, send mail to: linux-parport-request@torque.net --
> -- with the single word "unsubscribe" in the body of the message. --
>
>
-- To unsubscribe, send mail to: linux-parport-request@torque.net --
-- with the single word "unsubscribe" in the body of the message. --
This archive was generated by hypermail 2b29 : Mon Feb 19 2001 - 08:32:11 EST