First problem: Samsung Universal driver nowhere to be found, at least not in the download links for this model. Well, it's supposed to be universal, isn't it, so I got the tar archive from the SCX-4300 download page.
Installation: untar, cd to cdroot/Linux, ran sudo ./install.sh and followed the console instructions. And yes, the scx-4200 was included. What worked out of the box: Scanning, both xsane and skanlite interfaces. Printing worked for all kinds of files and apps except PDF from whichever source, which is a bit of a bummer.
Condensed console output from Okular and acroread:
As the Samsung driver setup had created a file 99_smfpautoconf_samsung.rules in /etc/udev/rules.d, including a rule for idVendor=04e8, and libusb had specifically not complained about device 001:017, it was probably not an udev problem.
I found a lot of "new" printers in CUPS (http://localhost:631), removed scx4100 and scx4200 (default), where CUPS claimed "backend failed", and set the default printer to SCX-4200-Series.
In the end, I traced the error back to the venerable lpr command (learned a lot about udev handling on the way), which acroread and okular seem to use as backend to print intermediate Postscript files.
lpr -P SCX-4200-Series test.ps produced all of the errors listed above, lp -P SCX-4200-Series test.ps didn't - and printed faultlessly.
Come to think of it - why is there a file lpr.orig in /usr/bin/ and why, oh why, does /usr/bin/lpr link to /opt/Samsung/mfp/bin/slpr?
Restoring the original lpr solved my problem.
To be fair, judging from the file creation dates in /opt/Samsung/mfp/bin, there might have been remnants of a botched installation of a previous version of the Samsung driver, which has a nasty trail of bugs.
Installation: untar, cd to cdroot/Linux, ran sudo ./install.sh and followed the console instructions. And yes, the scx-4200 was included. What worked out of the box: Scanning, both xsane and skanlite interfaces. Printing worked for all kinds of files and apps except PDF from whichever source, which is a bit of a bummer.
Condensed console output from Okular and acroread:
WARNING: configuration file not found
malloc: using debugging hooks #5 repetitions of this line
libusb couldn't open USB device /dev/bus/usb/001/001: Permission denied.
libusb requires write access to USB device nodes. #repeat that for all USB devices except the printer
unknown key <-P> #or any other first lpr option
From the lsusb output I got: Bus 001 Device 017: ID 04e8:341b Samsung Electronics Co., Ltd SCX-4200 seriesAs the Samsung driver setup had created a file 99_smfpautoconf_samsung.rules in /etc/udev/rules.d, including a rule for idVendor=04e8, and libusb had specifically not complained about device 001:017, it was probably not an udev problem.
I found a lot of "new" printers in CUPS (http://localhost:631), removed scx4100 and scx4200 (default), where CUPS claimed "backend failed", and set the default printer to SCX-4200-Series.
In the end, I traced the error back to the venerable lpr command (learned a lot about udev handling on the way), which acroread and okular seem to use as backend to print intermediate Postscript files.
lpr -P SCX-4200-Series test.ps produced all of the errors listed above, lp -P SCX-4200-Series test.ps didn't - and printed faultlessly.
Come to think of it - why is there a file lpr.orig in /usr/bin/ and why, oh why, does /usr/bin/lpr link to /opt/Samsung/mfp/bin/slpr?
Restoring the original lpr solved my problem.
To be fair, judging from the file creation dates in /opt/Samsung/mfp/bin, there might have been remnants of a botched installation of a previous version of the Samsung driver, which has a nasty trail of bugs.
2 comments:
thank you very much
Thank you. Also works with OpenSuse 12.1, but had to search for the driver as the link no longer works, and errors during install but don't seem to affect operation. Posted details on my blog http://www.dalescott.net/wordpress/?p=694
Post a Comment