Changes/IPPUSBasPrintScanDependency

Comments and Explanations
The page source contains comments providing guidance to fill out each section. They are invisible when viewing this page. To read it, choose the "view source" link.
Copy the source to a new page before making changes! DO NOT EDIT THIS TEMPLATE FOR YOUR CHANGE PROPOSAL.

Guidance
For details on how to fill out this form, see the documentation.

Report issues
To report an issue with this template, file an issue in the pgm_docs repo.

IPP-USB as a weak dependency of CUPS and sane-airscan

This is a proposed Change for Fedora Linux.
This document represents a proposed Change. As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee.

Summary

Add ipp-usb as a weak dependency of packages which provide support for driverless printing (cups) and driverless scanning (sane-airscan) for USB devices capable of using driverless functionality (how to find out whether your USB device is driverless here), so such devices will work without a specific driver. ipp-usb design conflicts with the way how drivers work with the device, so a user intervention is required after upgrade.

Owner

• Name: Zdenek Dohnal
• Email: zdohnal@redhat.com

Current status

• Targeted release: Fedora Linux 38
• Last updated: 2023-01-10
• FESCo issue: <will be assigned by the Wrangler>
• Tracker bug: <will be assigned by the Wrangler>
• Release notes tracker: <will be assigned by the Wrangler>

Detailed Description

Nowadays most printers and scanners from common vendors provide a way how to work without a specific driver. This way relies on driverless standards implemented in device's firmware and their support in the operating system user has. At first (in 2010) network driverless standards were implemented in devices and widely spread, such as AirPrint, IPP Everywhere for printers or eSCL (sometimes called AirScan) and WSD (Windows Service Discovery) for scanners. Those network driverless standards and others are already supported in cups (for printing) and sane-airscan packages. Two years later USB devices got their own driverless standard - IPP over USB - which is now implemented by ipp-usb.

The ipp-usb package contains ipp-usb daemon, which works as an HTTP proxy over the claimed USB devices, provides printing (via IPP 2.0+ protocol), scanning (via eSCL and WSD) and fax (via IPP Faxout) support and advertises them on localhost by mDNS protocol. mDNS is the key feature for automatic printer discovery, but it is not required to used it - the virtual device provided by ipp-usb can be accessed by URI ipp://localhost:60000/ipp/print and the URI can be used for permanent queue installation - here is the manual. Once ipp-usb is in place and has claimed the driverless USB device, CUPS and sane-airscan can pick up the virtual device shared by the daemon and then they communicate with it via network driverless protocols.

As mentioned above, the ipp-usb daemon claims the USB interface of the device which supports IPP over USB standard. This behavior conflicts with the previous driver approach, where the discovery mechanism only scans USB ports for available devices, but doesn't try to claim the device, which is unavailable because ipp-usb has claimed it already. The result is the device can be discovered by classic driver tools, but it won't work once user wants to print or scan. In such cases user intervention is needed, where user has to make a decision whether to use driverless USB printing or classic printing with drivers. The way how to do it will be explained later in this proposal.

As the last resort for opt-out from driverless USB printing the ipp-usb package will be added as a weak dependency of cups and sane-airscan, so it can be uninstalled without losing the rest of the printing and scanning stack.

Feedback

I've investigated possible solutions for two biggest concerns which adding ipp-usb has raised and consulted it upstream:

1. The current design of claiming the interface of IPP-over-USB device and not releasing it until ipp-usb daemon stops and whether it can be changed - I talked with upstream about it at upstream issue - the reason for it is to prevent potential race conditions/bugs in device's firmware, which is sometimes flaky and updates are not coming to it in regular manner, due combined access for printing or scanning.

2. The design makes impact to an existing setups as well, so the upgrade path has to be taken into consideration - this was mentioned in the upstream ticket too. Based on the following expectations regarding devices:

- might have firmware bugs - might have lesser functionality than classic driver

and the expectations above differ from device to device, we can't automatically prefer one solution over the other at the moment and user manual intervention after upgrade is needed.

This feature will explain how to create a quirk for the ipp-usb daemon to ignore the device or disable them in classic drivers to reduce this conflict.

Benefit to Fedora

Modern USB devices will work out of the box without a specific driver, so users don't need to install a driver or the device at all.

Scope

• Proposal owners:

The proposal owner will add Recommends: ipp-usb to cups and sane-airscan packages and rebuild them. The owner will update Fedora Quick Docs with the manual how to create the ipp-usb quirk and how to disable the device in classic drivers if possible.

• Other developers:

• Release engineering: #Releng issue number

• Policies and guidelines: N/A (not needed for this Change)

• Trademark approval: N/A (not needed for this Change)

• Alignment with Objectives:

Contingency Plan

• Contingency mechanism: (What to do? Who will do it?) N/A (not a System Wide Change)
• Contingency deadline: N/A (not a System Wide Change)
• Blocks release? N/A (not a System Wide Change), Yes/No

Documentation

N/A (not a System Wide Change)