PAPPL Scan API Bridging: GSoC 2024 Project Report 🖨️🧑‍💻

Diving Deep into Driverless Scanning: A Journey with PAPPL and eSCL Integration

After contributing to various facets of the Linux ecosystem—one side dealing with high-resource environments, complex memory architectures, and extensive resource demands, and on the other hand, working with real-time operating systems with constrained memory and architectures like Zephyr—it’s thrilling to tackle projects that push the boundaries of what’s possible, especially in driverless tech. Integrating scanning functionalities in Linux through PAPPL has been an intense, rewarding ride that’s still far from over. Here’s a breakdown of the work done, the vision we are working toward, and the nitty-gritty technical strides we are making to ensure a robust, future-proof solution.

Quick Overview of Core Work:

1. Scan API PR in PAPPL: Laying down the framework to make scanning work as seamlessly as printing.
2. PAPPL Retrofit Interface PR: Aiming to replace SANE with a more universal PAPPL interface, moving scanning closer to true driverless operation.
3. Last Year's eSCL Work in GSoC 2023: A deep dive into building groundwork for driverless scanning, covering our approach to sandboxing scanners.

What is PAPPL, and Why Should We Care?

While I have covered PAPPL in past discussions, it’s worth a recap. PAPPL is essentially a framework built for driverless printing, enabling developers to create printer applications that ‘just work.’ Its backbone? The Internet Printing Protocol (IPP), which PAPPL wraps up with robust API functionalities to handle printing jobs driverlessly.

However, PAPPL was initially built with a focus on printers only. In a Linux world where Ubuntu Core Desktop and similar projects are evolving, there's a real need for integrated, dynamic scanning that doesn't rely on SANE. And here’s where driverless scanning via eSCL (the driverless protocol) becomes essential.

Figure 1: An Overview of PAPPL Architecture

Integrating Scanning with PAPPL: The Big Shift

For years, SANE has been the default scanning interface across Linux distros. While reliable, SANE isn’t keeping pace with the shift toward modular, containerized environments. Enter eSCL. An HTTP(S)-based, XML-driven protocol, eSCL is designed for driverless scanning, making it a natural candidate for integration into PAPPL.

You can dig deeper into the MOPRIA eSCL scan specifications if you are interested in the protocol specifics.

Our objective here is straightforward: merge eSCL’s driverless scanning capabilities into PAPPL, thereby marrying MOPRIA eSCL with IPP’s robust, reliable handling. The initial configuration work for this integration began in earnest during my GSoC '23 project.

Breaking Down the Core Work

Our initial approach to integrating scanning into PAPPL revolved around five key issues (#130 to #135). Each tackled a crucial aspect:

• Creating a dedicated Scan API
• Implementing eSCL protocol handling
• Building out a testing suite
• Adding scan-specific commands to the CLI

One exception: Issue #132 was sidelined since IPP endpoints for scanning still aren’t prevalent. Let’s dive into the configured components:

Issue #130: Building the Core of Scanning

• pappl_scanner_t: Mirrors the pappl_printer_t for scanners, with necessary tweaks.
• Job Updates: The pappl_job_t object was updated to handle both print and scan jobs.
• Driver Data Structure: Built pappl_sc_driver_data_t based on pappl_pr_driver_data_t, with callback functions prefixed by pappl_sc_.
• Scanner-specific Headers: New scanner.h for public API access and scanner-private.h for internal workings.
• Core Files:
  • scanner.c: Sets up scanner object creation/destruction.
  • scanner-accessors.c: Provides accessor functions.
  • scanner-driver.c: Lays out driver interfaces and attributes.
  • scanner-webif.c: Scan-specific web pages.
  • job-scan.c: For scan job processing.

Figure 2: Code snippet configuring the enumeration for driver data.

With these, we have configured the foundational API architecture required to support scanning.

Bringing in eSCL and XML Processing

Integrating eSCL was a deep-dive into the MOPRIA specifications. The initial eSCL code resides in esclops and is configured to work independently, though it will eventually sync fully with the Scan API for a seamless experience.

This year’s work builds upon last year’s GSoC project. The mission: to make the Scan API a reliable, core component of PAPPL, mirroring the printing capabilities.

Interface Setup: Enter the DummyDriver

Testing any API is impossible without a viable test environment. For this, we’re leveraging a ‘DummyDriver’ that emulates scanner attributes and interactions in line with the MOPRIA spec files. This setup will help us validate API functionalities before moving to the final Retrofit API phase. Once stable, we will have our first driverless application crafted purely from PAPPL.

Figure 3: Scan driver capabilities for testing the Scan API

Fine-Tuning papplMainLoop for Scanning

Configuring papplMainLoop for dynamic HTTP request handling is ongoing. It’s in review, with tweaks to callback functions being finalized. This boilerplate will be key to flexible, reliable scanning operations.

Work in Progress: The Path Forward

1. Issue #134: The final touches are needed for complete project functionality.
2. Retrofit API Completion: Aiming to round out the Retrofit Interface.
3. Rebasing to PAPPL v2.0: The latest release has arrived, and while rebasing is on the horizon, it’s best saved until we are near the finish line.

Why This Matters

This project marks a pivotal shift for scanning on Linux, especially with Ubuntu Core Desktop’s growth. When this comes together, driverless scanning will finally be a reality, reducing friction and enhancing user experience for Linux-based systems.

A Heartfelt Thank You to the Team Behind the Work

A huge thanks to mentors Till Kamppeter, Michael Sweet, and Aveek Basu for their support on this journey. Here’s to pushing boundaries and building a Linux scanning ecosystem that’s as seamless as it is robust!