Vlákno názorů k článku XLibre jako další bouře ve sklenici vody, nebo spása pro X.Org? od vogo - Za sebe jsem rád, že jsem se na...
-
Za sebe jsem rád, že jsem se na všech počítačích toho molochu X11 zbavil. A to tak daleko, že není nainstalovaný ani balíček xorg-server. Jasně občas v některé plamenné diskuzi zatlačím nostalgickou slzu, pamatuji na vlastní kůži ještě XFree86, ale stýskat se mi nebude. Wayland prostě jede a ani KDE jsem za poslední rok nenarazil na nějaký problém. Zpětná kompatibilita přes XWayland prostě funguje, rozjede se i prehistorický Unreal Tournament z roku 1999 (uznávám, je to nějaká opatchovaná binárka, ale určitě jí bude víc než 20 let).
Vývoj jde dál a ono všechno tohle utichne, stejně jako všichni kvičeli když nás postupně opouštěli a potlesk pro ně: OpenSoundSystem, DevFS (vzpomene si ještě někdo?), SysV init, ReiserFS, HAL, lilo a další.
Jo tohle všechno staří harcovníci (i já) zažili, ale selektivní paměť nám povětšinou zanechala jen ty hezké vzpomínky. A přiznejme si nebylo to hezké, hromada probdělých nocích s manuálovými stránkami a vytáčeným spojením do Internetu a občas prostě bez úspěchu. V tomhle světle je současný Linux se současnými technologiemi růžovou zahradou. Ano, sem tam se píchneme o trn, ale jinak je to nádhera.
-
Za sebe jsem rád, že to nemusím řešit a chci jen, aby to tak zůstalo. Co bude ta okna kreslit je mi úplně jedno, jen by to prostě mělo fungovat samo. Audio systém je přesně stejný případ. To je pohled normálního uživatele. (A můj taky.) A mimochodem, zrovna RaiserFS byl alespoň u mě bezproblémový a kupodivu je použitelný je i dnes i když už k tomu samozřejmě není žádný důvod. Což je vcelku pozoruhodné.
-
DannyStříbrný podporovatelVsak vetsina distribuci to za vas proste vyresi. Normalni uzivatel ten podvozek vubec resit nemusi. Samo to obvykle funguje minimalne do chvile, nez do toho zacne ten uzivatel proaktivne vrtat :-)
-
No nevím, co si pamatuju, tak v dobách těsně po roce 2001, kdy jsem zápasil s Mandrage 8.něco zrovna všechno nebylo krásné a funkční. Taková zvuková karta dokázala potrápit, nebo rozběhnout 3D akceleraci, to byl občas zážitek. A člověk nemusel mít ani kdo ví jaký exotický hardware. Já tehdy měl nějaký AMD Duron na asi 800 MHz, GeForce2 a Sound Blaster Live, a že by to všechno fungovalo nějak pořádně out of the box, to si tak nějak nepamatuju...
Ano díky novým technologiím je nyní Linux po čerstvé instalaci plně funkční a proto nemá cenu brečet nad ničím starým, co pořádně nefungovalo.
-
DannyStříbrný podporovatel
V roce 2001... bylo hodne veci jinak. Neni dobre byt otrokem minulosti, mame rok 2025 ;-)
-
PulseAudio kladlo dost vysoke poziadavky na kvalitu ovladacov. V tej dobe ovladace mali kopu bugov, s ktorymi to drhlo. PA sa zlepsilo, ako sa popracovalo na oprave ovladacov.
A nielen ovladace, aj hardver mal kopec problemov. Mal som pocitac s audio kodekom (Nvidia ION 2), ktory tvrdil, ze zvlada 44,1 kHz, ale mal nejaky problem s timerom, takze z casu na cas sa ozvalo lupnutie, ked timer oddriftoval prilis daleko od realneho streamu. Po nanuteni 48 kHz v PA a softveroveho prevzorkovania tento problem zmizol.
-
Je "vrtání se", když chci, aby se mi po přihlášení do KDE otevřela okna alplikací, které chci, na těch místech a obrazovkách, kde je chci, podle toho, jak jsem si to uložil? Pro mne je to nesmírně užitečná funkce, která bez problémů fungovala přinejmenším od dob KDE3, ale pokud KDE běží nad waylandem, tak mám prostě smůlu - a není vůbec jasné, kdy a jestli vůbec to tam fungovat bude.
-
Zkusím se podívat, jestli by to šlo nějak využít v kombinaci s automatickým spouštěním po přihlášení. Můj hlavní problém je, že mám oblíbený layout s 12 okny konsole rozházenými určitým způsobem po čtyřech virtuálních plochách, každá přes dva monitory. Okna navíc nejsou stejně velká (někde chci šířku 80 znaků, někde víc). Takže bych musel při spouštění dát nějakou identifikaci, aby pravidlo dokázalo poznat, kam které okno patří. Ale to snad půjde zajistit nějakým parametrem.
Session save/restore navíc umí i to, že se v každém okně otevře "správný" počet tabů a v tabech se obnoví i pracovní adresáře, jak byly.
-
x11 je dosiroka otvorene.
Pri procesoch mame ochranu pamate, aby jeden nesahal druhemu do jeho zalezitosti, a ked uz chce, tak musi pouzit nejaku formu zdielanej pamate.
Pri suboroch mame pristupove prava a kontajnery. Ked uz nejaky proces chce sahat, tam, kam by nemal, tak sa mu to nie celkom podari.
No a x11 nic take nema. Kazdy proces si moze sahat kam len chce, aj ked to nie je jeho biznis. Niektore hracky vznikli len pre srandu (xeyes), niektore su uzitocne (screeshoty a streamovanie), no a pri takom malware a keygrabberoch, jeden nikdy nevie. Pamatame si na XP? No, tak nechceme, aby linuxovy desktop dopadol podobne. Ziaden tradicny uzivatel si ho nechce spustit, a tu sme, takyto sw existuje.
Takze wayland by default neumoznuje sahat kazdemu, kam si zmysli. Samozrejme, pre niektore veci treba vytvorit diery. Pre uzitocne veci ako screenshoty a stremovanie vzniklo api[1]. Niektore diskutabilne veci - ano, globalne shortcuty su diskutabilne[2] - sa holt budu robit inak. A niektore veci (globalne suradnice na monitore) holt nebudu. Napriklad aj preto, ze monitor nemusi byt obdlznik, ako sme zvyknuti. Moze mat konvexne a konkavne kraje (pristrojovka v aute, displej na macbook pro s vyrezom pre kameru), moze mat "diery" (bezny dnesny telefon s dierou na fotak), alebo len okruhle okraje (niektore displeje frame.work) Alebo moze byt "nekonecny" a nema [0,0] v globalnej sustave. Kompozitor na to pamata, nahodny klient nie.
A to sme sa este nedostali k hackom. Viacero displejov s rozlicnymi dpi? V X11 vec neriesitelna (xinerama je jeden velky displej s dierami; z definicie musi mat rovnake dpi a rovnaku farebnu hlbku na vsetkych obrazovkach). HiDPI? Ziaden X klient neoznamuje serveru, s akym DPI pocita. Ma potom server menit fyzicku velkost surface alebo nie? Niektori klienti vedia korekne pracovat s DPI, tym by nemal, niektori nevedia, tym by mal, ale kedze server nevie ktory je ktory, musi si tipnut a potom radsej kazdemu povie nizsie DPI a zvacsuje/rozmaze vsetko. Vo waylande, surface ma vlastnost, v akej mierke je a kompozitor sa zariadi.
No a takto by sme vedeli pokracovat donekonecna. Takze nie, pouzivatel si nechce len spustit browser. Chce si ho spustit na projektore. Alebo na HDR monitore. A potom chce vidiet HDR obrazky. A nechce, aby mu nahodny javascript v inom okne browsera graboval heslo do internet bankingu. Takychto poziadaviek je tam nakoniec docela hodne.
[1] a niekedy aj efektivnejsie ako v x11. V x11 "streamovenie" bolo kontinualne grabovanie screenshotov a prenos kazdeho z x11 serveru do pamate procesu (v pripade lokalneho minimalne z videoram do system ram). Wayland kompozitoru sa da povedat, ze chcem video stream, ci ho chcem uz komprimovany vybranym hw kodekom na gpu a nech mi ho necha v dmabuf bufferi na video karte.
[2] pretoze nechceme, aby si nahodna aplikacia zaregistrovala nahodny shortcut. Ina vec je, ked si zaregistruje akciu, pouzivatel jej priradi shortcut a pri tom priradovani sa da zariadit, aby neboli ziadne kolizie.
-
Problém je, že za nebezpečné se považuje i umístit okno na konkrétní pozici (např. víceoknové aplikace). Alespoň že sami po letech uznali, že přesunout kurzor myši je potřeba (např. first person hry). A různé DPI na displejích? Já to měl už před 15 lety v majoritním distru jménem Ubuntu, by default. Implementováno sice oklikou v desktopovém prostředí (nad X11), ale ve Waylandu se to řeší taky tak.
-
> umístit okno na konkrétní pozici
Časem to snad bude, viz: https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/264
-
Fungovalo to na stejném principu, jako skriptování X11. Akorát že ten skript byl předinstalován distribucí. Dávno jste si mohl všimnout, že Gtk a Qt aplikace mění GUI dynamicky po změně DPI. Takže stačilo jen říct aplikaci nové DPI po přesunu na jiný monitor. Jsou tam nedostatky, když je okno na půl cesty, ale stejné problémy jsou i ve Windows. Pro Firefox Canonical napsal patch, protože ten není ani Gtk, ani Qt (kreslí GUI prvky přes Gtk, ale okno je vlastní kód).
-
DPI v x11 je vlastnost displeja, nie screenu, ani toplevel okna, alebo ineho objektu. Hovorime o x11, nie o tom, co by teoreticky zvladlo Gtk a Qt.
Ano, je mozne vymysliet dalsi protokol typu ICCCM, kde by sa nastavil specificky atom na okno; len problem s takymto postupom je, ze to dana aplikacia musi podporovat a ze ho do starsich aplikacii retrofitovat nikto nebude; takze vznikde dalsi protokol, ktory funguje len s niektorymi aplikaciami a zvysok je rozbity.
Zatial co postup, ktory zvolil (x)wayland, funguje aj s 30 rocnou binarkou wordperfectu.
-
Samotný integer scaling funguje jen pro násobky sta procent. macOS to pro mezihodnoty řeší tak, že vykreslí 200% integer scaling, a pak to zmenší (nevím, jaký přesně filtr, stačil by i bilineární). Jenže na to je třeba vysoký rasterizační výkon GPU, to by půlka PC nedala. Apple si dělá vlastní GPU (i ta nejslabší je dostatečně výkonná) a předtím od Intelu bral procesory s dvojnásobným výkonem iGPU, než dostala většina PC.
Pro zajímavost, s příchodem 5K displeje Apple Cinema tehdejší Intel iGPU nestačilo, tak využil toho, že ten MacBook Air již měl první generaci Thunderbolt. Takže v případě toho notebooku se ve skutečnosti použila o generaci lepší Intel iGPU uvnitř monitoru (Thunderbolt je externí PCIe sběrnice). -
Lenze macOS to v GPU vobec nerobi (inak by to bolo primitivne zmensenie jednej textury, s cim nema ziadna GPU problem). Rovnaky postup pouziva aj na Intel Macoch, ktore maju GPU od Intelu a AMD. A ako to robi? Scalerom v output enkoderi (ekvivalent `xrandr --scale`). Intel to ma pekne popisane v ich dokumentacii k GPU.
Ked prisiel Apple s 5K displejmi, bolo nutne pouzit oba MST kanaly v displayporte uz na zobrazenie 4k@60. Pri jednom kanale, alebo pri hdmi 1.4 sa dalo zobrazovat iba 4k@30. Ak sa pouzivalo este dvi, tak bolo treba pouzit dva kable a monitor to musel vediet zlucit. To bolo obmedzenie portov, nemali dostatocny bandwidth, preto to Apple tuneloval cez thunderbolt, ktory bandwidth mal. V 2015 intel haswell igpu na to bohato stacilo.
-
Ano, mělo by to fungovat samo, ale mělo by to taky jít změnit, když to náhodou nefunguje. Třeba já provozoval starý monitor, u kterého, nevím proč, Linux nedokázal získat nebo přečíst EDID, nevím. Windows se s tím nějak popasoval a to rozlišení tam bylo, ale Linux prostě řekl ne, a tím to haslo. Na Xorg bylo řešení prosté - ve Windowsu vyexportovat EDID a Xorg ho nacpat ručně v .conf souboru. Ve Waylandu takové řešení buď neexistuje, nebo jsem na něj nepřišel.
-
Starsie monitory EDID neoznamovali.
Windows (resp. ovladace pre windows) si jednoducho tipli rozlisenie/nechali pouzivatela nastavit rozlisenie a timing vypocitali podla VESA GTF. Kedze VESA s publikovanim GTF svojho casu dost blbla, tak to XFree nevedel a pouzivatel si musel vypocitat modeline ako len chcel.
-
Mi X.org vyhovuje, byl to velky posun proti Xfree86 ;-) ... chapu ze se planuje vymenit - prozatim je to ale tak, ze je Waykland horsi a pomalejsi - a mel byt lepsi a hlavne rychlejsi ... ale koncepcne je asi lepsi a vse se vyresi - nakonec na nej prejdou vsichcni, nekteri az se odladi ;-)
kdyz mi tam bude fungovat NVIDA prtes uzavreny driver - noveou nechci ani videt, ten si strcte vi tam, 20x nizsi vykon ;-) a 80% nefunguje ... takze chci CUDA nebot na ni pocitam ;-) a samnozrejme Vulkan a VDPAU
