Xweston (diskuse)

[mankind_boost]

Jak je to zatim s proprietarnima driverama pro Wayland?

[Michal]

Dělají na tom, viz třeba: http://www.x.org/wiki/Events/XDC2013/XDC2013JamesJonesEGLDevices/

Spousta lidí se snaží pošpinit Wayland tvrzením že všechny drivery je potřeba přepsat a tedy obzlášť tvůrci proprietárních driverů se k tomu mít nebudou. Ale Wayland používá převážně věci který už existujou, do proprietárních driverů je potřeba dopsat jen relativně málo aby na nich mohl Wayland bežet. Naopak, až v daleký budoucnosti bude X server obsolete, budou moci zahodit hodně kódu který byl jen pro X server.

[mankind_boost]

Dík.

[Spike]

Z konce března [Phoronix] NVIDIA Reiterates That It's Working On Wayland Support

[chrono]

Ten problém okolo DDX bol nakoniec nejako vyriešený?

[chrono]

Spousta lidí se snaží pošpinit Wayland tvrzením že všechny drivery je potřeba přepsat a tedy obzlášť tvůrci proprietárních driverů se k tomu mít nebudou. Ale Wayland používá převážně věci který už existujou, do proprietárních driverů je potřeba dopsat jen relativně málo aby na nich mohl Wayland bežet.

Čiže je potrebné všetky ovládače prepísať.

[Václav "Darm" Novák]

Ne, je potřeba přidat jen málo kódu navíc, ale časem bude možné vyhodit spoustu obsolete bordelu, který už s Waylandem nebude nutné řešit.

[kavol]

Ne,

z výše uvedeného mi plyne, že protistrana by klidně mohla říci "ano", zdá se, že je to subjektivní (co je to "přepis"? co je to "málo", teď 10% a v budoucnu, až to nabobtná jako X, to bude proti současnému stavu 99%?)

raděj bych tady viděl vyjádření někoho, kdo ty drivery fakt píše, nežli nadšené hýkání fanklubu změn pro změny, podle kterých cokoli se blíží stáří dvou let už je vykopávka, kterou je nutno nahradit

[Michal]

Podle me to neni zmena pro zmenu, ale docela pekne osekani X serveru o veci ktere uz jsou zbytecne. I dneska se da pouzit X server jakoby to byl Wayland - staci poustet jen aplikace ktery vykreslujou primo.

Historicky se to (u opensource ovladacu) vyvijelo zhruba takhle:

• Ovladace pro grafiku byly dva, jeden, velmi jednoduchej v jadre (aby se grafika inicializovala a zobrazila konzoli) a druhej v X serveru (tj. knihovna pro X server) kterej tu grafiku obsluhoval kompletne se vsim vsudy, nikdo jinej na ni nesahal. Aplikace vykreslovaly stylem: poslu zpravu X serveru ze chci nakreslit caru, X server pomoci nejakyho ze svych API (treba XAA) rekne tomuhle ovladaci ze ma nakreslit caru a ten to prelozi na prikaz grafice.
• Jenze pak se zachtelo mit 3D a podobny vymozenosti a to vyzaduje treba OpenGL. Zabalovat kazdy gl* volani do X paketu a posilat ho X serveru je fakt pomaly (a presto to existuje: XGL). Takze je potreba aby kazda aplikace byla schopna pristupovat na grafiku primo. A tak kernelovej ovladac dostal schopnost kontrolovat a mixovat ty proudy prikazu pro grafiku a X server rozhoduje o tom koho kam necha kreslit. Aplikace teda posila grafice kreslici prikazy primo! Treba volanim funkci z libGL* poskytnuty Mesou nebo proprietarnim ovladacem.
• Pak se objevily kompozitni manazery oken. Tj. misto aby vsechny aplikace kreslily na jeden framebuffer, kazda si kresli na svuj vlastni a pak to kompozitor smicha (typicky rychle pomoci OpenGL). Ony nektere zvlastne vykreslovane aplikace (3D, video, ..) se i pred tim stejne musely domichavat/overlayovat, tak proc ne vsechny. Nevyhody: Sezere to vic graficky pameti a trochu grafickyho vykonu na to finalni smichani. Vyhody: Aplikace se nemusi prekreslovat pokud se na nich nic nezmenilo (!!!), celkem lehce se daji delat efekty jako nahledy, plynuly presuny, ...
• Pak si lidi rekli ze je fakt blby aby kernel nejak napul nastavil grafiku a pak ji X server prenastavoval. A ze nechteji mit duplicitni kod v kernelu a v X serveru, tak se to presune do kernelu. A vzniklo KMS.
• No a pak si nekdo vsiml ze mame KMS v kernelu, libkms na jeho ovladani z userspacu, libGL* na rychly kresleni z aplikaci, frameworky jako Qt a GTK ktery umi libGL* vyuzit, kompozitni okeni manazery na spravu oken. Tak na co vlastne potrebujeme ten monstrozni X server? Stacila by tenka vrstva, ktera da aplikacim okno kam si muzou naprimo akcelerovane kreslit a preposle jim udalosti z klavesnice a mysi. A dokonce to ani nemusi byt vlastni proces, jen knihovna kterou pouzije ten kompozitor! Tak vzniknul Wayland.

No a po tu dobu proprietarni ovladace porad dobihaji opensource vyvoj. Jediny v cem jsou napred je rychlost samotnyho kresleni.

Tu hlavni cast - libGL* pres ktery se da primo a rychle kreslit - proprietarni ovladace davno maji. Chybi jim nejaky standardni API pres ktery by Wayland mohl delat zakladni rizeni - zjisteni co tam ma za grafiky, nastaveni rozliseni... Takovy API musi implementovat a zpristupnit. Na druhou stranu se budou moct zbavit celyho toho ovladace pro X server, ktery musi mj. umet implementovat X server-only API jako XAA/EXA/UXA/SNA/whatever na kresleni. Stacit ze uz maji to kresleni pres standardni OpenGL.

PS: Moznost pouzit X pres sit mi bude taky chybet. Ale vim ze to neni rozhodnuti z rozmaru, ale vychazi to z principu.

[TM]

Z mého pohledu, pokud není možné grafiku použít přes síť, je takový princip špatný.
Některé aplikace tunelováním X přes ssh ovládám skoro denně a vzdálené přihlašování pomocí xdmcp používám také často. Pro mě jsou různé ty Waylandy a Miry jen krokem zpět do doby kamenné.

[Václav "Darm" Novák]

RDP nebo VNC stačit nebudou? Popřípadě bude možné integrovat nějakou schopnost vzdáleného renderingu přímo do kompozitoru. A vzhledem k tomu že zájem o tu vlastnost je, nebál bych se že časem nebude.

[Michal]

Da se pouzit reseni ala VNC. Wayland ma alespon dobry prehled o tom co se v okne zmenilo. Zalezi na aplikaci, ale rychly jako X to bohuzel nebude.

Holt rychlejsi lokalni vykreslovani za cenu pomalejsiho vzdalenyho.

[hydrandt]

Některé aplikace tunelováním X přes ssh ovládám skoro denně

Hmm ja to parkrat zkousel, hlavne v dobach, kdy jsem si neumel udelat ssh tunel a tak jsem takhle spoustel vzdalene iceweasel, abych mohl nastavit nejaky port forward na adsl routeru (pres links to neslo...), a bylo to teda silene nepouzitelne, hrozne pomale, hrozne lagy, obcas se to proste zaseklo a s tim i cela moje lokalni Xka...naprosto nesrovnatelne s teamviewerem nebo sveho casu freenx, co se dalo pouzivat i na hodne spatnych linkach.

Takze mozna na lokalni siti si umim predstavit, ze to funguje, ale i kdyz bylo na obou stranach adsl, bylo to totalne nepouzitelne.

[kavol]

tak adsl je pro některé nepoužitelné i na textovou konzoli

v dobách Qt3 jsem to úspěšně používal na poctivé dvoumegabitové lince, po zkriplení způsobu vykreslování (viz tady někde okolo) jsem i přes nárůst rychlosti linky přešel na xpra, nícméně doma na gigabitu si přes to klidně i pustím na noťasu video z "velkého" stroje (buď celá session přes xdmcp, anebo čistě ssh x forwarding)

[aubi]

Na to existuje ssh -Y, mne to fungovalo dobre i na pomaly lince.

[hydrandt]

Vida, clovek se porad uci, diky moc, vyzkousim!

[Conscript89]

A dalsi volba ktera je kandidatem na pomalou linku: -C (komprese)

[hydrandt]

Jo, to pouzivam, ale zrovna v tomhle pripade (forwardovani X) to nemelo zadny pozorovatelny vliv.

[Jendа]

-Y by nemělo mít vliv na přenosové pásmo, ale možná na rychlost vykreslování.

Mimochodem nezapomeňte, že vzdálený počítač vám může hrabat na lokální X server!

[Václav "Darm" Novák]

Ony už se přes tu síť ve většině případů stejně posílaly jen bitmapy.

[kavol]

Ony už se přes tu síť ve většině případů stejně posílaly jen bitmapy.

to ale už považuju za krok zpět ... ono se to hezky křičí "je to pomalé a nepraktické", když by být nemuselo, kdyby to předtím někdo "nerozbil" (viz vývoj popsaný výše, např. proč musí Qt řešit kreslení primitiv, když je umí kreslit X server, a stačilo by mu o to říct, jak se ve verzích <4 dělo ...)

[Václav "Darm" Novák]

Přesun kreslení GUI z CPU na GPU beru jako dost pozitivní důsledek.

[Václav "Darm" Novák]

A vlastně i to co z toho plyne. GUI KDE, GNOME's hell, Unity a aplikací prostě vypadá že drží krok s konkurencí. Víc uživatelů, větší podíl Linuxu, větší tlak na vývojáře ovladačů…

[kavol]

myslíš přesun z GPU na GPU oklikou přes CPU? - no, mně se to moc pozitivně nejeví ...

[Ondrej Santiago Zajicek]

To je takova mantra, ale opravdu k tomu nekde dojde (resp. nedoslo k tomu uz davno)?

AFAIK kresleni na CPU se pouzivalo driv, kdyz jeste X server nepodporoval alpha-blendovaci operace (napr. pro kresleni antialiasovanych fontu). To uz bylo vyreseno v teorii pred vic nez deseti lety zavedenim X render extension (a v praxi pozdeji, jak X drivery zacaly X render podporovat hardwarove).

Obecne kreslen na CPU se pouziva, kdyz stavajici renderovaci API je nevhodne. Zminovane zmeny v souvislosti s Waylandem ale zadne nove renderovaci API nezavadeji, takze programy, ktere pouzivaji X api, budou dal pouzivat X api, ti pouzivajici Xrender budou dal pouzivat Xrender a ti pouzivajici OpenGL budou dal pouzivat OpenGL. Pokud nekdo driv provadel kresleni GUI pomoci CPU namisto existujicich API, proc by mu zminovane zmeny mely umoznit pouzivat GPU?

[kavol]

díky

popsaný vývoj se mi nejeví příliš zdravě ... čeho si kdo "všimne" příště, za jak dlouho se to zase bude přepisovat na něco jiného?

[Václav "Darm" Novák]

Tak tenhle koncept zní neprůstřelně na dost dlouhou dobu. Jestli to vydrží stejně jako Xserver, bude to super. A vývoj proprietárních ovladačů to díky osekání dost usnadní, takže se budou schopni soustředit na výkon.

[Michal]

Popsal jsem to takhle ve zkratce, ale samozrejme ten vyvoj neni tak nahodilej.

A nahodou mi to pripada velmi zdravy: Ze stavu "o vsechno se stara X server" se postupne zodpovednost rozdelila na vic mist. Nizky HW veci se presunuly do kernelu. (Jeste pred KMS treba X server nemohl fungovat v secure bootu protoze moc sahal na HW. Ne ze bych mel secure boot nejak rad.) Spousta veci se extrahovala do knihoven ktery muze pouzit i nekdo jiny. (Tak treba libevdev pro cteni /dev/evdev* zarizeni.) Vyvoj waylandu pomohl odhalit hodne bugu v Mese (OpenGL). Aplikace/frameworky muzou kreslit s OpenGL, ktery je standardni a dostupny na spouste jinejch platforem, tj. ta platforme zavisla cast je o dost mensi.

Ja jsem tady optimista.

[Václav "Darm" Novák]

Nevíš jak je na tom Qt s kreslením ve Windows? Ten jejich kompozitor běží nad Direct 3D…

[Michal]

Nevim, s Qt na Windows zkusenost nemam. Podle zdrojaku to vypada ze pouziva GDI (GDI+ ?), to by melo byt na Windows akcelerovany taky. Mozna se tam da, stejne jako na linuxu, taky pouzit ten OpenGL backed. Rozhodne to nepouziva DirectX.

Nicmene co pouziva na vykreslovani aplikace a co pouziva kompozitor se nijak neovlivnuje. (Tak nanejvys formatem toho bufferu ve kterym si obsah toho okna predaji, ale ten je stejne stejnej. (danej grafikou -> ovladacem))

Grafika nakonec stejne vidi jen posloupnost instrukci a je ji jedno jestli vznikly tak ze aplikace volala DirectX, OpenGL, nebo posilala zpravy X serveru. Jde jen o to jak efektivne se k ni dostanou. Asi tak jako procesor vidi posloupnost instrukci a nevi jestli to je od zkompilovanyho Fortranu, C, nebo jestli prehrava interpret Pythonu...

[krabicezpapundeklu]

Používá buď OpenGL, nebo OpenGL ES + ANGLE ("překladač" OpenGL ES a GLSL do DirectX a HLSL.).

[kavol]

Ze stavu "o vsechno se stara X server" se postupne zodpovednost rozdelila na vic mist.

nějak nerozumím, co je na tom tak zdravého, proč je vůbec potřeba mít to na více místech nad rámec modularity X ...

Nizky HW veci se presunuly do kernelu.

v souvislosti s výše uvedeným nechápu, co mám vidět za výhodu v tom, že je jeden moloch zeštíhlen na úkor toho, že druhý ztloustne

Spousta veci se extrahovala do knihoven ktery muze pouzit i nekdo jiny. (Tak treba libevdev pro cteni /dev/evdev* zarizeni.)

viz výše o modularitě ... k tomu snad nebylo potřeba znovu vynalézat kolo

Vyvoj waylandu pomohl odhalit hodne bugu v Mese (OpenGL).

to je zajisté užitečný vedlejší efekt, ale jako argument pro vývoj to má nulovou hodnotu

Aplikace/frameworky muzou kreslit s OpenGL, ktery je standardni a dostupny na spouste jinejch platforem, tj. ta platforme zavisla cast je o dost mensi.

no, nevím, proč by nemohly i tak - popravdě, tvrzení o "fakt pomalém" XGL se mi nějak nezdá ... já tedy po letech nevím, jestli to bylo zrovna XGL nebo nějaký jiný čert, ale kdysi mi Quake 3 Arena chodil na Linuxu líp než na Woknech; o velikosti jeho platformově závislé části nemám ponětí, ale řekl bych opengl jako opengl ...?

[Mike]

No jo, věčně zhrzená konzerva, co bude pořád jen brblat... představuju si tě jak nějaký zapšklýho starýho dědka, tak na mě v diskuzích čím dál častěji působíš

[kavol]

jasně, podílet se na vývoji softwaru je ideální zaměstnání pro konzervu, nemluvě o mimopracovních věcech, kdy třeba teď uvažuju o nákupu elektropřibližovadla (i když na tom vlastně není nic progresivního, na elektriku se jezdilo dřív než na benzín, sorry, špatnej příklad)

jdi s tím nálepkováním do háje, protože považuju za ztracenej čas a peníze a taky uživatelský pohodlí, když se po letech znova vynalezne kulatý kolo, protože se předtím muselo vymyslet hranatý, tak je potřeba dělat ze mě třídního nepřítele?

jak nemám bejt zapšklej, když tu útočíš ad hominem, místo toho, abys mi tedy nějak racionálně vysvětlil, k čemu to celý bylo dobrý a jak to jinak nešlo, proč tady už dávno nemáme X11R20 a místo toho se vymějšlí Wayland, v roce 2012, když "design flaws" Xek se rozebíraj, včetně možnejch řešení, už od počátku devadesátejch let minulýho století? - to si myslíš, že je chování, který mě má přesvědčit, abych byl vstřícnější, abych nebyl "zhrzenej"?

[pavlix]

A argumenty by nebyly?

[Ondrej Santiago Zajicek]

á tedy po letech nevím, jestli to bylo zrovna XGL nebo nějaký jiný čert

XGL bylo zalezitost XFree 3.x. Pokud dobre pamatuju, tak uz od verze 4 se pouzival direct rendering pri lokalnim pouziti.

Na druhou stranu nevidim duvod, proc by XGL bylo nejak extra pomale. Opecne OpenGL je asynchronni rozhrani a ma separaci mezi klintskymi a renderovacimi objekty, takze provest jeho sitovou serializaci rozumne rychle by nemel byt problem. Samozrejme v pripade, kdy se provadi rendering lokalne, je to zbytecny overhead, a OpenGL knihovna muze automaticky zvolit direct rendering nebo sitovou serializaci.

[xkucf03]

Díky za komentář.

Moznost pouzit X pres sit mi bude taky chybet.

Mně taky. Šlo by to nahradit přes Spice? Dneska používám Xka tunelovaná přes SSH pro 3D grafiku (nic moc náročného, ale jde o to, aby 3D fungovalo).

[Michal]

Jo, Spice nebo VNC nebo podobny protokol, ktery prenasi az vysledny obraz, lidi od Waylandu slibujou. Taky jsem cetl nejaky uvahy o VirtualGL/XGL, tj. vzdaleny opengl volani. Oboji by s 3D slo a ani jedno by nebylo moc vykonny. Ale to je presne to co dostanes dneska pri pouziti 3D pres ssh: Bud se pouzije XGL a kazdy volani opengl funkce se posle vzdalenymu X serveru a ten ho provede na grafice u sebe. Nebo se pouzije softwarovy renderovani (swrast z Mesy, protoze bez pozehnani X serveru ta aplikace na mistni grafiku nemuze) a vzdalenymu X serveru se posilaji vysledny obrazky. Kazdy ma svoje vyhody a nevyhody. Defaultne se myslim snazi pouzit XGL, ale da se vynutit to druhy s LIBGL_ALWAYS_INDIRECT promennou prostredi.

[David Jaša]

Dost dobře si to nedokážu představit bez spolupráce kompozitoru (aby se kompozitování dělo na klientovi a všechno ostatní vykreslování lokálně na serveru/hypervizoru), a to jsem si nějak nevšiml, že by bylo na pořadu dne. :(

[Josef Kufner]

PS: Moznost pouzit X pres sit mi bude taky chybet. Ale vim ze to neni rozhodnuti z rozmaru, ale vychazi to z principu.

V podstatě to ani není až tak velký problém, jen to prostě je mimo Wayland. Vcelku se nabízí možnost spustit na vzdáleném stroji nějakou proxy, která nakreslené buffery pošle na lokální displej. O nějakém snažení už jsem zaslechl.

Co bych ale ocenil, je síťový přenos událostí už na úrovni toolkitu. Aplikace by se namísto k displeji připojila k GUI serveru a posílala mu, co chce zobrazit, a přijímala, co provedl uživatel. Narozdíl od X by to bylo na úrovni primitiv toolkitu, nikoliv kreslení čar a stisků kláves. Například v Qt by se přenesl signál o kliknutí na tlačítko, namísto stisknutí myšítka, nebo při stisku písmenka by se objevil text v QLineEdit, ale po síti by se nic nepřeneslo, protože aplikace by měla odchycený signál na potvrzení dialogu. Potíž je, co s widgety specifickými pro aplikaci, které si kreslí, jak je napadne.

[xkucf03]

Takové pokusy tu byly už přes několika lety – Qt GUI přes HTTP/AJAX.

[Václav "Darm" Novák]

Vím že je to něco trochu jiného, ale docela mě to zaujalo http://youtu.be/NESnTYVJxxU

[David Jaša]

Co bych ale ocenil, je síťový přenos událostí už na úrovni toolkitu. Aplikace by se namísto k displeji připojila k GUI serveru a posílala mu, co chce zobrazit, a přijímala, co provedl uživatel. Narozdíl od X by to bylo na úrovni primitiv toolkitu, nikoliv kreslení čar a stisků kláves. Například v Qt by se přenesl signál o kliknutí na tlačítko, namísto stisknutí myšítka, nebo při stisku písmenka by se objevil text v QLineEdit, ale po síti by se nic nepřeneslo, protože aplikace by měla odchycený signál na potvrzení dialogu.

Tady bych viděl hlavní potíž ve změnách protokolu - jednak se GUI toolkity vyvíjí velmi rychle, druhak potřebuješ nějak syncat schopnosti klienta, serveru a programu. To buď vede na využívání jen malé vzájemně kompatibilní podmnožiny schopností toolkitu (takže můžeš rovnou používat ty klapnutí, kliknutí a čáry), nebo musíš zajistit sync verzí na klientovi a serveru (vem do úvahu spojení k víc serverům různých architektur naráz), nebo budeš pokaždé přenášet část knihovny ze serveru na klienta.

Jako myšlenka dobrý, ale nedokážu si představit, že by v praxi přínosy převážily problémy při nasazování.

[pavlix]

Jako myšlenka dobrý, ale nedokážu si představit, že by v praxi přínosy převážily problémy při nasazování.

+1

Nic proti waylandu, ale trochu mě děsí ta halda lidí, co se vždy snaží nějak obhájit to, že už možná nikdy nebude fungovat klasický X11 forwarding a spouštění jednotlivých aplikací na vzdálených strojích vykreslujících své okno dolokální session. Však ono se to nějak vyřeší, že. To už je snad lepší, když řeknou, že je to nezajímá, protože to oni nepoužívají.

A ani představa, že různé vzdálené aplikace budou mít namísto jednoho standardu různé požadavky na lokální software mi nepřijde zrovna lákavá.

[Spike]

Ono to okno aplikace třeba ve Windows přes RDP nefunguje? Nevšiml jsem si, že by kvůli tomu potřebovali pošahanou svatou krávu X11.

[pavlix]

Windows nemám.

[Spike]

Škoda. Občas není špatný se podívat, jestli ti před 10 lety neujel vlak. Už funguje v té síťové transparentní úžasnosti přihlášení do běžící session?

[pavlix]

Škoda. Občas není špatný se podívat, jestli ti před 10 lety neujel vlak.

Rétorika podomního obchodníka. Do toho, co používám ke své práci a potažmo i zábavě je ti hovno. Spousta lidí používá windows ke své spokojenosti nebo s jejich pomocí vydělává a přesto nemají potřebu je druhým vnucovat.

[Spike]

Já bych se jako podomní obchodník neuchytil. ;) Spousta lidí používá všechno možné, takže jim pak přijdou některé proklamace o nenahraditelné nejúžasnější síťové transparentnosti X11 trochu nadnesené. To je vše.

[pavlix]

Pak ovšem nechápu, proč si ten problém léčíš zrovna na mně. Wayland je tu zjevně proto, aby nahradil X11, je tedy logické, že se dosavadní uživatelé X11 zajímají, o co všechno při tom přechodu přijdou.

[misko]

staci sa pozret na Tizen a wayland podporu od Intelu a ARM Mali ovladace su a ani im to dlho netrvalo

[pavele]

Zatím se zdá, že jde vše cestou evoluce a ne revoluce, jako např. systemd. Vítám takový přístup postupného přechodu.

[kralyk z abclinuxu]

Souhlasím, ale na druhou stranu ani evoluční postup se nesmí přehánět. Například podle aktuálního vývoje bych řekl, že schopnost používat IPv6 se u druhu homo sapiens sapiens vyvine až zhruba za 100 000 let, a to jsem optimista :-/

[Ondrej 'SanTiago' Zajicek]

Naopak, po mnoha letech stagnace je aktualni vyvoj dost pozitivni. Aktualni dostupnost IPv6 u klientu presahuje 4 % a poslednich nekolik let roste exponencialnie - zhruba udrzuje tempo zdvojnasobeni podilu za 3/4 roku. Kdyby se to tempo udrzelo, tak za 3 roky bude dostupnost u klientu vetsi nez 50 %.

[Peter Golis]

Tak Wayland a ARM Mali je pekná kombinácia. Škoda len že v tom oznámení o proof of concept nemajú popísané o ktoré Mali generácie sa jedná. Propagačné filmíky som nepozeral, nalinkovali ich cez flash a ten na ARM chodí dosť zúfalo. Hlava XXII.