Gutenprint / CUPS Dye-sublimation drivers

  • Status Closed
  • Percent Complete
  • Task Type Bug Report
  • Category Mitsubishi CP-Dxx family
  • Assigned To
    Solomon Peachy
  • Operating System All
  • Severity High
  • Priority Medium
  • Reported Version 1.0
  • Due in Version Undecided
  • Due Date Undecided
  • Votes
  • Private
Attached to Project: Gutenprint / CUPS Dye-sublimation drivers
Opened by Solomon Peachy - 2017-03-22
Last edited by Solomon Peachy - 2019-06-04

FS#564 - D70 fails to print on Raspberry Pi systems

We get failures when sending the printjob to the printer, with libusb reporting USB timeouts at random places.  There seems to be no consistency to when a transfer fails.  Using a hub makes this worse.

I have an additional two reports of a RPi3 failing USB transfers to a D80 when there is no ethernet cable plugged into the interface!


The K60/EK305 appears to work okay.

Closed by  Solomon Peachy
2019-06-04 12:39
Reason for closing:  Deferred
Additional comments about closing:  Not much that can be done on my end, as it's a confluence of two hardware quirks that are unlikely to be solved. Meanwhile, there is a workaround.
Solomon Peachy commented on 2017-03-25 12:36

So far I'm unable to get my main RPi2 to fail with the D80, with 20+ prints.

Fedora 25 w/ RPI-patched 4.9.11 kernel, ethernet unplugged, and the USB ports populated by two isl3887 WLAN adapters, a Microsoft USB keyboard dongle, and of course the printer itself.  The RPi2 also had an external DAC attached and was being supplied by a high-current +5v supply.

I'll try this going through a hub next, as that supposedly made the D70 problem worse.

(The EK305's seen even more prints on this RPi, but with Fedora 23 and an older kernel)

Solomon Peachy commented on 2017-04-20 03:46

Still unable to trigger this problem on my setup with a D80.  But I need to now correlate the kernel cmdlines between my setup and those that fail -- both the cmdline and the RPI's config.txt.  So it's time to gather logs.

No printer failures, but I've managed to completely wedge the USB subsystem a couple of times now..

Solomon Peachy commented on 2017-07-19 02:18

The underlying problem is that the RPi USB controller triggers a Denial-of-Service on the printer due to the former massively spamming the printer with USB NYET/PING/[N]ACK messages.

The D80 is also affected, just not as badly.

The solution is to generate a decent amount of USB traffic on the bus while accessing the printer. Plugging in an ethernet cable to the onboard ethernet appears to be sufficient most of the time!

Solomon Peachy commented on 2018-02-26 18:54

It's confirmed that simply plugging in a loopback cable or dongle is sufficient.  Here is one:


Available keyboard shortcuts


Task Details

Task Editing