Add device auto-setup

[JaiLuthra1]

[JaiLuthra1]

@michaelrsweet Can it be something like registering a hotplug callback that runs in the background?

Also, once this callback gets triggered, will we need to do most of the pappl_usb_find stuff?

[michaelrsweet]

@JaiLuthra1 The auto-setup stuff can be run in the main thread, and I would just use the papplDeviceList API to find any new printers. Like I mentioned in a separate email, it would probably make sense to have a function for looking up a printer by its device URI, and then you can add any new USB devices you find (that are supported by the printer application, at least...)

[lgtm-com[bot]]

This pull request introduces 1 alert when merging 5a1aeff7e837c0996c7f493ec48c98229b7ac864 into eee3b631916c764c285db5f49323096ebe692bed - view on LGTM.com

new alerts:

• 1 for Too few arguments to formatting function

[JaiLuthra1]

@michaelrsweet I have done the changes except a couple of things.

1. How do we set the offline state reason?
2. How to call the papplSystemFindPrinterByDeviceURI function?

[michaelrsweet]

@JaiLuthra1 I've added papplPrinterPause and papplPrinterResume functions for stopping and starting a printer, respectively. The corresponding IPP operations (IPP_OP_PAUSE_PRINTER and IPP_OP_RESUME_PRINTER) can be used for doing the same via IPP requests.

I also added a new PAPPL_PREASON_OFFLINE state bit, which you can set with the papplPrinterSetReasons function.

Finally, instead of adding a separate find function, I added the device URI as an argument to papplSystemFindPrinter which already allowed finding by resource path and printer ID. The same functionality can be implemented in the non-server code using an IPP_OP_GET_PRINTERS request and looking at all of the smi2699-device-uri values that come back. Look at the _papplMainloopShowPrinters code for inspiration...

[JaiLuthra1]

@michaelrsweet I have modified the auto-add command. Now, it stays only as long as we have a hotplug event every 30 seconds.

[tillkamppeter]

Ideal would be UDEV for USB if it works out of a Snap ...

[michaelrsweet]

@tillkamppeter As far as I can see from the snapcraft documentation (https://snapcraft.io/docs/hotplug-support), it does not currently support hot-plug for USB printers at all?!?

Moreover, the current command-line interface that supports auto-adding of supported devices still needs to enumerate the USB bus with libusb to find new printers (we can't use udev directly for this...), so it isn't clear how udev is at all important to use in PAPPL itself. Assuming we can configure a snap to run a program in the snap on a hot-plug event (like the existing Linux system level hot-plug support is farmed out), we don't need to use udev at all.

[tillkamppeter]

@tillkamppeter As far as I can see from the snapcraft documentation (https://snapcraft.io/docs/hotplug-support), it does not currently support hot-plug for USB printers at all?!?

Moreover, the current command-line interface that supports auto-adding of supported devices still needs to enumerate the USB bus with libusb to find new printers (we can't use udev directly for this...), so it isn't clear how udev is at all important to use in PAPPL itself. Assuming we can configure a snap to run a program in the snap on a hot-plug event (like the existing Linux system level hot-plug support is farmed out), we don't need to use udev at all.

If our Printer Application Snap plugs the raw-usb (and perhaps hardware-observe) interfaces, could we get some kind of USB hotplug events (does not necessarily be UDEV) to detect newly connected/disconnected printers? Or could we re-check in a loop (every 5s, 10s, 30s, ...)?

Here is also some discussion about USB hotplug and UDEV in the snapcraft forum.

[michaelrsweet]

@tillkamppeter It is possible to monitor for device additions/removals over longer periods of time, and this pull request does have an implementation of that using libusb's hotplug functionality (which is better than polling). I have my reservations about always adding newly connected (USB) printers, both for the obvious security issues but also performance and power issues - imagine having several printer applications all hammering the same USB device to see if it is something they need to add a printer for. Now imagine if that was expanded to include network devices...

That discussion thread doesn't seem particularly relevant in this case - the UDEV rule is just there to set permissions, but a) the printer application snap will likely be a server (which in snap-land means "run as root"...), and b) Linux distributions should probably start looking at making printer USB devices accessible to ordinary users...

[tillkamppeter]

For Printer Applications Linux distributions will not need to make USB devices accessible to ordinary users as, being a daemon/server they run as root anyway.

[lgtm-com[bot]]

This pull request introduces 2 alerts when merging a9c31368132084244af4830b4db163af9e77ca1d into 0787bca434c3ee058c6e91553059cbcf6215f4c6 - view on LGTM.com

new alerts:

• 2 for Local variable hides global variable

[michaelrsweet]

@JaiLuthra1 Sorry, been in crunch time for a customer, will try to review this later today or tomorrow.

[michaelrsweet]

OK, I'm going to spend a little more time reviewing this - the issue for me right now is the papplDeviceMonitor code and how that will interface with the snap/server.

[michaelrsweet]

OK, things have changed a bit since the last update on this PR. I have reworked the first half of this (the autoadd command) and pushed the changes as:

[master 0659ea2] Implement first half of "autoadd" command (Issue #36)

I still need to incorporate the hotplug code for USB and DNS-SD printers (to do the pause/resume bit), and maybe we want to support auto-add of USB printers with hotplug (I have mixed feelings about that...)

[michaelrsweet]

Moving this PR to track the new 1.1 milestone - the remaining tasks are:

• [ ] Auto-add on USB hotplug (as an option)
• [ ] Efficiently tracking the online/offline status of USB and DNS-SD printers and reflecting this in the printer-state-reasons

[tillkamppeter]

A Snap needs to plug hardware-observe and raw-usb for discovering USB printers via UDEV, and it needs to plug network and avahi-control (or avahi-observe?) for discovering printers via DNS-SD. The listening to UDEV is done via libudev, in a separate threa, with a function like monitor_devices(). For this in the Snap there also must be the udevadm package installed.

[tillkamppeter]

Having the PostScript Printer Application in the Snap Store now I am currently looking into the printer auto-setup problem and how we can finish this.

End users expect that if they plug in a USB printer that it is immediately available for use, without need to set it up. All Linux distributions work this way already for several years. Therefore a appreciate a lot if PAPPL supports auto-setup of USB printers. If a Linux distribution does not support the user's USB printer it should be enough for him to install a Printer Application Snap (= printer driver) from the Snap Store and the printer immediately starts to work, without any setup.

The switch to the new architecture should under no circumstances make it more difficult for end user to get printing to work.

One problem with Printer Applications is that a Linux distribution tries to include all free software hardware drivers which are available, to make as much hardware as possible "just work". In case of classic CUPS drivers replaced by Printer Applications one would have very many installed (apt search printer-driver | grep '^printer-driver-' | grep -v printer-driver-all | grep -v -- -common/ | wc -l -> 22) and then each of them would respond to a printer being plugged or unplugged. With classic drivers /lib/udev/udev-configure-printer (of system-config-printer) was the central instance for USB printer auto setup, so there was only one responder for plugging or unplugging a USB printer.

One way to at least partially reduce the number of responders is to wrap all unmaintained printer driver micro projects into the Foomatic/Ghostscript Printer Application instead of creating separate Printer Applications for them.

@tillkamppeter It is possible to monitor for device additions/removals over longer periods of time, and this pull request does have an implementation of that using libusb's hotplug functionality (which is better than polling).

What do you mean with "polling" here?

There are principally three ways to get notified when a USB printer is plugged or unplugged:

1. use libusb's hotplug functionality as @JaiLuthra1 is suggesting in his code.
2. Use a UDEV monitor based on libudev, as @dheeraj135 has used in his pre-PAPPL approach on Printer Applications in GSoC 2019.
3. Install a UDEV rules file which calls a program for the response.

The latter cannot be used in Snaps, so the two former remain to be used for us. Question is which one is more suitable, how much they are a load for the system and for the USB devices in general, how much load is caused when an actual printer (or scanner) is plugged or unplugged, how many false alarms we get (of unsupported, non-printer/scanner devices).

I have my reservations about always adding newly connected (USB) printers, both for the obvious security issues but also performance and power issues - imagine having several printer applications all hammering the same USB device to see if it is something they need to add a printer for. Now imagine if that was expanded to include network devices...

See above.

[michaelrsweet]

Deferring to future milestone.

[michaelrsweet]

OK, I think with current git master (for 1.4) we have enough of this merged to declare victory.