My Lenovo M1688W Pro at home is a wireless model—whoever wants to print has to connect to it from their phone each time, and even then, it doesn’t always recognize the printer. A few days ago, I wanted to solve this once and for all by setting it up as a permanent queue on my Feiniu NAS. I figured it would take about ten minutes—just find a PPD file and upload it. In reality, it took me an entire evening, and almost all the hurdles were related to the model name.

📄 The PPD just describes the printer; another program does the actual work

First, let’s clarify what a PPD is. In CUPS, each printer corresponds to a PPD file—a plain-text file that describes the paper sizes it supports, the resolution (in dpi), and whether it supports color. Since I’d installed Lenovo drivers on my Mac before, I started by digging through the driver library.

ls /Library/Printers/PPDs/Contents/Resources/

Thirty .ppd.gz files, with lenovom1688dwpro.ppd.gz tucked inside. I was pretty happy—I unzipped them, ready to transfer them directly to my NAS.

After unzipping, I casually glanced at the contents and got stuck on this line:

*cupsFilter: "application/vnd.cups-raster 50 rastertolenovo"

This line means that the PPD file only describes the printer’s capabilities; the step of converting the page into a byte stream that the printer can understand is handled by an external program called rastertolenovo .A PPD is text-based, so it can be read on any machine. That program, however, might not be.

file /usr/libexec/cups/filter/rastertolenovo
# Mach-O universal binary with 2 architectures [x86_64] [arm64]

Mach-O. When copied to Debian, it’s just a bunch of unrecognizable bytes. It was only then that I realized: having just the PPD is like bringing only the instruction manual—the machine that actually does the work is still sitting where it was.

📦 Of the three packages on the official website, only one includes W Pro

Lenovo’s Linux driver page is on the Lenovo Imaging website. There are three packages related to the 1688, none of which include the model number in their names; you’ll need to expand the “Compatible Models” column and compare them one by one.

The comparison results are a bit counterintuitive.

The one with the most similar name is called lenovo-100-m1520-m1688-series-linux . The model list includes M1688W and M1688DW , neither of which has “Pro.” The third one, containing M1688W Pro , is “G Series and GM Series Kylin V10 Drivers”—its name doesn’t even contain the number 1. Missing “Pro” means it’s a different set of PPDs; I only realized this after unpacking the package and checking the files—I’ll explain that later.

There was also a minor hiccup with the download link. The download icon on the page, href , was empty; the URL was embedded in the properties of data-href and dynamically generated by JavaScript. Here’s what I extracted.

curl -L -o lenovo-kylin.zip \
  "https://lenovo-upload.oss-cn-beijing.aliyuncs.com/drivers/G262DN_Series_drivers_Lin_20240109140629.zip"

unpacks into four DEB files, sorted by architecture.

lenovo-printer-driver_1.51-230329_amd64.deb
lenovo-printer-driver_1.51-230329_arm64.deb
lenovo-printer-driver_1.51-230329_loongarch64.deb
lenovo-printer-driver_1.51-230329_mips64el.deb

includes Loongson and mips64el as well, since this set was originally developed for Kylin and UnionTech. Feiniu runs on x86, so I took the amd64 version, which is 30.4 MB.

🔧 After unpacking the DEB, the only useful part is 121 KB

ar x . Strip away the DEB wrapper, list everything in tar tJf data.tar.xz , and the first thing I was looking for appears.

ar x lenovo-printer-driver_1.51-230329_amd64.deb
tar tJf data.tar.xz | grep -iE '1688|filter'
# ./usr/share/cups/model/lenovo/lenovom1688wpro.ppd
# ./usr/lib/cups/filter/rastertolenovo.sh

lenovom1688wpro.ppd —that’s exactly my machine, so I don’t have to make do with the DW version. Comparing the two files side by side, it’s clear they’re categorized based on the machine’s actual capabilities. The DW version is v1.14, which contains *OpenUI *Duplex/2-Sided Printing ; the W Pro version is v1.51, where grep -c Duplex counts to 0. In terms of hardware, the DW model supports automatic duplex printing, while the W model does not; the PPD follows the hardware configuration. You can still print using the DW version, though the interface will display an extra duplex toggle button that doesn’t actually do anything.

Next, let’s see what’s actually included in this package. It’s 30.4 MB, which expands to 102 MB; 31 MB of that is crammed into /opt/lenovo/vop —a complete set of Qt5 libraries intended for graphical user interfaces on desktop systems. Since there’s no X server on the NAS, this part is completely unnecessary.

Only three files are used by the print chain.

/usr/share/cups/model/lenovo/lenovom1688wpro.ppd   8.7 KB
/usr/lib/cups/filter/rastertolenovo.sh              110 B
/opt/lenovo/printer/rastertolenovo                  112 KB

That .sh consists of just three lines.

#!/bin/sh
LD_LIBRARY_PATH=/opt/lenovo/printer
export LD_LIBRARY_PATH
/opt/lenovo/printer/rastertolenovo "$@"

The one doing the actual work is that last 112 KB ELF file. I originally thought it would drag along a bunch of proprietary .so files, but after digging into the .dynamic section, there were only five NEEDED entries.

libcupsimage.so.2  libcups.so.2  libpthread.so.0  libm.so.6  libc.so.6

consists entirely of system libraries. Once CUPS is installed, they’re all there—not a single vendor-specific dependency. This result is much better than I expected. libcupsimage2 is occasionally not installed alongside CUPS on Debian; if it actually reports missing libraries, it’s apt install libcupsimage2 .

There was one other thing I’d been worried about beforehand. This NAS runs a Celeron J1900, which lacks AVX2. Previously, when I installed mihomo, the standard amd64 version would crash on startup, so I had to switch to the “compatible” version. This time, I made a point of checking the compilation targets.

ELF 64-bit LSB executable, x86-64, for GNU/Linux 2.6.32, stripped

The version compiled in 2023 targets kernel 2.6.32 with an x86-64 baseline. The old-school approach came in handy this time.

⬆️ Make sure you use the right entry point during installation

In Feiniu’s settings, there’s an “Upload Driver” option—just drag and drop the amd64 .deb file right in there. After the driver was uploaded, Lenovo M1688W Pro appeared in the driver list. I added it to the queue, printed a test page, and the paper came out.

To skip the 31 MB of unnecessary Qt libraries, package the three files in their original paths; extracting them to the root directory will work just as well.

sudo tar xzf m1688wpro.tar.gz -C /
sudo systemctl restart cups
lpinfo -m | grep -i 1688

There’s also a line in the package that says Conflicts: zx-printer-driver, lenovo-cups-driver . If you’ve previously tried installing other Lenovo or Zhixiang drivers on the same machine, dpkg will reject it outright—you’ll need to clean it up first.

dpkg -l | grep -iE 'lenovo|zx-printer'

Here’s an additional discovery. The DEB maintainer is listed as Githon Technology Co., Ltd. , while lenovo*.ppd and zx_*.ppd are mixed together in the PPD directory, and Conflicts also points to Zhixiang. These Lenovo printers and Zhixiang printers come from the same OEM, so a single driver package covers both brands.

🧭 Looking Back

The level of closed-source code in Chinese printer drivers is lower than I expected. When I unpacked the DEB file, it contained an 8.7 KB text PPD file and an 112 KB converter. The dependencies were clean, and the paths were neatly organized under /usr/lib/cups/filter and /usr/share/cups/model —it followed the standard CUPS setup exactly.

The hard part was finding them. The names of the three packages are very similar, the model list is hidden until you expand it, and the download links are tucked away in the file properties. I spent almost the entire night on this, rather than on the actual installation.

After setting up the print queue, I shared it right away, so I no longer needed to install the Lenovo driver on my Mac.

sudo cupsctl --share-printers --remote-any
sudo lpadmin -p M1688WPro -o printer-is-shared=true

CUPS broadcasts via IPP Everywhere, so the Mac’s “Add Printer” feature can detect it right away. Select the default AirPrint driver, and let the NAS handle the rasterization. For troubleshooting, see /var/log/cups/error_log .

If your printer natively supports AirPrint, you can actually skip this entire article. A single command is all it takes—no need to touch the PPD or filters.

lpadmin -p 打印机名 -E -v ipp://打印机IP/ipp/print -m everywhere

You only need to use the manufacturer’s filter if your printer is connected to the NAS via USB and you’re relying on the NAS to act as a network printer.

Related Reading

• After Accidentally Deleting a Production Data Volume - Another troubleshooting session on the same machine: recovering data from ext4 free blocks
• Traefik Cloud Server Deployment Guide - Reverse proxy configuration for self-hosted services