a linux desktop éve

Sajnos kénytelen vagyok ezt árnyalni.

Lenny alatt elég gyötrelmes kézimunkával sikerült felkalapálni egy használható ffmpeg csomagot. Végül csak sikerült meggyőzni a wengophone-t, hogy videót is továbbítson. Így volt öröm és bódottá, mert FLOSS-szal lehetett windows és linux között videofonálni a családban. (Az ekiga nem támogatja a titkosítást, már sok-sok éve, úgyhogy kénytelen vagyok azt feltételezni, hogy szándékosan.)

A Squeeze jól betett a videofonyálásnak.

Lenny alatt a gspca webcam-család meghajtója külön csomagban található (forrás, bináris). Ez a driver határozottan sokoldalú volt, és némi modparam reszelés után korrektül ment vele a qtwengophone. Ha nem tévedek, a driver kerneltérben végzett színtér-transzformációt. A forrás-színteret én adhattam meg modparammal.

A webcam-om egy mezei "046d:092f Logitech, Inc. QuickCam Express Plus". Ezt támogatta is a külön csomagolt driver, miután kézzel megadtam valami gbrg-re emlékeztető modparam-ot (már nem emlékszem pontosan).

A squeeze ezeket a változásokat hozta:

  • A gspca driver bekerült a 2.6.27 kernelfába (ha jól olvastam). A driver képességeit jól megcsonkították, a színtér-transzformációt userspace-be száműzték. (Ennek egyébként még lenne is értelme.) Ha jól tévedek, a driver innentől csak natív (gbrg?) stream-et ír a /dev/video0-ba az én webcam-om esetében. Lásd ezt és ezt.
  • Ettől rengeteg program fejreállt. Sajnos most nem találom azt wiki oldalt, ahol részletezték a státuszt, de lényegében az összes /dev/video0 fogyasztó lyukra futott. Úgyhogy arra az "átmeneti" időre, amíg a kliensprogramok át nem állnak a colorspace transform kézi bekapcsolására az új libv4l-ben, készült két wrapper (preload) lib:
    /usr/lib/libv4l/v4l1compat.so

    és 

    /usr/lib/libv4l/v4l2convert.so

    . Ez pótolja a kernelből kikerült colorspace transform-ot, a kliensek számára észrevehetetlenül.

  • Az mplayer pl. tökéletesen megy ezzel a módszerrel. A Squeeze-ben lévő qtwengophone, akarom mondani, frissített qutecom, azonban nem. A wrapper lib-ek nélkül semmit sem látok, a fenti kettő wrapper lib bármelyikével pedig látok valamit, de a kép szét van esve.
  • A hiba ismert (konkrétan az egész web tele van vele), és állítólag a 3.0-s alfa verzióban a qutecom javítja is. Mondanom sem kell, az még a sid-ben sincs csomagolva.

A kernel, a wrapper lib, és a kliens kód között szépen elveszett a helyes színtér-transzformáció, jókora regressziót okozva rengeteg (közös gyökerű) webcam-nál. Az idei sem a linux desktop éve!

( uid_4263 v | 2011. 11. 13., v – 12:11 )

Én kb. 1 hónapja dobtam a debian stable -t desktop/munka terén, megütötte az elavultság az ingerküszöböt (és gépet is váltottam, így egyébként is foglalkozni kellett a dologgal).

--
http://neurogadget.com/

Az otthoni gépen szeretnék debian-nál maradni. A testing-et sokan ajánlották, de arra nem ígérnek ugyanolyan szintű biztonsági támogatást.

Nyilván senkire sem tudok mutogatni; egyrészt mert senki nem tartozik nekem semmivel :), másrészt mert ez egy koordinációs probléma, ahol egyik projekt sem hibás egymaga. Fizetős supportnál ilyenkor backportolják a qutecom javítását.

Marhára nem old meg semmit, csak random dolgokat. Például gitg. 0.0.6 van stable -ben, de elég bugos (nagyobb commitok meg egyáltalán többezer revision mellett rendszeresen segfaultol). Backports -ban nincs, forrásból telepíteni esélytelen a rendszer felborítása nélkül (új GTK, új GNOME, új ez-az-amaz kell neki). Az upstream -ben meg rengeteg új változat van már.

--
http://neurogadget.com/

Én etch-en használtam (ha jól rémlik) inkscape-et, meg gimp-et, unstable chroot-ból futtatva. Teljesen oké volt.

Annyi hogy a debootstrap-pel létrehozott rendszerben is érdemes beállítani a gtk-s témát meg letelepíteni a gtk-s kiegészítőket, hogy ne legyen csúnya a chroot-ból indított cucc. Vagy persze azt is meglehet csinálni, hogy bemásolod az egész jelenlegi rendszeredet még egyszer egy mappába, majd chroot-olsz bele, és felupgrade-eled testing-re, majd unstable-re.

Ha esetleg nem használtál volna nagyon chroot-ot (nem tudom), akkor érdemes rendszer induláskor lefuttatni a "mount --bind /proc /chroot-dir/proc" parancsot. Vagy akár még más bind-okat is létrehozni, pl. a home-mal kapcsolatban. Meg ha új a chroot (jobban preferálom, mert kicsi lesz, főleg --minimal kapcsolóval), akkor még érdemes átmásolni az /etc/passwd, group meg shadow fájlokat is hogy stimmeljenek az uid-ok.

Én a progikat így futtattam:

./chroot_run.sh progi

A script meg így néz ki valahogy:

#!/bin/bash
xhost local:
chroot /chroot-dir "$@"
xhost -

Esetleg ez még hasznos lehet. Különösen strangelove chroot generáló script-je.

( bervi | 2011. 11. 13., v – 23:12 )

"(Az ekiga nem támogatja a titkosítást, már sok-sok éve, úgyhogy kénytelen vagyok azt feltételezni, hogy szándékosan."

nem-nem. ez csak egyszerűen a "választás szabadsága". vagy mi... pidgin-nel a mai napig nem tudok fájlokat küldeni (az utóbbi időben egyáltalán nem, de korábban is csak proxy-zva ment, amikor ment). ezt a meglehetősen alapvető problémát 13 év alatt nem sikerült még megoldaniuk.

[ NeoCalc - Earnings Calculator for NeoBux | Family Gags - Cutaway Gags from Family Guy ]

( agolon | 2011. 11. 16., sze – 21:11 )

Aki egy kicsit ismeri az X működését, az tudja, hogy micsoda hatalmas ötlet ilyen alapokra bármit felépíteni.