[Printing-architecture] How to add IPP over USB printer support to Linux?
James Cloos
cloos at jhcloos.com
Tue Feb 25 22:37:06 UTC 2014
>>>>> "MS" == Michael Sweet <msweet at 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 at jhcloos.com> OpenPGP: 1024D/ED7DAEA6
More information about the Printing-architecture
mailing list