[Printing-architecture] Removal of features in CUPS
Till Kamppeter
till.kamppeter at gmail.com
Tue Feb 7 18:07:49 UTC 2012
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
More information about the Printing-architecture
mailing list