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
exact amount requested). The problem was that when
usb_submit_urb(&usblp->readurb) was called in usblp_read(), it failed
out usblp->readcount the way it did in usblp_open().
The second problem was that selecting for a read never triggered when
had been received, because the check for usblp->bidir in usblp_poll()
I submitted a patch against 2.2.18 to the linux-usb-devel mailing list
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
Steps to Reproduce:
Problem #1 (read):
Connect USB HP OfficeJet G series, K series, or LaserJet 3200.
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
Problem #2 (poll/select):
Never returns even when bulk IN data is available, due to an inverted test
for bidirectionality in usblp_poll().
We (Red Hat) should really try to resolve this before next release.
Thanks for the report. Patch is applied and will be included in the
next kernelbuild in Rawhide.