HPLIP, HPLIP.conf and ipp-usb

[debiantriage]

This does not concern an issue with ipp-usb. It may be of interest to users and developers but I wouldn't be surprised should it be closed as needing no action.

A user required help to print with an HP Smart Tank 5100 Series. He had installed upstream's HPLIP 3.23.5. I do not do HPLIP with a modern device, so asked for outputs from avahi-browse and driverless. These outputs were empty. I was taken aback.

The user provided

scott@all-in-one:/var/log/cups$ sudo ipp-usb check
[sudo] password for scott:
IPP over USB devices:
Num Device Vndr:Prod Model

1. Bus 003 Device 004 03f0:5054 "HP Smart Tank 5100 series"

ipp-usb knows the printer exists but avaahi-browse doesn't. Puzzling.

The user looked at the ipp-usb logs:

In "main.log", I see that every few seconds it spits out 2 lines very much like the following:
28-06-2023 12:01:58: + PNP Bus 003 Device 004: retry
28-06-2023 12:01:58: ! PNP Bus 003 Device 004: Device is blacklisted

and

28-06-2023 12:08:28: Device quirks:
28-06-2023 12:08:28: from [HP*] (/usr/share/ipp-usb/quirks/HPLIP.conf:1)
28-06-2023 12:08:28: blacklist = true

HPLIP.conf is a file proved by HPLIP. It effectively kills ipp-usb by blacklisting all HP debices. How smart is that?

[alexpevzner]

Wow! We are being recognized by the whole Hewlett-Packard company!

Well, we probably could add a whitelist option which overrides blacklist...

[zdohnal]

Well, that's why I highly recommend that if you turn to OS forums/portals, use the packages from your OS if they are available.
I guess every distro removes that config file (I do it at least during packaging and I didn't find it in Ubuntu either, but I didn't look too deep), so that's the best we can do. I would not recommend whitelisting a blacklist in upstream code (if it wasn't sarcasm :) ).

To sum it up, if you install project from a different source than OS repos, you have to know what are you doing and if something doesn't work, ask that source for help.

[alexpevzner]

I have converted this issue into discussion, because it doesn't contain any bug report or feature request...

[mikhailnov]

We in ROSA will probably also blacklist ipp-usb for all HP printers because of problems like https://bugzilla.rosalinux.ru/show_bug.cgi?id=13422
Some HP printers stop working via not ipp (via hplip) when ipp-usb is in action, some do work, but scanners in them do not work without hplip.

[zdohnal]

Every non-ipp+classic driver installed print queues will stop working, if the connected printer supports IPP-over-USB and ipp-usb is installed, started and the model is not rejected. This is an expected behavior of ipp-usb, implemented to prevent firmware bugs in printers (we can't count on USB interface in the printer to be proof for several parallel communications, which can switch between each other...).
However, if the device works with ipp-usb and then sufficient (from user's POV) functionality is shown via CUPS (for printing and faxout) and sane-airscan/sane-escl (for scanning), IMHO user can remove the old print queue and ignore other scanner device.

In general I'm against adding a generic rule like this in my package - if some part of service (printing/scanning) does not work, first it would be great to check the printer settings, if some functionality is only disabled and not broken, before adding a reject rule. And if the device is really broken, user should report it to the vendor (if the vendor claims to support AirPrint or other driverless standard - user with the printer has higher change to get support than a simple maintainer) and a maintainer should send PR with reject rule here, mentioning the exact model, which is broken.

But that's just my 2 cents. I wouldn't like to impose one solution to a user, but let them decide which one they want to use (depending on their needs and either way the old print queues will go away, sooner or later, so people sticking with non-ipp queues will have to migrate to printer applications).

[mikhailnov]

Every non-ipp+classic driver installed print queues will stop working, if the connected printer supports IPP-over-USB and ipp-usb is installed, started and the model is not rejected.

Maybe system-config-printer should blacklist the printer in ipp-usb if it is added via non-IPP?

Will sane-airscan work if the printer is configured via non-ipp, but scannijng and printing is not done at the same time?

The problem is that:

• many printers in the wild do not support IPP (more than 50% of printers, I believe)
• system-config-printer-udev does not try to automatically configure printers which declare support of ipp-usb
• users open system-config-printer and try to add the printer in it. A non-ipp variant is shown on the first place, the ipp variant is hidden under network variants
• so most people add a non-IPP variant
• and then this printer does not work, but an IPP-enabled duplicate is shown in the list of printers and works

[mikhailnov]

What I am thinking about doing in ROSA distro out of the box is the following:

• blacklist all HP and Pantum devices in ipp-usb (unfortunately it is not possible to address every specific model ((
• somehow make them automatically configurable by system-config-printer-udev despite declared support of ipp-usb

[alexpevzner]

Some HP printers stop working via not ipp (via hplip) when ipp-usb is in action, some do work, but scanners in them do not work without hplip.

I've seen some reports about HP printers (and not only HP) which expose less features when working driverlessly in comparison with proprietary drivers (for example, less resolutions, less image quality controls), but not working scanned on the ipp-usb-capable device is the really rare story.

Can you demonstrate such a device?

In general, I still believe, that ipp-usb enables much more devices that disables (though it may be not very comfortable for user, if his or her device stops working after system upgrade). So as for me, the best solution would be to enable ipp-usb on new OS installations and keep existing configuration during upgrade.

[mikhailnov]

Can you demonstrate such a device?

My colleague does not own this device, but will try to find out its model.