OKI 407 receipt printer freezes

[jim-cathey]

Describe the bug We are updating our 150-odd Point-of-Sale array from LUbuntu 20.04 LTS to LUbuntu 22.04 LTS, and are having problems with our receipt printers, Oki 407's. (Prior to CUPS 2.2.12 we had serious problems with these printers using CUPS, but Issue #5583 seemed to have fixed that for 20.04. We use raw queues, as all receipt formatting is done directly by the PoS software itself, which it did long before Linux or CUPS was ever part of the picture.) CUPS 2.4.1, part of 22.04, has seemed to regress from our point of view, as the printers are again freezing. Near as I can tell the reaction to Issue 5879 (post-2.3.1) was to revert the fix for 5583, and this appears to be our problem.

Receipt-test (small) jobs to the OKI 407 work well enough, but an attempt to print a logo-bearing (large) receipt causes a freeze in printing, and top shows that the 'usb' process is running a lot, and 'cupsd' to a lesser extent. If this 'usb' process is STOPped and CONTed a couple of times, the receipt comes out. Otherwise, not. [EDIT: After maybe 20 minutes the receipt does make it out. Utterly useless in a retail environment!]

The speculation is that there's an internal quirk in the 407 printer that causes it to try to report a status back to the computer at some point during these larger jobs, and that CUPS' internals are reacting this status availability, and doing something besides (rather than in addition to) sending more data to the printer as a result. (Sending more data will clear the offending status, because you can just cat the print job data directly to the USB port, ignoring any status feedback, and it prints just fine. It is only sending this data through CUPS that has problems.) The extra delay thrown in by the (now-reverted?) 5583 fix allowed it to continue sending data to the printer during these delays, getting past the sticking point. With the delay gone, the problem is back.

To Reproduce Steps to reproduce the behavior:

1. Create raw printer queue, for OKI 407 receipt printer
2. Print a larger (logo-bearing) receipt.
3. Wait, forever.

Expected behavior Receipts should print, and quickly.

Screenshots N/A

System Information:

• LUbuntu 22.04
• Custom Point-of-Sale application, Lazarus-based.
• CUPS version 2.4.1

Additional context In comments. (I didn't seem to be able to attach non-text files, so binary files have had a .txt added to their names.)

[jim-cathey]

The error log has had the back end trimmed drastically at the point where it starts repeating itself. You can see that once the printer has something to say back that CUPS is pretty much unable to send it any more data. error_log.txt lpinfov.txt lpstate.txt lpstatt.txt

[jim-cathey]

The spooled print file: d00015-001.txt

[jim-cathey]

This test system has considerable USB resources besides the problematic OKI 407 printer, but production systems exhibit the same problems. lsusbv.txt

[jim-cathey]

The first 1024 tcpdump USB frames. (It's well into repetition at this point.) usb1.pcap.txt

[zdohnal]

Ah... we feared this when the original regression came - that the change will break some other USB device we don't have any way to check...

The current code works for Lexmark USB printers and legacy Samsung printers, so if we change anything in default behavior, we should check it with someone with the people which have those models...

The change is in reading data from backchannel - would it be possible to use your printer in unidir mode?

You can send the job like this:

$ lp -d <printer> -o usb-unidir=true <file>

does it work for you?

[zdohnal]

@michaelrsweet another way for this would be probably option in device uri, which, if set, would enforce the read limits as before...

[michaelrsweet]

@zdohnal If the unidir option works, just add the printer to the quirks file:

# OKI PT390 POS Printer
0x06bc 0x02bb unidir

[jim-cathey]

Yesterday I had already tried the unidir option, via post-printer-creation script, and it appears to solve the problem. (It took me some time to figure out that this might be the way to go, as I'd been too focused on the it-used-to-work-and-then-it-didn't nature of the problem!) Testing is in progress now, as we prepare for opening this season.

It's the OKI 407 printer, not the PT390. The PT390 works just fine as-is. (We use both of them in the Park, roughly in equal numbers. 407's spit the receipt out the top, 390's out the front.) Both printers were produced for many years, but are now discontinued, and the plan is to replace them individually with Star 743 printers as the originals die in the coming years. They are far too expensive to replace wholesale in response to software mutation.

BTW, we are relying upon CUPS' ability to provide raw queues, because all the application software does its own formatting. (This is very simplistic formatting. Cash register receipts, sometimes with logos and printer-formatted barcodes.) CUPS provides useful network-independence that we're now using. I would hate to have to go back to the pre-CUPS approach of driving printers directly, if CUPS makes good on its threat to eliminate the ability to support printers like these. We experimented with Star 143 printers, which are bitmap-only printers that require rendering drivers, and the results were far from satisfactory. Massive rewriting of the applications would be required, for no net benefit.

[michaelrsweet]

@jim-cathey So CUPS is moving aware from the current approach which allows for raw-only print queues. This process has been underway for many years now, with the replacement being printer applications that support the printer's native PDL as "raw" input, should you need it. But all printers need to support basic raster printing to work in this century.

OKI is out of the printer business in North America (at least). But Star is still selling printers and most of those printers support ESC/POS which is something that might end up being supported by LPrint in the future.

[jim-cathey]

Besides ESC/POS (and the 407 equivalent) we are also driving Boca ticket printers, using FGL, and Zebra wristband printers, using ZPL. All through CUPS and its raw queues. These are all technically raster printers, but don't necessarily offer that ability outside their respective print languages. All are expensive limited-market peripherals, unlike mass-market inkjets. If it came to a shootout in our corral, CUPS would lose. (Most likely we'd just lock in an old version.) I could also envision non-raster printers, like Braille or vinyl sign cutters, that might benefit from CUPS' presence.

[michaelrsweet]

@jim-cathey Regardless of what you would choose, CUPS and the OpenPrinting ecosystem is designed (and has always been designed) to offer a consistent, standards-based printing experience that is accessible to all applications. "Raw" printing is tolerated for specialty applications but is unreliable and a nightmare to support in the long term - changes in hardware necessitate (usually custom) changes in application software.

WRT "mass market" printing, label and receipt printers produce far more output these days than consumer inkjet printers - 200 billion shipping labels alone each year. Any label/receipt printer with a USB or network interface will be able to print raster data at engine speed.

WRT Braille printers, while there has been some work towards supporting PDF and text to Braille to support printing from normal applications, professional Braille output requires specialized software. Likewise sign cutting equipment can start from PDF but often needs some guidance to get the best results.

[jim-cathey]

Well, one of the very nice things about Linux is its ability to work well with what can be considered obsolescent hardware.

Also, things like roll-paper (indefinite-length) receipts cannot necessarily be sent cleanly to page printers. Some degree of device-dependence is often unavoidable. Likewise printing on wristbands, or perforated pre-printed ticket stock. Our particular system 'prints' on all of these, as well as blank magcards (including magstripe contents). Mostly using the print language (raw) specified by the vendor of the printer in question.

[EDIT: Roll-paper receipt printers have paper cutters that need to be controlled, the options are no, partial, and full cut, and they also have output ports that drive cash register drawers. (Depending upon method of payment, etc.) These kinds of options don't really fit naturally into a device-independent world.]

CUPS currently gives us nice administration abilities, spooling and network independence, all of which are very welcome. If it actually takes away our ability to talk to the devices in their native languages... well, that would not be so welcome.

[jim-cathey]

The unidir quirk is sufficient for this printer. Nothing more is needed.

[zdohnal]

Please don't close the issue until the quirk is merged into project, thanks!