Tim Waugh (tim@cyberelk.demon.co.uk)
Thu, 13 Jan 2000 08:50:44 +0000 (GMT)
On Thu, 13 Jan 2000, WODECKI, Victor wrote:
> In my own test program, I perform the following sequence;
> fd = open ("/dev/parport0", O_RDWR | O_NOCTTY)
> ioctl (fd, PPCLAIM)
> mode = IEEE1284_MODE_EPP | IEEE1284_ADDR
> ioctl (fd, PPNEGOT, &mode)
> This fails on the PPNEGOT, with EIO. Poking about with tracewrites in
> ppdev.c seems to show that it fails in negotiate(), waiting for nAck to
> go low.
>
> If I insert, before the failing ioctl, the following
> mode = IEEE1284_MODE_EPP
> ioctl (fd, PPSETMODE, &mode)
> then the failing ioctrl (PPNEGOT) now succeeds, although ppdev then
> seems to get stuck in a loop when I do the actual write() of the
> address.
Try putting a delay after the open. I think there's a bug somewhere. How
does write get stuck in a loop?
> I've also tried it under Wine, but that gets nowhere, and vmware doesn't
> work with EPP (only ECP?).
PS2 I think.
> I'm not sure what to make of all this. Is ppdev what I should be
> using? It seems to be the neatest approach, but it might not work for
> this device. Do the above symptoms mean that the device is only
> partially IEEE1284-compliant?
Yes, and yes.
> I did ask the manufacturer for more information on the interface, but
> all they said was
> "We are compliant with the timing and configuration of IEEE 1284.
> This document is available from IEEE as well as much data available
> on the internet. I/O's are simple Inp and Outp 'C' commands are
> all that are needed."
That's what _everyone_ says -- they can't _all_ be right. ;-)
Tim.
*/
-- 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 2.0b3 on Thu 13 Jan 2000 - 03:59:08 EST