Portál AbcLinuxu, 9. května 2025 00:26
Při porovnávání Waylandu s X Window Systemem se často zdůrazňuje, že Wayland není síťově transparentní, že není možné, aby aplikace běžela na jednom počítači a byla zobrazována na jiném. Derek Foreman ze Samsung Open Source Group představil v příspěvku WOW, Wayland Over Wire! na blogu návrh řešení tohoto problému a do diskusního listu věnovanému Waylandu poslal příslušné patche [reddit].
Tiskni
Sdílej:
a zaroven transparentni beh pres sit je Killer Feature X-Windows a no-go pro Wayland
tím, že se začne používat wayland, tak přece neznamená, že se přestane používat x.Nová dominantní technologie klidně může způsobit, že si člověk nebude moci dovolit v praxi stávající technologii použít.
Jestli to bude na nějakým serveru, tak "modulární" xorg.Xorg na serveru je ugly hack, který se používá, když špatný serverový software vyžaduje GUI.
Ale tady těma krokama už vidím to, že se začnou na wayland nabalovat funkce a bude tam, kde byl x(xfree) před 25 lety. Navíc čím víc kódu, tak tím víc chybA přitom nikdy nedotáhne funkce X11, o kterých se tu bavíme. Ale na druhou stranu jako podporovatel waylandu jistě vývojářům věříš, že jsou schopni lepších výsledků než vývojáři X. :)
Clients must use the wl_shm buffer type to work, meaning EGL and dmabuf won’t work.Njn, vždyť to říkám. Třeba QtWayland AFAIK používá jen EGL nebo GLX...
10.2.2016 12:13
Václav "Darm" Novák | skóre: 26
| blog: Darmovy_kecy
| Bechyně / Praha
Po 15 letech používání primary selection mi leze víc a víc na nervy nepřesnost chycení myší, vlastně nikdy pořádně nevím, co se mi překopíruje. Občas člověk při uvolňování prostředního tlačítka myší hýbne a pak se diví, co se mu to v terminálu spustilo. Ctrl+Shift+C/V novějších Xkových terminálů je daleko pohodlnější a hlavně bezpečnější.Máš asi namysli uvolňování levého tlačítka. Osobně na trackpointu ani s externí myší nepozoruju větší problémy s označením při použití tlačítka a bez něj.
Navíc ve VIMu přes SSH se ještě musí šachovat se shiftemVim přes SSH ovládám zcela totožně jako bez SSH, netuším o jakém šachování je tu řeč. Osobně ve vimu používám
10.2.2016 12:34
!xsel, což je další klíčová vlastnost X11, o kterou bych nerad přišel.
Ohledně toho vybraného inputu - u některých zabugovaných softů (myslím, že to dělaly GUI aplikace v Kylixu) je potřeba skriptem přehazovat schránku mezi primary a secondary, v takovém případě by se skript tedy k datům vůbec nedostal.Tady jde o to, že řešení existuje. Na vývojářské pracovní stanici stejně uživatelské aplikace nebývají oddělené, takže nemá smysl podobná opatření vůbec zapínat.
Za sebe bych v dnešní době klidně primary selection zrušil.Za sebe a ve svém systému si ho klidně zruš.
Máš asi namysli uvolňování levého tlačítka. Osobně na trackpointu ani s externí myší nepozoruju větší problémy s označením při použití tlačítka a bez něj.Jasně, levého, sorry. K poškození pracně označeného výběru dochází při jeho uvolnění velice často.
Vim přes SSH ovládám zcela totožně jako bez SSH, netuším o jakém šachování je tu řeč. Osobně ve vimu používám !xsel, což je další klíčová vlastnost X11, o kterou bych nerad přišel.
Ovládání je stejné, ale při výběru myší z vim v ssh do jiného vimu v ssh v terminálu je občas potřeba při výběru držet shift, jinak se označení nevybere. Je to klasika http://stackoverflow.com/a/4608387. OK, šlo by to překonfigurovat
Tady jde o to, že řešení existuje. Na vývojářské pracovní stanici stejně uživatelské aplikace nebývají oddělené, takže nemá smysl podobná opatření vůbec zapínat.Nevím, co myslíš oddělenými aplikacemi, ale tohle se týkalo normální Xkové aplikace (starší verze účetnictví v Kylixu), která nekomunikuje přes secondary selection. Navíc se tam ještě mršilo kódování češtiny, co si pamatuju.
Jasně, levého, sorry. K poškození pracně označeného výběru dochází při jeho uvolnění velice často.Chápu, ale nemůžu potvrdit.
Ovládání je stejné, ale při výběru myší z vim v ssh do jiného vimu v ssh v terminálu je občas potřeba při výběru držet shift, jinak se označení nevybere. Je to klasika http://stackoverflow.com/a/4608387. OK, šlo by to překonfigurovatNikde se tam nezmiňuje SSH a nevím, proč by mělo hrát roli. Ale ani nepoužívám
mouse=a, takže nemůžu sloužit.
Nevím, co myslíš oddělenými aplikacemi,V tom případě není důvod se vůbec bavit o ochraně označených řetězců.
Ovládání je stejné, ale při výběru myší z vim v ssh do jiného vimu v ssh v terminálu je občas potřeba při výběru držet shift, jinak se označení nevybere. Je to klasika http://stackoverflow.com/a/4608387. OK, šlo by to překonfigurovatTohle nijak nesouvisi se ssh. Tohle je vlastnost terminalu term. Alespon tech jeho novejsich verzi. Aplikace muze zjistit co je na terminalu napsano, co je oznaceno a taky muze zjistit kam uzivatel kliknul mysi. Ten shift zaridi, ze kliknuti funguje "lokalne" a do aplikace se nic neposila. Tohle se tyka i links-u anebo mc.
11.2.2016 10:10
Václav "Darm" Novák | skóre: 26
| blog: Darmovy_kecy
| Bechyně / Praha
Hezky to popsali tak, aby se to nedalo číst, že je to funkce, která k***vsky šetří práci, což vidím pokaždé, když koukám přes rameno do terminálu kolegovi, kterému tohle nefunguje.Nevím, co dělá kolega špatně, ale mně funguje v terminálu cut & paste i bez primary selection...
Jak říkám, pokud nebude mít wayland primary selection, mně osobně to nevadí. Ale chápu, že to pro někoho může být show stopper.
10.2.2016 14:00
Fluttershy, yay! | skóre: 93
| blog:
10.2.2016 18:15
Grunt | skóre: 23
| blog: Expresivní zabručení
| Lanžhot
10.2.2016 18:57
Grunt | skóre: 23
| blog: Expresivní zabručení
| Lanžhot
TCP/IP
Xorg listens on port 6000+n, where n is the display number. This
connection type is usually disabled by default, but may be enabled
with the -listen option (see the Xserver(1) man page for details).
Tunelování X přes SSH považuju za obrovskou výhodu Linuxu.No jistě, používá to tak asi 1 člověk ze 100 a nadává u toho... Skoro bych si myslel, že Linuxáci budou spíš na command-line interface. A pak přijde Wayland, a najednou chtěj všichni okýnkna po síti...
No jistě, používá to tak asi 1 člověk ze 100 a nadává u toho...Docela by mě zajímalo, jak by vypadal svět, kdybysme zrušili všecko u čeho lidé nadávají. :D
Skoro bych si myslel, že Linuxáci budou spíš na command-line interface.Jsou případy, kdy to nejde nebo je to nepraktické.
A pak přijde Wayland, a najednou chtěj všichni okýnkna po síti...Všichni, kteří doposud některé situace mohli řešit pomocí X11 po síti a najednou se dozvěděli, že jim chtějí tuto možnost odebrat. Navíc to pro většinu není jediná funkce, o kterou přijdou a nejspíš přijdou i o funkce o kterých si ani neuvědomovali, že je potřebují. Wayland tak bude na některé působit jako návrat do minulosti... nebo do Windows.
A na ta rozšíření jsem zvědavý. Když se říká, že všechno můžou řešit rozšíření, je to většinou signál k opatrnosti.Obrovské množství software funguje přesně takhle a imho to není úplně špatně. Namátkou editory (vč. klasických jako Vim a Emcas), IDE, prohlížeče, mailový klienti, file managery atd...
10.2.2016 14:15
Hans1024 | skóre: 5
| blog: hansovo
10.2.2016 16:33
Dreit | skóre: 15
| blog: Dreit a jeho dračí postřehy
| Královehradecký kraj
10.2.2016 20:23
little.owl | skóre: 22
| blog: Messy_Nest
| Brighton/Praha
10.2.2016 23:28
Hans1024 | skóre: 5
| blog: hansovo
11.2.2016 00:29
little.owl | skóre: 22
| blog: Messy_Nest
| Brighton/Praha
Přitom řešení na kompletních bitmapách vyžaduje při překrývajících se oknech mnohem více paměti, než muselo stačit X-kám, kterým historicky stačila jen paměť jedné virtuální obrazovky.Neřeší to celkem standardní clipping? Skládání v hardware (hardware overlay) se navíc ukazuje jako ještě výhodnější řešení, když to umí software správně využít, což aktuální X11/Xorg umí dost blbě. A tak.
Myslím, že hlavní problém je zcela jinde. Dnes si nikdo nedokáže představit aplikaci bez antialiasingu fontů a přechodů v pozadí, lištách atd.Někdo to zjevně vidí jako problém! Měl by ses stydět, že máš něco tak neergonomickýho a energeticky náročných, jako jsou nekostrbatý fonty. :)
Jakých tajemných omezení se máme bát?Třeba v oblasti xinput, xrandr a dalších o kterých se v souvislosti s waylandem moc nemluví?
Někdy mám pocit, že někteří jedinci mají prostě jen psychologický blok z tohoSpíše mám pocit, že mají někteří jedinci psychologický blok, když si někdo dovolí kritizovat jejich oblíbený kus software a tak si vymýšlejí konspirační teorie jako že někdo potřebuje konkrétní sérii znaků a další blbiny.
Někdy mám pocit, že někteří jedinci mají prostě jen psychologický blok z toho, že by snad pro vzdálené připojení nepoužívali přesně sekvenci znaků "ssh -X", ale, chraň bůh, třeba "ssh -W".Mam úplně stejný pocit. Jim je ve skutečnosti jedno, jestli má Wayland takové nebo makové technické vlastnosti, většině lidí jde o to, aby nemuseli naprosto nijak měnit své návyky. Přesně ze stejných důvodů sklidí pokaždé kritiku jakákoli nová verze KDE, Gnome, ls, Fedory, Firefoxu atd. Prostě cokoli, co není striktně zpětně kombatibilbí release, je špatně.
ssh -X nepotřebuje. Možná mi přijde trochu podivné na UNIXovém systému bazírovat na okýnkách, ale ok, chápu, že jsou situace, kdy to bohužel jinak nejde.
Co mi vadí je, že lidi požadují integraci této fíčury do kompozitoru, a to v podstatě jenom z toho důvodu, že "U X11 to tak bylo, takže u Waylandu by to tak taky mělo být". Přijde mi to nemlich to samý jako systemd-resolved nebo systemd-whateverd. Prostě to tam z hlediska návrhu, KISS principu atd. nemá co pohledávat.
A co je na tom extra fascinující je, že ti samí lidé si stěžují, že systemd touto cestou jde, zatímco u Waylandu si stěžují, že touto cestou nejde.
Nechci někomu cpát, že ssh -X nepotřebuje. Možná mi přijde trochu podivné na UNIXovém systému bazírovat na okýnkách, ale ok, chápu, že jsou situace, kdy to bohužel jinak nejde.Ale tady se nebavíme o ideálním návrhu, ale o praktickém adminování, kdy takové situace skutečně nastávají. A lidé je řeší pro hodně staré i hodně nové aplikace, takže je žádoucí mít řešení, které bude fungovat univerzálně.
Co mi vadí je, že lidi požadují integraci této fíčury do kompozitoruStraw man. Ve skutečnosti jde adminům jen o to, aby tato vlastnost, která byla doposud více méně univerzálně dostupná, byla i nadále univerzálně dostupná. A pokud jde o
ssh -X, tak si naopak myslím, že je tady velký prostor pro zlepšení.
Přijde mi to nemlich to samý jako systemd-resolvedNení. Pokud vím, tak systemd-resolved nabídne podmnožinu funkcionality DNS resolveru, kterou můžou aplikace používat. Pro aplikace, které potřebují plné DNS je tu unbound. Pro obsluhu obou typů aplikací bude muset mít člověk nainstalované oba projekty. Na úrovni distribuce se akorát musí zajistit integrace, protože každá služba v systému, která cachuje DNS představuje problém pro mobilitu.
nebo systemd-whateverd.Neznám, nemůžu posoudit.
A co je na tom extra fascinující je, že ti samí lidé si stěžují, že systemd touto cestou jde, zatímco u Waylandu si stěžují, že touto cestou nejde.Pokud vím, tak si u obou stěžují na způsobené regrese, a v tom nevidím žádný rozpor.
Ve skutečnosti jde adminům jen o to, aby tato vlastnost, která byla doposud více méně univerzálně dostupná, byla i nadále univerzálně dostupná.Proč to teda v tom případě chtějí po Waylandu, který jednak IMHO není to správné místo pro implementaci téhle věci a jednak je otázka, jestli vůbec má tu možnsot (protože EGL).
Není. Pokud vím, tak systemd-resolved nabídne podmnožinu funkcionality DNS resolveru, kterou můžou aplikace používat.Mně šlo o to nesmyslné nabalování funkcionality do systemd, na které si lidi stěžují, ať už to přináší regrese nebo ne. Viz ty komentáře, jestli už to umí bulánky. Ne, že bych s nimi nesouhlasil, taky to nevidim rád, nicméně narvat do Waylandu
ssh -X - a to ještě i třeba s HW akcelerací a jánevím čím vším, jak někteří vyhrožují - by mi přišlo v tomhle ohledu to samé.
Proč to teda v tom případě chtějí po Waylandu, který jednak IMHO není to správné místo pro implementaci téhle věci a jednak je otázka, jestli vůbec má tu možnsot (protože EGL).Straw man. Jde pouze o to, zda bude tato funkcionalita i nadále univerzálně dostupná. Tedy, zjednodušeně řečeno, jestli skupina softwarových balíků, které dneska tvoří běžně používanou funkcionalitu X, bude nahrazena jinou (ne nutně disjunktní) skupinou balíků, které nabídnou stejnou nebo odpovídající funkcionalitu. Nic na tom nemění ani to, že někteří šíří svoje nápady, jak by se to mohlo udělat. Ty nápady můžou být na škále od hodně dobrých až po zcela nepoužitelné. Ale pořád jsou to jenom nápady, podstatné je, zda se docílí výše popsaného výsledku nebo nikoliv.
nicméně narvat do Waylandu ssh -X - a to ještě i třeba s HW akcelerací a jánevím čím vším, jak někteří vyhrožují - by mi přišlo v tomhle ohledu to samé.Vzhledem k tomu, že
ssh -X není ani součástí Xorg, považuju tutu stížnost za bezpředmětnou.
Ale pořád jsou to jenom nápady, podstatné je, zda se docílí výše popsaného výsledku nebo nikoliv.To mi až tak podstatné nepřijde - takovým nebo onakým způsobem se toho docílí určitě. IMHO se ale spousta lidí bude zlobit, že třeba nebude dostupný drop-in replacement nebo že to bude fungovat trochu jinak. Což bude určitě, vzhledem k jiné architektuře Waylandu, důrazu na provázanost s HW, atd.
To mi až tak podstatné nepřijdeJá se na to dívám z pohledu uživatele, který se bude muset potýkat s regresemi namísto toho, aby nahlásil pár chyb, naučil se pár nových věcí, a fungoval dál jako doposud.
Nemyslim si, že je úplně prakticky možné se u takovéhle změny technologie obejít bez regresí.Pak existuje ještě jedna možnost, a to vzniklé regrese aktivně řešit.
14.2.2016 14:35
little.owl | skóre: 22
| blog: Messy_Nest
| Brighton/Praha
Tak vetsina lidi chce souvisejici funkcionalitu a ted jim hrozi, ze s nasazenim Wayland on ni prijdou, nikoliv ze to musi byt zadratovane ve Wayland.+1
V rade use case nasazeni Wayland v soucasnem stavu nic moc neprinasi, ale spise bere; za rok dva to muze byt jine.Přičemž vůbec není zřejmé, zda bude jiné pro všechny znamenat jednoznačně lepší. A ve chvíli, kdy budou „in the wild“ wayland-only aplikace (ať už na úrovni zdrojáků nebo hotových buildů), už nebude cesty zpět.
11.2.2016 14:00
little.owl | skóre: 22
| blog: Messy_Nest
| Brighton/Praha
Dnes si nikdo nedokáže představit aplikaci bez antialiasingu fontů ...To se ani nedivim. A brzy s poradnym rozlisenim.
1) Buď přenášet lépe či hůře komprimované bitmapy.To bych povazoval za reseni "lepsi neco nezli nic". Pokud bitmapa neni renderovana pro uzity display a jsou tam i minimalni artefakty po kompresy, vypada to casto dost spatne, zejmena i zminene fonty.
2) Přístup aplikací řízeného vektorového vykreslování typu X-windows. ...To se musi resit protokolem, ktery bude umet veci od zakladnich vektorovych primitiv, pres zasilani fontu, s podporou veci jako scene graph. Zatim v nedohlednu.
3) Manipulace na straně klienta (grafického serveru) s výrazně většími objekty, ...
Pokud bitmapa neni renderovana pro uzity displayA zrovna tohle třeba RDP určitě nedává. A bál bych se, že i při přenášení oken implementované někým, kdo to vlastně ani nechce používat, se budou bitmapy vykreslovat nezávisle cílovém zobrazovacím zařízení. A zase budu koukat na duhové nápisy. :D
To se musi resit protokolem, ktery bude umet veci od zakladnich vektorovych primitiv, pres zasilani fontu, s podporou veci jako scene graph. Zatim v nedohlednu.V nedohlednu, ale chtělo by to, aby protokol počítal s rozšiřitelností a fallbackem na primitivnější metodu.
Co přesně nedává? Teď jsem se ze svého počítače s UHD displejem přihlásil přes RDP na starou testovací mašinu s Windows XP a nic problémového nevidím.Pokud bitmapa neni renderovana pro uzity displayA zrovna tohle třeba RDP určitě nedává. A bál bych se, že i při přenášení oken implementované někým, kdo to vlastně ani nechce používat, se budou bitmapy vykreslovat nezávisle cílovém zobrazovacím zařízení. A zase budu koukat na duhové nápisy. :D
11.2.2016 19:16
Grunt | skóre: 23
| blog: Expresivní zabručení
| Lanžhot
Ten protokol tu dnes máme. Jmenuje se X11. A nikdo ho už takřka nepoužívá, neboť to nestačí. Wayland udělal dobře, že omezil vykreslování na společnou základní věc (framebuffer). To zjednodušení je velmi výrazné a může to sloužit jako základ pro další chytřejší nadstavby. Já vidím tři možnosti, jak efektivní grafiku po síti přenášet: 1. Přenos vykreslené bitmapy. Je to neefektivní, ale bude to fungovat se vším. Navíc to může řešit kompozitor bez podpory aplikace. 2. Přenos OpenGL příkazů. Trochu efektivnější verze předchozího, obzvlášť na větších rozlišeních a při malém množství textur. Tohle má asi k vektorovému vykreslování nejblíž a šlo by to pořešit na úrovni knihoven, kde by kompozitor jen poskytl transportní vrstvu. 3. Přenos na úrovni toolkitu. Toolkit serializuje požadované GUI a pošle ho svému protějšku po síti. Ten to interpretuje, vykreslí s použitím místních knihoven a zpět pošle už předzpracované události (kliknutí na položku menu namísto pohybu myši). To by bylo asi nejefektivnější a vzdálená aplikace by byla k nerozeznání od lokální. Vyžaduje to ale ten interpret na zobrazovadle. Řekl bych, že k tomuto směřuje web.2) Přístup aplikací řízeného vektorového vykreslování typu X-windows. ... 3) Manipulace na straně klienta (grafického serveru) s výrazně většími objekty, ...To se musi resit protokolem, ktery bude umet veci od zakladnich vektorovych primitiv, pres zasilani fontu, s podporou veci jako scene graph. Zatim v nedohlednu.
11.2.2016 16:44
Petr Tomášek | skóre: 39
| blog: Vejšplechty
3. Přenos na úrovni toolkitu. Toolkit serializuje požadované GUI a pošle ho svému protějšku po síti. Ten to interpretuje, vykreslí s použitím místních knihoven a zpět pošle už předzpracované události (kliknutí na položku menu namísto pohybu myši). To by bylo asi nejefektivnější a vzdálená aplikace by byla k nerozeznání od lokální. Vyžaduje to ale ten interpret na zobrazovadle. Řekl bych, že k tomuto směřuje web.
Ano, přesně tohle si myslím, že by bylo ideální řešení pro nástupce X11. Mělo by to ten "vedlejší" efekt, že by se dalo snadněji oddělit GUI od logiky aplikace, takže by bylo snažší např. mít různá GUI pro různé typy zařízení (s tou samou aplikací). Např. stejná aplikace by tak mohla fungovat jak na desktopu tak na šmatlafounu. Ale znamenalo by to konec toolkitů jako je Qt nebo GTK+.
11.2.2016 18:15
Petr Tomášek | skóre: 39
| blog: Vejšplechty
14.2.2016 10:35
Petr Tomášek | skóre: 39
| blog: Vejšplechty
Jasně, prostě stačí framebuffer. A pak by ještě nebylo špatně se dohodnout na nějakém společném způsobu, jak se budou bavit ty aplikace s kompozitorem, která aplikace bude dostávat vstupní události, jak z nich udělat "okna" a pár dalších drobností, aby to tak nějak fungovalo dohromady, třeba i na různých platformách a s různými backendy... a ještě bys to mohl nějak nazvat, třeba podle nějakýho zapadákova...+1
Ale jasně, lidi, co na tom pracují, zjevně neví, co dělají a co je potřeba. Už jsi jim řekl, že nedělají nic jiného než framebuffer s pár implementačními detaily a jejich práce je zcela zbytečná?Tak jaká práce je užitečná a jaká ne, to je snad opravdu věcí názoru, ne?
Tak jaká práce je užitečná a jaká ne, to je snad opravdu věcí názoru, ne?Rozhodně. V tomto případě mi přijde užitečná jak práce na Waylandu a na jeho podpoře, tak práce na Xorg (podpora libinput, DRI3, xf86-video-modesetting, GLAMOR atd.), i když by někdo řekl, že je to zbytečné prodlužování agónie. Někomu zase přijde užitečnější práce na Miru... :D
14.2.2016 14:35
little.owl | skóre: 22
| blog: Messy_Nest
| Brighton/Praha
14.2.2016 17:19
little.owl | skóre: 22
| blog: Messy_Nest
| Brighton/Praha
Wayland nemůže být nástupcem X11 (jestliže je na X11 postavený)XWayland implementuje X11 protokol, a to ze je postaveny na stavajici kodu nehraje roli, nema smysl ho psat znovu a bude se vyvijet svou cestou.
navíc nemůže být plnohodnotným nástupcem XorgTo nikdo netvrdi. Z X11 implementace byla v minulych letech vyvedena prakticky veskera zavislost na HW, podstatna cast sla do kernelu, cast byla reimplementovana ve forme externich knihoven a cast koexistovala ve stejne repository majici v nazvu x*; tam az tak velke zmeny nejsou. n
trojice zahrnující X11 backendPokud se na to kouknem z pohleduj aplikace, tak tem je backend ukradeny.
11.2.2016 14:08
Petr Tomášek | skóre: 39
| blog: Vejšplechty
Myslím, že hlavní problém je zcela jinde. Dnes si nikdo nedokáže představit aplikaci bez antialiasingu fontů a přechodů v pozadí, lištách atd. Tím pádem jednoduché vykreslování pomocí geometrických primitiv posílaných po odkrytí/update plochy (exposition) z klienta na server zcela padá.
No tak takovou hovadinu už jsem dlouho neslyšel. Samozřejmě, že je možné vykreslovat fonty s antialiasingem, bezierovy křivky (vyhlazené) nebo barevné přechody na straně serveru. Akorát by někdo musel napsat rozšíření, které příkazy pro Cairo knihovnu serializuje a na straně serveru vykreslí...
X-ka se pomerne radikalne predelavala minimalne poslednich dvanact let a z podstatne casti prave temi lidmi kteri ted stoji za vyvojem Wayland.To jsem si myslel. Proto taky neberu argumenty, že něco sice ve waylandu nefunguje, ale v X už taky moc ne.
11.2.2016 14:02
Petr Tomášek | skóre: 39
| blog: Vejšplechty
Co je moderního na tom, že se všechna práce hodí na aplikaci a ta dostane jen přístup do framebufferu, kam si bude čmárat?Práci odvede toolkit. A toolkity už to dnes dělají tak jako tak.
Co je moderního na tom, že aplikace musí mít přímí přístup do videopamětiHeadless režim Westonu potřebuje taky přístup do videopaměti?
11.2.2016 14:29
Hans1024 | skóre: 5
| blog: hansovo
11.2.2016 18:53
little.owl | skóre: 22
| blog: Messy_Nest
| Brighton/Praha
11.2.2016 19:42
Hans1024 | skóre: 5
| blog: hansovo
11.2.2016 22:40
little.owl | skóre: 22
| blog: Messy_Nest
| Brighton/Praha
12.2.2016 19:45
Hans1024 | skóre: 5
| blog: hansovo
14.2.2016 14:37
little.owl | skóre: 22
| blog: Messy_Nest
| Brighton/Praha
11.2.2016 13:59
Petr Tomášek | skóre: 39
| blog: Vejšplechty
11.2.2016 14:44
Hans1024 | skóre: 5
| blog: hansovo
Fakt nechápu, proč nemůže např. 2D vykreslování probíhat pomocí Cairo (nebo něčeho na ten způsob) na straně serveru a na straně klienta mít jenom tenkou vrstvu, která volání pro Cairo serializuje.Zjevnou vyhodou kresleni na strane klienta je vykon vyplyvajici z paralelniho kresleni jednotlivych aplikaci.
11.2.2016 16:38
Petr Tomášek | skóre: 39
| blog: Vejšplechty
11.2.2016 15:04
Grunt | skóre: 23
| blog: Expresivní zabručení
| Lanžhot
IMHO by nejlepší bylo vytvořit úplně nový protokol, slušně napsaný tak aby se požadavky neposílaly sem tam a nevznikaly vysoké latence atd,Myslíš jako tohle?
11.2.2016 16:37
Petr Tomášek | skóre: 39
| blog: Vejšplechty
11.2.2016 19:15
Grunt | skóre: 23
| blog: Expresivní zabručení
| Lanžhot
11.2.2016 19:13
Grunt | skóre: 23
| blog: Expresivní zabručení
| Lanžhot
Doporučuju např. Wayland vyzkoušet v nějakém virtuálu bez hostitelských addonů. Mě to nefuguje ani s těma addonama.
11.2.2016 16:37
Petr Tomášek | skóre: 39
| blog: Vejšplechty
Já zase nechápu, proč tlačit veškeré vykreslování skrze jedno obrovské monstrum a jedno API, které určitě nebude vyhovovat vždy a všude. Když ne teď, za pár let může.
Tak se udělá nové rozšíření a je po ptákách. Stejně 95% aplikací žádné složité vykreslování nepotřebuje (a koho zajímají nějaké debilní hry)...
Kromě toho se dnes často používá direct rendering, který Xka obchází skoro úplně.
A přesně to je špatně!
Client-side buffery a jejich sdílení Waylandím stylem Xka s DRI3 používají taky a ten rozdíl je znát jednak objektivně (https://www.phoronix.com/scan.php?page=article&item=radeon-dri3-perf&num=1) a dále i subjektivně. Po zapnutí DRI3 mám konečně po deseti letech akcelerovaný desktop bez tearingu a plynulé animace bez podivných cukanců a zaškobrtnutí (KWin, Plasma 5.5, Intel HD3000). Skoro mi to vyvrátilo představu, že Xka jsou nezachranitelný krám.
No ale ten tearing je právě důsledek toho, když se kopírují zbytečně pixmapy místo toho, aby to server vykresloval sám...
Rozšíření, která jsou vyžadována pro běh aplikací je cesta do pekel, X11 to myslím předvedlo docela dobře. S podobným přístupem můžete za pár let na cokoliv jako zpětnou kompatibilitu zapomenout. Argument, že hry (a vůbec jakékoliv aplikace vyžadující vysokovýkonné 3D vykreslování) nikoho nezajímají je fakt blábol non plus ultra, namátkou zmiňme třeba SteamOS. Offloadovat maximum zátěže na grafický procesor, aby se mohlo CPU věnovat něčemu jinému je užitečné ve všech netriviálních případech.Já zase nechápu, proč tlačit veškeré vykreslování skrze jedno obrovské monstrum a jedno API, které určitě nebude vyhovovat vždy a všude. Když ne teď, za pár let může.Tak se udělá nové rozšíření a je po ptákách. Stejně 95% aplikací žádné složité vykreslování nepotřebuje (a koho zajímají nějaké debilní hry)...
Pokud vidíte možnost plně využít potenciálu hardwarové akcerelace jako něco špatného, nevím, co na to říci...Kromě toho se dnes často používá direct rendering, který Xka obchází skoro úplně.A přesně to je špatně!
S direct renderingem je prostě potřeba dobrý synchronizační mechanismus, který v DRI2 nebyl. Wayland tohle má "by design".Client-side buffery a jejich sdílení Waylandím stylem Xka s DRI3 používají taky a ten rozdíl je znát jednak objektivně (https://www.phoronix.com/scan.php?page=article&item=radeon-dri3-perf&num=1) a dále i subjektivně. Po zapnutí DRI3 mám konečně po deseti letech akcelerovaný desktop bez tearingu a plynulé animace bez podivných cukanců a zaškobrtnutí (KWin, Plasma 5.5, Intel HD3000). Skoro mi to vyvrátilo představu, že Xka jsou nezachranitelný krám.No ale ten tearing je právě důsledek toho, když se kopírují zbytečně pixmapy místo toho, aby to server vykresloval sám...
11.2.2016 19:50
Petr Tomášek | skóre: 39
| blog: Vejšplechty
Jejda, to je blábol. Na hardwarové akceleraci samozřejmě nic špatného není. Špatné je, že by měla aplikace přímo šahat na GPU...Pokud vidíte možnost plně využít potenciálu hardwarové akcerelace jako něco špatného, nevím, co na to říci...Kromě toho se dnes často používá direct rendering, který Xka obchází skoro úplně.A přesně to je špatně!
11.2.2016 19:53
Grunt | skóre: 23
| blog: Expresivní zabručení
| Lanžhot
13.2.2016 18:27
Petr Tomášek | skóre: 39
| blog: Vejšplechty
Hardwarová akcelerace síťově transparentní být nemůže z principuPán chce být vtipný?
14.2.2016 18:55
little.owl | skóre: 22
| blog: Messy_Nest
| Brighton/Praha
skutečně funkční HW akceleraci jaksi esenciální.Coz neni uplne pravda, viz treba VirtualGL.
Podlé té, kterou zde předpokládá Petr Tomášek.Aha. Tak to bych vůbec neřešil.
VirtualGL, Wayland over Wire a (pravděpodobně) i Citrix HDX posílají klientovi rovnou výsledek, který je předchroupán na serveru.Já nemám nic ani proti renderování na klientovi, pokud je k dispozici a dává lepší výsledky. Fonty klienta a podobné věci v podporovaném formátu by teoreticky šly odeslat na server, nebo se na ně dá kašlat. Ale samozřejmě musíš pak mít na serveru celý ten stack. Ale co jsem se bavil s lidmi, tak je v dnešní době asi fakt schůdnější posílat bitmapy a můžeme být rádi, když funguje aspoň to.
Třeba (mimo jiné) je na tom špatně, že to není síťově transparentní.Mně to přijde naopak dobře.
Stejně 95% aplikací žádné složité vykreslování nepotřebujeAno, až na takové aplikace jako třeba prohlížeč, že, to stejně nikdo nepoužívá. Další věcí jsou přehrávače videa.
Tak se udělá nové rozšíření a je po ptákách.Jo, a to rozšíření začne používat většina aplikací, protože pro multiplatformní framework typu Qt nebo GTK dává mnohem větší smysl vykreslovat si sám nebo používat hardware. A byl bys přesně tam, kde je teď X11. To, že Wayland nemá ssh -X a podobně není vina Waylandu nebo jeho "zlých" tvůrců, ale je to důsledek toho, jak dnes GUI aplikace fungují. Wayland jim pouze vychází vstříc.
Nebo pro zobrazovadla neplatí argumenty UNIXové čistoty používané proti systemd?Když neplatí pro systemd, neplatí přece ani pro wayland, to je snad logické.
11.2.2016 10:35
Petr Tomášek | skóre: 39
| blog: Vejšplechty
11.2.2016 19:20
Grunt | skóre: 23
| blog: Expresivní zabručení
| Lanžhot
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.
11.2.2016 13:46
