[Printing-architecture] Automatic printer setup with Printer Applications

Wed Feb 24 08:03:57 UTC 2021

Hi Till!

On 2/23/21 8:27 PM, Till Kamppeter wrote:
> Hi,
>
> one important feature for a good user experience with printing is the
> automatic setup of printers. at least locally connected (USB) printers
> either when they get plugged in and turned on or when their Printer
> Application gets installed and started.
>
> The user expects this behavior, as in the current Linux distributions
> which use classic printer drivers consisting of PPD files and filters
> the locally connected printers also get their CUPS queue set up
> automatically and we do not want to loose this functionality when
> switching over to Printer Applications.
Totally agree.
>
> The first though here is to let the Printer Application, which is
> running as daemon observe the system for USB printers appearing or
> diappearing. This can be done using the hotplug functionality of
> libusb or with a UDEV monitor based on libudev (installing a UDEV
> rules file to make UDEV trigger a command execution does not work out
> of a Snap or other sandboxed packages).

Ok, I did a quick search, udev rules don't work because /sys is a
read-only in Snap?

Then a service/daemon looks like a only way. Printer applications will
run as a service and udev-configure-printer is run as a service already,
but the udev rules must be removed and we need to add libusb/libudev
functionality into udev-configure-printer, if we are going to use it.

Do I understand it correctly?

> As soon as a new device appears the Printer Application would check
> whether it is supported by it and if so, create a print queue.
>
> A proposed implementation is discussed as a Pull Request for the
> Printer Application support library PAPPL:
>
> https://github.com/michaelrsweet/pappl/pull/36
>
> There see especially my comment
>
> https://github.com/michaelrsweet/pappl/pull/36#issuecomment-783533960
>
> The main problem of this approach is that there can be many Printer
> Applications installed, especially with a desktop Linux distribution
> which should support as many different models of hardware as possible
> and therefore has practically all drivers available as free software
> installed. Once a new printer plugged in every Printer Application
> checks whether it supports it. Depending on how they do this this can
> cause a load peak for the system and also for the printer (if the
> Printer Application has to do additional queries on the decision
> whether the printer is supported).

It just got on my mind (probably it will be nonsense) - what about
having only one printer application as a front door and a communication
point with other stuff in the system, and the other driver specific
stuff will be as a module, which could be loaded by one main printer
application, which would do the registering in MDNS and communication
with USB, so hammering USB ports could be prevented.

Even users can be happy that they don't need to install
'foomatic-printerapp' for this printer, 'hplip-printerapp' for other
printer, and they can just install 'generic-printerapp' and if they
don't care about installing all drivers (iiuc our CUPS snap integrates
all drivers anyway...) the modules will be installed via weak deps. Who
cares about minimization, he can install without weak deps and find out
which module supports his printer.

I just got this thought because I'm thinking more about systemd
nowadays, so it would be kind of systemd-version for printing apps.

>
> So we need to do one or more of the following:
>
> - Use the lowest impact method to observe device appearing and
> disappering. Is it libusb's hotplug or libudev's monitor?
>
> - Lowest impact determining whether the appearing printer is
> supported, ideally letting the libusb/libudev process already grab the
> device ID and then run this device ID through PAPPL's auto-add
> callback function (this is the function with which each driver checks
> whether a printer is supported).
>
> - Configurability of Printer Applications to turn off auto-setup and
> to blacklist selected printers, to avoid that there are more that one
> queues because a printer is supported by several Printer Applications.
>
> - Reduce the number of Printer Applications which come with a Linux
> distribution by creating only one Printer Application which retro-fits
> all legacy printer drivers which are not maintained any more.
>
> On a Debian or Ubuntu distribution you find all available printer
> drivers with the command line
>
> apt search printer-driver | grep '^printer-driver-' | grep -v
> printer-driver-all | grep -v -- -common/ | cut -d / -f 1 | sed -e
> s/^printer-driver-//
>
> which results in
>
> brlaser
> c2050
> c2esp
> cjet
> cups-pdf
> dymo
> escpr
> foo2zjs
> fujixerox
> gutenprint
> hpcups
> hpijs
> indexbraille
> m2300w
> min12xxw
> oki
> pnm2ppa
> postscript-hp
> ptouch
> pxljr
> sag-gdi
> splix
>
> Take out hpcups, hpijs and postscript-hp and replace them by hplip.
> Also take out cups-pdf. Then we have 19 drivers and in addition we
> have foomatic which supports all built-in drivers of Ghostscript.
> Looking through the list there are many which are not maintained
> upstream any more: c2050, c2esp, cjet, m2300w, min12xxw, pnm2ppa,
> pxljr, sag-gdi, splix (and perhaps even more). They can all get joined
> into the Foomatic Printer Application, so we end up with a maximum of
> 11 Printer Applications. One needs to find out whether the impact of
> all of them on an appearing USB printer is too high or not.
>
> An alternative approach would be to have a separate, external program
> to auto-setup printers instead of each Printer Application doing it
> individually, as we have currently /lib/udev/udev-configure-printer
> (part of system-config-printer) to auto-create CUPS queues with
> classic printer drivers. This program identifies the printer and
> assigns a driver supporting it, using a priority scheme if there is
> more than one suitable driver. One could proceed similarly for Printer
> Applications or even extend /lib/udev/udev-configure-printer for
> Printer Application support. This would especially also assure that
> only one print queue gets set up, independent of how many Printer
> Applications support the printer.
>
> WDYT?
>
> Should we take the centralized approach? Or should we let the Printer
> Applications do the auto setup individually?
If the one big printer application system+modules is a complete
nonsense, I would go with at least putting all dead drivers into
foomatic printer application, and then update udev-configure-printer to
use libusb/libudev for checking USB device, and if found any, it will
contact a printer application via PAPPL API or (probably rather, it
looks like it is more popular) via DBUS message.
>
> Should we use libusb's hotplug approach or libudev's UDEV monitor
> approach to get notified of appearing and disappearing printers?
I would prefer libusb - IMO libudev is closer to HW, which IIUC is not
needed here, so libusb looks fine for us.
>
> Any other thoughts?
>
>    Till
>
-- 
Zdenek Dohnal
Software Engineer
Red Hat Czech - Brno TPB-C

-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 495 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/printing-architecture/attachments/20210224/00371b5c/attachment.sig>