On 15.08.2025 8:07 PM, Alan Stern wrote:
However the printout is still not in full. Now the same picture prints about
4/5 of the page, but still not 100% (previously it failed on 1/3).
Would the .pcap of the printing process be useful?
I rather doubt it. You might be able to figure something out by looking
at the timing of the various transfers, particularly near the end when
the underflow occurred. But I don't even know what the printer's timing
requirements are (and maybe you don't either).
Overall this probably isn't a battle worth fighting. Either just attach
the printer to a high-speed hub or get a better printer.
I *buy* these legacy devices to improve them in Linux :)
I'm making an open-source print server hardware for older printers,
that's why for me this issue is worth researching, at least to document
such hardware heisenbugs.
There've been different USB behavior and incompatibilities with scanners
(fixed it in SANE) and printers (fixed by CUPS quirks file), but this is
the first time I'm going down to USB HC level.
This printer (Canon LBP1120) does not have drivers for 64-bit Windows or
recent macOS, that's why for many it's a paperweight device you can't
use or sell, unless fixed by other means (usually a VM with 32-bit
Windows, and now my print server as well).
You gave me directions where I should look for, because I didn't know
how to start debugging without the logic analyzer.
Usbmon captures only USB communication packets and some of USB HUB
controlling packets (such as TT related), but does not include
device-controlling MMIO registers, which was the case here.
I'll add debug prints to everything related to MMIO and take a look what
could be improved. Thanks!
If you have other ideas I could try right away, please share them!
