Description of problem: Setting up a networked HP all-in-one printer using settings in Gnome Shell is easy but left the ability to use the scanner feature when using the dnssd for uri rather than hp:\ protocol. I don't know if the case also applies to other desktop environments. Version-Release number of selected component (if applicable): 1.7.5-5 How reproducible: Always Steps to Reproduce: 1. Set up a networked HP all-in-work printer 2. 3. Actual results: Only the printer part works. simple-scan failed to detect networked scanner part. Expected results: All functions work as intended without manual intervention Additional info: CUPS uses dnssd for detecting a networked printer. It recognized a networked all-in-one printer then assign the correct uri, in this example, hp:/net/Photosmart_eStn_C510_series?ip=192.168.1.67 . It seems dnssd cannot use hp:/ protocol.
*** Bug 1150319 has been marked as a duplicate of this bug. ***
Policy about which device URI to use for a queue comes from system-config-printer. (In reply to Luya Tshimbalanga from comment #0) > It seems dnssd cannot use hp:/ protocol. This isn't quite right. The real issue is that libsane-hpaio only finds queues with hp:/ device URIs. The question remains whether libsane-hpaio should interrogate other backends, or whether system-config-printer should use hp:/ device URIs when applicable (probably the latter). It's a shame that we have to do some special-case handling either way.
(In reply to Tim Waugh from comment #2) > Policy about which device URI to use for a queue comes from > system-config-printer. > The question remains whether libsane-hpaio should interrogate other > backends, or whether system-config-printer should use hp:/ device URIs when > applicable (probably the latter). > > It's a shame that we have to do some special-case handling either way. Thank you for the explanation about the problem related to libsane-hpaio. I don't know if it will be possible to address that to HP themselves.
So, configuring the queue using system-config-printer results in the hp: URI being used, as it already prefers hp: URIs to dnssd: URIs. However, in order to have an hp: URI to compare against it needs to run a special command (hp-makeuri) if it thinks this is an HP printer. This is pretty ridiculous. The correct answer is for HPLIP to perform proper network detection in its backend, or in another backend it provides.
Too bad hplip relies on special command. Is it possible to for it using standard command? Once the fix will come, I am willing to test the network detection for all-in-one printer.
I am reopening this bug because the issue is still present in all version of hplip (including Rawhide) which still uses dnssd rather than hp:/net. Launchpad bugreport remained inactive with no proper patch or fixes :(
This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component.
Fedora 22 changed to end-of-life (EOL) status on 2016-07-19. Fedora 22 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.