Better out-of-kernel driver support (esp. printers)

The good news: an increasing number of device manufacturers are releasing Linux drivers. The bad news: the drivers they release are only for the most popular Linux distros, and the manufacturers provide no support to end-users for their Linux drivers.

From my experience and what I’ve read here, CL users are pretty much on their own when it comes to adapting mfgr-provided drivers to CL (especially printer drivers). This harks back to when peripherals support was the Achilles tendon of Linux, which was why I didn’t migrate from Windows years ago (but I sure did want to).

Given the articles I’ve read on the web, the drivers issue is still of concern to the Linux community. Given the help request posts on this forum, it is certainly of concern to new CL users. The recent addition of hplip is definitely a step in the right direction, but more is needed if the CL community is to grow. We have a ways to go before the mfgrs start developing drivers for us!

Maybe some automation might be developed to adapt an RPM or DEB file to CL?

.
.
.

(On a personal note, I survive on disability benefits, and cannot afford to buy a new Linux-compatible scanner/printer. I was able to build my new desktop only because of an interest-free promotion on my credit card, and even then it was 8 months of rice and beans (no exaggeration). I’m not the only shut-in who depends on stimulation from the Internet to stay sane.)

@eadams and me talked about this yesterday.

All these RPMs just contain a PPD file. These files need to go into /etc/cups/ppd. The RPM method would place them in the wrong location and possibly cause them to be erased by a swupd repair which we don’t want.

I think the best thing to do is to create a helper application that can perform the install. It shouldn’t be rocket science, it’s just extracting and copying the file after all, but making it nice might be some work. It would be entirely cross-distro - it would work on any distro - you could use it to install PPD files from a deb package on a rpm distro…

I noticed that while working on the driver package for my Epson XP-610. I’m grateful that PPDs are human-readable text files, that helped me figure out a lot.

The thing about PPDs is they may call other necessary driver files. The one for my Epson calls a CUPS filter that turns out to be a binary executable, it calls a shared object, and it calls several binary data files. A helper app would need to read the PPD and then place these extra files where CUPS is told to find them.

Another thing that CUPS needs to know is the URI where the printer is connected. For a LAN printer, that is mostly the IP address the printer is on, given to CUPS in IPP format. But how do you tell CUPS which USB port your local printer is connected to? hp-setup accepts this information on the command line, and sets the correct connection URI. CUPS on its own cannot even detect a local printer (at least not on my system).

I was able to manually install the files for my Epson, and install the printer in CUPS by using the web interface. But printing fails with multiple occurances of:

XP-610: File “/opt/epson-inkjet-printer-201308w/cups/lib/filter/epson_inkjet_printer_filter” has insecure permissions (0100755/uid=1000/gid=1000).

It also fails when CUPS attempts to run ippfind.

I am mostly certain these errors are down to an incorrect connection URI. I searched the web for help and tried different connection URIs, and got different combinations of those two errors in each case.

Your team recently adapted ‘hplip’ to CL. Perhaps that experience can help? One thing that modern multi-function printers do need is something more than PCL and a connection to realize their full potential.

We’d rather provide these through normal packaging. Installing random executables into your system that gets executed with elevated privileges isn’t something we want to just blindly do or trust.

That printing companies still rely on these is terrible, of course.

Apparently, CUPS filters usually are binary executables, but as far as I can tell they have no UI, and they run under CUPS, which hopefully places limits on what they can do.

Without it being open source, we can’t verify what it does.

https://www.cups.org/doc/api-filter.html

This document scares me. I would urge people to make sure that they’re not using printers that require binary print filters, since that is an obvious way to avoid this potential security issue.

Wow, thanks for the heads-up.Currently this Epson is connected to my old Windows XP box, where I mainly use it for the scanner. Beggars can’t be choosers; it was donated to me at a time when my previous printer/scanner all-in-one had died and I couldn’t afford a new one (and I still can’t). This Epson and the HP LaserJet (also very old, also a donation) are the heart of my home office, which helps me keep a roof over my head. :no_mouth:

Edit: has your team ever discussed bundling the Gutenprint project? I know little about it, except it offers drivers for many different printers.

https://gimp-print.sourceforge.net

Right, I found that. My Epson model is not on the supported printers list. Thanks, tho…

http://gimp-print.sourceforge.net/p_Supported_Printers.php

It’s part of the desktop bundle. I noticed it wasn’t part of hardware-printing bundle, so I’ll add it there as well.

1 Like