Samsung laser drivers for Linux - thinking aloud

[Fernando Cassia]

I have an old system around with F16, which I didnt bother to update
to F17 or F18 because I seldom use it (old specs, ancient cpu, low ram
,120GB IDE HD, etc) but XFCE boots and can be used when everything
else fails.

I decided to plug a Samsung 2165W laser to it through its usb port.

The 2165W like many other cheap Samsung lasers are closer to
´winprinters´ because, althought not GDI printers, those use the
proprietary Samsung SPL page description language, implemented in
Samsung´s windows drivers, -but also as Linux binaries, more on that
later-. In other words, these printers don´t enjoy the flexibility of
PCL/PCL5 or PostScript printers that are almost ´universal´ and work
out of the box with little fiddling around.

F16 XFCE showed a nice ´detecting new printer´ dialog on the top-right
side of the screen only to conclude 30 seconds later with ´drivers not
found´ or a message like that, with a ´search for drivers´ button
below.

1. I pressed ´search for drivers´ and the dialog went away, networking
leds flickered a bit, then nothing. (??)
I decided I had to try again, unplugged and replugged the device,
althought this time, after the flickering stopped, it said once again,
that no drivers were found, so I choose the option to ´manually point
towards driver´ or words to that effect. A file selection dialog asks
you to point to a .psd file.

2. Luckily, I had downloaded the Samsung drivers and unpacked those to
the hard drive by then, so I pointed it towards
./drivercd/linux/noarch/bin/(something else, I didn´t keep notes) and
there was a long list of .psd files, one for each samsung printer
model #.  I selected 2160 because I know 2160 and 2165 are the same
model# family. Cups did its magic and lo and behold I had a printer
object with the right cups driver.

3. When I tried to print, obviously, it failed (you saw that coming),
the problem ´rasterizer not found´ or words to that effect. It was
complaining about a missing package dubbed ´raster2samsungspl´ engine.

Obviously Samsung´s idea is for one to run the ´install script´ as
root. Apparently it copies binary files around (and libs, like
libstdc++) to fixed destination paths and hopes for the best.

My idea, on the other hand, was that cups should be (by now)
intelligent enought to search for some sort of ´driver description
file´ and install the driver from the cups side, not from a
manufacturer-provided ugly bash script.

I was wrong. apparently the only way to make it work is by running
Samsung´s install bash script.

So the $1M question is: can´t Samsung design drivers which can be
installed via a package manager (rpm), or via a cups install routine,
instead of the current method?. I´m sure they can, in theory.

Which is the right venue to complain about this? (other than Samsung,
which I´m sure couldn´t care less about us Linux users).
There was an ´openprinting´ effort... or perhaps the FSF? or the cups project?.

One would think that by 2013 distros would have gotten around to
design a foolproof way for hardware manufacturers to properly package
drivers (even proprietary blobs) which would then be installed
semi-automagically by the Linux printing subsystem, no?.

Anything wrong with my analysis?. Yeah, I know "just run the darn
manufacturer-provided bash install script and be grateful it at least
works". Yes, that´d be the easy way. I don´t think it´s the right way
going forward....

No, I´m not asking for directions on how to get my printer working.
No, please don´t tell me to update to F17 or F18. No, please don´t
start a flamewar. My point is about the packaging of Samsung´s drivers
and the install method they have chosen. "doesn´t it suck? what -if
anything- can we do to get it improved?".

FC

-- 
During times of Universal Deceit, telling the truth becomes a revolutionary act
- George Orwell