ipp-usb compatibility issues with existing/future software in distributions

[zdohnal]

To ease up using ipp-usb in the system by default, we should try to tackle and track issues which other apps have if ipp-usb is on system.

There are:

1. any classic USB printer backends (CUPS usb, hplip hp, gutenprint gutenprint53+usb and more proprietary ones) list the device even if its interface is claimed by ipp-usb, which means the newly installed printer won't work, even if the device was advertised by the backend
2. any printer applications list the device even if it claimed by ipp-usb, thus unavailable
3. any already installed USB printers from the past which interface is now claimed by ipp-usb don't work - aka migration solution
4. there is duplicity in the scanner's list, if the scanner/multifunction device is supported by ipp-usb and by a classic driver, but the classic driver won't work because ipp-usb claims the device's interface.

Ad 1.

• CUPS tracks the issue - usb backend will check mDNS comm and if the found device is on mDNS, ignore this device in usb backend
• the similar solution can be done in other open source driver packages - probably gutenprint will be a possible candidate because it has responsive upstream

Ad 2.

• we can get the similar fix as for CUPS issue - I created a new issue for PAPPL https://github.com/michaelrsweet/pappl/issues/211

Ad 3.

• already being covered in https://github.com/OpenPrinting/ipp-usb/issues/50

Ad 4.

• I've reported the issue to SANE project, proposing the CUPS solution. I mentioned an idea for ipp-usb writing a file with claimed devices in /tmp, and function in SANE library, libusb_scan_devices() will read it and ignore devices mentioned there
• issue https://gitlab.com/sane-project/backends/-/issues/603

[zdohnal]

@debiantriage

AFAIK there are two ways right now how to find out whether a scanner device is under control of ipp-usb:

• check mDNS communication via Avahi for our device
• try to claim USB interface and if it fails, we know ipp-usb holds it

The former can be implemented in sanei_usb_find_devices(), which can cover backends which uses the library function (some big backends - pixma, genesys - use it), however the change needs sane-backends starting to require Avahi as a whole (now only escl requires and pixma can require Avahi).

The latter has disadvantages which Mike mentions at https://github.com/OpenPrinting/ipp-usb/issues/28#issuecomment-828392483 .

The approach you mentioned - check whether ipp-usb claimed the device (you can have ipp-usb running even without any ipp-over-usb device if you run it in standalone mode or you can have more devices where one is ipp-over-usb and other not) and then disable non-driverless backends - I'm not sure whether it can work with current SANE design. sane-backends currently doesn't implement disabling backends per device, only for a whole system - so in case you have two scanners, one driverless and other non-driverless - you will see only the driverless one.

I've checked sane-backends' code further - we can add some generic function which omitts driverless scanners in classic backends into libusb_scan_devices() function.