tag:blogger.com,1999:blog-88030549737993024482024-03-13T18:17:50.156+01:00czarking aroundUNIXes, software, the Web...Anonymoushttp://www.blogger.com/profile/08403280595072424564noreply@blogger.comBlogger2125tag:blogger.com,1999:blog-8803054973799302448.post-5410597282969535392014-09-18T00:49:00.000+02:002014-09-18T01:20:52.036+02:00Getting USB printer to work under OpenBSD<p style="font-style: italic;">
I am writing this post mainly for myself, although it may be helpful to other OpenBSD users as well.
</p>
<h2>Preparation</h2>
<p>
The first and most important step is to find a driver for your printer. Binary Linux–only support packages most likely won't help, particularily in case of <code>amd64</code> system, so your only hope is open–source driver.
</p>
<p>
I was lucky to find that my printer is supported by <a href="http://gimp-print.sourceforge.net/">Gutenprint</a> project, and thus a driver is available in <code>gutenprint</code> package (<code>print/gutenprint</code> port).
</p>
<p>
So, the preparation stage concludes into following command:
</p>
<pre class="console">
$ sudo pkg_add a2ps gutenprint
</pre>
<p>
Now, that packages are installed, we are ready to continue with configuration.
</p>
<h2>Device</h2>
<p>
By default OpenBSD recognizes USB printers and assigns <code><a href="http://www.openbsd.org/cgi-bin/man.cgi/OpenBSD-current/man4/ulpt.4">ulpt(4)</a></code> driver to them. Unfortunately, this printer can't work via <code>ulpt(4)</code>, so we have to disable this driver in kernel:
</p>
<pre class="console">
$ sudo config -fe /bsd<br />
OpenBSD 5.6-current (GENERIC.MP) #372: Wed Sep 10 18:03:54 MDT 2014<br />
todd@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP<br />
Enter 'help' for information<br />
ukc> disable ulpt<br />
282 ulpt* disabled<br />
ukc> quit<br />
Saving modified kernel.
</pre>
<p>
Running the same command without <code>-f</code> switch will result in modification to the current kernel, which is needed to avoid rebooting.
</p>
<p>
Now that printer will be identified as generic usb device (<code><a href="http://www.openbsd.org/cgi-bin/man.cgi/OpenBSD-current/man4/ugen.4">ugen(4)</a></code>, the appropriate file permissions for corresponding devices should be set. Once printer is connected to OpenBSD PC, it will show up in <code>dmesg</code> and <code>usbdevs</code> as <code>ulpt<i>N</i></code> device:
</p>
<pre class="console">
$ usbdevs -d<br />
addr 1: EHCI root hub, ATI<br />
uhub0<br />
addr 2: MP210 series, Canon<br />
ugen1<br />
addr 1: EHCI root hub, ATI<br />
uhub1<br />
addr 2: Integrated Camera, Ricoh Company Ltd.<br />
uvideo0<br />
addr 1: OHCI root hub, ATI<br />
uhub2<br />
addr 2: Broadcom Bluetooth Device, Broadcom Corp<br />
ugen0<br />
addr 1: OHCI root hub, ATI<br />
uhub3
</pre>
<p>
In this case it appears as <code>ugen1</code> (its identifier, "MP210 series, Canon") will also be needed later.
</p>
<p>
As <code>lpt</code> operates with "daemon" permissions, and <code>sane</code> operates with group "_saned", both daemon will be able to use device after following change in ownership:
</p>
<pre class="console">
$ chown daemon:_saned /dev/ugen1.*
</pre>
<h2>Getting PPD</h2>
<p>
According to <code>/usr/local/share/doc/pkg-readmes/cups-filters</code>, there are two ways of getting PPDs:
</p>
<ol>
<li>
Get readily available PPD file from <code>/usr/local/share/foomatic/db/source/PPD</code> or
</li>
<li>
Generating one from source.
</li>
</ol>
<p>
Unfortunately, there is no pre-build PPD for Canon PIXMA MP10, so PPD should be generated manually following instruction from <code>/usr/local/share/doc/pkg-readmes/foomatic-db-engine</code>:
</p>
<pre class="console">
$ sudo mkdir /etc/foomatic/direct
$ foomatic-ppdfile -P MP210<br />
Canon MP210-series Id='Canon-MP210-series' Driver='No Default Driver' CompatibleDrivers='gutenprint-ijs-simplified.5.2 gutenprint-ijs.5.2 '<br />
Canon MULTIPASS-MP210 Id='Canon-MULTIPASS-MP210' Driver='No Default Driver' CompatibleDrivers='gutenprint-ijs-simplified.5.2 gutenprint-ijs.5.2 '<br />
$ foomatic-ppdfile -p 'Canon-MP210-series' -d 'gutenprint-ijs.5.2' | sudo tee /etc/foomatic/direct/canon.ppd >/dev/null
</pre>
<p>
(Of course "MP210" and "Canon-MP210-series" "gutenprint-ijs.5.2" and "canon" in PPD path should be replaced with parameters corresponding to actual printer. Choice of particular driver among several matching is, of course, individual. If in doubt, choose randomly and try; you'll always have a chance to make different choice any time later.)
</p>
<h2>
Configuration
</h2>
<p>
Readme file <code>/usr/local/share/doc/pkg-readmes/cups-filters</code> gently suggests continuing with creating a converter script (filename may be chosen by user; I chose <code>/etc/converter.sh</code>):
</p>
<pre class="file">
#!/bin/sh
/usr/local/bin/a2ps -BRq --columns=1 -o - | \
/usr/local/bin/foomatic-rip -P canon
</pre>
<p>
Next, <code>/etc/printcap</code> entry pointing to actual printer device and converter script should be created:
</p>
<pre class="file">
lp|canon:\
:lp=/dev/ugen1.01:\
:if=/etc/converter.sh:\
:sd=/var/spool/output:\
:lf=/var/log/lpd-errs:\
:sh:
</pre>
<p>
(In MP210 the actual device turned out to be <code>/dev/ugen1.01</code>. Actual number of sub–device may be different on other devices.)
</p>
<p>
Ultimately <code>lpd</code> service should be enabled and started:
</p>
<pre class="console">
$ sudo rcctl enable lpd<br />
$ sudo /etc/rc.d/lpd start
</pre>
<p>
At this stage printing test document should succeed:
</p>
<pre class="console">
$ lpr test.pdf
</pre>
<h2>Scanner</h2>
<p>
Scanner component of the device should already work since changing ownership of <code>/dev/ugen1.*</code>:
</p>
<pre class="console">
$ scanimage > 1.pnm<br />
scanimage: open of device pixma:04A91721 failed: Access to resource has been denied<br />
$ sudo scanimage > test.pnm
</pre>
<p>
(Scanning should probably work without "sudo". The last command, although it produces the output image, exists with non-zero status and "<code>Bus error (core dumped)</code>" message. I'll investigate these issues and update this post "later".)
</p>
<h2>Hotplugging</h2>
<p>
Although contrary to <code>/usr/local/share/doc/pkg-readmes/cups-filters</code> ownership of <code>/dev/ugen1.*</code> devices persists over reboots, there is no guarantee that every single time the printer will attach as <code>ugen1</code> each and every time.
</p>
<p>
The process of changing and restoring permissions may be automated using <code><a href="http://www.openbsd.org/cgi-bin/man.cgi/OpenBSD-current/man8/hotplugd.8">hotplugd(8)</a></code> daemon. To make <code>hotplugd</code> do its job the following files should be created:
</p>
<ul>
<li><code>/etc/hotplugs/attach</code>:
<pre class="file">
#!/bin/ksh
DEVCLASS=$1
DEVNAME=$2
case $DEVCLASS in
0) # Generic devices
if [ "${DEVNAME%%+([0-9])}" == "ugen" ]; then
DEVDESCR=$(usbdevs -d | grep -B1 ugen1 | sed -Ee 's/ addr [0-9]+: (.+)$/\1/' -e 1q)
if [ "${DEVDESCR}" == "MP210 series, Canon" ]; then
chown daemon:_saned /dev/${DEVNAME}.*
echo "#!/bin/ksh\nchown root:wheel /dev/${DEVNAME}.*" > /etc/hotplug/detach.$DEVNAME
chmod +x /etc/hotplug/detach.$DEVNAME
echo "/canon/\n/:lp=/c\n\t:lp=/dev/${DEVNAME}.01:\\n.\nwq" | ed /etc/printcap
fi
fi
;;
esac
</pre>
(Upon detecting "MP210 series, Canon" device the script changes permissions, fixes device name in <code>/etc/printcap</code> and creates a script for cleaning up permissions after device is disconnected.</li>
<li><code>/etc/hotplug/detach</code>:
<pre class="file">
#!/bin/ksh
DEVCLASS=$1
DEVNAME=$2
if [ -x /etc/hotplug/detach.${DEVNAME} ]; then
/etc/hotplug/detach.${DEVNAME} && rm /etc/hotplug/detach.${DEVNAME}
fi
</pre>
(Basically this file just calls cleanup scripts and removes them after completion.</li>
</ul>
<p>
With this setup the printer may be connected and disconnected on demand with no additional actions required.
</p>
<h2>Further directions</h2>
<p>
By default <code>a2ps</code> and <code>foomatic-rip</code> understand several formats including PostScript, PDF and DVI documents, as well as popular image types and several other formats. Support for additional formats may be added by modifying <code>/etc/a2ps.cfg</code> and <code>/etc/a2ps-site.cfg</code> files. Reading manuals may also help.
</p>Anonymoushttp://www.blogger.com/profile/08403280595072424564noreply@blogger.com0Herceg Novi, Montenegro42.4572478 18.53147530000001142.4338178 18.491134800000012 42.480677799999995 18.57181580000001tag:blogger.com,1999:blog-8803054973799302448.post-73592479468189658392012-05-01T20:27:00.000+02:002014-09-17T21:43:49.178+02:00Proper Unicode Serbo-Croatian digraphs<p>Here in ex-Yugoslavia we have three letters that are nearly never properly spelled out: digraphs "DŽ", "LJ" and "NJ" (Cyrillic corresponding letters are "Џ", "Љ" and "Њ". In fact, the standard Yugoslav keyboard doesn't even have corresponding keys:</p>
<a href="http://upload.wikimedia.org/wikipedia/commons/2/2e/KB_Slovene.svg"><img style="display: block; margin: auto auto; text-align: center;" src="http://upload.wikimedia.org/wikipedia/commons/thumb/2/2e/KB_Slovene.svg/500px-KB_Slovene.svg.png" /></a>
<p>Though in most fonts "NJ" (digraph, single letter) is visually [nearly] indistinguishable from "NJ" (letters "N" and "J"), some practical concerns still apply. Eg., the length of word "injekcija" in any case will be correctly counted, as it has two letters "n" and "j" (Cyr. "инјекција"), but the length of the word "njen" (Cyr. "њен") will depend on the way it is entered, and if it is spelled incorrectly, will be reported to be one letter longer and will get improperly sorted.</p>
<p>With the introduction of Unicode the digraphs received their own range: 0x01C4–0x01CC; so in theory we got a chance to fix the problem. Still, until yet to be released Windows 8 Microsoft's operating systems simply didn't render the single-letter Unicode versions digraphs, so using them in a wild was problematic.</p>
<p>The situation was quite a bit better in X11 environments: the "Unicode" family of XKB keymaps for Serbo-Croatian language<a style="vertical-align: super; font-size: 66%;" name="fn1t" href="#fn1b">1</a> maps these digraphs to the keys where Cyrillic counterparts can be found in standard layout. Still this approach isn't very useful, as it dismisses the one of the design goals of the Yugoslav keyboard layout standard: the ability to enter text in virtually any language – the digraphs replace letters "Q", "W" and "X", that are used quite extensively in English and many other languages.</p>
<p>As my needs demand being able to write also in English, French, German and Russian, I had three options:</p>
<ol>
<li>use two separate Latin layouts (one for digraphs, one for "Q", "W" and "X");</li>
<li>create custom XKBlayout with some kind of magic;</li>
<li>use <em>Compose</em> X11 extention to create the key mappings.</li>
</ol>
<p>The first option was rejected from the very beginning: as i already have Cyrillic layout for typing in Russian (no native Latin alphabet to date, unfortunately), switching between three layouts would certainly create too much confusion to overcome the benefit of making less moves to get things done. The second option, while generally appealing (I already had to create a layout for typing Russian on Yugoslav keyboard without pain), had significant flow: unlike the rest of Latin letter the digraphs have 3 (yes, three) cases: lower, upper and <em>title</em> ("<b>nj</b>en", "<b>NJ</b>EN" and "<b>Nj</b>en" respectively), so the letters can't be simply mapped to third level "L", "N" and "D".</p>
<p>So I was left with the only option to define my custom <em>~/.XCompose</em> list:</p>
<pre class="console"><Multi_key> <D> <Zcaron> : U01c4<br />
<Multi_key> <D> <zcaron> : U01c5<br />
<Multi_key> <d> <zcaron> : U01c6<br />
<Multi_key> <L> <J> : U01c7<br />
<Multi_key> <L> <j> : U01c8<br />
<Multi_key> <l> <j> : U01c9<br />
<Multi_key> <N> <J> : U01ca<br />
<Multi_key> <N> <j> : U01cb<br />
<Multi_key> <n> <j> : U01cc</pre>
<p>Given the fact that this solution allowed me to avoid relearning my Serbo-Croiatian typing skills (I just have to press a Compose<a style="vertical-align: super; font-size: 66%;" name="fn2t" href="#fn2b">2</a> key once before entering digraph), I would say that this solution is nearly perfect. The only caveat is the necessity of amending <em>~/.xsession</em> script with the <code class="console">export GTK_IM_MODULE=xim</code> (similar variable exists for Qt which I don't have).</p>
<p>Similarly the support for other weird Latin letters can be added if needed simply by amending this file.</p>
<p style="margin-top: 1em;"><b>P.S.</b>: I'm still somehow uncomfortable with two features of standard Yugoslav keyboard: pressing 3 keys to emit "^" character drives me nuts. Though I don't use the "Ł" and "ł" letters, having them on different keys ("K" and "L" respectively) also seems insane. Probably it's time to make a dvorak-like layout for Serbo-Croatian...
<hr style="margin-top: 3em;" />
<p id="fn1b"><a style="vertical-align: super; font-size: 66%;" href="#fn1t">1</a> The <a href="http://lurkmore.so/images/e/e1/Arguing.retarded.jpg">Special Olympics</a> naming conventions for Serbo-Croatian language include "Bosnian", "Croatian", "Montenegrin" or "Serbian".</p>
<p id="fn2b"><a style="vertical-align: super; font-size: 66%;" href="#fn2t">2</a> On my ThinkPad Edge E325 there is a <em>PrtSc</em> key next to <em>AltGr</em>; as I don't take screenshots regularly, using "<em>compose:pscr</em>" XKB option was a natural choice.</p>Anonymoushttp://www.blogger.com/profile/08403280595072424564noreply@blogger.com0Herceg Novi, Montenegro42.45295 18.5314542.4295185 18.491968 42.4763815 18.570932