[Printing-architecture] PAPPL 1.2rc1

[Printing-architecture] PAPPL 1.2rc1

[Michael Sweet]

[-- Attachment #1: Type: text/plain, Size: 1147 bytes --]

PAPPL v1.2rc1 is now available for download from:

    https://github.com/michaelrsweet/pappl/releases/tag/v1.2rc1

PAPPL v1.2 adds full localization, support for additional IPP features, and some other improvements.  Changes in 1.2rc1 include:

- Added explicit support for running macOS printer applications as a server.
- Added unit test support for the new SNMP-based supply level and status monitoring code.
- Updated USB gadget code to not enable gadget until system is started or USB options are set.
- Updated default spool directory to use a persistent, per-user location.
- Fixed DNS-SD advertising when adding a printer from the web interface.
- Fixed double "Supplies" buttons in the web interface.
- Fixed human-readable location fields in web interfaces.
- Fixed an issue with the default system callback for `papplMainloop`.
- Fixed an issue with `papplDeviceList` and DNS-SD discovery when there was no active system.
- Fixed printer compatibility issues with the new `papplDeviceGetSupplies` API.
- Fixed some locking issues with the macOS menubar icon.

Enjoy!

________________________
Michael Sweet




[-- Attachment #2: Message signed with OpenPGP --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [Printing-architecture] PAPPL 1.2rc1 (Supply levels)

[Till Kamppeter]

On 04/05/2022 02:49, Michael Sweet via Printing-architecture wrote:
> PAPPL v1.2rc1 is now available for download from:

[...]

> - Added unit test support for the new SNMP-based supply level and status monitoring code.

[...]

> - Fixed double "Supplies" buttons in the web interface.

[...]

> - Fixed printer compatibility issues with the new `papplDeviceGetSupplies` API.

[...]

Is there any documentation/example for how to get a "Supplies" button 
(or permanent display on printer page) to display the supply levels 
obtained from the printer via SNMP? I would like to add such 
functionality to pappl-retrofit.

    Till

Re: [Printing-architecture] PAPPL 1.2rc1 (Supply levels)

[Michael Sweet]

[-- Attachment #1: Type: text/plain, Size: 926 bytes --]

Till,

You need to set the "have_supplies" member of the pappl_pr_driver_data_t structure to 'true'.


> On May 15, 2022, at 9:47 AM, Till Kamppeter <till.kamppeter@gmail.com> wrote:
> 
> On 04/05/2022 02:49, Michael Sweet via Printing-architecture wrote:
>> PAPPL v1.2rc1 is now available for download from:
> 
> [...]
> 
>> - Added unit test support for the new SNMP-based supply level and status monitoring code.
> 
> [...]
> 
>> - Fixed double "Supplies" buttons in the web interface.
> 
> [...]
> 
>> - Fixed printer compatibility issues with the new `papplDeviceGetSupplies` API.
> 
> [...]
> 
> Is there any documentation/example for how to get a "Supplies" button (or permanent display on printer page) to display the supply levels obtained from the printer via SNMP? I would like to add such functionality to pappl-retrofit.
> 
>   Till
> 

________________________
Michael Sweet




[-- Attachment #2: Message signed with OpenPGP --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [Printing-architecture] PAPPL 1.2rc1 (Supply levels)

[Till Kamppeter]

On 15/05/2022 15:53, Michael Sweet wrote:
> Till,
> 
> You need to set the "have_supplies" member of the pappl_pr_driver_data_t structure to 'true'.

Can I do this simply generally for all printers, regardless whether they 
actually support the reporting of supply levels via SNMP and then the 
ones which support it report the levels and with the others nothing bad 
will happen? Or do I need to somehow find out during printer setup 
whether the printer supports it or not? For example by some entry in the 
PPD or querying the printer somehow?

    Till

Re: [Printing-architecture] PAPPL 1.2rc1 (Supply levels)

[Michael Sweet]

[-- Attachment #1: Type: text/plain, Size: 830 bytes --]

Till,

You can set it unconditionally; ideally I'd at least look at the device URI and only do it for network printers.

> On May 15, 2022, at 10:43 AM, Till Kamppeter <till.kamppeter@gmail.com> wrote:
> 
> On 15/05/2022 15:53, Michael Sweet wrote:
>> Till,
>> You need to set the "have_supplies" member of the pappl_pr_driver_data_t structure to 'true'.
> 
> Can I do this simply generally for all printers, regardless whether they actually support the reporting of supply levels via SNMP and then the ones which support it report the levels and with the others nothing bad will happen? Or do I need to somehow find out during printer setup whether the printer supports it or not? For example by some entry in the PPD or querying the printer somehow?
> 
>   Till
> 

________________________
Michael Sweet




[-- Attachment #2: Message signed with OpenPGP --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [Printing-architecture] PAPPL 1.2rc1 (Supply levels)

[Till Kamppeter]

On 15/05/2022 17:30, Michael Sweet wrote:
> Till,
> 
> You can set it unconditionally; ideally I'd at least look at the device URI and only do it for network printers.
> 

Set it unconditionally in pappl-retrofit, file 
pappl-retrofit/pappl-retrofit.c:

----------
--- a/pappl-retrofit/pappl-retrofit.c

+++ b/pappl-retrofit/pappl-retrofit.c

@@ -1785,7 +1785,7 @@ pr_driver_setup(

      driver_data->ppm_color = 0;



    // Properties not supported by the PPD

-  driver_data->has_supplies = false;

+  driver_data->has_supplies = true;

    driver_data->input_face_up = false;



    // Pages face-up or face-down in output bin?

----------

Now I get a "Supplies" button for each network printer setup.

But clicking it does not show any ink levels, only a gauge as it would 
appear above the ink level diagram (when comparing to what I see in the 
test app of PAPPL where the ink levels are totally artificial).

Printer is the HP OfficeJet Pro 8730.

Can it be that the printer does not supply sufficient info? How can I do 
a simple test on the printer?

system-config-printer (Right-click printer icon in main window -> 
Properties -> Ink/Toner Levels) displays the ink levels correctly (and I 
assume this uses some mechanism of CUPS).

GNOME Control Center (Printers) does not show the ink levels of this 
printer.

    Till

Re: [Printing-architecture] PAPPL 1.2rc1 (Supply levels)

[Michael Sweet]

[-- Attachment #1: Type: text/plain, Size: 1199 bytes --]

Till,

> On May 15, 2022, at 2:57 PM, Till Kamppeter <till.kamppeter@gmail.com> wrote:
> 
> On 15/05/2022 17:30, Michael Sweet wrote:
>> Till,
>> You can set it unconditionally; ideally I'd at least look at the device URI and only do it for network printers.
> 
> Set it unconditionally in pappl-retrofit, file pappl-retrofit/pappl-retrofit.c:
> ...
> Now I get a "Supplies" button for each network printer setup.
> 
> But clicking it does not show any ink levels, only a gauge as it would appear above the ink level diagram (when comparing to what I see in the test app of PAPPL where the ink levels are totally artificial).
> 
> Printer is the HP OfficeJet Pro 8730.
> 
> Can it be that the printer does not supply sufficient info? How can I do a simple test on the printer?

The "testpappl" program provided with PAPPL can be used to test the SNMP stuff:

    git clone https://github.com/michaelrsweet/pappl.git
    cd pappl
    ./configure
    make
    testsuite/testpappl --get-id socket://IP-ADDRESS
    testsuite/testpappl --get-status socket://IP-ADDRESS
    testsuite/testpappl --get-supplies socket://IP-ADDRESS

________________________
Michael Sweet




[-- Attachment #2: Message signed with OpenPGP --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [Printing-architecture] PAPPL 1.2rc1 (Supply levels)

[Till Kamppeter]

Seems that ink level query on my printer is supported:

----------
$ testsuite/testpappl --get-id socket://192.168.68.101

MFG:HP;MDL:HP OfficeJet Pro 8730;

$ testsuite/testpappl --get-status socket://192.168.68.101

none

$ testsuite/testpappl --get-supplies socket://192.168.68.101

                       cyan ink HP N9H71A: 54% (ink, cyan)

                    magenta ink HP N9H75A: 58% (ink, magenta)

                     yellow ink HP N9H79A: 60% (ink, yellow)

                      black ink HP N9H83A: 79% (ink, black)

$
----------

What else could go wrong here?

I have tested with the original network backends (schemes, devices) of 
PAPPL, both the one with DNS-Sd discovery and the one with SNMP 
discovery, and even with them I get only the gauge.

    Till


On 15/05/2022 21:37, Michael Sweet wrote:
> 
> The "testpappl" program provided with PAPPL can be used to test the SNMP stuff:
> 
>      git clone https://github.com/michaelrsweet/pappl.git
>      cd pappl
>      ./configure
>      make
>      testsuite/testpappl --get-id socket://IP-ADDRESS
>      testsuite/testpappl --get-status socket://IP-ADDRESS
>      testsuite/testpappl --get-supplies socket://IP-ADDRESS
> 

Re: [Printing-architecture] PAPPL 1.2rc1 (Supply levels)

[Michael Sweet]

[-- Attachment #1: Type: text/plain, Size: 1503 bytes --]

Till,

Try the dnssd and snmp URIs with these commands and post the results.


> On May 15, 2022, at 3:46 PM, Till Kamppeter <till.kamppeter@gmail.com> wrote:
> 
> Seems that ink level query on my printer is supported:
> 
> ----------
> $ testsuite/testpappl --get-id socket://192.168.68.101
> 
> MFG:HP;MDL:HP OfficeJet Pro 8730;
> 
> $ testsuite/testpappl --get-status socket://192.168.68.101
> 
> none
> 
> $ testsuite/testpappl --get-supplies socket://192.168.68.101
> 
>                      cyan ink HP N9H71A: 54% (ink, cyan)
> 
>                   magenta ink HP N9H75A: 58% (ink, magenta)
> 
>                    yellow ink HP N9H79A: 60% (ink, yellow)
> 
>                     black ink HP N9H83A: 79% (ink, black)
> 
> $
> ----------
> 
> What else could go wrong here?
> 
> I have tested with the original network backends (schemes, devices) of PAPPL, both the one with DNS-Sd discovery and the one with SNMP discovery, and even with them I get only the gauge.
> 
>   Till
> 
> 
> On 15/05/2022 21:37, Michael Sweet wrote:
>> The "testpappl" program provided with PAPPL can be used to test the SNMP stuff:
>>     git clone https://github.com/michaelrsweet/pappl.git
>>     cd pappl
>>     ./configure
>>     make
>>     testsuite/testpappl --get-id socket://IP-ADDRESS
>>     testsuite/testpappl --get-status socket://IP-ADDRESS
>>     testsuite/testpappl --get-supplies socket://IP-ADDRESS
> 

________________________
Michael Sweet




[-- Attachment #2: Message signed with OpenPGP --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [Printing-architecture] PAPPL 1.2rc1 (Supply levels)

[Till Kamppeter]

SNMP:
----------
$ testsuite/testpappl --get-id snmp://HP5B78A3

MFG:HP;MDL:HP OfficeJet Pro 8730;

$ testsuite/testpappl --get-status snmp://HP5B78A3

none

$ testsuite/testpappl --get-supplies snmp://HP5B78A3

                       cyan ink HP N9H71A: 54% (ink, cyan)

                    magenta ink HP N9H75A: 58% (ink, magenta)

                     yellow ink HP N9H79A: 60% (ink, yellow)

                      black ink HP N9H83A: 79% (ink, black)

$
----------

DNS-SD:
----------
$ testsuite/testpappl --get-id 
dnssd://HP%5C032OfficeJet%5C032Pro%5C0328730%5C032%5C0915B78A3%5C093._pdl-datastream._tcp.local/

MFG:HP;MDL:HP OfficeJet Pro 8730;

$ testsuite/testpappl --get-status 
dnssd://HP%5C032OfficeJet%5C032Pro%5C0328730%5C032%5C0915B78A3%5C093._pdl-datastream._tcp.local/

none

$ testsuite/testpappl --get-supplies 
dnssd://HP%5C032OfficeJet%5C032Pro%5C0328730%5C032%5C0915B78A3%5C093._pdl-datastream._tcp.local/

                       cyan ink HP N9H71A: 54% (ink, cyan)

                    magenta ink HP N9H75A: 58% (ink, magenta)

                     yellow ink HP N9H79A: 60% (ink, yellow)

                      black ink HP N9H83A: 79% (ink, black)

$
----------

The answers with the SNMP URI take some seconds, with the DNS-SD URI 
they are instantaneous.

    Till


On 15/05/2022 23:22, Michael Sweet wrote:
> Till,
> 
> Try the dnssd and snmp URIs with these commands and post the results.
> 
> 
>> On May 15, 2022, at 3:46 PM, Till Kamppeter <till.kamppeter@gmail.com> wrote:
>>
>> Seems that ink level query on my printer is supported:
>>
>> ----------
>> $ testsuite/testpappl --get-id socket://192.168.68.101
>>
>> MFG:HP;MDL:HP OfficeJet Pro 8730;
>>
>> $ testsuite/testpappl --get-status socket://192.168.68.101
>>
>> none
>>
>> $ testsuite/testpappl --get-supplies socket://192.168.68.101
>>
>>                       cyan ink HP N9H71A: 54% (ink, cyan)
>>
>>                    magenta ink HP N9H75A: 58% (ink, magenta)
>>
>>                     yellow ink HP N9H79A: 60% (ink, yellow)
>>
>>                      black ink HP N9H83A: 79% (ink, black)
>>
>> $
>> ----------
>>
>> What else could go wrong here?
>>
>> I have tested with the original network backends (schemes, devices) of PAPPL, both the one with DNS-Sd discovery and the one with SNMP discovery, and even with them I get only the gauge.
>>
>>    Till
>>
>>
>> On 15/05/2022 21:37, Michael Sweet wrote:
>>> The "testpappl" program provided with PAPPL can be used to test the SNMP stuff:
>>>      git clone https://github.com/michaelrsweet/pappl.git
>>>      cd pappl
>>>      ./configure
>>>      make
>>>      testsuite/testpappl --get-id socket://IP-ADDRESS
>>>      testsuite/testpappl --get-status socket://IP-ADDRESS
>>>      testsuite/testpappl --get-supplies socket://IP-ADDRESS
>>
> 
> ________________________
> Michael Sweet
> 
> 
> 

Re: [Printing-architecture] PAPPL 1.2rc1 (Supply levels)

[Michael Sweet]

[-- Attachment #1: Type: text/plain, Size: 418 bytes --]

Till,

> On May 15, 2022, at 5:47 PM, Till Kamppeter <till.kamppeter@gmail.com> wrote:
> ...
> The answers with the SNMP URI take some seconds, with the DNS-SD URI they are instantaneous.

That's to be expected - SNMP name resolution is slow... :/

Have you implemented the status callback or added a call to papplDeviceGetSupplies anywhere in ps-printer-app?

________________________
Michael Sweet




[-- Attachment #2: Message signed with OpenPGP --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [Printing-architecture] PAPPL 1.2rc1 (Supply levels)

[Till Kamppeter]

On 16/05/2022 00:31, Michael Sweet wrote:
> Till,
> 
>> On May 15, 2022, at 5:47 PM, Till Kamppeter <till.kamppeter@gmail.com> wrote:
>> ...
>> The answers with the SNMP URI take some seconds, with the DNS-SD URI they are instantaneous.
> 
> That's to be expected - SNMP name resolution is slow... :/
> 
> Have you implemented the status callback or added a call to papplDeviceGetSupplies anywhere in ps-printer-app?
> 

I have a status callback, but without papplDeviceGetSupplies() call. How 
do I call it in this case. As only example I see the code for 
"--get-supplies" in testsuite/testpappl.c. But how does the array with 
the output make it into the web interface page?

    Till

Re: [Printing-architecture] PAPPL 1.2rc1 (Supply levels)

[Michael Sweet]

[-- Attachment #1: Type: text/plain, Size: 1332 bytes --]

Till,

The status callback is called as needed, so you basically need to open the printer device, query, and set the supplies from the response.  Look at the "pcl_status" code in my hp-printer-app for a complete example:

    https://github.com/michaelrsweet/hp-printer-app

You don't need the "dummy" sample values I include in hp-printer-app (it is still mostly sample code, even if people are apparently using it :) - if you don't get a response, just don't set the supplies.

> On May 16, 2022, at 3:05 AM, Till Kamppeter <till.kamppeter@gmail.com> wrote:
> 
> 
> 
> On 16/05/2022 00:31, Michael Sweet wrote:
>> Till,
>>> On May 15, 2022, at 5:47 PM, Till Kamppeter <till.kamppeter@gmail.com> wrote:
>>> ...
>>> The answers with the SNMP URI take some seconds, with the DNS-SD URI they are instantaneous.
>> That's to be expected - SNMP name resolution is slow... :/
>> Have you implemented the status callback or added a call to papplDeviceGetSupplies anywhere in ps-printer-app?
> 
> I have a status callback, but without papplDeviceGetSupplies() call. How do I call it in this case. As only example I see the code for "--get-supplies" in testsuite/testpappl.c. But how does the array with the output make it into the web interface page?
> 
>   Till
> 

________________________
Michael Sweet




[-- Attachment #2: Message signed with OpenPGP --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [Printing-architecture] PAPPL 1.2rc1 (Supply levels)

[James Cloos]

>>>>> "MS" == Michael Sweet via Printing-architecture <printing-architecture@lists.linux-foundation.org> writes:

MS> The "testpappl" program provided with PAPPL can be used to test the SNMP stuff:

MS>     git clone https://github.com/michaelrsweet/pappl.git
MS>     cd pappl
MS>     ./configure
MS>     make
MS>     testsuite/testpappl --get-id socket://IP-ADDRESS
MS>     testsuite/testpappl --get-status socket://IP-ADDRESS
MS>     testsuite/testpappl --get-supplies socket://IP-ADDRESS

i wanted to check that out with my printers.

it worked well for socket: on one of my boxen, but on my main
workstation i got:

Compiling printer-webif.c...
printer-webif.c: In function '_papplPrinterWebCancelAllJobs':
printer-webif.c:64:42: error: 'HTTP_STATUS_FOUND' undeclared (first use in this function); did you mean 'HTTP_STATUS_GONE'?
   64 |       papplClientRespondRedirect(client, HTTP_STATUS_FOUND, path);
      |                                          ^~~~~~~~~~~~~~~~~
      |                                          HTTP_STATUS_GONE
printer-webif.c:64:42: note: each undeclared identifier is reported only once for each function it appears in
printer-webif.c: In function '_papplPrinterWebCancelJob':
printer-webif.c:169:44: error: 'HTTP_STATUS_FOUND' undeclared (first use in this function); did you mean 'HTTP_STATUS_GONE'?
  169 |         papplClientRespondRedirect(client, HTTP_STATUS_FOUND, path);
      |                                            ^~~~~~~~~~~~~~~~~
      |                                            HTTP_STATUS_GONE
printer-webif.c: In function '_papplPrinterWebDelete':
printer-webif.c:784:42: error: 'HTTP_STATUS_FOUND' undeclared (first use in this function); did you mean 'HTTP_STATUS_GONE'?
  784 |       papplClientRespondRedirect(client, HTTP_STATUS_FOUND, "/");
      |                                          ^~~~~~~~~~~~~~~~~
      |                                          HTTP_STATUS_GONE
printer-webif.c: In function '_papplPrinterWebReprintJob':
printer-webif.c:1414:50: error: 'HTTP_STATUS_FOUND' undeclared (first use in this function); did you mean 'HTTP_STATUS_GONE'?
 1414 |               papplClientRespondRedirect(client, HTTP_STATUS_FOUND, path);
      |                                                  ^~~~~~~~~~~~~~~~~
      |                                                  HTTP_STATUS_GONE
make[1]: *** [../Makedefs:75: printer-webif.o] Error 1
make: *** [Makefile:28: all] Error 1


make -k showed a number of similar issues in other files.

obviously some dependency is too old; where does HTTP_STATUS_FOUND come
from?

in any case it looks like configure fail to notice that said dep is too
old.

-JimC
-- 
James Cloos <cloos@jhcloos.com>         OpenPGP: 0x997A9F17ED7DAEA6

Re: [Printing-architecture] PAPPL 1.2rc1 (Supply levels)

[Michael Sweet]

[-- Attachment #1: Type: text/plain, Size: 3088 bytes --]

James,

What version of CUPS do you have on that system?  The change from HTTP_STATUS_REDIRECT_TEMPORARILY to HTTP_STATUS_FOUND happened back in 2017 (so CUPS 2.2/2.3 timeframe), so I might need to add some conditional code to still support the old name since I'm using the new name to avoid future breakage (current CUPS has a define from the old name to the new one...)  The hunan readable name changed when they updated the HTTP RFCs, and we *do* try to keep those in sync for sanity's sake... :(

A Github issue would be appreciated so that I don't forget this... :)

	https://github.com/michaelrsweet/pappl/issues

Thanks!


> On May 16, 2022, at 10:35 AM, James Cloos <cloos@jhcloos.com> wrote:
> ...
> it worked well for socket: on one of my boxen, but on my main
> workstation i got:
> 
> Compiling printer-webif.c...
> printer-webif.c: In function '_papplPrinterWebCancelAllJobs':
> printer-webif.c:64:42: error: 'HTTP_STATUS_FOUND' undeclared (first use in this function); did you mean 'HTTP_STATUS_GONE'?
>   64 |       papplClientRespondRedirect(client, HTTP_STATUS_FOUND, path);
>      |                                          ^~~~~~~~~~~~~~~~~
>      |                                          HTTP_STATUS_GONE
> printer-webif.c:64:42: note: each undeclared identifier is reported only once for each function it appears in
> printer-webif.c: In function '_papplPrinterWebCancelJob':
> printer-webif.c:169:44: error: 'HTTP_STATUS_FOUND' undeclared (first use in this function); did you mean 'HTTP_STATUS_GONE'?
>  169 |         papplClientRespondRedirect(client, HTTP_STATUS_FOUND, path);
>      |                                            ^~~~~~~~~~~~~~~~~
>      |                                            HTTP_STATUS_GONE
> printer-webif.c: In function '_papplPrinterWebDelete':
> printer-webif.c:784:42: error: 'HTTP_STATUS_FOUND' undeclared (first use in this function); did you mean 'HTTP_STATUS_GONE'?
>  784 |       papplClientRespondRedirect(client, HTTP_STATUS_FOUND, "/");
>      |                                          ^~~~~~~~~~~~~~~~~
>      |                                          HTTP_STATUS_GONE
> printer-webif.c: In function '_papplPrinterWebReprintJob':
> printer-webif.c:1414:50: error: 'HTTP_STATUS_FOUND' undeclared (first use in this function); did you mean 'HTTP_STATUS_GONE'?
> 1414 |               papplClientRespondRedirect(client, HTTP_STATUS_FOUND, path);
>      |                                                  ^~~~~~~~~~~~~~~~~
>      |                                                  HTTP_STATUS_GONE
> make[1]: *** [../Makedefs:75: printer-webif.o] Error 1
> make: *** [Makefile:28: all] Error 1
> 
> 
> make -k showed a number of similar issues in other files.
> 
> obviously some dependency is too old; where does HTTP_STATUS_FOUND come
> from?
> 
> in any case it looks like configure fail to notice that said dep is too
> old.
> 
> -JimC
> --
> James Cloos <cloos@jhcloos.com>         OpenPGP: 0x997A9F17ED7DAEA6
> 
> 

________________________
Michael Sweet




[-- Attachment #2: Message signed with OpenPGP --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [Printing-architecture] PAPPL 1.2rc1 (Supply levels)

[Till Kamppeter]

On 16/05/2022 16:35, Michael Sweet wrote:
> Till,
> 
> The status callback is called as needed, so you basically need to open the printer device, query, and set the supplies from the response.  Look at the "pcl_status" code in my hp-printer-app for a complete example:
> 
>      https://github.com/michaelrsweet/hp-printer-app
> 
> You don't need the "dummy" sample values I include in hp-printer-app (it is still mostly sample code, even if people are apparently using it :) - if you don't get a response, just don't set the supplies.
> 

Perfect, that is what I was looking for. I will apply it to 
pappl-retrofit soon.

Thank you very much.

    Till

Re: [Printing-architecture] PAPPL 1.2rc1 (Supply levels)

[James Cloos]

the failing box still had 2.2.6 on it.

i'm in the process of trying to update that, but a simple emerge cups
failed.....

-JimC
-- 
James Cloos <cloos@jhcloos.com>         OpenPGP: 0x997A9F17ED7DAEA6

Re: [Printing-architecture] PAPPL 1.2rc1 (Supply levels)

[Michael Sweet]

[-- Attachment #1: Type: text/plain, Size: 542 bytes --]

James,

It looks like the change was made in CUPS 2.2.7 to use the new name.  I've pushed a workaround to the PAPPL repository - please let me know whether that fixes things for you.


> On May 16, 2022, at 1:13 PM, James Cloos <cloos@jhcloos.com> wrote:
> 
> the failing box still had 2.2.6 on it.
> 
> i'm in the process of trying to update that, but a simple emerge cups
> failed.....
> 
> -JimC
> --
> James Cloos <cloos@jhcloos.com>         OpenPGP: 0x997A9F17ED7DAEA6
> 

________________________
Michael Sweet




[-- Attachment #2: Message signed with OpenPGP --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [Printing-architecture] PAPPL 1.2rc1 (Supply levels)

[Till Kamppeter]

Thank you very much, Mike!

It works now!

I have done the same implementation as with hp-printer-app in 
pappl-retrofit now and I get supply levels! At least if I use one of 
PAPPLs own backends (and not embedded CUPS backends) and network printers.

Later on I will see how to do it with the CUPS backends (they are custom 
scheme "cups:", any hints welcome) and also whether one can use 
hp-levels of HPLIP in the HPLIP Printer Application so that there one 
can also get supply levels of USB printers.

https://github.com/OpenPrinting/pappl-retrofit/commit/f5ba4229ddb

    Till

On 16/05/2022 16:35, Michael Sweet wrote:
> Till,
> 
> The status callback is called as needed, so you basically need to open the printer device, query, and set the supplies from the response.  Look at the "pcl_status" code in my hp-printer-app for a complete example:
> 
>      https://github.com/michaelrsweet/hp-printer-app
> 
> You don't need the "dummy" sample values I include in hp-printer-app (it is still mostly sample code, even if people are apparently using it :) - if you don't get a response, just don't set the supplies.
> 

Re: [Printing-architecture] PAPPL 1.2rc1 (Supply levels)

[James Cloos]

>>>>> "MS" == Michael Sweet via Printing-architecture <printing-architecture@lists.linux-foundation.org> writes:

MS> It looks like the change was made in CUPS 2.2.7 to use the new name.
MS> I've pushed a workaround to the PAPPL repository - please let me know
MS> whether that fixes things for you.

cups 2.4.0_pre refused to emergem but 2.3.3_p2-r3 succeeded.

before that, there was still another failure due to the older cups.

but pappl compiles fine with 2.3.3_p2-r3 installed.

on all of the boxen snmp:// fails even though socket:// uses snmp to get
its data.

strace shoes that it succeeds in gettig snmp date, but it prints
nothing.

the strace output ends with:

recvfrom(3, "00\2\1\0\4\6public\242#\2\1\4\2\1\0\2\1\0000\0300\26\6\20+\6\1\4\1\225\v\1\2\1\3\1\1\6\1\1\2\2\2\3", 1472, 0, {sa_family=AF_INET, sin_port=htons(161), sin_addr=inet_addr("192.168.1.5")}, [256 => 16]) = 50
pselect6(4, [3], NULL, NULL, {tv_sec=2, tv_nsec=0}, NULL) = 1 (in [3], left {tv_sec=1, tv_nsec=990743222})
recvfrom(3, "0+\2\1\0\4\6public\242\36\2\1\4\2\1\2\2\1\0010\0230\21\6\r+\6\1\4\1\205+\6\3\1\4\21\0\5\0", 1472, 0, {sa_family=AF_INET, sin_port=htons(161), sin_addr=inet_addr("192.168.1.5")}, [256 => 16]) = 45
pselect6(4, [3], NULL, NULL, {tv_sec=2, tv_nsec=0}, NULL) = 0 (Timeout)
pselect6(4, [3], NULL, NULL, {tv_sec=2, tv_nsec=0}, NULL) = 0 (Timeout)
close(3)                                = 0
exit_group(1)                           = ?
+++ exited with 1 +++

(that trace is from my magicolor.  my cheap inkjet shows a similar end.)

-JimC
-- 
James Cloos <cloos@jhcloos.com>         OpenPGP: 0x997A9F17ED7DAEA6

Re: [Printing-architecture] PAPPL 1.2rc1 (Supply levels)

[Michael Sweet]

[-- Attachment #1: Type: text/plain, Size: 2452 bytes --]

James,

So "socket://ip-or-hostname" works but "snmp://name" doesn't?

Can you send me (privately) a wireshark or tcpdump capture showing the runs?  The SNMP "backend" in PAPPL is using the Host MIB to find the named printer and use the response address as the printer's local IP address.  It is a pitiful backup to DNS-SD and mDNS discovery, but a somewhat necessary one given that certain popular label printers from a vendor whose name starts with the last letter of the alphabet doesn't implement mDNS nor do they provide an easy way to configure a static IP for their network interfaces... :(



> On May 16, 2022, at 4:02 PM, James Cloos <cloos@jhcloos.com> wrote:
> 
>>>>>> "MS" == Michael Sweet via Printing-architecture <printing-architecture@lists.linux-foundation.org> writes:
> 
> MS> It looks like the change was made in CUPS 2.2.7 to use the new name.
> MS> I've pushed a workaround to the PAPPL repository - please let me know
> MS> whether that fixes things for you.
> 
> cups 2.4.0_pre refused to emergem but 2.3.3_p2-r3 succeeded.
> 
> before that, there was still another failure due to the older cups.
> 
> but pappl compiles fine with 2.3.3_p2-r3 installed.
> 
> on all of the boxen snmp:// fails even though socket:// uses snmp to get
> its data.
> 
> strace shoes that it succeeds in gettig snmp date, but it prints
> nothing.
> 
> the strace output ends with:
> 
> recvfrom(3, "00\2\1\0\4\6public\242#\2\1\4\2\1\0\2\1\0000\0300\26\6\20+\6\1\4\1\225\v\1\2\1\3\1\1\6\1\1\2\2\2\3", 1472, 0, {sa_family=AF_INET, sin_port=htons(161), sin_addr=inet_addr("192.168.1.5")}, [256 => 16]) = 50
> pselect6(4, [3], NULL, NULL, {tv_sec=2, tv_nsec=0}, NULL) = 1 (in [3], left {tv_sec=1, tv_nsec=990743222})
> recvfrom(3, "0+\2\1\0\4\6public\242\36\2\1\4\2\1\2\2\1\0010\0230\21\6\r+\6\1\4\1\205+\6\3\1\4\21\0\5\0", 1472, 0, {sa_family=AF_INET, sin_port=htons(161), sin_addr=inet_addr("192.168.1.5")}, [256 => 16]) = 45
> pselect6(4, [3], NULL, NULL, {tv_sec=2, tv_nsec=0}, NULL) = 0 (Timeout)
> pselect6(4, [3], NULL, NULL, {tv_sec=2, tv_nsec=0}, NULL) = 0 (Timeout)
> close(3)                                = 0
> exit_group(1)                           = ?
> +++ exited with 1 +++
> 
> (that trace is from my magicolor.  my cheap inkjet shows a similar end.)
> 
> -JimC
> --
> James Cloos <cloos@jhcloos.com>         OpenPGP: 0x997A9F17ED7DAEA6
> 

________________________
Michael Sweet




[-- Attachment #2: Message signed with OpenPGP --]
[-- Type: application/pgp-signature, Size: 833 bytes --]