Úton van a Wayland a NetBSD-sekhez is

NetBSD

Részletek itt.

( kikadff v | 2020. 09. 30., sze – 07:28 )

Inkább úton volt, eljutott vele egy állapotig a blogot író dev, ki lehet próbálni, de felemás még. Tele van linuxizmussal, ami miatt nem egyszerű portolni, FreeBSD-vel ellentétben meg nem cél komplett linux-os cuccokat a NetBSD-be húzni. A már kész NetBSD patch-eket sem fogadták még be a wl-be, úgyhogy szerintem nem lesz a közeljövőben teljes wayland náluk. 

( khiraly | 2020. 09. 30., sze – 08:53 )

Anno a Mir-t hogy fikaztak, hogy minek fejleszteni a wayland mellett, ami mar *mindjart* kesz.

Az ubuntu touchot mikor kezdtek 2011? Talan 2013-volt az elso dev release.

 

Itt vagyunk 7-9 evvel utana es a wayland meg mindig egy felkesz bughalom.

 

Ezt valamelyik waylandes hirhez be kellett irnom.:-(

Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

Ha nem titok, ezt kifejtenéd kicsit bővebben?

Párszor nekifutottam én is már tesztelés jelleggel, nekem a megszokás volt a visszatartó erő. Pl egyszerűen annyira megszoktam már az X egérkezelését, hogy képtelen voltam tartósan használni. Hallottam persze olyanról, hogy össze lehet kalapálni hasonló megoldást, de a kényelem nagy úr :)

Esetemben a dolog elég egyszerű. Fedorát használok, ami pár éve már GNOME alatt Waylandot használ alapértelmezetten. Kb. egy éve váltottam nVidia videókártyáról Radeonra, és mivel az utóbbira van jó minőségű open-source driver (mekkorát fordult a világ) ezért azóta a Waylandot használom. Egyszerűen csak újratelepítettem a Fedorát és ezzel mostmár a Waylandot használom. Én semmi különbséget nem észlelek, sőt szerintem a Fedora/GNOME kombó már jobban megy Waylandon mint X-en, szubjektív megfigyelés alapján.

:wq

én FreeBSD-n és Arch-on tolom sway/wayland-en és hibátlan a cucc, semmilyen bugot nem tapasztaltam az elmúlt egy évben, a wayland-es firefox pedig fantasztikus 60Hz-es smooth scrollt tud, olyan mint MacOS-en, nagyon kellett már valami az X11 helyett. az egeret/touchpad-et úgy konfigolod ahogy akarod, az egyetlen fájó dolog hogy a libinput nem tud driver szintű momentum scrollt, de hát az open source desktop világ a kompromisszumokról szól.

( kris | 2020. 09. 30., sze – 14:12 )

Már alig várom, hogy kipróbálhassam a CTWM-et rajta ?

( SzBlackY | 2020. 10. 01., cs – 10:37 )

Akik fikázzák a Waylandet, hogy csúnya gonosz Binugz-specifikus izé, azok legalább tudják, hogy egy protokollról beszélnek, aminek van egy raklap implementációja? A referencia Westontól kezdve a cikkben idézett swc-n át a DE-specifikus kompozitorokig minden...

BlackY

"Gyakran hasznos ugyanis, ha számlálni tudjuk, hányszor futott le már egy végtelenciklus." (haroldking)

Persze-persze.
A macos alatt levo haromujjas touchpad gesture-ok mennek?:)

 

De meg az X alatti egerkezelest se sikerult hozni (automatic palm rejection, ket ujjas gorgetes, finomhangolas(!), stb, stb).

 

Es mostmar 2020 van, mostmar erintoceruzaval akarok bohockodni linux alatt...:)

Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

Azért a follow-up cikket is linkelhetted volna, amiben helyreigazítja jó néhány pontját :)

És igen, lehet, hogy a Weston trágya, de legalább protokoll-szinten nincs elbaszva, mint az X11 (oks, "nem szar az, csak másra lesz jó", a több évtizeddel ezelőtti állapothoz tényleg jó volt az X11 is).

Egyébként meg ja, a Wayland kifforatlan és vannak vitás pontok a protokoll körül (ill. egyéb alapvető kérdések), de azért ne csináljunk már úgy, mintha az X11 (és az összes protocol extension) teljesen jó lenne és távolról emlékeztet a kiindulási X11-re (gyakorlatilag kernel support nélkül nem kapsz értelmes teljesítményt, a protokoll nagy részét adó grafikus primitíveket senki nem használja, helyette framebuffereket küldözgetnek, ...). [gyakorlatilag képzeld ide azt a rant-et, amit az elavult-e a Linux topicban az RDP-hez tettem, az X11 ugyanaz pepitában, a folyamatosan változó környezethez és igényekhez ad-hoc szabott kiterjesztésekkel bloatolt izé :)]

BlackY

"Gyakran hasznos ugyanis, ha számlálni tudjuk, hányszor futott le már egy végtelenciklus." (haroldking)

> Azért a follow-up cikket is linkelhetted volna, amiben helyreigazítja jó néhány pontját :) Minek, amikor ott van a blogposzt első sorában a link? > És igen, lehet, hogy a Weston trágya, de legalább protokoll-szinten nincs elbaszva, mint az X11 (oks, "nem szar az, csak másra lesz jó", a több évtizeddel ezelőtti állapothoz tényleg jó volt az X11 is). > Egyébként meg ja, a Wayland kifforatlan és vannak vitás pontok a protokoll körül (ill. egyéb alapvető kérdések), de azért ne csináljunk már úgy, mintha az X11 (és az összes protocol extension) teljesen jó lenne és távolról emlékeztet a kiindulási X11-re (gyakorlatilag kernel support nélkül nem kapsz értelmes teljesítményt, a protokoll nagy részét adó grafikus primitíveket senki nem használja, helyette framebuffereket küldözgetnek, ...). [gyakorlatilag képzeld ide azt a rant-et, amit az elavult-e a Linux topicban az RDP-hez tettem, az X11 ugyanaz pepitában, a folyamatosan változó környezethez és igényekhez ad-hoc szabott kiterjesztésekkel bloatolt izé :)] Nekem nem kell bemutatnod az X11-et, programoztam eleget (kísérletezésképpen anno elkezdtem írni rá egy saját GUI toolkitet is), nem vitatom, hogy ezer sebből vérzik. Viszont X11-ből csak egy van, míg Wayland implementációból számos és ezek csak parciálisan kompatibilisek egymással. Ha írnék egy Wayland protokollt támogató libet, vagy programot, akkor melyik implementációt válasszam? A Claylandet? Támogatja/szállítja azt valaki? Az swc-t? Az van bármire Linuxon kívül? Mégis a Westont? Azért ez nem olyan egyszerű, hogy az X11 szar és monnyonle; amíg nincs egységes platform amire váltani lehet, addig öngyilkosság lenne.
Oldschool Computer - http://oscomp.hu
Nem most tárgyaltuk ki, hogy a Wayland - a protokoll - platformfüggetlen? Ez inkább a freedesktop-féle-fejetlenség: egyszerűen nincs mire lecserélni az X11-et, hiába van minden baja. Majd, ha a Wayland teljesen megérett és van egy defacto-standard WL implementáció, ami a Linuxon kívül támogatja a BSD-ket, Solarisokat, AIX-ot, HP-UX-et, meg a többi élő UNIX-ot is (ld. Clayland), akkor lesz értelme.
Oldschool Computer - http://oscomp.hu

Nekem az a tippem hogy a Solaris, AIX, HPUX, és a többi élő Unixra nincs mérhető desktop igény, így gyakorlatilag mindenkinek hótmindegy, hogy x11 van-e rajta vagy valamilyen wayland implementáció.

Én azt mondom hogy ez a wayland buli minimum 5 éve "mindjárt ott tartunk" van, és azóta sem jutottunk el odáig, hogy az legyen a standard. Egy időben észrevettem hogy a GDM Wayland-del indul, a cred beírás utáni Enter meg kilövi és indul az x11, mert még a Gnome / gpu driver / appok / franctudjaki nem támogatja.

A freedesktop meg úgy tűnik gyenge szervezetileg ahhoz hogy ezt megfelelő súllyal végigvigye, így marad a véletlenszerű (lassú) haladás.

> Nekem az a tippem hogy a Solaris, AIX, HPUX, és a többi élő Unixra nincs mérhető desktop igény, így gyakorlatilag mindenkinek hótmindegy, hogy x11 van-e rajta vagy valamilyen wayland implementáció. Fatális tévedés. Az, hogy mi mérhető, meg mi nem, az egy dolog, de nem egy helyen használják őket, tehát nem mindegy. Ha viszont a GUI toolkitek átállnak a WL-re úgy, hogy nincs WL rájuk, akkor ezek a rendszerek gyakorlatilag elvesztik az egész desktop szoftverparkjukat, max. a régebbi verziók maradnak. (Mondjuk amerre fejlődnek a szoftverek, ez még előny is lehet, de ebbe ne menjünk bele.) > Én azt mondom hogy ez a wayland buli minimum 5 éve "mindjárt ott tartunk" van, és azóta sem jutottunk el odáig, hogy az legyen a standard. Talán azért, mert még nem ért arra a szintre, hogy az X11 helyett lehessen standard. > A freedesktop meg úgy tűnik gyenge szervezetileg ahhoz hogy ezt megfelelő súllyal végigvigye, így marad a véletlenszerű (lassú) haladás. Ez viszont baromi érdekes... A systemd-t, a pulse-t, a pkg-configot és még ki tudja hány szemetüket sikeresen letolták a UNIX/Linux világ torkán; pont azt nem sikerül erőltetni, aminek - megfelelő kivitelezés és hordozhatóság mellett - még értelme is lenne?
Oldschool Computer - http://oscomp.hu
Egyrészt, mert ez így egy baromi erőforrásigényes middleware lenne, ami akár a használhatatlanságig is lassíthatja a rendszert. (Keress csak rá, hogy az XWayland, vagy a wikicikkben említett XQuartz mennyire "gyorsak" és mennyi CPU-időt hagynak meg a rendszernek.) A másik probléma: ha van valami olyan WL feature, ami wrappelhetetlen X11-re, nem megoldható a dolog, akkor mi lesz? Kibővíted az X11-et? Legyen még spagettibb? (Meg ennyi erővel minek a Wayland, ha az X11-be tákoljuk bele az új feature-öket?)
Oldschool Computer - http://oscomp.hu

Nem másztam bele nagyon a témába, de tudtommal a compositingre épít az egész. Mióta van hardveresen gyorsított compositing X.orgban? 10+ éve biztosan. A másik irány (XWayland, XQuartz) sokkal bonyolultabbnak tűnik.

A másik probléma: ha van valami olyan WL feature, ami wrappelhetetlen X11-re, nem megoldható a dolog, akkor mi lesz? Kibővíted az X11-et? Legyen még spagettibb? (Meg ennyi erővel minek a Wayland, ha az X11-be tákoljuk bele az új feature-öket?)

Tudsz ilyen feature-ről? Tudtommal a Wayland compositor egyben ablakkezelőként is funkcionál, nyilván emiatt a window managerhez is beszélnie kell, de ennek is megvannak a standard megoldásai.

Szerk.: egyébként a Weston fut X felett is, tehát a kérdést rövidre zárhatjuk.

Weston has several backends as loadable modules: it can run on Linux KMS (kernel modesetting via DRM), as an X client, or inside another Wayland server instance.

>Tudsz ilyen feature-ről?

Van jópár X fícsör, amit kihagytak a Wayland protokollból, akár valami (vélt vagy valós) security probléma, akár csak valaki elborult autizmusa miatt. Pl. teljes értékű Wayland natív Wine nem lesz sosem, mert hiányzik valami a Wayland protokollból, ami kellene az ablakkezeléshez. (Hogy az XWaylandon keresztül hogyan működik mégis azt ne kérdezd, addig nem másztam már bele).

- Az X11 nem támogat per-screen skálázást, a beállított DPI globális, szoftveresen kell átskálázni a képernyőket. - Az X11 nem támogat 255 feletti keycode-okat. - Konkrét cikket nem találtam, csak fórumposztokat, ahol azt írják az X11 nem támogat triple buffert.
Oldschool Computer - http://oscomp.hu
> Nem másztam bele nagyon a témába, de tudtommal a compositingre épít az egész. Mióta van hardveresen gyorsított compositing X.orgban? 10+ éve biztosan. És? Szerinted ez ennyi, hogy ez is compositing, meg az is? Ilyen egyszerű és kész? Hát nem. A Wayland az "local" render, az X11 meg kliens-szerver alapú, lévén anno arra lett kitalálva, hogy a szervergépen fut az X11 szerver és a terminálokon az X11 kliensek, ennek megfelelően teljesen más a compositing flow a kettőben: X11, WL Ezek miatt a - local / kliens-szerver felállás miatti - különbségekből egy csomó működésbeli eltérés adódik. A Wayland, mivel local renderer, ad egy buffert és azt csinálsz vele, amit akarsz. Az X11 viszont kliens-szerver kommunikációt csinál, ami akár gépek között is mehet, ennek megfelelően a tervezésénél a kliens-szerver kommunikáció minimalizálása volt a fő szempont és ennek megfelelően neki pl. van drawing API-ja, mert nagyon nem volt mindegy, hogy a módosított terület minden egyes bitjét átküldöd egy négyzet kirakásához (sok kB), vagy csak egy sima XFillRectangle tokent, meg az argumentumokat. A Waylandban viszont ilyen nincsen, mert egyszerűen nincs rá szükség, minden rajzolás így is helyben történik meg, tehát a drawing API-val nem rövidítenéd le a kirajzolás idejét. Vagy másik példa: az X11 képes síkokban (bitplane) kezelni a bitmap-eket, ugyanis nem volt ritka, hogy az egyik terminál csak monokróm, a másik 16, a harmadik meg 256 színű, így az egyiknek elég volt csak egy bitet átküldeni, a másiknak meg négyet, csak a harmadiknak kellett mind a nyolcat. Ez nem csak a kommunikáció csökkentése miatt volt, hanem azért is, mert a terminálok túl gyengék voltak a szerverhez képest, hogy ők kvantizáljanak. Na, Waylandon erre sincs szükség, mert neki egy local framebuffere van, ami a videókártyának megy, közvetlenül. Mind a két rendszert úgy tervezték meg, hogy minél gyorsabb legyen, csak éppen két - egymástól negyed évszázadnyi távolságra lévő és - teljesen eltérő korban, ahol a "gyorshoz" más volt a követelmény, mert más volt a rendszer kiépítése és ennek megfelelően, ha az egyikből a másikba wrappelsz, az minden lesz, csak gyors nem. Nem véletlen, hogy az XWayland lassú és erőforrászabáló. Ez nem a Wayland hibája, hanem az emuláció eredménye. > A másik irány (XWayland, XQuartz) sokkal bonyolultabbnak tűnik. http://wayland.freedesktop.org/docs/html/ch05.html
X11 and Wayland are different enough that there is no "simple" way to translate between them.
Nekik mondd. > Tudsz ilyen feature-ről? És ha én nem tudok, akkor nincs is? > Tudtommal a Wayland compositor egyben ablakkezelőként is funkcionál, nyilván emiatt a window managerhez is beszélnie kell, de ennek is megvannak a standard megoldásai. 10 WM 11 féleképpen működik, ugyanis az X11-hez többféleképpen is beszélhetsz. > Szerk.: egyébként a Weston fut X felett is, tehát a kérdést rövidre zárhatjuk. Skippelted a válaszom első felét:
Egyrészt, mert ez így egy baromi erőforrásigényes middleware lenne, ami akár a használhatatlanságig is lassíthatja a rendszert. (Keress csak rá, hogy az XWayland, vagy a wikicikkben említett XQuartz mennyire "gyorsak" és mennyi CPU-időt hagynak meg a rendszernek.)
Szóval nem. Sem az X11 over WL, sem a WL over X11 nem megoldás hosszútávon. Nyilván, ha csak "épp kell" valami, akkor hasznos, ha van, de amúgy így nem lehet normálisan dolgozni, ha a grafikus alrendszer az emuláció miatt megzabálja a gépet. És egyébként konkrétan a Weston egy hulladék.
Oldschool Computer - http://oscomp.hu

Eleve feltételezem, hogy ha egy rendszerre nem elérhető natív Wayland compositor ~10 éven belül, az halott. Tehát csak a köztes időszakot kell átívelni valahogy, azoknak az alkalmazásoknak, amik már nem támogatnak X-et. Jelenleg a GUI toolkitek tipikusan támogatják mindkettőt, tehát még a probléma sem létezik. Innen kezdve ez nem egy hosszútávú megoldás, ahol a hatékonyság másodlagos kérdés. Az teljesen irreleváns, hogy pár évtizede miért volt jó az X, mert nem a korabeli hardveren akarsz majd Wayland alkalmazásokat futtatni.

Elég baj az, ha nincs egy egységes protokoll, ami WM és alkalmazás független. De még ha így is van, a Wayland réteg az X szerver felé csak egy kliens, vagyis ugyanazt kell csak tudnia mint bármilyen másik kliensnek.

> Eleve feltételezem, hogy ha egy rendszerre nem elérhető natív Wayland compositor ~10 éven belül, az halott. És mire alapozod ezt a feltételezést? Csak mert a Clayland elérhető szinte minden platformon. Mégsem vagyunk kint vele a vízből, ha a toolkitek nem támogatják. > Jelenleg a GUI toolkitek tipikusan támogatják mindkettőt, tehát még a probléma sem létezik. Nem, a GUI toolkitek egy része támogatja az X11-et és egy-vagy-több WL kompozitort. De pont az implementációk taglalt inkompatibilitásaiból eredően baromira nem mindegy, hogy melyiket, mert ha pont azt nem támogatják, ami elérhető a platformodra, akkor buktad a dolgot. A probléma nagyon is létezik. > Innen kezdve ez nem egy hosszútávú megoldás, ahol a hatékonyság másodlagos kérdés. Az teljesen irreleváns, hogy pár évtizede miért volt jó az X, mert nem a korabeli hardveren akarsz majd Wayland alkalmazásokat futtatni. Senki nem akart a korabeli gépeken Waylandot futtatni. Most vagy nem érted, hogy mit írtam, vagy szalmabábot csépelsz. > Elég baj az, ha nincs egy egységes protokoll, ami WM és alkalmazás független. De még ha így is van, a Wayland réteg az X szerver felé csak egy kliens, vagyis ugyanazt kell csak tudnia mint bármilyen másik kliensnek. De nem érted, hogy az XWayland-ra nem lehet bazírozni? Az emuláció okozta overhead csak az egyik fele, de van még egy-két baj vele. Az egyik, hogy nem kötelező eleme a WL kompozitornak, az egy külön réteg. A Clayland például egyáltalán nem tartalmazza, de az swc-ből is kidobták már két éve, azzal a felkiáltással, hogy az swc írója nem használ már X11 alkalmazásokat, csak többen kérték, hogy rakja vissza, így végül visszakerült, de amúgy is bajai voltak az swc XWayland rétegének, amiknek egy részét sosem fixálták (#14, #18), mert a "fix" az volt, hogy "Xwayland support has been removed." Komolyan erre akarunk bármit is alapozni? Szerinted mennyire lenne ez használható, ezzel a felállással? És ebből következik a másik is, az, hogy csak addig fogják tessék-lássék támogatni, ameddig igény van rá és miért van most még igény rá? Azért mert sok aktívan használt GUI toolkitnek még nincs Wayland backendje. Azonban a toolkitek is állnak át a WL-re. Ha eldobják az X11 backendet, akkor az XWaylandra sem lesz szükség többé. Legalábbis ott, ahol van támogatott WL implementáció. Ameddig azonban a GUI toolkitek által támogatott WL implementációkat szinte csak Linuxra csinálják meg, addig a többi platformon nem nagyon van ok az örömködésre. Egy kis lista ide: - A Weston "nem hivatalosan" (értsd: talán lefordul, nagyon talán fut) támogatja a BSD-ket, de mást nem. - Az swc-be most próbálják beemelni a NetBSD támogatást, amúgy Linux-only. - A Clayland elvileg mindenre van, csak őt nem támogatja senki és nincs benne XWayland réteg. - A Hikarinak a FreeBSD a fő platformja, de azon kívül csak Linuxra van. - Egynémelyik ablakkezelőnek van saját WL backendje (KWin, Mutter, Enlightenment), de ezek nem használhatóak standalone WL kompozitorként, tehát csak a KDE5/GNOME3/Enlightenment megy velük és ebből is a GNOME3 már Linux-only a systemd dependencia miatt. - A többit ahogy néztem, mind Linux only, de fixme.
Oldschool Computer - http://oscomp.hu

Ha írnék egy Wayland protokollt támogató libet, vagy programot, akkor melyik implementációt válasszam?

Egyiket sem, a protokollra fejlesztesz, nem az implementációra. A protokoll része, hogy kommunikálja az implementáció a kliens felé, hogy mit támogat. Neked azt kell eldönteni, hogy a protokoll milyen subsetjét követeled meg, amit célszerűen úgy választasz meg, hogy a lehető legtöbb implementációval kompatibilis legyen.

> Neked azt kell eldönteni, hogy a protokoll milyen subsetjét követeled meg, amit célszerűen úgy választasz meg, hogy a lehető legtöbb implementációval kompatibilis legyen. Az implementációk csak részben kompatibilisek egymással, sok szerencsét hozzá...
Oldschool Computer - http://oscomp.hu

Ha a protokollal nem kompatibilisek, az bug. Ha a protokollt jól beszélik, akkor adott feature mindegyik implementációval ugyanúgy kell, hogy működjön. Ha nem így van, akkor a protokoll a hibás, ami megint csak bug.

X11 implementációból is több van, ott ugyanez a kérdés miért nem merül fel?

> Ha a protokollal nem kompatibilisek, az bug. Ha a protokollt jól beszélik, akkor adott feature mindegyik implementációval ugyanúgy kell, hogy működjön. Hát ehhez képest nem teszik, az implementációk API-jai eltérnek, nem teljesen kompatibilisek. Namármost, hogy ez bugnak tekinthető-e, vagy sem, az egy dolog, de ha maga a cucc működik, csak nem kompatibilis a másik implementációval, akkor te a fejlesztőjének meg nem magyarázod, hogy ez egy bug, mert csak azt fogja hajtogatni, hogy dehát működik, nincs hiba. > Ha nem így van, akkor a protokoll a hibás, ami megint csak bug. Ha a protokoll a hibás, akkor az nem bug, hanem koncepciós hiba. Azt te szoftverből ki nem javítod. Akkor módosítani kell a protokollt és akkor lehet átírni az összes implementációt, amit viszont a fejlesztők/cégek nem biztos, hogy meg akarnak csinálni, mert pénzbe és időbe kerül. > X11 implementációból is több van, ott ugyanez a kérdés miért nem merül fel? Felmerül. Ha olyan X11 implementációd van, amiből hiányzik valami, ami a WM-ednek, GUI toolkitednek kell, akkor nem fog vele menni. Miből gondoltad, hogy nem merül fel?
Oldschool Computer - http://oscomp.hu