[Printing-architecture] How to add IPP over USB printer support to Linux?

[Printing-architecture] How to add IPP over USB printer support to Linux?

[Ira McDonald]

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

Hi,

After a discussion at today's Open Printing call, Till and Ira suggest that
we
should discuss what steps are necessary to add IPP over USB printer
support to Linux (see Mike's original reply below).

Please send your thoughts and design suggestions in this thread.

Cheers,
- Ira

On Tue, Feb 18, 2014 at 12:45 PM, Michael Sweet <msweet@apple.com> wrote:

> Ira,
>
> Currently there is no support for IPP USB under Linux.
>
> Conceptually it will be possible to support through a separate "proxy"
> daemon that arbitrates access over the USB interfaces provided by the
> printers via a local loopback port - this is what we do on OS X, but there
> remains some architecture work on Linux to wire it up and hide the
> corresponding printers in the standard USB backend.
>
>
> On Feb 18, 2014, at 12:17 PM, Ira McDonald <blueroofmusic@gmail.com>
> wrote:
>
> Hi Mike and Jeff,
>
> There is a recent USB-IF spec for IPP over USB:
>
> http://www.usb.org/developers/devclass_docs/IPP.zip
>
> Does this work in current Linux and CUPS?  Does it need
> (I presume) updates to the default USB driver?
>
> Cheers,
> - Ira
>
> Ira McDonald (Musician / Software Architect)
> Co-Chair - TCG Trusted Mobility Solutions WG
> Chair - Linux Foundation Open Printing WG
> Secretary - IEEE-ISTO Printer Working Group
> Co-Chair - IEEE-ISTO PWG Internet Printing Protocol WG
> IETF Designated Expert - IPP & Printer MIB
> Blue Roof Music / High North Inc
> http://sites.google.com/site/blueroofmusic
> http://sites.google.com/site/highnorthinc
> mailto: blueroofmusic@gmail.com
> Winter  579 Park Place  Saline, MI  48176  734-944-0094
> Summer  PO Box 221  Grand Marais, MI 49839  906-494-2434
>
>
>  _________________________________________________________
> Michael Sweet, Senior Printing System Engineer, PWG Chair
>
>

[-- Attachment #2: Type: text/html, Size: 3934 bytes --]

Re: [Printing-architecture] How to add IPP over USB printer support to Linux?

[James Cloos]

Does it really need a daemon, and not just proto 4 support in cups/backend/usb?

-JimC
--
James Cloos <cloos@jhcloos.com>         OpenPGP: 1024D/ED7DAEA6

Re: [Printing-architecture] How to add IPP over USB printer support to Linux?

[Michael Sweet]

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

James,

Putting it in the USB backend would greatly increase the complexity of that backend without actually enabling things like the embedded web interface of the printer and other IPP and HTTP services offered by these printers over USB.  Also, while the IPP API in libcups can handle alternate IO paths, the HTTP API is tied to sockets, so any implementation inside the USB backend would need to provide its own mini HTTP API to send requests and receive responses over USB.

On OS X we have a launchd service (launch-on-demand) that is setup when a printer is connected and removed when disconnected. This service basically acts as a proxy or gateway between IP connections and the USB interfaces offered by the printer (minimum requirement is 2 interfaces, which looks to be the limit for most printers in the foreseeable future thanks to the SoCs they use...), and the service arbitrates access from multiple IPP/HTTP clients to that limited number of IP interfaces.



On Feb 22, 2014, at 2:12 AM, James Cloos <cloos@jhcloos.com> wrote:

> Does it really need a daemon, and not just proto 4 support in cups/backend/usb?
> 
> -JimC
> --
> James Cloos <cloos@jhcloos.com>         OpenPGP: 1024D/ED7DAEA6

_________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair


[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 4881 bytes --]

Re: [Printing-architecture] How to add IPP over USB printer support to Linux?

[Till Kamppeter]

On 02/24/2014 01:54 PM, Michael Sweet wrote:
> James,
> 
> Putting it in the USB backend would greatly increase the complexity of that backend without actually enabling things like the embedded web interface of the printer and other IPP and HTTP services offered by these printers over USB.  Also, while the IPP API in libcups can handle alternate IO paths, the HTTP API is tied to sockets, so any implementation inside the USB backend would need to provide its own mini HTTP API to send requests and receive responses over USB.
> 
> On OS X we have a launchd service (launch-on-demand) that is setup when a printer is connected and removed when disconnected. This service basically acts as a proxy or gateway between IP connections and the USB interfaces offered by the printer (minimum requirement is 2 interfaces, which looks to be the limit for most printers in the foreseeable future thanks to the SoCs they use...), and the service arbitrates access from multiple IPP/HTTP clients to that limited number of IP interfaces.
> 

Is it already possible to buy an IPP-over-USB printer? If yes, which
model(s)? Would be great if one could by one for an appropriate Linux
kernel developer.

   Till

Re: [Printing-architecture] How to add IPP over USB printer support to Linux?

[Michael Sweet]

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

Till,

On Feb 24, 2014, at 12:53 PM, Till Kamppeter <till.kamppeter@gmail.com> wrote:
> On 02/24/2014 01:54 PM, Michael Sweet wrote:
>> James,
>> 
>> Putting it in the USB backend would greatly increase the complexity of that backend without actually enabling things like the embedded web interface of the printer and other IPP and HTTP services offered by these printers over USB.  Also, while the IPP API in libcups can handle alternate IO paths, the HTTP API is tied to sockets, so any implementation inside the USB backend would need to provide its own mini HTTP API to send requests and receive responses over USB.
>> 
>> On OS X we have a launchd service (launch-on-demand) that is setup when a printer is connected and removed when disconnected. This service basically acts as a proxy or gateway between IP connections and the USB interfaces offered by the printer (minimum requirement is 2 interfaces, which looks to be the limit for most printers in the foreseeable future thanks to the SoCs they use...), and the service arbitrates access from multiple IPP/HTTP clients to that limited number of IP interfaces.
>> 
> 
> Is it already possible to buy an IPP-over-USB printer? If yes, which
> model(s)? Would be great if one could by one for an appropriate Linux
> kernel developer.

I know many of the recent HP OfficeJet and Photosmart printers support it, and others are on the way soon.

_________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair


[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 4881 bytes --]

Re: [Printing-architecture] How to add IPP over USB printer support to Linux?

[James Cloos]

>>>>> "MS" == Michael Sweet <msweet@apple.com> writes:

MS> Putting it in the USB backend would greatly increase the complexity of
MS> that backend without actually enabling things like the embedded web
MS> interface of the printer and other IPP and HTTP services offered by
MS> these printers over USB.

True.  It seemed a reasonable compromise, at least in the short term.

MS> Also, while the IPP API in libcups can
MS> handle alternate IO paths, the HTTP API is tied to sockets, so any
MS> implementation inside the USB backend would need to provide its own
MS> mini HTTP API to send requests and receive responses over USB.

I expect any implementation of the idea would move some of the code from
the http backend into a .c file to be shared with the http and usb backends.

MS> On OS X we have a launchd service (launch-on-demand) that is setup
MS> when a printer is connected and removed when disconnected.

I didn't get from your previous post that it launches on demand (as
opposed to always running, monitoring usb changes, and linking to any
proto 4 print endpoints as they appear).

I agree that that is a good general solution.  I only thought that
adding proto 4 to usb would be a quicker first step.

MS> This service basically acts as a proxy or gateway between IP
MS> connections and the USB interfaces offered by the printer (minimum
MS> requirement is 2 interfaces, which looks to be the limit for most
MS> printers in the foreseeable future thanks to the SoCs they use...),

Interesting.  I see that the spec requires at least two, but wasn't
aware more than two are unlikely in the wild.

MS> and the service arbitrates access from multiple IPP/HTTP clients to
MS> that limited number of IP interfaces.

I don't know about bsd, but with most linux dists udev rules would
enable the start/quit on demand semantic.

I presume libusb provides enough access to the usb protocol upon which
to write such a daemon.

It will need kernel support to show up as a network interface.  Perhaps
the same support the ppp daemons use?  Or tun/tap?

I think you've covered the rest of the requirements.

-JimC
--
James Cloos <cloos@jhcloos.com>         OpenPGP: 1024D/ED7DAEA6

Re: [Printing-architecture] How to add IPP over USB printer support to Linux?

[Michael Sweet]

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

James,

On Feb 25, 2014, at 5:37 PM, James Cloos <cloos@jhcloos.com> wrote:
> ...
> I expect any implementation of the idea would move some of the code from
> the http backend into a .c file to be shared with the http and usb backends.

Please don't.  The HTTP state engine is quite complex and is always getting small bug fixes and improvements. Having a separate copy means you need to track all of those fixes and improvements in your own copy, and speaking from experience we don't want to do that (that's one of the reasons why the Ghostscript and PDF stuff is now maintained in one place rather than us bundling our own copies of those programs in CUPS...)

> MS> On OS X we have a launchd service (launch-on-demand) that is setup
> MS> when a printer is connected and removed when disconnected.
> 
> I didn't get from your previous post that it launches on demand (as
> opposed to always running, monitoring usb changes, and linking to any
> proto 4 print endpoints as they appear).

On OS X there is a process that manages device connect/disconnect (similar to the udev stuff on Linux), and that creates lauunchd "services" that are associated with a given USB printer.  Those jobs are launch on demand (whenever somebody tries to connect to the service on its dedicated port), at which point the ippusbd process manages access to the printer until all clients go away, at which point it exits (after a suitable idle timeout) to let launchd listen for new connections.

> I agree that that is a good general solution.  I only thought that
> adding proto 4 to usb would be a quicker first step.

Unfortunately, it really doesn't buy you much of anything over the existing proto 1/2 support, and it would likely break scanning for MFPs (since the same endpoints get shared between IPP USB and the vendor interfaces for scanning).

> MS> This service basically acts as a proxy or gateway between IP
> MS> connections and the USB interfaces offered by the printer (minimum
> MS> requirement is 2 interfaces, which looks to be the limit for most
> MS> printers in the foreseeable future thanks to the SoCs they use...),
> 
> Interesting.  I see that the spec requires at least two, but wasn't
> aware more than two are unlikely in the wild.

Yes, it basically is a limitation of the SoCs that vendors are using, which typically only support a maximum of 5 endpoints divvied up for the interfaces; each IPP USB interface needs a pair of endpoints (for bulk-in and bulk-out).

> MS> and the service arbitrates access from multiple IPP/HTTP clients to
> MS> that limited number of IP interfaces.
> 
> I don't know about bsd, but with most linux dists udev rules would
> enable the start/quit on demand semantic.

Actually, udev gets you connect/disconnect.  Conceptually you could have a mini-daemon that runs as long as the printer is connected - systemd would allow that to be optimized further so that you don't have the process overhead when the printer is not being used.

> I presume libusb provides enough access to the usb protocol upon which
> to write such a daemon.

Yes.

> It will need kernel support to show up as a network interface.  Perhaps
> the same support the ppp daemons use?  Or tun/tap?

No, you don't need a network interface.  You need to listen for connections on a TCP port, and then proxy the requests and responses to an "idle" IPP USB interface.  So, perhaps you reserve a block of ports from 4000 to 4015 (I have no idea if those are free in practice) and then assign a port to each attached printer.  The IPP backend then just connects to localhost:4000 to print to the first printer, localhost:4001 for the second, etc.

The listen can be on the loopback interface or the "any" address to support simple USB printer sharing through IPP USB.

_________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair


[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 4881 bytes --]