Eipä ole koskaan aiemmin tarvinnut perehtyä *nix ympäristöissä tulostamiseen näin perusteellisesti. Pieni suunnitteluvirhe nimittäin tapahtui aikanaan, kun hankin HP LaserJet 1018 USB -tulostimen. Windows Printing -tulostimeen kyllästyttyäni halusin “jotain muuta”, mutta menin taas ansaan. 1018 ei ole Windows Printing -laite, mutta sikäli täysin rampa, ettei vehkeessä ole firmwarea ollenkaan rommilla ja laite on “Host based printing” vempele. Käytännössä siis aina kun laite kytketään, pitää sille lähettää firmware binaari. Tuo fimwaren lähettäminen vaatii omat erikoisjärjestelynsä (esim. udeviin). Lisäksi 1018 ja 1020 tulostimille on olemassa vain Windows ajurit sekä Un-official tuki HPlip ohjelmistolla Linuxille.

Macit taloon

Kun PC:t kannettiin talosta ulos ja Macit sisään, tuli mieleen, että tulostaakin joskus pitäisi. Homma piti saada siis toimimaan sekaympäristössä ja erityisesti Mac OSX:llä. Potentiaalisia tulostajia siis Windowsit, Linuxit ja Macit.

Ensin Linuxista ja siitä  jako verkkoon

1018 kiinni Debian koneeseen ja apt-get install hplip. Asensi 2.8.6a:n. Pari päivää tämän kanssa tappelin ja luovutin. Ei toimi.

HP:n sivuilta uusi 3.10.5 Hplip ladaten ja asentaen. Asentaminen oilskin sitten aikamoinen trial-by-error ja sisälsi noin 20 muun Debianin dev -paketin asentamisen. Udev -toiminnallisuus firmwaren on-demand -lataamiseen toimii. Firmwarekin löytyi joltain sumuiselta .ru saitilta. Tulostusjonoja on erilaisten konfisteluiden jälkeen varmaan 27 erilaista. Yksikään ei tulosta. Huomaa muuten asennuksessa, että Hplip valittaa puuttuvasta kirjastosta, mutta tarkoittaa ko. kirjaston -dev versiota aina…

Cupsd:n logitus on surkeaa jopa debug moodissa, mutta yhdestä rakosesta vilahtaa virheilmoituksesta vinkki ; “foomatic-rip-hplip no such file”. Ahaa.

KVG

Onneksi yhdestä keskusteluketjusta löytyi vinkki, että hplip:in asennusohjelma on mitä on ja että homma pitää tehdä itse komentoriviltä (no niin tietysti, miten ajattelinkin toisin . Configure -skriptille pitää luetella optiot eri tavalla, kuin asentaja ohjelma ne tekee. Foomatic-rip-hplip ei nimittäin muuten ainakaan Debianissa toimi. Asentaja antaa drivereille jollain sumealla logiikalla –disable määreitä, kun joillain pitää olla –enable. Käytännössä siis ; aja asentaja, jos ei toimi => muuta configure:n kaikki drivereitä, foomaticcia ym. koskevat –disablet –enable:ksi.

No tämän jälkeen hplip alkoikin toimimaan ja Debianista nyt saa tulostettua paikallisesti. Sitten ne muut koneet…

Puuttuva OSX ajuri 1018:lle

Tulostimen voi jakaa eri tavoin verkkoon. Ensin tein sen Samballa. Hetki meni ymmärtäessä miten näitä “erikoisia” tulostusjonoja lisätään OSX:ään. Tarvittava dialogi nimittäin puuttuu valikosta (Tulostimet ja faksit => Lisää => Lisävalinnat on se joka puuttuu) ja sen ikoni pitää ensin lisätä toolbaariin (mistä tämä olisi pitänyt tietää?). Jonon saa sitten nätisti Macista kiinni, mutta 1018 ajuria ei tietysti ole. Tavara päätyy jonoon asti, mutta on väärässä muodossa ja menee roskiin. Tätä päättelyä en kuitenkaan heti osannut tehdä, joten tuli mahdollistettua myös suora cupsd IPP -tulostaminen cupsd:lle verkon yli (lisää IP osoite -> Allow from x.y.z.f cupsd.conf:iin). Muista avata portti 631 iptablesta sekä udp-, että http-protokollille. No kaikkinensa, tavara tulee kaikilla perille, mutta ei tulostu, kun ajuri on väärä ja faili sopimatonta.

Foo2zjs, gs ja foomatic

OSX:aan saa 1018 ajurin asentamalla foo2zjs paketin. Se vaatii kaverikseen paketit Ghostcript ja foomatic. Ne kaikki onneksi kääntyvät ja asentuvat nätisti, kunhan uusin XCode on asennettuna. Yhden illan turaamisen jälkeen 1018 ajuri löytyy hienosti asennusdialogista. Ei vaan toimi. Mihinkään ei tule mitään virheilmoitusta, mutta koska Debianin cupsd:lle menee n. 240 tavua huolimatta mitä tulostaa, voinee olettaa että Macistä lähtee tyhjä tiedosto.

FOOMATIC ja FOO2ZJS SAAMINEN TOIMIMAAN: Valehtelematta meni viikon illat, koska en antanut periksi tälle ongelmalle. Lopulta Samba tulostuksen autentikointivirhe sai Macin cupsin tulostamaan sellaisen error_login, josta Foomaticin toimimattomuuden syy selvisi:

D [03/Aug/2010:21:57:11 +0300] [Job 74] /usr/bin/foo2zjs-wrapper: line 213: gs: command not found
D [03/Aug/2010:21:57:11 +0300] [Job 74] /usr/bin/foo2zjs-wrapper: line 816: gs: command not found

Eli todellakin arvaus piti paikkansa, eli tyhjä tiedostohan sitä Macistä lähti. Jostain syystä tuon wrapperin (joka on Perliä) toiminnassa oli kaksi virhettä:

1) Foomatic ei saanut ladattua moduleitaan, koska Foomaticin asennuskripti ei osaa laittaa oikeaan paikkaan Perl moduleita. Ratkaisin asian kopioimalla käsin asennushakemistosta foomatic-db-engine-4.0.4/lib/Foomatic -hakemiston /System/Library/Perl/Extras/5.10.0/ alle.

2) Foo2zjs-wrapper ei löytänyt Ghostscript (eli gs binaaria)

Vaikka gs toimii komentoriviltä (/usr/local/bin:issä kun on) kaikilla halutuilla käyttäjillä, typerä skripti arpoo sen pieleen. Korjasin lisäämällä /usr/bin/foo2zjs-wrapper skriptiin riville 185:

GSBIN=/usr/local/bin/gs

Tulee kohtaan “Process the options” juuri ennen CMDLINE=”$*” -riviä.

Vaihtoehtoinen korjaus postscript -kikkaa käyttäen, tosin rikkonaisilla marginaaleilla

Luovutus oli monesti lähellä, mutta huomasin cupsd:n logista, että “auto recognizing file”. Hmm. Debianissa kun on kaikki mahdolliset Ghostscript ja foomatic filtterit ja ne toimivat, joten mitähän jos tuolle syöttäisikin ps -tiedoston ? No eikun kokeilemaan ja taas jono kiinni OSX:stä, ajuriksi “Generic postscript printer” ja voilá! Macista lähtee nyt IPP-http:nä postscript -tiedosto, jonka Debianissa oleva tulostusjono tunnistaa ps:ksi ja vääntää sen printterille sopivaksi. Tulostuvat kuvat ja tekstit niin kuin pitääkin. Case almost closed. (Paitsi että oli marginaalit pielessä. Tämä toimi siksi, ettei foomaticcia käytetty ollenkaan. Jos säätäisi marginaalit PPD tiedostosta käsin kohdilleen niin saattaisi toimia.)

Luovutinkin kerran jo

Tarina sai sikäli myös epäonnellisen lopun, että kävin ostamassa offset -ongelmien takia uuden HP P1102 tulostimen 89 eurolla Expertistä. Sen mukana tullut HP:n asennuspaketti kuitenkin sai jatkamaan tuon 1018:n kanssa tappelua, sillä uuden tulostimen mukana tuli myös “piilotettu” foo2zjs asennus. Uusi tulostin nimittäin käyttää sitä samaa, joskin HP on vääntänyt siitä omat binaarinsa (rastertozps). Sitäkin yritin käyttää, mutta kun tuosta paketista taas puuttui 1018 tuki, niin tulostinten erilainen resoluutio sai rasteroinnin epäonnistumaan. Hyviä vinkkejä siitä sai!

Nyt on sitten kaksi toimivaa tulostinta

English summary

To be able to print to HP Laser Jet 1018 from Mac OSX, you need to do a lot. The only way seems to be to use foo2zjs package, which I first didn’t get to work. Instead I installed a remote printer to my Debian bpx using HP’s version of hplip 3.10.5. After discovering, that in Debian 5.0.4 the installation script composes a wrong configure statement (disables drivers instead of enabling them) I got to work it locally in Linux. Even the on-demand firmware download works as an udev script. After that, it was simple to share the printer through the network to Mac. Both Samba and IPP work just fine.

Since my foo2zjs on OSX  (probably due to foomatic problem) does not work (always outputs 237 bytes of something, probably just an error message) I’m using the general postscript driver for that print-queue and the Debian hplip then translates that to what-ever-that-monster-printer-talks. That works automatically, since the hplip installation works. However, it has wrong margins for the print-area, which might be fixed by editing the PPD (I didn’t have spark to do it).

I did buy the new printer too… 89 euros with OSX support for HP P1102. But since it came with HP’s version of foo2zjs, which worked, it gave me more strength to fight the 1018 installation too. Unfortunately the package for P1102 lacks driver for 1018 and it uses HP’s own rastertozps binary, I wasn’t able to use that driver for 1018.

I got foo2zjs and foomatic to work at last. There were two problems:

1) Foomatic couldn’t load it’s Perl modules (installation script doesn’t recognize Apple’s Perl version’s @INC

=> Copy directory foomatic-db-engine-4.0.4/lib/Foomatic into /System/Library/Perl/Extras/5.10.0/

2) Foo2zjs-wrapper can’t locate gs, even it works from command line (/usr/local/bin/gs)

=> Add following to /usr/bin/foo2zjs-wrapper as line 185

GSBIN=/usr/local/bin/gs

To subsection “Process the options” just before line CMDLINE=”$*”

After that it works. Voilá!

Päivitys Plus -malliksi toi kaivattua lisävauhtia sekä vihdoinkin 2.6 kernelin. Ohjelmien kehittäminen helpottuu ja saataville tulee aimo pläjäys tuttuja ohjelmistoja, jotka voi kätevästi kääntää käyttöön OpenEmbedded:in avulla. Voit myös käyttää pelkästään laitteen omaa kehityspakettia. Katso artikkelit ohjelmistokehityksestä ja ristiinkääntämisestä.

Miten sitten käännän näillä ohjelman Moxalle ? Asenna Moxan CD-ROM:ilta roottina työkalut suorittamalla tool-chain/Linux/xscale_be_1_1.sh. Oletusasennuspaikka on /usr/local/xscale_be ja sen alta löytyy hakemisto sitten  armv5teb-montavista-linuxeabi. Siltä löydät /bin ja /lib hakemistot, joita tarvitset kehittämiseen. Binistä löytyvät tutut gcc, ar, as, cpp, g++ ja niin edelleen.

Täydellisessä maailmassa ohjelmiston kääntäminen onnistuisi asettamalla ympäristömuuttujaan CC tuo XScale kääntäjän polku sekä komentamalla configure skriptille esim. –build=i686-pc-linux-gnu –host=armv5teb-montavista-linuxeabi –target=armv5teb-montavista-linuxeabi –enable-strip –enable-static.

Käytännössä vaan tuotettu Makefile sisältää erilaista kovakoodattua viittausta CPP:hen ja muihin lisätyökaluihin. Käy siis tiedosto läpi ja käännä käännöstyökaluviittaukset osoittamaan Toolchainiin. Aika monet Makefilet jättävät stripin ajamatta uudelle binaarille, joten jos käännetyn ohjelman koko on posketon, aja strip vielä binaareille manuaalisesti.

Aika monet ohjelmistot kääntyvät melko kivutta tällä metodilla (esim. Nut-2.4.1, ltermcap, ncurses, MicroEmacs, …)

Aika kätevä tapa on kirjoittaa Makefileen “install” osio, joka kopioi suoraan scp:llä binaarit Moxaan haluttuun hakemistoon.

Toinen lähestymistapa on käyttää OpenEmbedded kehitysympäristöä, joka osaa ristiinkääntää ohjelmistoja todella automatisoidusti. Katso asennusohjeita täältä.

Sulautetut Linux palvelimet ovat varsin kätevä tapa kehittää automaatiota teollisuudessa ja miksipä kotiautomaatiota ei voisi rakentaa myös samalle alustalle. Ainakin allekirjoittanut arvostaa suuresti jokaista kohdetta, missä herkästi vikaantuvat PC-pohjaiset integraatiokomponentit korvataan levyttömällä, virtalähteettömällä ja täysin passiivisesti jäähdytetyllä laitteella. MontaVista Linuxin luotettavuuskin on uskomatonta luokkaa. Uptimet vierähtävät helposti vuosiin.

Pohjalla on kuitenkin Linux, joten integrointi, valvonta ja hallittavuus ovat aiempia DOS-pohjaisia laitteita huomattavasti kehittyneempiä. Moxa:n UC-74xx sarjan laitteet tulevat MontaVistalla, Busybox komentopaketilla ja muutamilla olennaisilla valmiiksi asennetuilla ohjelmistoilla (kuten Apache2).

Ohjelmien lisääminen käy mukana tulevalla työkalupakilla (Linux 2.6 Toolchain), joka valitettavasti on kovin jälkijättöisesti päivitetty. Uusin versio on vuodelta 2007 ja alustaksi suositellaan Fedora FC5:ttä. Sitähän ei missään ole enää ollut olemassa aikoihin… Onneksi sellainen vielä löytyy, joten VMwaren päällä tuota voi sitten kehitysympäristössä ajaa.

Toinen mielenkiintoinen tapa kehittää (=kääntää) sovelluksia sulautetulle alustalle on OpenEmbedded -projektin työkalupakki. Valitettavasti Moxa:lle ei sopivia konfiguraatioita löydy ja MontaVista ei ole toistaiseksi tuettujen jakeluiden listalla. Hyötyä tästä on kuitenkin sikäli, että tuota valmiiksi käännettyä Toolchain:ia voi käyttää OpenEmbedded:in kanssa (=kääntää valmiilla kääntäjällä ja kirjastoilla). Se mitä tästä hyötyy on Bitbake:n mainio cross-compile -kirjasto, jonka avulla saa tutut ohjelmistot todella helposti käännettyä MontaVistalle (esim. Python, Perl, Wget, Samba, Strace ,…)

Niiden ohjelmistojen kääntäminen, jotka Bitbake:n resepteistä löytyy, on todella helppoa (“bitbake perl”). Muiden ohjelmien tapauksessa helpoimmaksi osoittautui configure -skriptien parametrointi ja niiden generoimien Makefile tiedostojen muokkaus (useat ohjelmat eivät noudata configuren –build, –host ja –target määreitä vaikka ne ymmärtävätkin). Käytännössä skriptin generoimista Makefile -tiedostoista riittää CC määreen kääntäminen osoittamaan Toolchainin kääntäjään, sekä muiden vastaavien (esiprosessorin, stripin jne.) korjailu. Oma haasteensa ovat ohjelmat, jotka viittaavat toisiin kirjastoihin, koska joudut kääntämään myös ne erikseen (esim. libneonxml, ncurses, termcap, …).

OpenEmbedded:in käyttöönvaljastaminen ei ollut kaikkein selkein prosessi, joten katso täältä ohjeita. Läpi käydään ainakin ympäristömuuttujat sekä local.conf joka pistää Bitbaken käyttämään Moxan omaa Toolchain:iä (sekä esitellään nerokkaat tyhjät MACHINE ja DISTRO konfiguraatiotiedostot). Toivottavasti näistä ohjeista on hyötyä – itse käytin yhden sunnuntain sählätessäni näiden kanssa, asia kun ei ollut tuttua

English summary: Embedded Linux computers are a great thing for industrial automation builders, not forgetting the home automation. Building software for embedded distributions can be tricky though and there OpenEmbedded project comes to help. The article provides pointers to setup OpenEmbedded with pre-built toolchain for Moxa-UC7420+ embedded computer. Bitbake provides great collection of cross-compile recipes for the most popular tools for system design like Python, Perl, Samba and so on. See the installation article and examples for setting up OpenEmbedded and Bitbake as well as example envs script for setting the compile environment and local.conf for deploying pre-build toolchain. Also genious empty MACHINE and DISTRO config files need to be setup.

If OpenEmbedded does not carry a receipe for your most wanted app, you can allways cross-compile it with the Toolchain from the source. Please note, that many configure -scripts do accept –build, –target and –host parameters but never actually use them. So you need to manually fix the automatically generated Makefiles. Usually pointing CC to Toolchain gcc, ar, strip and other friends is enough. Remember to cross-compile the referenced libraries too!

The most annoying feature with Moxa is the pretty old Toolchain package, which is made for Fedora FC5. That has been unsupported for some time now, so prepare yourself for some serious tuning with some other 2.6.10 linux kernel distro. I managed to find an old installation CD set, that allowed me to run FC5 in VMware.

Tässä versiossa (kun molemmissa päissä 0.9.0) toimii HD kanavan eli H.264 DVB videostriimin striimaus verkkoon (toki myös mpeg2 striimit). Libavcodec ei linkkautunut minulla oikein, joten esim. transcoodaus ei toimi. Sitä ei tässä tapauksessa nyt edes tarvita, joten olkoot rikki.

1) Asenna git-1.5.6.4

2) Check-outtaa VLC ja X264 gitillä

3) Asenna a52dec-0.7.4

4) Päivitä tarvittaessa vähintään autoconf-2.60

5) Päivitä tarvittaessa dbus (käytin dbus-1.1.20)

6) Asenna yasm-0.7.1

7) Käännä ja asenna X264 kirjasto. Käytetty versio:

#define X264_VERSION ” r928 4816918″
#define X264_POINTVER “0.60.928 4816918″

8 ) Käännä ja asenna VLC

Käännös ei löytänyt minulla .pc tiedostoja, joten sanoin ennen makea export PKG_CONFIG_PATH=”/usr/local/lib/pkgconfig”. Configure ne kyllä löysi, mutta tuolla tempulla se onnistui myös kääntää.

Lopputulos:

VLC media player 0.9.0-test3 Grishenko
[00000001] main libvlc debug: VLC media player - version 0.9.0-test3 Grishenko - (c) 1996-2008 the VideoLAN team
[00000001] main libvlc debug: libvlc was configured with ./configure '--enable-debug' '--enable-pp' '--enable-gpl' '--with-ffmpeg-tree=/root/vlc/ffmpeg' '--enable-v4l' '--enable-dvb' '--disable-mad' '--enable-vcdx' '--disable-wxwidgets' '--disable-skins2' '--enable-shared' '--disable-fribidi' '--disable-v4l2' '--with-x264-tree=/root/vlc/git/x264' 'PKG_CONFIG_PATH=/usr/local/lib/pkgconfig'
[00000001] main libvlc debug: translation test: code is "C"
VLC version 0.9.0-test3 Grishenko
Compiled by root@lelux.
Compiler: gcc version 4.1.1 20070105 (Red Hat 4.1.1-51)
Based upon Git commit [e3da66b706]

Toimii tosi nätisti, eli 2.8.2008 git versiot vlc:stä ja x.264:stä käännettynä ja YLE Peking HD näkyy kotikoneissa. Verkkoon sen puskee vanha P4 1.8 Ghz Fedora FC5 Linux Budget DVB-T kortilta. Lähete näkyy 0.9.0 playerillä XP:ssä, Vistassa ja OSX:ssä.

Vihonviimeinen vänkä oli udp, joka ei toimi (ilmeisesti FC5:ssä) tuolla VLC versiolla, mutta http:llä homma toimii. Tietysti kauneusvirhe, kun udp multicast olis kiva.

Kuvanlaatu on äkkiseltään parempi VLC:llä (tai ainakin yhtä hyvä), kuin tuolla Fujitechin Total Media katseluohjemalla. Tosin Vistassa toisto rykii aika-ajoin pahasti (vaikka CPU utilisaatio on n. 50%). MacBook taasen toistaa homman ilman ongelmia.

Olihan savotta. Tuli taas verestettyä muistia autoconfin ja m4:n kanssa turaamisesta, kun näyttää olevan talon tapa, että VLC:n, mediakirjastojen ja ffmpegin configure skriptit ovat rikki. Paria funktiota piti puukottaa, jotta homma saatiin urille. Ja miksi tähän pitää ryhtyä ? Hyvä kysymys.

Alkuperäinen pitkä tarina aiheesta täällä.

cd DarwinStreamingSrvr6.0.3-Source/
patch -p1 < dss-6.0.3.patch
./buildtarball
cd DarwinStreamingSrvr-Linux
./Install

Sellainen käpy sattui itselläni, että qtss käyttäjän ja ryhmän lisääminen meni pieleen aluksi (käytin tosin eri asennuskriptiä kuin tuo). Toimi kyllä, kun loi ne käsin ja ajoi sitten asennuksen uudelleen. Tuo tarripalloasennus saattaa toimia paremmin. DSS:n löydät tietty täältä.