Re: [PARPORT] parport / ppdev/ pc superio chipsets

From: Matthew Duggan (stauff@guarana.org)
Date: Sun Jun 01 2003 - 19:12:28 EDT

  • Next message: Peter Asemann: "[PARPORT] Daily ppdev question... difference between nibble and compat and byte mode"

    Quoting Peter Asemann <sipeasem@immd3.informatik.uni-erlangen.de>:

    ...
    > There might be a very old compatibility mode device connected to a
    > state-of-the-art ieee1284 controller.
    > Is there a way to detect whether the controller would support some advanced
    > mode even if the device connected doesn't support that mode?
    > E.g. to write a program that says "Your controller has ECP hardware support
    > but your printer only understands SPP"?
    >
    > Is it possible to simply try negotiating to all possible modes using ppdev to
    > find out which modes are supported by the actual hardware?

    Hi,

    Not sure about your first questions regarding SuperIO hardware, but this I do
    know. The capabilities detected by ppdev et al. will always be the caps of the
    port, not of the devices attached to it.

    The reason for this is that many devices implement ECP or alike, but may not
    require negotiation (eg, simple devices which are always stuck in ECP mode
    regardless of what the host does).. or they might require some special wakeup
    sequence before they will respond to negotiation (as is the case with scanners
    which have a pass-through port). Working out exactly what mode each peripheral
    wants is left as an exercise for the application writer, as it's assumed the
    person who built the hardware will know how to get the best performance out of
    their device.

    You can try negotiating all modes if you want, but it still won't be accurate in
    most non-printer cases - and doesn't seem worth the trouble.

    > Where in the parport driver codes are the "finite state machines" which
    > perform negotiation with connected devices, daisy chaining etc.?

    For negotiation, you will find some code in ieee1284-ops.c which references
    port->physport->ieee1284, which holds the ieee1284 phase etc, but the FSM may be
    built into the hardware if the port supports hardware transfers.

    Cheers,

    Matthew Duggan

    -------------------------------------------------
    This mail sent through IMP: http://horde.org/imp/

    -- 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 : Sun Jun 01 2003 - 19:22:17 EDT