Date: Sun, 26 Feb 2012 18:46:53 +0100 From: Polytropon <freebsd@edvax.de> To: Jerome Herman <jherman@dichotomia.fr> Cc: freebsd-questions@freebsd.org Subject: Re: Installing Samsung CLX-2160 color laser printer on USB using CUPS Message-ID: <20120226184653.e695327b.freebsd@edvax.de> In-Reply-To: <4F498DF0.5070504@dichotomia.fr> References: <20120225221433.cba3d0dd.freebsd@edvax.de> <4F498DF0.5070504@dichotomia.fr>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 26 Feb 2012 02:42:08 +0100, Jerome Herman wrote:
> You did nothing wrong, on the contrary. You now have a prefectly working
> printer. You just need to tell cups it exists.
> Since
>
> # foo2qpdl-wrapper -p 2 -c cupstest.ps> cupstest.xqx
> # cat cupstest.xqx> /dev/ulpt0
>
> works, you should be able to create a new printer using a direct device.
> So go on as if you wanted to create a network printer, choose
> HPJetDirect (for example) when asked about the connection. Then when you
> have to input the uri remove the socket:// and type usb:///dev/ulpt0.
> (Yes triple / before dev)
> The you can process as usual for name, options and PPD.
> If it doesn't work try parallel:///dev/ulpt0
Interesting approach. Fully "unimaginable" from the CUPS
"guide to things" (i. e. how normal users _assume_ things
should be done!), but interesting. I'll try that.
The option to enter such kind of data ("parallel://" and
"usb://" isn't mentioned):
Add Printer
-----------
Connection: _________________________________
Examples:
http://hostname:631/ipp/
http://hostname:631/ipp/port1
ipp://hostname/ipp/
ipp://hostname/ipp/port1
lpd://hostname/queue
socket://hostname
socket://hostname:9100
See "Network Printers" for the correct URI to use with your print
[ Continue ]
See? Nothing for parallel or USB to enter manually.
It's like going to a car salesman, buying a car, but before
driving home from his yard, quickly exchanging the car you
bought for the car you initially wanted. :-)
> Normally one should work.
Today, I tried to add the printer again. Unlike yesterday,
it got detected! (Note: System shut down during night.)
It also accepts print jobs, but they are stuck somewhere.
% lpq -PSamsung_CLX-216x_Series
Samsung_CLX-216x_Series is ready
Rank Owner Job File(s) Total Size
1st poly 202 Unbenannt1 7563264 bytes
This is from an OpenOffice session. The printer doesn't
print anything. No action.
> Basically in cups choosing "network connection" allows you to input any
> URI you want, including file and raw (now defunct I think - it was
> mainly for debug anyway).
Why haven't the CUPS people thought of a kind of "know what
you want mode" where you can simply enter what you think is
correct, no matter if any auto-detection magic did work (or
not)?
> I never tried this specific printer, but this trick worked well on a few
> HP and Canon.
> Tell us how it went.
I tried both of your suggestions for specifying the connection
and chose the PPD file for the printer CLX-216xsplc.ppd (size
12208 bytes). Jobs get queued, printer "is ready", but no
action on the printer.
However, when I issue a command like this:
% foo2qpdl-wrapper -p 2 -c /tmp/testpage.ps > /dev/ulpt0
pcache: unable to open '/home/poly/.ghostscript/cache/gs_cache'
pcache: unable to open '/home/poly/.ghostscript/cache/gs_cache'
pcache: unable to open '/home/poly/.ghostscript/cache/gs_cache'
pcache: unable to open '/home/poly/.ghostscript/cache/gs_cache'
The printer works. The result is _very_ dark. But hey, it's
stupid commodity hardware, and RGB and CMY are "a little bit"
different, and nothing of the cheap crap is calibrated. :-)
In the system log, I get those:
ugen1.5: <Samsung Electronics Co., Ltd.> at usbus1
ulpt0: <Samsung Electronics Co., Ltd. CLX-216x Series,
class 0/0, rev 2.00/1.00, addr 5> on usbus1
ulpt0: using bi-directional mode
ulpt0: output error
ulpt0: output error
ulpt0: output error
ulpt0: output error
Unlike yesterday, the printer now is on ugen1.5. I'll have to play
with the permissions a bit, maybe that's the reason why nothing
can be printed, even though the changes I made for device permissions
should cover all imaginable cases - all devices /dev/usb/* now
are root:cups with crwxrwx--- permissions, the /dev/u(n)lpt0
devices are also root:cups with crw-rw---- permissions.
Really, I _need_ to dump CUPS relapse to _standard_ system tools
that seem to be easily capable of what the web-driven autodetected
elastic-legged program magic of CUPS can't. :-)
--
Polytropon
Magdeburg, Germany
Happy FreeBSD user since 4.0
Andra moi ennepe, Mousa, ...
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20120226184653.e695327b.freebsd>