X.Org Server 1.8.0 - udev místo HAL (diskuse)

[disorder]

nove? mam 1.7.4 s udev...

[chrono]

V takom prípade možno tvoja distribúcia pridala nejaké záplaty. Práve som pozeral zdrojové kódy verzie 1.7.6 a udev podpora v nich ešte nebola.

[disorder]

neviem...

xorg-server (2:1.7.2-1) experimental; urgency=low

* Use libudev instead of libhal for input hotplug on linux.

-- Julien Cristau <...> Sat, 28 Nov 2009 16:48:43 +0100

[chrono]

To nie je špecifické pre Ubuntu (prípadne Debian)?

[Sten]

Je to debianní úprava, je to změněné ve verzi za pomlčkou

[trekker.dk]

Tak tomu se říká, že trpělivost přináší růže. Po několika letech vytrvalého vypínání HALu ručně jsem konečně mohl udělat apt-get remove --purge hal a prošlo to bez odinstalování čehokoliv.

Zase jednou o zbytečný proces míň.

[blami]

Jojo. Tady je aspon videt jak ty vsechny dnesni Kity, HALy a DBUSy potrebujeme...

[andree]

yoyo, ubuntaci (alebo debianaci, ako sa pise nizsie) to backportovali...

[JoHnY2]

Podle me jednoznacne krok spravnym smerem. Pokud jsem mel s Xkama potize, tak to vzdycky bylo diky problemum HAL/Driver/Kernel. S udevem by to melo jit o dost lip.

[vencour]

V gentoo při včerejší aktalizaci xorg-server 1.7.6. Flag -hal používam někdy od verze 1.7.

[Marián Kyral]

Jé to zase bude katastrofa. Člověk horko těžko zjišťoval, jak vlastně přemigrovat na hal a když to konečně šlape jak má, tak bude pro změnu horko těžko migrovat na udev

Konfigurace je zpět v xorg.conf nebo je třeba vytvářet nějaká super duper udev pravidla?

[vencour]

Jen jsem nastavil flag, překompiloval x11-drivers, xdm a bylo to. Je to cca 3 měsíce, přesně si nevzpomínam.

[Marián Kyral]

No že se vůbec ptám

[thingie]

Zkus se ptát někde, kde mají rozum. Ne u těch… no, těch.

[Marián Kyral]

já se zeptal Googlu. Bohužel ti co mají rozum tam nejsou tolik populární. Stejně si počkám, až se něco objeví na forums.gentoo.org.

[Scarabeus IV]

Hint od cloveka co bude tu dokumentaci psat:

ENV{ID_INPUT_KEYBOARD}=="?*", ENV{x11_driver}="evdev", ENV{xkblayout}="us,cz",
ENV{xkbvariant}=",qwerty",
ENV{xkboptions}="grp:alt_shift_toggle,terminate:ctrl_alt_bksp"
ENV{ID_INPUT_MOUSE}=="?*", ENV{x11_driver}="evdev"

[thingie]

Kdybyste raději napsali pořádnou dokumentaci k tomu xorg.conf.d…

[chrono]

Ako to funguje je podľa mňa zrejmé aj bez čítania dokumentácie (keďže to nebude prvý program používajúci taký spôsob konfigurácie).

[andree]

nahodou je to celkom lahke, nie je az taky problem spravit mapovanie 1:1 medzi hal a udev pravidlami.. aspon medzi tymi jednoduchymi... akurat udev nepouziva xml, ale jednoduchu skriptovaciu syntax, co mne osobne vyhovuje...

[Michal Kubeček]

nie je az taky problem spravit mapovanie 1:1 medzi hal a udev pravidlami.. aspon medzi tymi jednoduchymi

U nejjednodušších ano, ale obecně je syntaxe HALu podstatně silnější a umožňuje pravidla lépe a přehledněji strukturovat.

[Martin Böhm]

No, ale "-hal" Ti (v soucasnem gentoo) nevyresi autodetekci zarizeni pomoci udevu, ne? Jen si to musis naklepat v xorg.conf sam.

[vencour]

Zatim mi stačilo "X -configure" a s tim jsem jel.

[Tomáš]

Takže s trochou laborování s pravidly udev docílím toho, že vyndám klávesnici z českými popisky, zapojím klávesnici s azbukou a X-ka přepnou rozložení klávesnice z češtiny do ruštiny?

[Marián Kyral]

A není lepší mít obě klávesnice připojené a podle toho na které píšeš, by se určovalo rozložení? To fyzické přepínání mi přijde takové nešikovné. Ale zase nevím, jestli by šlo docílit toho chování, které jsem navrhoval.

[andree]

ak si to dokazal pomocou hal, tak by to nemal byt problem pomocou udev...

[blami]

Jo to normalne pujde. Pokud si teda koupis dve klavesnice ktere se pomoci udaju exportovanych kernelem daji dost jednoznacne identifikovat. Pokud chces mam genialni prekomplikovanej setup s dvema klavesnicema jp/en/cz + en/cz (obe maji navic trackpoint a jedna ma navic touchpad), mysi a synaptics tabletem :)) vsechno funguje skvele a prislusna pravidla se aplikuji jen na vybrana zarizeni ;)

[JoHnY2]

Pokud na to udelas patch, tak to bude v X.Org 1.14

[Konqui]

Není to trochu schizofrenie? Napřed HAL, teď udev - vývojáři neví do čeho píchnout....Xka na desktopu by měly chcípnout, neznám horší a něnažranější věc.,,Ten vývoj fakt spěje doprdele...

[Neel]

Znáte nějakou alternativu? Třeba i nějakou v pre-vývoji.

[podhaj]

wayland? http://www.phoronix.com/scan.php?page=article&item=xorg_wayland&num=1

[imploder]

Zaujalo mě, co popisují tady: EROS Trusted Window System

Je to pro systém EROS (jeho nástupce je teď Coyotos), zatím experimentální, ale prý to má být částečně kompatibilní s Linuxem (někdy, až to bude - tj. možná nikdy). Ten window systém je udělaný tak, že jsou aplikace i na společné ploše bezpečně oddělené a vstup od uživatele se nedá falšovat.

X.org má některé docela nepříjemné vlastnosti:

• každý program si může dělat co chce, okna různých programů na jedné ploše (i pod různými uživateli) před sebou nejsou v bezpečí
• není problém, aby jakýkoliv program bez vědomí uživatele fungoval jako keylogger
• když X server spadne, jsou všechny okenní programy v háji, tj. v dnešní době skoro totéž, jako by spadl celý systém
• (...)

Prostě tam chybí vynutitelnost a bezpečné oddělení jednotlivých programů. Přitom je běžné si pustit nějakou adminskou aplikaci na ploše společně s uživatelskými.

Navíc se tam píše, že EWS překvapivě vyšel výrazně menší a jednodušší než Xka i s tím zabezpečením. Kdyby měly unixy a Linux vyměnit Xka za něco jiného, tak by se rozhodně měly tyhle věci řešit. Až se bude místo X.org používat něco na úrovni EWS, pak teprv bude UNIX/Linux doopravdy odolnější proti malwaru a nebudou to jen kecy založené na tom, že se akorát nikomu nechce ty viry/trojany dělat.

Samozřejmě jsou i jiné možnosti než zneužití window systému, jak může na unixu malware krást data nebo se nabourat do systému. UNIX asi nikdy nebude přidělovat oprávnění zvlášť každé aplikaci, tak aby to jednoduše fungovalo (teda pokud admin není expert na nastavení SELinuxu), nebyl na to navržený. Ale prostě fakt, že si cokoliv může jen tak v Xkách odposlouchávat hesla atd., je docela velký problém.

[Ondrej 'SanTiago' Zajicek]

když X server spadne, jsou všechny okenní programy v háji,

To neni uplne pravda. Bez problemu jde napsat X program, ktery by prezil pad X serveru a po opetovnem prihlaseni znova vytvoril sve Xove objekty, ale nikdo to tak nedela.

Co se tyce bezpecnostnich problemu X, tak jediny vyznamny dysledek je v tom, ze by se clovek nemel prihlasovat s povolenym X forwardingem na mene duveryhodne stroje.

Ale co se tyce procesu jednoho uzivatele na jednom stroji, tam je to uplne jedno - procesy jednoho uzivatele od sebe stejne nejsou dost izolovane na urovni jadra a existuje spoustu moznosti, jak jeden proces muze ovlivnovat ostatni procesy stejneho uzivatele (treba moznosti pres soubory v /proc), ze jedna moznost navic uz nehraje roli.

Bezpecne oddeleni aplikaci na urovni X serveru by se hodilo, kdyby bylo zvykem nektere procesy (treba webovy prohlizec) spoustet s nizsimi pravy nez jsou bezna uzivatelska prava.

[Dusan]

Hm hm zaujímavé informácie.

[Michal Kubeček]

Navíc se tam píše, že EWS překvapivě vyšel výrazně menší a jednodušší než Xka i s tím zabezpečením.

Pak se ovšem nabízí otázka, jestli opravdu umí všechno co X nebo jen to, co autoři považovali za důležité.

[D.A.Tiger]

Xka na desktopu by měly chcípnout, neznám horší a něnažranější věc

Já už ano - Firefox.

[chrono]

Je zaujímavé, že práve nízka spotreba pamäte je jedna kategórií, v ktorých Firefox zvyčajne nad ostatnými prehliadačmi vyhráva.

[D.A.Tiger]

No, to (alespoň na mém systému) nebyla pravda. Spotřeba paměti, stejně jako zatěžovaní proceru prudce kolísala a v případě paměti byla schopná vyrůst až na 10-15%, v případě procesoru klidně až na 50% (i s vypnutým flashem). Xorg zabírá pamět od 0 - 15% a procesor 1.5% stabilně.

Opera u mě má stabilně paměť 5,6% a zátěž procesoru nepřestoupí 20%

(měřeno pomocí top a htop)

[D.A.Tiger]

PS. omlovám se, ale u toho XOrgu jsem přehodil hodnoty. správně má být CPU 0-15% a MEM 1.5 stabilně...

[Michal Kubeček]

http://www.bugemos.com/?q=node/196

[D.A.Tiger]

[trekker.dk]

Házet číslama jako 5% paměti je fakt hezké, akorát bychom ještě potřebovali vědět, kolik máš paměti. Ono přece jenom 5% z 8GB je taky poměrně hodně.

Jinak mě se občas Opera "zblázní", zátěž procesoru vyskočí na 100%, i když se nic nedělá (flash plugin nemám) A paměti si taky dovede pápnout hodně, řádově GB a více.

A jinak ... fuck Opera Prohlížeč slušný, ale jinak jsou to blbečci.

[D.A.Tiger]

2GB, ale to není v tomto případě nijak podstatné. Jde o ten poměr - 5% je vždy méně než 50%, ať už máte 250MB, nebo 8GB.

Jinak s Operou nemám problémy vůbec žádné - a to flash plugin používám. Jen občas mi někdy chybí některé doplňky, které byly k dispozici pro Firefox... Ale jinak Opera rulez.

[JeChW]

A proč Ti vadí, že prohlížeč využije dostupnou paměť? Prohlížeč tam má nakešované stránky, aby si se mohl pohybovat rychle v historii. Pokud by tu paměť potřeboval jiný program (rozuměj začala by docházet), prohlížeč ji okamžitě uvolní. Takže prohlížeč, který používá pořád stejně paměti, je špatný, funguje neefektivně. To samé se dá říct o prohlížeči, který není schopný využít 100% CPU.

[trekker.dk]

Pokud by tu paměť potřeboval jiný program (rozuměj začala by docházet), prohlížeč ji okamžitě uvolní.

Tohle není pravda. Když začne docházet paměť, začne se swapovat a/nebo nastoupí OOM killer. Prohlížeč nemá žádnou možnost zjistit, že paměť dochází (rozhodně ne nijak moc přesně); navíc silně pochybuju, že by to nějaký dělal.

A když si Opera nakašuje giga a půl stránek na systému s 2GB paměti celkem, tak to neustálé swapování je na výkonu poznat opravdu dobře, to mi věř.

[D.A.Tiger]

Nevím, ale mě to přijde jako trochu zbrklý krok zpět.

V čem pomůže přechod XOrg o úroveň níže? Xserver si nyní bude muset obstarávat sám všechno, co dělal HAL pro celý systém. To znamená rozpoznat graf. zařízení, načíst ovladač a hlídat stav zařízení na základě událostí z udev. Takže se dostaneme do situace, kdy dva dělají totéž - to mi jako vyhovující řešení zrovna nepřipadá.

Spíš bych se na místě vývojářů XOrg pokusil ve spolupráci s vývojáři HAL/D-BUS lokalizovat problém, který bude dle mého názoru buď ve špatné konfiguraci HAL/udev, pro některý grafický hw.; nebo ve špatně řešené komunikaci mezi HAL a XOrg...

[kouby]

HAL je deprecated a uz dale neni vyvijen - snad jen mirne udrzovan do doby nez vetsina aplikaci prejde na neco jineho. Takze proc zbrkly krok zpet?

[Michal Kubeček]

HAL je sice oficiálně deprecated, ale při bližším prozkoumání zjistíte, že DeviceKit má dělat v podstatě totéž co HAL a že jeho definiční soubory vypadají a fungují naprosto stejně jako ty od HALu…

[thingie]

To je nějaký divný pohled [1]. Když se totiž skutečně podíváte, zjistíte, že žádný DeviceKit už není, jsou jenom démoni UDisk a UPower, kteří dělají pár věcí, na které by samotný udev jen tak nestačil (třeba historii nabíjení/vybíjení baterie a opravy odhadů a tak), jinak žádný další démon nikde neběží, narozdíl od HALu, který by pořád běžel jako hald. Nikde se neskladuje žádný duplicitní stav, ani nic takového, všechno je v udevu, odkud se to přes lehký wrapper bere. Ani nemá konfigurační soubory, to je udev…

[1] Přesněji, popisuje stav asi tak před rokem a půl, který už dávno není aktuální, a snad ani nikdy v distribucích pořádně nebyl.

[Michal Kubeček]

Já bych s těmi kategorickými závěry, co je mrtvé a co je budoucnost, byl trochu opatrnější. Koneckonců v aktuálních verzích distribuce HAL stále je (a to i třeba ve vývojových jako OpenSuSE 11.3 M4), ono by totiž bylo dost nezodpovědné ho jen tak vyhodit bez adekvátní náhrady.

[thingie]

A to tam píšu kde? HAL bude v distribucích ještě hodně dlouho, ničemu tam nějak zásadně nevadí, a obskurnější aplikace to asi jen tak používat nepřestanou. Ještě dneska nezřídka najedete v zastrčenějších repozitářích GTK 1.2… (I když byste už fakt nechtěli.)

[Michal Vyskočil]

Koneckonců v aktuálních verzích distribuce HAL stále je (a to i třeba ve vývojových jako OpenSuSE 11.3 M4), ono by totiž bylo dost nezodpovědné ho jen tak vyhodit bez adekvátní náhrady.

Ono se intenzivně pracuje na jeho vyhození - třeba bug#590709.

Problémem je, že přechod HAL -> něco jiného není na stránkách freedesktop.org dokumentován. Tak například z hlavní stránky projektu hal se člověk na UPower a UDisks nedostane. DeviceKit neobsahuje ani zmínku o tom, že je to deprecated.

[Michal Kubeček]

Pomalu se začínám 11.3 děsit, tyhle vylomeniny (vyhodit HAL, zavést upstart) jsou totiž daleko horší než nějaké nedokončené a neodladělné KDE4…

[Michal Kubeček]

Ještě poznámku k udevu: je moc fajn a rozhodně je dobře, že existuje. Ale pokud by měl převzít zodpovědnost za tolik dalších funkcí systému, bylo by nutné konečně něco zásadního udělat s formátem jeho konfiguračních souborů. Už teď je to dost neúnosné - stačí se podívat na rules files nějaké trochu komfortnější distribuce.

[thingie]

On je taky skoro nikdo radši nepíše Většina cool lidiček radši ani neví, že něco takového má.

[Martin Mareš]

Na druhou stranu je to stále řádově příjemnější než úplně příšerné konfiguráky HALu v XML...

[Michal Kubeček]

To bych neřekl. Pro začátek by třeba docela pomohlo, kdyby měl udev něco na způsob continuation lines z Bourne shellu. Ne že bych se s HALovými fdi vždycky vešel do 80 znaků šířky, ale u udevu zcela běžně (zvlášť u distribučních pravidel) nestačí ani 197 znaků na řádek, které dostanu z konsole při roztažení na celou šířku monitoru. Přičtu-li k tomu možnost skládání hodnot (append, prepend), rejstřík porovnávání nebo již zmíněné cílení pomocí @property:property (oproti ATTRS{idVendor} matchujícímu jak USB vendor id, tak PCI vendor id), vychází mi porovnání jazyků - kromě nejjednodušších případů - jednoznačně ve prospěch HALu. Možná mi ale jen chybí potřebná míra alergie na XML. :-)

[Martin Mareš]

Mně hlavně přijde, že porovnáváme nepodstatné vlastnosti dvou formátů, které jsou mizerně navržené jeden jako druhý. Prostý zápis podmínek ve tvaru výrazů by byl mnohem použitelnější a čitelnější. Používat pro zápis výrazů XML mi přijde přibližně stejně pohodlné, jako k tomu používat INTERCAL.

[Michal Kubeček]

…které jsou mizerně navržené jeden jako druhý.

Tak na tom asi nebude problém se shodnout.

[chrono]

třeba docela pomohlo, kdyby měl udev něco na způsob continuation lines z Bourne shellu.

Niečo takéto?

SUBSYSTEMS=="ide", KERNEL=="hd[a-z]", ATTR{removable}=="1", \
        ENV{ID_MODEL}=="IOMEGA_ZIP*", OPTIONS+="all_partitions", GROUP="floppy"

(lebo takých pravidiel mám v udev/rules.d dosť veľa)

[Michal Kubeček]

Zvláštní, že o tom v dokumentaci není ani slovo. Není to nějaký distribuční patch?

[chrono]

Pravdepodobne je to priamo v udev. V udev-rules.c som našiel niečo takéto:

/* continue reading if backslash+newline is found */
while (line[len-2] == '\\') {
	if (fgets(&line[len-2], (sizeof(line)-len)+2, f) == NULL)
		break;
	if (strlen(&line[len-2]) < 2)
		break;
	line_nr++;
	len = strlen(line);
}

[chrono]

Inak je zaujímavé, že takto stará vlastnosť (do udev to bolo pridané pred viac ako piatymi rokmi) nie je v dokumentácii [PATCH] allow multiline rules by backslash at the end of the line.

[Ondrej 'SanTiago' Zajicek]

Treba proto, ze spousta uzivatelu HAL nepouziva a nechce?

HAL nedelal prakticky nic, co by Xka potrebovala. Natazeni spravneho kerneliho ovladace delal udev, natazeni spravneho Xkoveho ovladace si delaji Xka sama. Takze cele to je jenom otazka toho, prez jake rozhrani se budou Xka dozvidat o novych zarizenich zda pres kerneli, udevove nebo HALi rozhrani.

Osobne bych preferoval, kdyby Xka pouzivala rovnou kernelove rozhrani, ale to je tak pitome navrzene rozhrani, ze aplikace radsi komunikuji s udevem.

[D.A.Tiger]

Treba proto, ze spousta uzivatelu HAL nepouziva a nechce?

Najde se zase spousta lidí (včetně mě), kteří jsou rádi, že něco jako HAL vůbec existuje. Mohu Vám důvěrně říci, že je celkem papačka rejpat se v konfiguraci udev, když chcete zprovoznit nějaké zařízení. Já si to docela užil s mob. telefony (NOKIA, SAMSUNG). A i když se Vám podařilo zařízení rozjet, nemusel jste mít pořád vyhráno, protože se docela často stalo, že od té chvíle zase nejelo něco jiného... ;)

HAL nedelal prakticky nic, co by Xka potrebovala. Natazeni spravneho kerneliho ovladace delal udev, natazeni spravneho Xkoveho ovladace si delaji Xka sama. Takze cele to je jenom otazka toho, prez jake rozhrani se budou Xka dozvidat o novych zarizenich zda pres kerneli, udevove nebo HALi rozhrani.

Mám takový dojem, že se mýlíte. Minimálně zavádění kernelových ovladačů hlídá HAL. Udev pokud vím nedělá nic jiného, než že podle informací od jádra a pravidel ve své konfiguraci aktualizuje obsah v /dev a informuje přes D-BUS zbytek systému o tom, že něco provedl. Proto většinou mělo stačit nakonfigurovat HAL a ten se měl sám postarat o zbytek, včetně přidání odpovídajících pravidel do udev, a zjištění všech potřebných informací o nově přidaném/změněném stavu zařízení.

Osobne bych preferoval, kdyby Xka pouzivala rovnou kernelove rozhrani, ale to je tak pitome navrzene rozhrani, ze aplikace radsi komunikuji s udevem.

Já osobně ne. Jak jsem psal výše jsem rád, že existuje alespoň nějaký projekt, který se stará o správu hardware v Linuxu. Možná není zn. ideál ale pořád lepší, než přímo ručně domlouvat udev a pak se ještě starat o správné a včasné načtení/odstranění ovladačů a potřebných modulů v jádře... A navíc, aby si to obstarávala každá aplikace sama - to by byl děs už vůbec.

[Michal Kubeček]

Udev pokud vím nedělá nic jiného, než že podle informací od jádra a pravidel ve své konfiguraci aktualizuje obsah v /dev a informuje přes D-BUS zbytek systému o tom, že něco provedl.

To druhé dělá spíš HAL než udev. Na druhou stranu se dá udev přimět, aby na události reagoval v podstatě čímkoli - i když se k tomu účelu jeho rozhraní moc nehodí a sami autoři (nebo přinejmenším autoři dokumentace) to příliš nedoporučují.

V každém případě ale tvrdím, že pokud by měl udev převzít část práce HALu, bylo by nutné nejprve nahradit jazyk jeho konfiguračních souborů něčím přehlednějším a pokud možno i silnějším - přinejmenším nějaká forma cílení atributů (obdoba @property:property) by byla nutností.

[D.A.Tiger]

Udev takto komunikuje s HALem.

Jinak souhlasím. Je mi v podstatě jedno jak se vrstva bude jmenovat, jde jen o to aby obstarávala všechny služby, alespoň tak jak to dělá HAL. Pokud přibere funkcionalitu udev a navíc bude dobře konfigurovatelná s propracovaným rozhraním - tím lépe

Freedesktop.org začali vyvíjet nový projekt DeviceKit, který by měl HAL nahradit, a navíc od něj by měl být i modulární. Bohužel, krom tohoto a toho, že by měl být už ve Fedoře nějaké rozumné informace se mi zatím získat nepodařilo

[Michal Kubeček]

Udev takto komunikuje s HALem.

To se mi moc nezdá, kdyby nic jiného, tak udevd není linkovaný proti libdbus. Možná se v některé distribuci jako reakce na událost spouští něco, co dává HALu vědět přes D-BUS, ale ani tak bych to neformuloval, že udev posílá notifikace přes D-BUS.

[thingie]

No, on dbus drátový protokol není nic hrozného, pokud chcete jenom něco strašně jednoduchého, tak žádný libdbus nepotřebujete.

[Ondrej 'SanTiago' Zajicek]

Mám takový dojem, že se mýlíte. Minimálně zavádění kernelových ovladačů hlídá HAL.

V davnych dobach automaticke zavadeni kernelovych modulu fungovalo tak, ze kernel primo spustil program modprobe (nebo skript hotplug) na fiktivni jmeno (bud odvozene od device node, na ktere se pristupovalo, nebo odvozene od vendor/device ID zarizeni, ktere se objevilo pri enumeraci) a zbytek zaridil program modprobe sam (prevedl fiktivni jmeno na skutecne jmeno modulu a to zavedl).

Protoze caste spousteni tech hotplug skriptu dost zpomalovalo, zavedl se udev, ktery ceka na netlink socketu, po kterem se dozvida o udalostech (objevilo/zmizelo zarizeni, objevilo/zmizel device node) a podle konfigurace dela ruzne cinnosti. Mimochodem, protokol, pomoci ktereho je udev informovan, vznikl nejspis tak, ze se vzaly promenne prostredi, se kterym se drive spoustel hotplug skript, a to se zabalilo do netlink socketu.

Takze striktne vzato se udev o zavadeni modulu nestara. Aby udev zajistil zavedeni modulu, staci mit v konfiguraci jedine pravidlo:

ENV{MODALIAS}=="?*", RUN+="/sbin/modprobe $env{MODALIAS}"

To zajisti pusteni modprobe, ktery zaridi uz vse ostatni.

[chrono]

Najde se zase spousta lidí (včetně mě), kteří jsou rádi, že něco jako HAL vůbec existuje. Mohu Vám důvěrně říci, že je celkem papačka rejpat se v konfiguraci udev, když chcete zprovoznit nějaké zařízení. Já si to docela užil s mob. telefony (NOKIA, SAMSUNG). A i když se Vám podařilo zařízení rozjet, nemusel jste mít pořád vyhráno, protože se docela často stalo, že od té chvíle zase nejelo něco jiného... ;)

Keď bola tá konfigurácia udev tak zložitá, prečo si nekonfiguroval HAL?

[D.A.Tiger]

To je jednoduché - v té době jsem o tom nevěděl (mimo toho SAMSUNGU, tam to bylo dané). A jsem rád, že jsem si to vyzkoušel, alespoň vím, že to opravdu nemusí být není nic jednoduchého...