I still didn't understand when negotiation is done.
In his book parallel port complete Jan Axelson writes on page 210:
"Through negotiation, the host can find out which modes a peripheral support.
When a peripheral supports multiple modes, the negotiation tells the
peripheral which mode the host wants to use".
My problem is that I sincerely do not understand if there is any real-life
software that doesn't care how it communicates with the peripheral connected.
I guess that most real-life software is rather picky regarding the modes of
communication it supports.
So when and how do real drivers or real programs directly accessing the
hardware do negotiation?
Do they "software-emulate" ecp/epp negotiation?
Do they rely on the hardware?
Will a software which wants to communicate via EPP just try if there is an
EPP present and go on "talking" EPP no matter what happens - even if a
"wrong" peripheral is connected which doesn't understand EPP?
If a software uses ECP to select the communication, and tells the ECP
controller to negotiate to some mode, will the ECP hardware try an 1284
negotiation handshake with the peripheral automatically? What happens if the
negotiation fails? I guess the controller returns to compatibility mode and
sets the extended control register accordingly?
Well, I was glad if I knew what the most common drivers and programs for
Linux do.
Peter Asemann
-- 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 : Tue Jun 17 2003 - 09:19:41 EDT