ipp-usb 0.9.29

Hi,

ipp-usb version 0.9.29 is now available.

This release addresses issues #64, #32, and #83 and introduces several 
enhancements and bug fixes.

1. Performance Tuning After Receiving 0-Length USB Packets

When a 0-length packet is received, there is a high probability that 
subsequent attempts to receive a packet from USB will return 
immediately, also yielding 0-length packets. To prevent excessive CPU 
usage, ipp-usb introduces pauses upon receiving zero-length USB packets 
and employs an exponential backoff algorithm to manage wait intervals.

The algorithm's parameters have been fine-tuned to avoid performance 
degradation when working with high-end devices capable of transmitting 
large volumes of data at high speeds.

2. Fixed Crash in ipp-usb status Command (PR #85)

A crash occurring when executing the ipp-usb status command has been 
resolved.

3. Added TCP Port Information to Status Output (PR #86)

The status output now includes TCP port information:

   $ ./ipp-usb status
   ipp-usb daemon: running
   ipp-usb devices:
    Num  Device              Vndr:Prod  Port  Model
      1. Bus 001 Device 039  04a9:1912  60100 "Canon LiDE 400" status: OK

4. USB Serial Number and Vendor/Device ID Exposed via TXT Record

The following parameters have been added to the TXT record published by 
ipp-usb:

     usb_SER=VCF9192281 ; Device serial number
     usb_HWID=0482&069d ; Vendor and device ID

This change affects the _ipp._tcp, _printer._tcp, and _uscan._tcp 
services. The _http._tcp service remains unchanged.

This enhancement facilitates matching devices exposed via ipp-usb with 
those detected on the local USB bus.

5. Refactored Quirks Handling

The internal implementation of quirks has been significantly refactored 
to simplify code maintenance and streamline the addition of new quirks. 
This change does not alter the syntax or semantics of existing quirks.

6. Revisited Device Initialization Timeout Handling

When a new device is added, ipp-usb performs multiple HTTP requests 
(IPP/eSCL) to retrieve device parameters for DNS-SD advertising. 
Previously, the entire initialization process was governed by a single 
timeout, which disproportionately affected different requests in the 
sequence. Additionally, fetching unnecessary response bodies was not 
subject to a timeout, potentially causing ipp-usb to indefinitely hold a 
failed USB interface and prevent a clean shutdown (see #32 for details).

The updated implementation introduces individual timeouts for each HTTP 
request during initialization, including a timeout for body reception.

7. Added Alternative Syntax for Delays in Quirks

Delays (e.g., init-delay, request-delay, ...) can now be specified using 
the following syntax:

    init-delay = 15s

This syntax is more convenient, especially for delays longer than a few 
seconds. The old syntax remains supported.

8. Added 'init-timeout' Quirk

This quirk defines a timeout for HTTP requests sent by ipp-usb to a 
device during initialization.

9. Added 'zlp-send' Quirk

When enabled, this quirk sets the LIBUSB_TRANSFER_ADD_ZERO_PACKET flag 
on each outgoing transfer. This causes libusb to terminate outgoing 
transfers that are a multiple of the endpoint's packet size with an 
extra zero-length packet.

Note: No known devices currently require this quirk. It has been added 
for completeness.

10. Added 'zlp-recv-hack' Quirk

Some enterprise-level HP devices, during their initialization phase 
(which can last several minutes), may respond with an HTTP 503 status or 
similar. While this is expected, the response body may be truncated 
(often missing the terminating \n). In such cases, ipp-usb would wait 
indefinitely for a response to maintain synchronization with the device.

These devices also send a zero-length UDP packet at the end of the 
truncated output. When the zlp-recv-hack quirk is enabled, ipp-usb 
interprets the combination of a zero-length packet followed by a receive 
timeout as a valid termination of the response body. This quirk only 
applies during initialization and does not affect subsequent operations.

11. Added 'init-retry-partial' Quirk

When enabled, this quirk retries device initialization if only part of 
the device's functions (e.g., only the printer or only the scanner) have 
been initialized, rather than continuing with incomplete functionality.

This is particularly useful for devices that take a long time to fully 
initialize. During this period, some components may respond normally 
while others are still initializing. For example, a device may quickly 
report its scanning capabilities shortly after startup, while its 
printing functionality may take several minutes to become operational.

Some enterprise-level HP printers are known to exhibit this behavior.

12. Fixed Initialization for HP Color LaserJet Flow X677 and HP Color 
LaserJet FlowMFP M578

With the help of the newly added quirks, initialization issues for the 
HP Color LaserJet Flow X677 and HP Color LaserJet FlowMFP M578 have been 
resolved.

This release brings significant improvements to performance, stability, 
and usability, ensuring better compatibility with a wide range of devices.

-- 

	Wishes, Alexander Pevzner ([email protected])