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

Michael Sweet msweet at apple.com
Wed Feb 26 01:27:01 UTC 2014


James,

On Feb 25, 2014, at 5:37 PM, James Cloos <cloos at 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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4881 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/printing-architecture/attachments/20140225/9a6e8604/attachment-0001.p7s>


More information about the Printing-architecture mailing list