HP Color LaserJet m278-m281 needs plugin for scanning

Could you please also update the page: https://developers.hp.com/hp-linux-imaging-and-printing/supported_devices/index that states that the "HP Color LaserJet Pro MFP M281fdw" does *not* require a driver plug-in. I specifically bought this printer because I did not want proprietary software on my system.

> I specifically bought this printer because I did not
> want proprietary software on my system.

Just in case you ever want to return the MFD on the basis of its capabilities being misrepresented - keep a copy of that web page.

--
Brian.

> The attached patch changes m278-m281 record in
> data/models/models.dat to that it needs plugin
> for scanning.

Dealing with the issue of non-scanning because of the ty= TXT record being truncated and not matching anything in models.dat is bad enough, but having the need for a plugin being sprung on a user is not my idea of fun.

In

  https://bugs.launchpad.net/hplip/+bug/1816226

Peter Schüller managed to get scanning working on the network with the aid of libsane-hpaio. Note

 * He required upgrades to libsane-hpaio and lihpmud0 to accomodate his scanner.
 * Printing was set up as an everywhere queue. I had no intention of debugging an hplip-3.19.1 installation. This means, of course, that the scanner is not available through an hp:/... queue.
 * A SANE frontend is provided with a URI. Not so great for automatic discovery.

The M28-M31 also has the same non-free plugin issue in models.dat.

--
Brian.

I'm still not fully convinced that the plugin is needed for scanning. See https://bugs.launchpad.net/hplip/+bug/1816226 starting by comment 7 and the following comments.

I'm sure how to test and Fedora 29 is still on hplip 3.18.

That was a typo in my previous comment. It should read *not sure*.

I did do a little test. See: https://bugzilla.redhat.com/show_bug.cgi?id=1694663#c31

> The attached patch changes m278-m281 record in
> data/models/models.dat to that it needs plugin
> for scanning.

Upstream need to do more than patch one portion of models.dat. The attached file is for devices using scan-type=5 (SOAPHT). Shouldn't this directive correlate with plugin=1?

  [hp_laserjet_pro_mfp_m127fp]
  plugin=0
  plugin-reason=65
  scan-type=5

A different story is at
https://developers.hp.com/hp-linux-imaging-and-printing/binary_plugin.html

A file for scan-type=9 (ESCL) is also attached.

scantype5 attached.

Jan said:

> I did do a little test.

and at https://bugzilla.redhat.com/show_bug.cgi?id=1694663#c31

went on to say

  > So it looks that indeed bb_soapht.so is required.
  >
  > I moved the plugins back into place:
  > mv /usr/share/hplip/scan/plugins-back/ /usr/share/hplip/scan/plugins

  > And scanning works again.

I am bothered by this "works". How was the scanning carried out?

--
Brian.

Brian, the scanning was carried out from the command line with:

scanimage -v -p -d hpaio:/net/HP_ColorLaserJet_MFP_M278-M281?ip=192.168.178.16 > janscan

Exactly as stated in:

https://bugzilla.redhat.com/show_bug.cgi?id=1694663#c31

For the scan that worked fine (after moving the plug-in back to the correct location) I used the same command to test scanning.

Thank you, Jan. I now understand.

  hpaio:/net/HP_ColorLaserJet_MFP_M278-M281?ip=192.168.178.16

is the correct URI. Using 'xsane' or 'simple-scan' wouldn't work with this device on the network due to

https://bugs.launchpad.net/hplip/+bug/1797501

--
Brian.

Brian, I think the URL issue has also been fixed in hplip-3.18.12-9.fc29.
simple-scan works perfectly fine for me at the moment.

I did another test on a clean (i.e. a system where I did not apply any patches for testing) Fedora 29 with hplip-3.18.12-9.fc29.

Initially, I had not run hp-plugin => simple-scan did not work with the HP M281fdw Color LaserJet scanner. It gave an error message in a popup window: "Failed to scan. Unable to contact scanner."

Then I ran:
# hp-plugin

I tried simple-scan again. It worked flawlessly.

>Upstream need to do more than patch one portion of models.dat. The attached file is for devices using >scan-type=5 (SOAPHT). Shouldn't this directive correlate with plugin=1?
>
> [hp_laserjet_pro_mfp_m127fp]
> plugin=0
> plugin-reason=65
> scan-type=5

IMO scan-type and plugin are correlated like 'some device handlers needs plugin' (so every escl, marvell, orblite, soap, soapht device should need a plugin - so plugin should be 'plugin=1'), but the number in plugin-reason is not correlated to scan-type like you mentioned.
There are constants in base/codes.py, which IMO define plugin-reason numbers (like when you have plugin-reason=64, the record says the device needs plugin for scanning, because it is equal to PLUGIN_REASON_SCANNING_SUPPORT, which is defined as 0x40h).

Ad the other devices you find in models.dat, which have scan-type which should need the plugin (according to my understanding of code) - you are probably right, but we cannot test it for to be sure. And upstream seems to have other issues to attend to, so we cannot ask them neither. So my proposal will be to wait for user/customer with hardware, cooperate with them on testing and fix the issue after that.

Ad URL issue - I backported your patch from Debian (which you mentioned in one of hplip tickets) with mentioning it is Debian patch in spec file. But now when I check the logs, the errors are still there, so I need to work on it further.

Hi Zdohnal,

Thanks for finding the issue. We will incorporated the changes. You can see the changes in the next build.

Thanks,
Umesh

Hello Umesh,

I take it you have read all the information provided in this report. The following is a sampling of devices from models.dat in 3.17.10:

hp_laserjet_pro_mfp_m27c
hp_color_laserjet_pro_mfp_m176n
hp_laserjet_pro_mfp_m128fp
hp_laserjet_pro_mfp_m126nw
hp_laserjet_pro_mfp_m125r

These are designated as "plugin=1". models.dat in 3.19.1 has the designation as "plugin=0".

So - what changes are being incorporated into the next build? A change to a single section in models.dat? No other alterations?

--
Brian.

Shouldn't there be a distinction between for what the plugin is required. For printing, or for scanning? And maybe also for faxing.

For example, printing with the HP Color LaserJet Pro MFP M281fdw works perfectly fine without the plugin. But for scanning the plugin is required.

It should be taken care of in plugin-reason directive (64 means 'needed for scanning')

Each section in models.dat has plugin-reason as an entry. At the end of the file, there is a list of reasons. 64 is scanning. 65 is scanning and printing.

--
Brian.

Earlier brian_p rashly said:

> Using 'xsane' or 'simple-scan' wouldn't work with this
> device on the network due to
>
> https://bugs.launchpad.net/hplip/+bug/1797501

Jan Vlug also categorically said

> Brian, I think the URL issue has also been fixed in
> hplip-3.18.12-9.fc29. simple-scan works perfectly fine
> for me at the moment.

This caused me to reassess the status of #1797501 using the technique described in Mesage #7 at the link above. I had seen no need to have done this before because HPLIP's Release Notes had no mention of the issue having been attended to, and upstream feedback was conspicuously absent. Thank you for the prod, Jan.

It turns out that a partial, unpublicised fix was introduced with HPLIP 3.18.10. The outcome of my testing is in Message #5 at

https://bugs.launchpad.net/hplip/+bug/1824659

My apologies if I have clouded any issue in this bug report, #1822762.

--
Brian.

Hmm... I can still see these cropped models in messages in the logs.

Does this help?

With ty=HP_Laserjet_100_colormfp_M175nw I get these two lines in the journal. HP_ has been cropped, there is an error and the scanner is not found. The HP_ is added back and the scanner is now found. No error now, so only two lines.

scanimage[17408]: io/hpmud/model.c 532: no laserjet_100_colormfp_m175nw attributes found in /usr/share/data/models/models.dat
scanimage[17408]: io/hpmud/model.c 543: no laserjet_100_colormfp_m175nw attributes found in /usr/share/data/models/unreleased.unreleased.dat

Now I make ty=Laserjet_100_colormfp_M175nw. Las is cropped and leads to an error in the journal. Las is not added back but HP_ is. Yet another error is detected. This is why I said it was a partial fix on 3.18.10.

scanimage[17413]: io/hpmud/model.c 532: no erjet_100_colormfp_m175nw attributes found in /usr/share/data/models/models.dat
scanimage[17413]: io/hpmud/model.c 543: no erjet_100_colormfp_m175nw attributes found in /usr/share/data/models/unreleased.unreleased.dat
scanimage[17413]: io/hpmud/model.c 532: no hp_erjet_100_colormfp_m175nw attributes found in /usr/share/data/models/models.dat
scanimage[17413]: io/hpmud/model.c 543: no hp_erjet_100_colormfp_m175nw attributes found in /usr/share/data/models/unreleased.unreleased.dat

Brian,

I track new hplip release at my github since upstream does not have any public versioning system, to track at least changes between releases. https://github.com/zdohnal/hplip

I see a probably relevant change in 3.18.9 in scan/sane/hpaio.c:

@@ -252,7 +255,29 @@ static int AddDevice(char *uri)
     }
     else
     {
- DBG(6,"unsupported scantype=%d %s\n", ma.scantype, uri);
+ // This is added to make the uri hp:/net/hp_model_name?ip-xxx.xxx.xxx.xxx&queue=false
+ // For some of the devices the scan MDL recevied would be model_name instead of hp_model_name
+ len = strlen(uri);
+ strncpy(new_uri, uri, 9);
+ new_uri[8] = 'h';
+ new_uri[9] = 'p';
+ new_uri[10] = '_';
+ for (i = 11,j = 8; j<=len; ++i, ++j)
+ new_uri[i] = uri[j];
+
+ hpmud_query_model(new_uri, &ma);
+ DBG(6,"scantype=%d %s\n", ma.scantype, new_uri);
+
+ if(ma.scantype>0)
+ {
+ hpmud_get_uri_model(new_uri, model, sizeof(model));
+ AddDeviceList(new_uri, model, &DeviceList);
+ device_added = 1;
+ }
+ else
+ {
+ DBG(6,"unsupported scantype=%d %s\n", ma.scantype, new_uri);
+ }
     }

IMO it is that partial fix you talk about - I overlooked it before.