Bug 2072448 - ipp-usb claims USB port with IPP-over-USB device which breaks already installed print queues and scanner backends for this IPP-over-USB device
Summary: ipp-usb claims USB port with IPP-over-USB device which breaks already install...
Alias: None
Product: Fedora
Classification: Fedora
Component: golang-github-openprinting-ipp-usb
Version: 37
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
Assignee: Zdenek Dohnal
QA Contact: Fedora Extras Quality Assurance
Whiteboard: https://ask.fedoraproject.org/t/commo...
Depends On:
TreeView+ depends on / blocked
Reported: 2022-04-06 10:51 UTC by Zdenek Dohnal
Modified: 2023-06-12 07:31 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Last Closed: 2023-06-12 07:31:39 UTC
Type: Bug

Attachments (Terms of Use)

Description Zdenek Dohnal 2022-04-06 10:51:21 UTC
The common behavior for ipp-usb is that if ipp-usb is running, it keeps USB port of ipp-over-usb device (a device capable of driverless printing) for itself, which breaks already installed print queues which uses classic drivers and SANE backends, which don't use driverless scanning protocols.

Behavior of print queue breakage:
- the old queue is visible, but when a print job is sent to the old queue, it fails because the queue (its backend to be specific) cannot claim the device

Behavior of SANE backend breakage:
- the old device is visible, but scanning doesn't work because the backend cannot claim the device

The possible solutions are:

- redesign ipp-usb to don't claim the USB port by default, but only when there is communication to do - this would let the old setup working
- (future when print drivers go away) remove old print queues by some daemon/script


- prepare a migrate path right now, which will remove the old print queue once IPP-over-USB is connected (IPP Get Printers -> check model name in device-uri attribute and compare with model from libusb).
- SANE backends will need to have quirks functionality, which will stop advertising the broken devices

Currently I would prefer point A) and I'm discussing the issue with upstream.

Comment 1 Zdenek Dohnal 2022-04-06 11:43:10 UTC

The issue affects any installation with ipp-usb (ipp-usb is in repos since Fedora 32) - version: rawhide is just a placeholder.

Comment 2 Kamil Páral 2022-04-06 13:32:28 UTC
This was originally accepted as a blocker bug, in bug 2066528, and in this blocker discussion:

However, since then, ipp-usb dependency was removed in F36:
> https://bodhi.fedoraproject.org/updates/FEDORA-2022-7f4925bd0a
> https://bodhi.fedoraproject.org/updates/FEDORA-2022-5eac55ee86

These two updates are now stable, and I verified that Fedora-Workstation-Live-x86_64-36-20220406.n.0.iso doesn't contain ipp-usb, nor ipp-usb gets installed if you update an F36 Beta installation. So the blocker status is now removed.

Comment 3 Ben Cotton 2022-08-09 13:14:40 UTC
This bug appears to have been reported against 'rawhide' during the Fedora Linux 37 development cycle.
Changing version to 37.

Comment 4 Zdenek Dohnal 2023-06-12 07:31:39 UTC
We discussed this upstream as part of https://github.com/OpenPrinting/ipp-usb/issues/50 .

The final result is that ipp-usb won't change this behavior to prevent possible firmware issues in the printers. The behavior is explained and workaround is presented at https://docs.fedoraproject.org/en-US/quick-docs/cups-known-issues/#_usb_printerscanner_doesnt_work_due_a_conflict_on_usb_port and https://fedoraproject.org/wiki/Changes/IPPUSBasPrintScanDependency .

Note You need to log in before you can comment on or make changes to this bug.