Bug 2072448

Summary: 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
Product: [Fedora] Fedora Reporter: Zdenek Dohnal <zdohnal>
Component: golang-github-openprinting-ipp-usbAssignee: Zdenek Dohnal <zdohnal>
Status: CLOSED NOTABUG QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 37CC: kparal, mcatanza, zdohnal
Target Milestone: ---Keywords: CommonBugs
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard: https://ask.fedoraproject.org/t/common-issues/20975
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2023-06-12 07:31:39 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

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:

A)
- 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

or

B)
- 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 
Note:

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:
https://pagure.io/fedora-qa/blocker-review/issue/696

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 .