X.Org upustí od používání HALu

X.Org používá HAL pro detekci hardwaru od X Serveru 1.4. Toto zajistilo například podporu připojování nového hardwaru za běhu. Na Phoronixu se však píše, že od používání HALu bude upuštěno a namísto toho se bude používat kód specifický pro používaný OS. V případě Linuxu půjde například o přímé napojení na udev. Důvodem je ukončení vývoje HALu ve prospěch DeviceKitu a jiných.

3.12.2009 08:18 | Luboš Doležel (Doli) | Zajímavý článek

Komentáře

[pepazdepa]

konecne pujde ten neportabilni pristup (orientace na linux sracky jak hal) do vecnych lovist :)

[R]

Hlavne je ten HAL nechutny XML humus s nulovou dokumentaciou.

[Amarok]

+1

Uz se ale netesim na opakovani problemu, az nastane prestup. Mozna to ale pujde hladce a ne jako kdyz nastoupil HAL a plno lidi najednou nechapalo, proc jim nejde spravne klavesnice apod.

[Tomáš Bžatek]

Tak zrovna problem klavesnice byl zapricinen prioritizaci evdev misto kbd driveru a presunutim konfigurace z xorg.conf do prislusnych HAL fdi files, ktere byly specificke pro kazde vstupni zarizeni zvlast. Mimochodem, project XI2 stale pokracuje a spousta komponent jeste nebyla do xorg-serveru zaclenena, muzete se tesit na dalsi vyznamne zmeny v brzke budoucnosti.

[DNA]

zajímavé, že na kbd je závislé splashy (alespoň to v sidovi), nechápu proč...

[Jardík]

Udev je ale chlapci naprosto to samé, hal z něho vychází. Místo HAL pravidel tak budete psát udev pravidla v naprosto stejném XML s trochu jinýma fíčurama

[miso]

Mohol by si sem pastnut nejake udev pravidlo v XML?

[Tomáš Bžatek]

Jo to by me teda taky zajimalo

[Milan Lajtoš]

Tiež by som chcel vidieť. ;)

[Mti.]

heh... ja bych to radeji videt nechtel

[R]

Pravidla pre udev som viackrat pisal a ziadne XML tam nikde nebolo. Na par jednoduchych pravidiel typu "aby /dev/touchscreen bol symlink na touchscreen" som ani ziadnu dokumentaciu nepotreboval. S HALom neporovnatelne.

[mirec]

Hlavne tá dokumentácia chýba, ak by bola kvalitná tak aj nejaké tie xml pretrpím zá to, že by som mal samostatné nastavenia pre trackpoint a myš.

[R]

Nechapem, preco na taketo zakladne veci treba HAL.

[mirec]

To nechápem ani ja, ale momentálne je to jediná možnosť ;)

[petr_p]

Rozdílnou konfiguraci můžete mít i nyní bez evdev, jen si musíte jinak (udev, ručně) zajistit, že každé zařízení uvidí server pod stejným názvem.

[mirec]

To už sa dá ako? Povedzme chcem nastavenie pre trackpoint (emulácia kolieska) a myš (špeciálne nastavenia tlačidiel mojej myši, ktorú občas používam, nie je pripojená vždy) a všeobecné nastavenia pre všetky ďalšie myši.

[petr_p]

Více InputDevice sekcí s ovladačem mouse a rozdílnou volbou Device.

nie je pripojená vždy

To jste ale minule nepožadoval. Je možné nařídit serveru, že nemá selhat při neexistujícím zařízení, ale jaksi z nedostatku X serveru, jej nedokáže objevit po připojení po startu, protože ovladač mouse tohle neumí.

všeobecné nastavenia pre všetky ďalšie myši

To neumí. Můžete sice použít /dev/input/mice, kam jádro multiplexuje všechny ukazatele, ale to s sebou vezme i události ze zvláštních input zařízení.

Prostě není to dynamické. Musíte to mít staticky. Ale konfiguraci zvlášť pro každé zařízení to umí.

[mirec]

No tak to je teda riešenie ;) Takto som s tým kedysi pracoval a pripadalo mi to ako v stredoveku po pripojení myši nakonfigurovať X a reštartovať aby pracovalo so správnym zariadením. Alebo proste nikdy nepripájať inú myš než najčastejšie používam a vtedy to funguje aj bez zmeny konfigurácie, ale otravný reštart X ostáva. Ďakujem, to sa radšej budem hrabať v kope sračiek (číta sa to HAL).

[Luboš Doležel (Doli)]

Tak na to HAL fakt nepotřebuju.

[kuly]

Jeden z nás dvou tu zprávičku nepochopil

[Milan Lajtoš]

Hmm.. Dosť zvláštne rozhodnutie, myslel som, že to len prepíšu pre DeviceKit.

[belisarivs]

Ktery by pak treba casem taky zkoncil a byl nahrazen necim jinym.

Mne to rozhodnuti prijde jako smysluplne.

[michich]

DeviceKit jako samostatný daemon byl zrušen, protože se přišlo na to, že to, co měl dělat, může zvládat sám udev. Z projektu DeviceKit jsou dále vyvíjené pouze specializované služby DeviceKit-disks a DeviceKit-power, které nejsou pro potřeby X.org relevantní (X.org používá HAL pouze pro vstupní zařízení).

[Tomáš Bžatek]

DeviceKit byl jen malicky daemon, ktery preposilal udev events pres d-bus svym podrizenym. Kod byl zmergovan do udevu primo (cast extras), vysledkem je krasna knihovna libgudev s GObject inteface.

DeviceKit-disks a DeviceKit-power zustaly v podstate nezmenene, jen se nyni v ramci konzolidace budou prejmenovavat na udisks a upower + se zmeni cislovani.

DeviceKit-power se hojne pouziva v user aplikacich (gnome-power-manager), jak moc zasahuje do jadra X.org netusim, ale v dnesni dobe se powermanagement uz ridi pres DRM moduly v kernelu.

[Delaunay]

+1 Moc děkuji za informaci.

[Grunt]

Takže se to všechno smrskne na udev, který se skrze dracut nacpe do initrd? Tož to je fajnové.

[Kvakor]

V intitrd/initramfs nebude udev zas tak nutný, poněvač nová jádra mohou používat devtmpfs, což je takový "devfs 2.0". Při jeho použití udev nebude muset dělat coldplug a soustředí se jen na hotplug.

[Grunt]

Se s tím furt tak šachuje aby se v tom čert vyznal.

[ph0enix]

Podle vyjadreni na http://www.x.org/wiki/XorgHAL DeviceKit a dalsi nepodporuji potrebnou funkcionalitu. Vyvojari DeviceKitu se snad i vyjadrili tak, ze ani neni v planu a doporucili vyuziti OS interfaces.

[Tomáš Bžatek]

O modulu DeviceKit-input se diskutovalo, ale mam pocit, ze jej nikdo nepise.

Dulezity krok v ramci teto konzolidace je konverze HAL fdi files na udev rules, ktera by snad uz mela byt z velke casti hotova.

[Milan Lajtoš]

A čo všetky programy, ktoré využívajú HAL na zistenie vstupných zariadení? Napr. Gimp... Budú sa aplikácie dotazovať samotných X?

[Milan Lajtoš]

Resp. libgudev?

[Tomáš Bžatek]

Tak zrovna GIMP je vystaven nad GTK+ toolkitem verze 2, kteryzto by mel sam obhospodarovat vstupni zarizeni (tablety apod.). Ale koukam, ze GtkInputDialog je deprecated, tak nevim, jaky je ted stav (nedelam s tim). Mluvilo se o portu na XI2 pro enumeraci zarizeni a jejich vlastnosti, ale nevim jak moc je to v soucasne dobe implementovane.

Doporucuju serial od naseho kolegy, ktery ma XI2 na starosti: http://who-t.blogspot.com/2009/05/xi2-recipes-part-1.html

[alblaho]

Ač se za lamu nepovažuju, z těch udev, devicekit, hal a kýho čerta jsem dost zmatený. Naštěstí mi počítač USB disky mountuje k mé spokojenosti, tak jsem s touhle cháskou zatím nic řešit nemusel.

Ale vím jedno, časem se mi do ruky dostane Ubuntu, kde bude rozbité něco, co před tím roky fungovalo

Vývoj je vývoj, to je mi jasné. Mám ale pocit, že to střídání démonů, kitů atd. je v Linuxu až příliš časté. Zajímalo by mě, jak tohle řeší Windows a jestli jim to tam funguje.

[Tomáš Bžatek]

Windows maji release cycle nekolik let, linuxove distribuce povetsinou pul roku. V pripade Ubuntu se hodi srovnavat Long Term Support releasy nebo v pripade jinych distribuci jejich enterprise verze.

[alblaho]

Já bych neřekl, že je to jenom o délce vývojového cyklu. Je to spíš "katedrála vs. bazar".

Linux je taková brutální evoluce, kde jsou staré koncepty rychle opouštěny ve prospěch nových. Je to možné proto, že jednotlivé možnosti se často vyvíjejí paralelně a každá z nich se snaží přežít tak, že se dostane do nějaké masové distribuce.

V Redmondu (řekl bych) jsou zvyklí více pracovat se starým kódem, zahodí to až když už opravdu není zbytí.

[TM]

Brutální evoluce, která ale uživatelům ztěžuje život kde jen může. Sotva je něco přivedeno do jakž takž funkčního stavu, je to vzápětí opuštěno ve prospěch nedodělku, který pak v distribucích otravuje pár let než se stane použitelným. Pak je ihned nahrazen dalším nedodělkem. Tímto způsobem se k cíli (existuje vůbec?) dostaneme tak za 100 let. Mezi tím bude typický Linuxový desktop i nadále spíše sbírkou polofunkčních utilit než něčím co byste mohli dát na stůl typickému uživateli.
Diví se ještě někdo malému zájmu uživatelů a výrobců softwaru? Já si to vždy nějak přiohnu a vyházím ty tuny nesmyslů, kterými jsou dnešní distra zanesena (ale čím jsem starší tím mě to víc štve). Většina čtenářů tohoto webu také...ale typický uživatel nás s něčím takovým pošle do ... a jde ke konkurenci. Tak to bohužel je.

[Amarok]

Vyrobci software se nemusi starat o to, jak je reseno ovladani zarizeni apod., to jsou nesmysly.

A vetsina BFU s tim taky nebude mit problemy, pokud pouziva nejakou distribuci zamerenou na BFU, tam uz jsou prechody koordinovane. Ja mel jen problem v archu s prepinanim klavesnic, coz neni zrovna BFU distro.

[razor]

Koordinovanými přechody myslíš třeba přechod na pulseaudio (specielně pro intel chipsety) v bfu distribuci ubuntu 9.04. Nebo verze intelovských ovladačů grafiky vs verze xorg v ubuntu 9.04 ... ?

[petr_p]

Co vy víte o typickém uživateli?!

[fettgesicht]

To se zas budu muset učit cosi nového? Tyhlety HALy a udevy každého jenom otravují...

[Stanislav Brabec]

Tak tak, stále je třeba se učit.

Hal to byl takový velký tlustý kůň, co se jen těžko učil novým kouskům. Časem se sice pár lidí naučilo, jak se na něj musí, ale dalo to spousty práce. Jednoho dne došla ošetřovateli trpělivost, vykopal jámu, a prohlásil, že Hal je mrtvý.

Teď místo něj pořídíli několik malých poníků, a každého z nich učí něco jiného.

[Gilhad]

Vyborne, prijde mi fakt na hlavu muset mit beziciho demona a bandu XML nesmyslu jen proto, abych dokazal emulovat ponechani JEDNOHO RADKU v textovem konfiguraku v puvodnim zakomentovanem stavu

# Option "DontZap"

[Luboš Doležel (Doli)]

Jakým způsobem souvisí DontZap a podpora HALu?

[Gilhad]

prez novy xorg

[Nick]

Tady je vidět jaký byl Patrick the Man vizionář. Faktem ale je, že změknul a hal do distra hlavně kvůli novému Xorg zařadil.

[kolotoc]

3x sláva. btw. já ve svém Gentoo kompiluji Xorg bez podpory Halu.

[kuly]

A už se nemůžeš dočkat až je na Nový rok spustíš, viď

[Semo]

Ked som potreboval vyrobit nastroj pre malu jednoucelovu distribuciu, ktory dokaze skopirovat instalacny image na flash disk, tak sa mi HAL celkom hodil. Pomerne lahko sa dali s nim najst removable disky v systeme a ich oznacenie a cesty. Netvrdim, ze to uz nikdy nepojde vyriesit inak, ale ze som v zivote narazil aj na pozitivne ucinky HALu.

[blami]

coz ovsem muzes vklidu udelat i pres nejake udevinfo nebo jeho soucasne platnou nahrazku ...

[hajma]

Vývojář A: "Hele, koukám, že poslední dva měsíce jsme opravili víc bugů, než jich přišlo. A dlouho jsem neslyšel nikoho, kdo by si nějak zásadně stěžoval..."
Vývojář B: "Jo, už je to nuda, co kdybysme to celý napsali znova a úplně jinak?"

[m;)]

vie tu prosim niekto strucne vysvetlit ako to s tym HAL vlastne bolo a je ? myslim tym kto s nim prisiel, ake boli ciele, ako ho dokazal presadit takmer vsade, aby bol potom nahle ukonceny a opusteny .. co sa zmenilo a ake su nove vizie ?

myslim, ze nie som sam kto sa uz pomaly nestiha orientovat v tych stale novych komponentach, ktore sa zjavia, zaziaria a vzapati su zabudnute. pocas ich casto kratkeho zivota ich cast ludi oslavuje a dalsia zatracuje. prikladov by bolo vela a urcite ma kazdy svoj oblubeny.

[Stanislav Brabec]

HAL: Hardware Abstraction Layer měl být systém pro abstrakci veškerého hardware. Poté, co s ním autoři distribucí začali řešit reálné problémy, se postupně ukazovala jeho těžkopádnost:

• FDI XML pravidla se aplikují průběžně. Při vyhodnocování se tedy nelze odkazovat na podřízené struktury. Zpětná aplikace při vyhodnocení podřízené struktury se již provádí pozdě, a nelze ji aplikovat. Nejdou tedy pokládat podminky jako: Má tento disk oddíl daného jména? Obsahuje toto USB zařízení rozhraní dané třídy?
• HAL nevytváří připojné body v /dev a nestará se o jejich práva (s výjimkou spolupráce s PolicyKit). Nedokáže cokoliv udělat ještě před jejich vytvořením.
• Ani rozdělení pravidel na preprobe, information a policy tomuto problému nedokázala zabránit. Například při připojení šifrovacího tokenu se nejdřive provedou všechny fáze pro fyzické zařízení. Připojí se jako obecné USB zařízení s velmi volnými právy. Teprve v okamžiku, kdy HAL vyhodnocuje jednotlivá rozhraní, a zjistí, že jde o šifrovací token, může práva omezit. Potenciální vetřelec měl stovky milisekund na to, aby si příslušné USB zařízení otevřel.
• FDI pravidla v HAL do značné míry duplikují pravidla v udev. Značně tak komplikují trasování problémů.
• Nový udev a D-Bus umí prakticky totéž co HAL, aniž by se musela zavádět nová vrstva abstrakce.
• Mít v jedné tabulce pohromadě tlačítka na case, USB myš i oddíl na vzdáleném iSCSI disku se neukázalo jako skutečná výhoda.
• I v případě, že něco jde, je stromová struktura často poměrně nepraktická. Ukázkou budiž pravidlo, které zakáže automatické připojení oddílů disků připojených na Fibre Channel řadič (a to ještě pouze tehdy, když daný řadič obsahuje vhodný identifikační řetězec):

  <?xml version="1.0" encoding="UTF-8"?>
  <deviceinfo version="0.2">
    <device>
      <match
        key="@info.parent:@info.parent:@info.parent:@info.parent:info.product"
        contains_ncase="Fibre Channel">
        <merge key="storage.policy.should_mount">false</merge>
      </match>
    </device>
  </deviceinfo>
  

Náhrady už zde popsali jiní.

[Amarok]

To by se v klidu mohlo pripsat do slovniku tady na abc do odstavce "nevyhody HALu".