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.
Note: The issue affects any installation with ipp-usb (ipp-usb is in repos since Fedora 32) - version: rawhide is just a placeholder.
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.
This bug appears to have been reported against 'rawhide' during the Fedora Linux 37 development cycle. Changing version to 37.
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 .