From Bugzilla Helper:
User-Agent: Mozilla/4.72 [en] (X11; U; Linux 2.2.18-dsp1 i686)


The biggest problem was that after I successfully read an MLC/1284.4 packet
     on a 7/1/3 interface, every subsequent read would return garbage (but
in the
     exact amount requested).  The problem was that when
     usb_submit_urb(&usblp->readurb) was called in usblp_read(), it failed
to zero
     out usblp->readcount the way it did in usblp_open().

     The second problem was that selecting for a read never triggered when
data
     had been received, because the check for usblp->bidir in usblp_poll()
was
     inverted.

I submitted a patch against 2.2.18 to the linux-usb-devel mailing list
(http://www.geocrawler.com/lists/3/SourceForge/2571/0/5123030/).  Looking
at drivers/usb/printer.c in 2.4.x in Fisher, the read bug is partially
fixed, and the poll bug is not fixed.  Hopefully somebody on
linux-usb-devel will ensure that these fixes get incorporated into 2.2.19
and 2.4.2, but I'm submitting this bug report against Fisher so it will get
tracked.

Reproducible: Always
Steps to Reproduce:
Problem #1 (read):

Connect USB HP OfficeJet G series, K series, or LaserJet 3200.
fd=open("/dev/usb/lp0",O_RDWR);
write(fd,"\0\0\0\8\1\0\0\x20",8); // Send 1284.4 Init packet.
read(fd,buffer,6); // Receive 1284.4 header.
read(fd,buffer+6,3); // Receive data portion of 1284.4 InitReply.
Everything works fine so far.

read(fd,buffer,6); // Receive next 1284.4 header.
This and every subsequent read() returns garbage data in the exact amount
requested, because the readcount variable is not zeroed out when submitting
another readurb.

Problem #2 (poll/select):

fd_set rset;
FD_ZERO(&rset);
FD_SET(fd,&rset);
select(fd+1,&rset,0,0,0);
Never returns even when bulk IN data is available, due to an inverted test
for bidirectionality in usblp_poll().