[JessePomeroy]

With the default bidirectional I/O, a Canon Pro9000 Mark II (04a9:10cf) prints one job and then accepts no further job until it is power-cycled. The next job sits at "Sending data to printer" with no state reason; when the printer was finally switched off, the backend log for that job showed Sent 0 bytes.

With usb-unidir consecutive jobs print without a power cycle. Other Canon entries, among them the PIXMA iP4200, iP4300 and iP6000D, already use the same quirk; the iP6000D report (Launchpad 1160638) describes a similar stall that lasts until power is cycled.

Observed with CUPS 2.4.20, libusb 1.0.30, Linux, raw jobs:

Job before it	Jobs	I/O	Result
a bidirectional job, 10 min earlier	2	bidirectional	not accepted
a bidirectional job, 11 h earlier	1	bidirectional	not accepted, Sent 0 bytes
a bidirectional job, 21 s earlier	1	unidirectional	not accepted
power cycle	4	either	printed
a unidirectional job, 16 s, 7 h and 4 h earlier	3	unidirectional	printed

Every job that followed a bidirectional job without a power cycle was refused (four of four); every job that followed a unidirectional job printed (three of three).

Limits: one printer. The kernel usblp module's attachment also differed between some runs and was not controlled for. Tested with lp -o usb-unidir=true and lpadmin -o usb-unidir-default=true, not with the quirk file itself, and with debug logging off, so the backend's "Forced uni-directional communication" line was not captured.