Andrea Arcangeli (andrea@e-mind.com)
Thu, 21 Jan 1999 00:02:55 +0100 (CET)
On Wed, 20 Jan 1999, Tim Waugh wrote:
> Then your printer is _not_ compliant. This is exactly what I was seeing
So most of printers are _not_ compliant. (maybe Hp are compliant?).
> with my printer, and exactly why I put the hack of waiting a tiny bit
> before checking ERROR. Did you try it before removing it? Maybe the
Sure! It made no one difference.
> fudge delay needs to be longer to accommodate your printer as well.
The error signal seems to be logical and _not_ timing related.
> _Don't_ just eliminate code because your particular hardware doesn't need
> it, and _never_ eliminate code when it does.
Do you want to force me to not use parport_probe? ;). I am not asking to
include it in your tree, I only told you what an Epson Stylus Color 740
need to work _fine_.
> > This patch against the latest Tim's 1284 code I merged, fix everything
> > here (P2B motherboard and Epson Stylus Color 740 printer), with this patch
> > applyed both parport_probing and lp readback works fine.
>
> Does your printer give status readback separately to device ID information
> then? What kind of thing does it say?
Now that for the first time in my life it works I get:
root@laser:/home/andrea# cat /dev/lp0
?MFG:EPSON;CMD:ESCPL2,BDC,D4;MDL:Stylus COLOR 740;CLS:PRINTER;
It change when something change in the printer.
> Bzzzt. This is wrong, Andrea. We don't _always_ want device ID. You
> are right that the original code is wrong. The correct fix is to
> remember if we wanted device ID before we explicitly ignore the bit a
> few lines up.
I have no ida of what is device ID (a real fix is welcome, I guess I had
to ask for some parport_negotiate() in lp_read() in the same way we just
do in parport_probe()). I know how to make the code working though ;). I
am out from the real developing because I don't have the specs. I only can
give you some hint when something doesn't work right now.
> > +#if 0 /* completly breaks Epson Stylus Color */
> > /* Does the error line indicate end of data? */
> > if (parport_read_status(port) & PARPORT_STATUS_ERROR) {
> > port->ieee1284.phase = IEEE1284_PH_HBUSY_DNA;
> > @@ -287,6 +293,7 @@
> > port->ieee1284.phase = IEEE1284_PH_REV_IDLE;
> > break;
> > }
> > +#endif
> >
> > /* Event 7: Set nAutoFd low. */
> > parport_frob_control (port,
>
> This is not acceptable.
It has to become acceptable or I should do more reverse engeneering to
understand what the ERROR line means here and how could I make it working
here too otherwise nobody with a Stylus Color will ever be able to use the
1284 nibble mode handshake. (I don't try to ask Epson, they will not care
me, I'm sure).
> Why? And anyway, everything else is not fine -- you said yourself that
> you are not getting reliable data-ready indication.
But I don't have the real specs, so I couldn't know if the data-ready
indication was an hack as the Canon one. See things from my point of view
;).
Andrea Arcangeli
-- 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 Wed 20 Jan 1999 - 18:04:08 EST