pb with hp laserjet M15

[alphacentauri31]

just installing debian 11 bullseye and every cups package.

printer is well recognized, and well connected (toner info available)

when printing, all seems correct on cups side (finishing with job done, without errors) but nothing on the printer.

trying on other usb ports : same problem.

printer works well with W10

trying to find help on debian forum, but no solution found.

is this printer not compatible with cups ?

thanks

some informations :

ipp-usb check

IPP over USB devices:
Num Device Vndr:Prod Model

1. Bus 002 Device 005 03f0:be2a "HP LaserJet M14-M17"

avahi-browse -rt _ipp._tcp

• enp2s0 IPv4 bbox Ippos Printer Internet Printer local

• lo IPv4 HP LaserJet M15a (B6676D) (USB)               Internet Printer     local
  

= enp2s0 IPv4 bbox Ippos Printer Internet Printer local
hostname = [bbox.local]
address = [192.168.1.254]
port = [631]
txt = []
= lo IPv4 HP LaserJet M15a (B6676D) (USB) Internet Printer local
hostname = [bruno-TOSH.local]
address = [127.0.0.1]
port = [60000]
txt = ["air=none" "mopria-certified=1.3" "rp=ipp/print" "priority=50" "kind=document,envelope,photo" "PaperMax=legal-A4" "UUID=564e4333-4234-3434-3231-c8d9d2b6676d" "Color=F" "Duplex=F" "note=" "qtotal=1" "usb_MDL=HP LaserJet M14-M17" "usb_MFG=HP" "usb_CMD=PJL,PML,PWG_RASTER,URP" "ty=HP LaserJet M14-M17" "product=(HP LaserJet M14-M17)" "pdl=application/PCLm,application/octet-stream" "txtvers=1" "adminurl=http://localhost:60000" "Fax=T" "rfo=ipp/faxout" "Scan=F"]

le log lors de l'envoi d'une page de test... sans aucune sortie sur l'imprimante...

logcupspagetest.txt

[debiantriage]

You are advised to read the Release Notes for Debian 11.

= lo IPv4 HP LaserJet M15a (B6676D) (USB)

This is a USB-only device. It is one of the few I have come across that understands IPP-over-USB. But we also have

pdl=application/PCLm,application/octet-stream

Apple raster is not offered as a pdl. The CUPS PPD generator does not deal with application/PCLm.

From the error_log:

application/vnd.cups-pdf to printer/HP_LaserJet_M15a_B6676D_USB_/application/pdf, cost 0

A PDF is sent to the printer. It does not understand PDF. (it is not in the pdl= line.

trying to find help on debian forum, but no solution found.

If you posted there, please give a link.

[tillkamppeter]

First, CUPS development has moved to OpenPrinting, so do not use this bug tracker at Apple any more but the one of CUPS on OpenPrinting:

https://github.com/OpenPrinting/cups/issues

From there one can also easily move bugs to cups-filters, ipp-usb, ... or any other part of the printing stack when it turns out that the problem is not actually in CUPS.

Your case is something very rare which we did not hit before. As manufacturers want their devices being usable also with smartphones the devices usually accept Apple Raster so that AirPrint works. This is the first one I emcountered which of the 4 driverless IPP data formats (PDF, Apple Raster, PWG Raster, PCLm) only supports PCLm. The fact that the devices usually all understand Apple Raster lead to CUPS development never including PCLm.

Fortunately, cups-filters and Ghostscript actually support PClm. So it should be possible to use this printer. Simply proceed as follows:

Make sure you have ipp-usb installed (you have it already). Then run

driverless

This gives you the URL of your printer.

Do not use -m everywhere (triggers PPD generator of CUPS) for setting up your printer, instead, use the driverless utility to generate the PPD (PPD generator of cups-filters):

lpadmin -p m15a -v 'URI' -E -m driverless:'URI'

For URI insert the URI which you got from the driverless command. Insert it at both places.

Now you have a print queue which should actually work with your printer.

[tillkamppeter]

Note: As CUPS is capable of creating queues based on its own PPD generator completely automatically, as its temporary queues and this actually only works with the subset of driverless IPP printers which support one of the 3 data formats PDF, Apple Raster, and PWG Raster, and not with PCLm-only printers, we should consider the missing PCLm support in CUPS as a bug.

Especially, this legitimately driverless printer requires the user to manually create a print queue and this is a permanent queue whereas usually CUPS auto-generates a temporary queue for driverless IPP printers.

And even worse, this is not supported any more in CUPS 3.x which will drop support for PPD files and permanent queues and only support automatic creation of temporary queues for driverless IPP printers and HP LaserJet M15a is a driverless IPP printer which should just work with CUPS 3.x.

[zdohnal]

And even worse, this is not supported any more in CUPS 3.x which will drop support for PPD files and permanent queues and only support automatic creation of temporary queues for driverless IPP printers and HP LaserJet M15a is a driverless IPP printer which should just work with CUPS 3.x.

AFAIK permanent queues will be available in CUPS Sharing server, so people who want or need to use permanent queues can install this type of server - unless some distributions choose to don't package the sharing server.

According IPP Everywhere 1.1 standard, the driverless device must support image/pwg-raster and (if it is color device) image/jpeg, so strictly speaking, the device in question is not a driverless device by standard. Although it would be great if the PCLm support was in CUPS in the future, but we can have a discussion about it.

[tillkamppeter]

There is not only IPP Everywhere but AFAIK 4 driverless IPP printing standards: AirPrint, IPP Everywhere, Mopria, and Wi-Fi Direct Print. The printer in question does not do AirPrint as it does not support Apple Raster, it does not do IPP Everywhere as it does not support PWG Raster, and it does not do Wi-Fi Direct Print as it is USB-only, perhaps it does Mopria, but I do not know the exact definition of that standard, whether it is good enough for Mopria to only support PCLm.

[zdohnal]

Aha, thanks! I kind of thought Wifi Direct Print and Mopria are contained in AirPrint/IPP Everywhere.

[debiantriage]

An interesting aspect is that the device is an HP LaserJet M15a and does not do wireless. The TXT record has

mopria-certified=1.3

and, AFAIK, Mopria stipulates PCLm and is is intended to to support Android, which is wireless-only.

So, why offer PCLm on a USB-only printer? Amazon have it available on 3 Mar. 2018, so it is not exactly an old device.

[tillkamppeter]

@debiantriage probably HP has several devices which differ only in having wireless or not and to reduce costs they have practically the same firmware (why invent a proprietary PDL for the USB-only version?). For us, Linux users, it is a nice gesture to have a known PDL and a known communication protocol) in a USB-only device and so being able to use it without a driver, with the infrastructure which is already there.

[debiantriage]

@tillkamppeter

My question was partly rhetorical but my main point was that the M15a would be useless to the average Android user. There are very few USB-only printers that offer IPP-over-USB and those I have encountered do offer Apple raster.

Granted, offering PCLm is a nice touch for us, but some consistency in what is offered would be appreciated. It would also be nice if IPP-over-USB capability was mentioned in a vendor's literature.

[alphacentauri31]

hi, thank you for your comments; I'm not an informatician, and my english is not really fluent, but I understand my printer could be not compatible with cups. :-(
i've tried driverless : gives ipp://HP LaserJet 20M15a (B6676D) (USB)._ipp._tcp.local/
but lpadmin -p m15a -v 'URI' -E -m driverless:'URI' gives bash: erreur de syntaxe près du symbole inattendu « ( »

I think the only solution for me is to go back to stretch, or to run W10 on my PC :-( :-(

[debiantriage]

lpadmin -p m15a -v 'URI' -E -m driverless:'URI' gives bash: erreur de syntaxe près du symbole inattendu « ( »

Try double quotes: "URI".

I think the only solution for me is to go back to stretch, or to run W10 on my PC

It is unfortunate you have the printer you have, but we can get it working with CUPS on bullseye. Promise.

[alphacentauri31]

ok, result of the command : lpadmin: Printer drivers are deprecated and will stop working in a future version of CUPS.

when printing he test page, no différence : job completed, but nothing on ther printer :-(

[debiantriage]

ok, result of the command : lpadmin: Printer drivers are deprecated and will stop working in a future version of CUPS.

That's OK.

when printing he test page, no différence : job completed, but nothing on ther printer :-(

I cannot explain that and do not intend to pursue it further. We will move on to another solution. Please give

systemctl status ipp-usb.service

[tillkamppeter]

Could you run

ipptool -tv ipp://localhost:60000/ipp/print get-printer-atrributes.test > attrs.txt

and attach attrs.txt to this bug report?

Could you also run

driverless ipp://localhost:60000/ipp/print > ppd.txt

and attach also here the resulting file to this bug report?

[alphacentauri31]

good news, after rebooting the PC and with the lpadmin command, the test page has been printed and I can print with LO...

I guess I must use this command after each reboot, or write it in a .profile or something like that...

do you still need the report files ?

thank you for your help.

[tillkamppeter]

Please still post the files.

If you reboot again now, does the printer stop printing again and you need to issue the lpadmin command again?

[alphacentauri31]

surprisingly, after a reboot, the printer is still working... :-)

systemctl status ipp-usb.service :

● ipp-usb.service - Daemon for IPP over USB printer support
Loaded: loaded (/lib/systemd/system/ipp-usb.service; static)
Active: active (running) since Fri 2022-02-25 12:31:24 CET; 3min 5s ago
Docs: man:ipp-usb(8)
Main PID: 566 (ipp-usb)
Tasks: 12 (limit: 4470)
Memory: 16.9M
CPU: 190ms
CGroup: /system.slice/ipp-usb.service
└─566 /sbin/ipp-usb udev

the file attrs.txt is empty.

ppd.txt attached
ppd.txt

[tillkamppeter]

@alphacentauri31 thank you. Could you also run the command

ipptool -tv ipp://localhost:60000/ipp/print get-printer-atrributes.test > attrs.txt

and attach attrs.txt to this bug report?

[alphacentauri31]

@tillkamppeter :

the command ipptool -tv ipp://localhost:60000/ipp/print get-printer-atrributes.test > attrs.txt gives no result (empty file)

perhaps you mean ipptool -tv ipp://localhost:60000/ipp/print get-printer-attributes.test > attrs.txt ?
if yes; here is the result
attrs.txt
:

[debiantriage]

@alphacentauri31 As I understand the situation, you have a functioning ipp-usb.service. If you disconnect from USB, it will be shown as inactive. Reconnect and it will be shown as active and you will be able to print with a queue set up with

lpadmin -p m15a -v "URI" -E -m driverless:"URI".

However, your logcupspagetest.txt has made me curious about what originally happened on your Debian system. Do you stll have /etc/cups/ppd/HP_LaserJet_M15a_B6676D_USB_.ppd? If so, please give

grep cupsFilter etc/cups/ppd/HP_LaserJet_M15a_B6676D_USB_.ppd

grep PCFileName etc/cups/ppd/HP_LaserJet_M15a_B6676D_USB_.ppd

[alphacentauri31]

@debiantriage
there is no HP_LaserJet_M15a_B6676D_USB_.ppd file, but, I've this file : HP_LaserJet_M14-M17.ppd
grep cupsFilter etc/cups/ppd/HP_LaserJet_M14-M17.ppd : *cupsFilter: "application/vnd.cups-raster 0 hpcups"
grep PCFileName etc/cups/ppd/HP_LaserJet_M14-M17.ppd : *PCFileName: "hp-laserjet_m14-m17.ppd"

[debiantriage]

@alphacentauri31 Thanks. The PPD is for a queue set up with an HPLIP driver. Perhaps the other PPD was one generated for a CUPS temporary queue. That one disappears after a minute.

I am intrigued by the error log showing

[Job 36] 4 filters for job:
[Job 36] bannertopdf (application/vnd.cups-pdf-banner to application/pdf, cost 32)
[Job 36] pdftopdf (application/pdf to application/vnd.cups-pdf, cost 66)
[Job 36] - (application/vnd.cups-pdf to printer/HP_LaserJet_M15a_B6676D_USB_/applicat
ion/pdf, cost 0)

when PDF is not a pdl for the printer.

[tillkamppeter]

@alphacentauri31 I have found a bug in cups-filters which affects your printer, see this commit. Your PPD does not specify a default resolution for PCLm and the rastertopclm filter cannot cope with that. This I have fixed in cups-filters 2.x with said commit. I will look into backporting this to cups-filters 1.x.

If you are familiar with applying patches and compiling software, you could try out the fix by yourself. If you do so, tell here about your experience.

[tillkamppeter]

@alphacentauri31 I have backported it to cups-filters 1.x now: commit.

Please test.

Or wait for the 1.28.14 release of cups-filters (or Ubuntu 22.04 LTS).

[alphacentauri31]

Thank-you for the information ; I'm with debian, and I'm not comfortable with compiling system software, so I'll wait for the update.