
Megjelent a Wayland 1.24-es verziója, amely a nyílt forráskódú Wayland protokoll újabb fejlesztéseit és bővítéseit tartalmazza. A Wayland célja, hogy leváltsa a korosodó X11 ablakkezelő rendszert egy egyszerűbb, biztonságosabb és hatékonyabb alternatívával, és ezt a célt a mostani kiadás is tovább erősíti. A 1.24-es verzió főként a fejlesztők számára hoz új lehetőségeket, de ezek az újdonságok közvetve a végfelhasználók élményét is javítják – különösen azokban a modern grafikus környezetekben, amelyek már a Wayland protokollra épülnek.
A frissítés egyik legfontosabb újítása a wl_fixes nevű interfész bevezetése, amely lehetővé teszi a wl_registry objektum explicit megsemmisítését. Ez egy régóta hiányzó képesség volt, amely a memóriakezelést és az erőforrások felszabadítását is megbízhatóbbá teszi. Ezzel együtt új API-függvények is érkeztek, például a wl_proxy_get_interface() és a wl_resource_get_interface(), amelyek lehetőséget adnak arra, hogy lekérdezhessük egy adott objektumhoz tartozó interfész definícióját. Ezek különösen hasznosak lehetnek fejlett alkalmazások és hibakeresési eszközök fejlesztése során.
Fontos előrelépés történt a billentyűismétlés kezelésében is. A wl_keyboard.key új „repeated” állapota lehetővé teszi, hogy a kompozitor – vagyis a grafikus rendszer központi egysége – saját maga szabályozza a gombismétlést. Ez különösen akkor jelent előnyt, ha valaki távoli asztali megoldást használ, mivel ezeknél eddig gyakran előfordult, hogy a kliens és a szerver közötti ismétlés nem volt megfelelően szinkronizálva.
A fejlesztők munkáját olyan új lehetőségek is segítik, mint a wl_display_dispatch_timeout() és a wl_display_dispatch_queue_timeout() függvények, amelyekkel eseménykezelési időtúllépéseket (timeout) lehet beállítani. Ezáltal megbízhatóbbá válik a protokollal kommunikáló alkalmazások működése, különösen lassabb vagy akadozó rendszerek esetén.
A memóriakezelést érintő fejlesztések közé tartozik a wl_shm_buffer_ref() és wl_shm_buffer_unref() bevezetése is. Ezek akkor is hozzáférést biztosítanak a megosztott memória (shm) pufferéhez, ha maga a protokollobjektum már megsemmisült. Ez például akkor hasznos, ha egy kliens hirtelen bezárul, de a grafikus rendszernek még szüksége van az ott tárolt képi adatokra.
A hibakezelés is átalakult: a wl_resource_post_error_vargs() egy új lehetőséget kínál a fejlesztőknek, amely va_list típusú paraméterlistákkal is tud dolgozni. Ez rugalmasabb és hatékonyabb hibaüzenetkezelést tesz lehetővé, különösen változó paraméterszámú hibák esetén.
Természetesen a verzióhoz hozzátartoznak a szokásos hibajavítások és a protokoll leírásainak finomítása is, amelyek célja a meglévő funkciók pontosítása és az eltérő implementációk közötti kompatibilitás javítása.
A Wayland 1.24 forráskódja már elérhető a hivatalos projektoldalon, ám a legtöbb Linux disztribúció – mint például a Fedora, Arch Linux, Debian Sid vagy Ubuntu – néhány héten belül automatikusan elérhetővé teszi az új verziót saját csomagtáraiban. A felhasználóknak tehát általában nincs szükségük arra, hogy manuálisan fordítsák le a protokollt, különösen mivel sokszor a rendszerük már így is Wayland-et használ, akár észrevétlenül is.
A 1.24-es verzió tehát nem látványos felhasználói funkciókkal érkezett, hanem inkább a háttérben dolgozó alapokat erősíti meg, megbízhatóbbá és modernebbé téve a Linux grafikus infrastruktúráját. Mindez fontos lépés a jövő felé, ahol a Wayland egyre több asztali környezetben válhat elsődleges megoldássá.
Letöltés
Mi az a Wayland? – Az X11 utódja egyszerűbb és korszerűbb alapokon
A Wayland egy modern protokoll és architektúra, amely a régi X11 ablakkezelő rendszer helyettesítésére jött létre. Fő célja, hogy könnyebben fejleszthető, bővíthető és karbantartható legyen, mint elődje, az X11, amely már több évtizede működik, de mára elavulttá vált sok szempontból.
A Wayland mint kommunikációs nyelv
A Wayland egy protokoll, vagyis egyfajta „nyelv”, amelyet a grafikus alkalmazások használnak arra, hogy kommunikáljanak a megjelenítő szerverrel. Ez a kommunikáció lehetővé teszi számukra, hogy:
- megjelenítsék magukat a képernyőn, és
- bevitelt fogadjanak a felhasználótól (például egér vagy billentyűzet használatával).
Ebben a rendszerben a megjelenítő szervert „kompozitornak” (compositor) nevezik, míg az egyes alkalmazások Wayland kliensek.
Nem csak protokoll, hanem teljes architektúra
A Wayland nem csupán egy kliens-szerver protokoll. Egyben egy rendszerarchitektúra is, amely új módon szervezi a grafikus környezetek működését. Ellentétben az X11-gyel, ahol egyetlen közös kiszolgáló (például az Xorg) felel minden grafikus műveletért, a Wayland világában minden grafikus környezet saját kompozitort hoz – ezek az implementációk eltérhetnek egymástól.
Ez azt is jelenti, hogy az ablakkezelés és a felhasználói élmény szorosan kötődik az adott kompozitorhoz, és nem cserélhetők ki olyan könnyen különálló komponensekként, mint az X11 világában.
A libwayland szerepe
A Wayland működésének kulcsfontosságú eleme a libwayland nevű könyvtár. Ez egy folyamatok közötti kommunikációs (IPC) könyvtár, amely képes egy XML-ben definiált protokollt C nyelvű API-vá fordítani.
Fontos tudni, hogy a libwayland nem maga a Wayland, nem tartalmaz semmilyen konkrét működést vagy grafikus logikát. Csupán a Wayland üzenetek kódolásáért és dekódolásáért felelős. A konkrét megvalósításokat a különféle kompozitorok és alkalmazásfejlesztő keretrendszerek végzik (például GNOME – Mutter, KDE – KWin, Weston stb.).
Rugalmas felhasználhatóság
A Wayland használata nem korlátozódik egy konkrét rendszerre vagy eszközre. Egy Wayland kompozitor lehet:
- önálló megjelenítő szerver, amely közvetlenül a Linux kernel grafikus és bemeneti alrendszerein (modesetting, evdev) fut,
- vagy beágyazott (nested) kompozitor, amely maga is egy X11 vagy más Wayland kliensként működik.
Továbbá, a Wayland alkalmazáson belüli kommunikációra is használható, például egyes modern webböngészőkben (pl. a grafikus felület és megjelenítő motor között).
Wayland kritika
Bár a Wayland modern és előremutató megközelítést kínál a grafikus rendszerek működtetésére, számos kritika éri, különösen akkor, amikor azt próbálják egy az egyben az X11 utódjának tekinteni. A leggyakoribb kifogás az, hogy Wayland – bár technológiailag letisztultabb – még mindig nem nyújtja azt a funkcionalitást és rugalmasságot, amit az X11 hosszú évek alatt kínált.
Az egyik legsúlyosabb hiányossága, hogy nem biztosít egységes megoldást a távoli asztali elérésre, képernyőmegosztásra vagy képernyőfelvételre. Míg az X11 világában a képernyő tartalmához való hozzáférés közvetlen és szabványos volt (ez tette lehetővé a VNC, RDP, X forwarding és más technológiák egyszerű működését), addig Waylandben minden ilyen funkciót a kompozitor szabályoz. Mivel azonban többféle kompozitor létezik – például Mutter a GNOME-ban vagy KWin a KDE-ben – és ezek nem követnek közös szabványokat a képernyő tartalmának exportálására, ezért sok esetben külön fejlesztés vagy workaround szükséges ahhoz, hogy egy adott funkció működjön. Ez különösen problémás a videokonferenciák, távsegítség, képernyőfelvétel, oktatás vagy streaming során, ahol a képernyőmegosztás vagy videokimenet kezelése alapvető lenne.
Szintén gyakori panasz, hogy a Wayland nem támogatja univerzálisan az összes bemeneti eszközt vagy koncepciót, amit az X11 már évtizedek óta kezel. Ilyenek például a fejlett billentyűzetkiosztások, a speciális input eszközök (például digitalizáló táblák), a több egér vagy több billentyűzet kezelése, illetve a szabadon konfigurálható globális gyorsbillentyűk. Ezek némelyikét már implementálták egyes kompozitorokban, de nem egységes a megvalósítás, és gyakran nem is dokumentált vagy nyíltan elérhető az API. Ez a szoftverfejlesztők számára is kihívást jelent, mert nem írhatnak egyszerűen „Wayland-kompatibilis” alkalmazást – alkalmazkodniuk kell az egyes környezetek sajátosságaihoz.
A fejlesztők és rendszeradminisztrátorok körében gyakran visszatérő érv az is, hogy a Wayland nem ad lehetőséget az X11-nél megszokott debugolási és monitorozási eszközökre. A grafikus események naplózása, a rendszer szintű vizsgálat vagy hibaelhárítás sokkal nehezebb, mert a Wayland architektúrája eleve kizárja az ilyen típusú központi hozzáférést.
A végfelhasználók szempontjából a leginkább érezhető probléma, hogy a Wayland nem egységes rendszer, hanem inkább egy protokoll, amit minden környezet másként valósít meg. Ez azt jelenti, hogy ugyanaz az alkalmazás máshogy viselkedhet KDE alatt, mint GNOME alatt, ha mindkettő saját kompozitort használ. Az ablakkezelés, az alt-tab viselkedés, a képernyőfelbontás váltás, az érintőképernyő-támogatás vagy a többmonitoros beállítások kompozitorfüggők, tehát a felhasználói élmény nem garantáltan következetes.
Végül, bár a Wayland célja éppen az egyszerűsítés és a biztonság növelése, egyesek szerint a rendszer túl nagy hatalmat ad a kompozitoroknak, és ez a modularitás rovására megy. Az X11 világában sok komponens – mint például az ablakkezelő, háttérképkezelő vagy panelszoftver – cserélhető volt egymással, míg Wayland alatt ezek szorosan össze vannak építve a kompozitorral, ami megnehezíti a testreszabást vagy alternatív megoldások bevezetését.
