[PARPORT] negotiation questions

From: Peter Asemann (sipeasem@immd3.informatik.uni-erlangen.de)
Date: Tue Jun 17 2003 - 09:14:49 EDT

  • Next message: Peter Asemann: "[PARPORT] parallel port functionality in the "standard" linux kernel config?"

    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