Re: [Printing-architecture] Removal of features in CUPS

[Till Kamppeter <till.kamppeter@gmail.com>]

On 02/03/2012 05:32 PM, Michael Sweet wrote:
>
> We continue to develop and support the USB backend, although my personal
> development time is (unfortunately) quite limited. I will be integrating
> Till's libusb 1.0 patch in the near future, so at least the current
> functionality will be usable with both the old and new libusb.
>
> For bidirectional printing support, we need to adopt the method used for
> the Darwin/OS X USB backend where there is a separate read thread that
> just does a bulk-in every 200ms. That provides good latency for drivers
> that need it while avoiding the performance hit for printers that just
> return a copy of their 1284 Device ID with status info every time.
>
> Depending on my time constraints and whether libusb 1.0 has the
> necessary support (I think so, but it has been a while since I looked),
> we may be able to get bidi support in CUPS 1.6. The big hurdle was
> moving to libusb 1.0, and Till has already done that work.

As mentioned, I have done the port of the USB backend from libusb 0.1.x 
to libusb 1.0.x (http://www.cups.org/str.php?L3477, scheduled for CUPS 
1.6). It was no problem to do this port. libusb 1.0.x contains all 
needed functions. The new libusb-1.0.x-based backend performs as well as 
the old one not better, not worse, but is now backed by a fully 
upstream-supported library.

Now I am thinking about adding bi-di support to the USB backend. My 
first approach was using the new asynchronous API of libusb 1.0.x, doing 
something similar to the usbmuxd (this is a daemon for Linux to 
communicate with iOS devices on USB), but comparing the complexity of 
usbmuxd compared to the Darwin version of the USB CUPS backend 
(backend/usb-darwin.c) I am tending to do the approach of three threads, 
generated by libpthread: Job transport, back channel and side channel, 
including the reading of the back-channel of the device being done only 
every 200ms and the reading only ebding several seconds after the job 
transport has finished, to assure to get all the printer's answers and 
the printer getting back into its initial state for the next job.

Using the libpthread approach will also make the libusb-based backend 
very similar to the Darwin backend, which should make maintenance of 
CUPS easier.

Mike, what do you think about that?

I am working on this to get this done before Ubuntu's Feature Freeze on 
Feb 16, as in Oneiric (11.10) we have lost the USB bi-di feature by 
deprecating the usblp kernel module, causing bugs with several 
closed-source manufacturer-supplied drivers.

    Till