Messages

Thanks for pointing this out.  It appears that this version also supports a couple of additional printers.  I will work on packaging these and adding the new architecture when I have time, maybe in a couple of weeks.

Open-source SpliX drivers now support the majority of SPL-based Samsung, Xerox and HP models.

Thanks for highlighting this.  I have updated the sticky post, as well as the web pages, to encourage moving to Splix as CUPS 3.0 rolls out.

The repository key has been updated, with the old key removed.  A transition package was in place for six months, but if you missed that window and now get errors, refer to step 4 installing the repository (the part about the key) here: https://www.bchemnet.com/suldr/

Also, libxml2 is a required dependency of all versions of the driver, but has recently been removed from Debian Testing and will not be provided in future stable releases (and therefore will be dropped from Ubuntu, Mint, etc. that use Debian as the primary source of packages).  To ensure that the packages remain installable, I am now providing the most recent (as of today) version of the package through this repository.  The package is officially obsolete so no future updates are likely.

The dependencies have not been updated because the GUIs do not work with new versions.  The last update to the GUI from Samsung was over a decade ago, and the issue is worse than just python 2.7 dependency: it also requires Qt4, which is similarly obsolete and removed from Debian, and the GUI depends on a library with a known major, unpatched security flaw.  I have tested the programs with updated Qt and python, and they load but ultimately fail to work correctly.

I would like to achieve the goal that you describe, especially because I have seen a large increase in traffic to this repository over the past few months so there clearly is still interest in using these printers.  But the software is simply too old and closed source, so I do not have a solution.

The scantopc scripts could be updated, but would require a major rewrite because the core python library used was not ported to python 3.  So far nobody has been motivated to put in that effort since the original authors moved on.

The other problem that is coming up soon is CUPS 3.  When that is finally released, likely within the next year (although it has been "within a year" for nearly 4 years now), the drivers will also stop working due to a fundamental change in how CUPS will interact with printers.  Obviously it will take some time for CUPS 3 to work its way into enough distributions to have a major impact, but there is a definite end of life coming for the Samsung printers even if the hardware is still good, except for people with the considerable expertise to configure their printer without any GUI or CUPS.

Have you tried the various strategies given on the scanning page (https://www.bchemnet.com/suldr/scanning.html), specifically issue 11?

Unfortunately that collection of posts is probably all the specific guidance that I can provide.

Another solution for anyone encountering this and wanting to prevent the warnings: disable this repository except when you are actively using it.  Given that the binary files are unlikely to ever change again, there really is no need to regularly check for updates after setting up working drivers, except possibly around the major updates of your Linux distro.  For context, there has not been an update to most driver packages in over 4 years, and it is entirely possible that there will never be another major change to most of them.

Thanks for the quick response!
But is it really necessary to leave the old key, since repository users will automatically update to the new keyring package by merely using the repository?

Yes, the old key has to remain for a while.  The key is used to sign the information about available packages, which is read before updates happen.  If the existing key on someone's system does not match the signature, the update to the new key will not be allowed automatically.  So I have to temporarily sign the package list with both keys, so that everyone can update without having to manually install the new key.  And many people do not run updates every day, so it can take a while before the large majority of users have installed the new key.

The reason revoking the old key does not help is that the warning is not actually about the key.  It is a warning about the signature in the package file, which still refers to the old key whether or not the key is trusted by your system.  I am not familiar enough with Sequioa (the new PGP system replacing GPG in Debian) to know if there is a way to suppress the warning during this transition.  If the package sqv is not installed (and gpg still is), there is no warning, although that is not an elegant solution or consistent with the direction Debian is moving in.

Thanks for the alert.  Apparently the key was one caught in a long-standing bug that is now being exposed as Debian changes over their default GPG tool.  I have added a new key that does not trigger the warning.  You may still see the warning for the existing key until I remove it, but I will allow a few months before doing so to give repository users time to update to the new keyring package.

Thank you for sharing this fix.

Update: there is no reason to keep the repository enabled on your system after installing the desired packages, as there are unlikely to be any future updates.  See this announcement:
https://www.bchemnet.com/suldr/forum/index.php?topic=406.0

[Update February 2026]

Summary: starting in a year or two, the vast majority of Samsung-branded printers will no longer be able to print when using a version of Linux incorporating CUPS 3.0 or higher.

When CUPS 3.0 is released, printer drivers will no longer function.  The only printing methods supported by CUPS will be driverless options listed here:
https://openprinting.github.io/driverless/

Most Samsung printers do not support any of these options (although some later models do apparently work with IPP, possibly with a reduced feature set).  While the CUPS team has provided a limited mechanism for driver-mandatory printers to still function the 3.0 series, that mechanism is not applicable to the Samsung driver.  The CUPS team has effectively declared that these older printers are simply to not be supported.  I do not have any information to help you determine if your printer is an impacted one or not, other than to suggest that you try installing it using IPP instead of the driver (which can be done with existing CUPS versions) and see if it works.

As of May 2024, the planned release of CUPS 3.0 is "mid-2025".  It has been pushed back several times already, so it may be later.  And your particular distro may not incorporate CUPS 3.0 until significantly later still.  But once 3.0 is on your system, the Samsung (or HP version) drivers will cease to function.

Note that all the packages will still be installable, as I have no plan to make them explicitly conflict with CUPS 3.0, and I will continue to provide the Samsung installers as well.  There are two reasons for that: (1) the scanning functions of the drivers will still likely be useful to some people even when the printing drivers do not work, and (2) I do not want to cripple any possibility of a future work-around that allows these drivers to continue working, though I view that as extremely unlikely.

Use of this repository has slowly been declining since Samsung sold off their printer business, and HP sold only a couple of models that used the same driver system.  I anticipate a significantly greater rate of decline over the next few years, but I intend to leave this resource in place as long as there are a significant number of people apparently benefitting from its availability.

At this time, I do not anticipate any future updates to the packages or content.  Therefore, there is no reason to leave the repository enabled on computers once the desired packages have been installed.

Update February 2026 CUPS 3.0 is rolling out.  I strongly recommend starting to move to Splix (see below) if possible.

There have been previous reports that this behavior sometimes happens with the automatically installed/detected printer.  You can try deleting the installed printer and then adding it again manually.

If that does not help, apparently certain models also benefit from the following to address what might be a name coding error for certain printers:

Code Select Expand

cd /usr/lib/cups/filter/
sudo ln -s rastertospl rastertosplc

The 1.00.39hp driver might also work.

The three approaches can tried in combination as well.

You can try adding

Code Select Expand

deb http://deb.debian.org/debian bookworm main to your sources.  I am not familiar with what Raspbian provides directly, but it should be compatible with the main Debian repository ("universe").  Certainly that repository has the packages that are being reported missing.

Try without the amd64.  So either make sure all your sources are "armhf" rather than "amd64", or try

Code Select Expand

apt-get install suld-driver2-100.39hp:armhf

The "hp" version of the driver should work without any of the amd64 tricks.  If it does not, then you can try the amd64 version, in which case you probably need to make sure that you have amd64 in the sources for some of the raspbian respositories.

The raspbian server does not provide the "-updates", "-security", or "-backports" sections, which is why you are getting the errors.  The main "bookworm" lines are okay, though.  But to use that solution, you also need to enable multi-arch:amd64.  It is simpler to try this, which needs only the bchemnet repository:

Code Select Expand

apt-get install suld-driver2-1.00.39hp
The "hp" on the end is important to be able to pull the armhf version.

I have not tried that version myself (no appropriate hardware), but it will probably work to install the printer and scanner drivers.

Have you tried following the steps here to set up the repository:
https://www.bchemnet.com/suldr/
Then installing version 1.00.39hp?

Alternatively, another way is given here: https://www.bchemnet.com/suldr/forum/index.php?msg=1717.

The Xerox drivers appear to be equivalent to version 1.00.25, which means the ARM is probably armel rather than armhf and therefore useless to anyone trying to use this on a Raspberry Pi - which as far as I know is the only reason anyone is trying to run ARM drivers.

If you can verify that the ARM drivers in that download are instead armhf and therefore potentially useful, I can work on packaging them.

A driver that nominally works for arm64 is now avialable for experimenting through the repository, but it is untested.

Experimental packages for arm64 are now available.

Packages posted and some web content updated, with the caveat that I have done zero testing.

I have posted version 1.00.39hp.  These are the latest (I think) HP-released drivers based on the Samsung technology.  These are experimental and 100% untested with any Samsung-branded printer (as far as I know), but it appears they will probably work.

Perhaps most importantly, these also provide ARM64 (and MIPS64) support.  Again completely untested.

Feedback is welcome, but I make no promises anything will work, now or in the future.

Yes, it does look that way.  I will build packages in the near future for testing.  Unfortunately I no longer have access to any relevant hardware so cannot test myself.

Thanks for sharing the solution.  Your error log seems to have not have had anything obvious in it, but clearly the job was being lost somewhere.  Fortunately that sounds like it is no longer a problem.

I suggest trying this (all will require sudo/root):
1. edit in /etc/cups/cupsd.conf to change the "LogLevel" line to "debug" instead of "warn"
2. restart the cups service
3. see what you get in /var/log/cups/error_log after a job that disappears without printing

Then post the error log output, if you cannot make progress yourself from what it says.

Just a thought: have you tried a different USB cable?  Very occasionally a cable will start to fail and cause connect/disconnect cycles such as this.

Unfortunately I do not have any hardware I can use to provide further insight, but perhaps someone else does and will.

Thanks for sharing.  I have added a link on the main pages to this post as an alternative driver option.

Whichever driver version you are using, I first recommend trying a different one.  This printer is supported by a wide range of options, and that may solve the problem.

If not, this sounds like an issue with CUPS.  The latest versions of CUPS are much slower under some circumstances and with some printers (brand-independent), but I have not worked out when or why.

The forum has undergone a major upgrade.  If you run into technical issues that seem related, let me know.

You are welcome.  I am glad it helped to keep old hardware working.

There is no development on any part of this project.  The Qt interface development was actually discontinued 9 years ago, well before Samsung sold their printer business to HP in 2016.  HP has not shown any interest in developing the driver (the last true update was nearly 6 years ago), let alone reviving that interface.  And there is no practical way to get Qt4 working in the latest Debian-based distributions due to some severe security issues that were discovered after Qt4 development ended.

However, you should be able to use system-config-printer to set up the printer.