[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#912768: hplip-data: hp-toolbox fsck



On Tue 06 Nov 2018 at 20:47:25 +0100, Till Kamppeter wrote:

> Concerning the scanning, I have done the following observation:
> 
> I have the HP OfficeJet Pro 8730.
> 
> I have removed all print queues using the "hp" CUPS backend (I print with a
> driverless queue). With an HPLIP-based print queue my scanner is always
> found.

I too can set up an HPLIP-based print queue for the 8730:

  lpadmin -p 8730 -v hp:/net/HP_OfficeJet_Pro_8730?ip=192.168.7.238 -E -m drv:///hpcups.drv/hp_officejet_pro_8730.ppd

'scanimage -L' gives

  device `hpaio:/net/HP_OfficeJet_Pro_8730?ip=192.168.7.238' is a Hewlett-Packard Officejet_Pro_8730 all-in-one

I would contend that no discovery over the network is taking place.
HPLIP knows the URI of the printer and simply substitutes "hpaio" for
"hp" to get the scanner URI. It is bound to work unless cupsd is
stopped.

> 1. Printer on the network
> 
> scanimage -L
> 
> does not find the scanner in my MF device, but

I think something similar happens in #879719.

> scanimage -d hpaio:/net/HP_OfficeJet_Pro_8730?ip=w.x.y.z > x.pnm
> 
> scans correctly.
> 
> hp-probe finds the URI:
> 
> hp:/net/HP_OfficeJet_Pro_8730?ip=w.x.y.z

By default hp-probe uses SLP for discovery. What is a little puzzling is
that the specs for the 8730 do not have it as a network protocol. A way
to check for the service is at

  https://wiki.debian.org/PrintQueuesCUPS#hplip.
 
> 2. Printer on USB
> 
> scanimage -L
> 
> finds the scanner with the following URI:
> 
> hpaio:/usb/HP_OfficeJet_Pro_8730?serial=xxxxxxxxxx
> 
> and it scans also when specifying this URI.
> 
> hp-probe finds the URI:
> 
> hp:/usb/HP_OfficeJet_Pro_8730?serial=CN783F60W1
> 
> 
> Now I did some debugging and found out that "scanimage -l" discovers the
> scanner with the URI (device on network, note the "hp_" missing in the model
> name, upper/lower case is ignored by HPLIP):

Is "-l" a typo?
 
> hpaio:/net/officejet_pro_8730?ip=w.x.y.z
> 
> This does not match the model name in
> /usr/share/hplip/data/models/models.dat which is "[hp_officejet_pro_8730]".
> 
> So I did the following change:
> 
> ----------
> --- io/hpmud/model.c~   2018-08-21 17:42:16.000000000 +0200
> +++ io/hpmud/model.c    2018-11-06 17:14:04.302446688 +0100
> @@ -420,7 +420,10 @@
>           strncpy(section, rcbuf+1, sizeof(section)); /* found new section
> */
>           n = strlen(section);
>           section[n-2]=0; /* remove ']' and CR */
> -         if (strcasecmp(model, section) == 0)
> +         if (strcasecmp(model, section) == 0 ||
> +            (section[0] == 'h' && section[1] == 'p' &&
> +             section[2] == '_' &&
> +             strcasecmp(model, section + 3) == 0))
>           {
>              /* Found model match. */
>              *bytes_read = ResolveAttributes(fp, attr, attrSize);
> ----------
> 
> This matches the model names both with and without "hp_" in the beginning.
> 
> Note that I did not yet upload an Ubuntu package of HPLIP with this patch as
> the archive is not yet opened for the disco (19.04) development cycle.
> 
> After applying this change "scanimage -L" discovers also my scanner when
> connected to the network and I can scan from any SANE-based application
> without needing a print queue using the "hp" CUPS backend of HPLIP.
> 
> Cristian, this could solve your scanner problem if the other fixes did not
> solve it yet, please try and report back.
> 
> In general this patch helps for using driverless printing on HP devices as
> long as they are connected by the network. If you do driverless printing via
> USB, with ippusbxd (IPP over USB) scanning does not work while ippusbxd is
> connected to the printer (it is really time that manufacturers start with
> driverless IPP scanning).
> 
> So for USB connection you will still need to print with HPLIP if you want to
> be able to scan.

I will draw attention to LP #1797501 even though it does not appear to
be the same issue.

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

-- 
Brian.


Reply to: