Xorg Vs Wayland: quali sono le differenze?
Vi sto che tempo fa ho postato una discussione dal nome "Perché il protocollo X11 è ormai sente il passare degli anni? E perché nonostante tutto ci ostiniamo ad utilizzarlo?" ho deciso di fare un aggiornamento visto che comunque di acqua sotto i ponti n'è passata parecchia e soprattutto nel giro di quest'anno e mezzo Wayland e lo standard Wlroots sono cresciuti tanto in funzionalità e compatibilità, tanto che al momento sto utilizzando l'ambiente grafico DWL, un porting di dwm per Wayland, in un modo stabile e comodo, con gestures 1:1 e tante altre cose che su Xorg mi sognavo sul fronte dell'efficienza, incluso l'addio definitivo a quel leggero sfarfallio caratteristico di questo di X11.Qui di seguito riporterò alcuni estratti che ho scritto in un paper di cui vi lascio il link: https://github.com/NF02/wayland-wlroot-dwl-guida/blob/main/wlroot-dwl-implementation.org
1 Introduzione
Visto che il paper citato parla più che altro di Wlroots e delle differenze principali tra X e wayland, perché non partire proprio da Wlroots, che si è distinto per essere uno degli appoggi sostanziali per la creazione di tantissimi compositor manager.1.1 Wlroots
Wlroots è un protocollo pensato per composite manager ”equivalenti dei WM per X11 ma più complessi” per Wayland protocols, esso consente di risolvere tutti quei problemi che il giovene protocollo grafico non è pensato; Tra cui la condivisione delle risorse:- Presentazione dello schermo tramite protocollo WebRTC;
- Gestione dei DRM/KMS tra qui quelli per il render GPU;
- Gestione delle Periferiche di I/O;
- Integrazione con le funzionalità e le sessioni di systemD;
- xkbcommon, gestire le descrizioni della tastiera ed elaborare gli eventi chiave.
- etc.
2 Xorg Vs Wayland
2.1 X11 (X window system)
Il protocollo e sistema per la gestione di finestre conosciuto con il nome di X Window System nasce nel lontano 1984, all’interno dell’athena project, organizzato dal MIT e il Digital Equipment Corporation, grazie anche ai denari di IBM che era interessato ad un sistema grafico GUI per UNIX che fosse funzionale per le esigenze dell’epoca, siamo negli anni 80 uno dei modelli più comuni è quello basato sui un calcolatore ad altissime prestazioni conosciuto come “mainframe” o in territorio nostrano come “cervellone” e una serie di terminali stupidi (dispositivi a bassa potenza che servivano solo come punti di accesso). Da questo deduciamo che esso fosse pensato per sistemi centralizzati, non sistemi indipendenti che svolgono anche la funzione di calcolo oltre che a quella di puro input/output. Ora, anche all’epoca fu criticato per diverse criticità, in primo luogo fa un numero criminoso di chiamate al sistema e anche lo scambio tra X e le finestre crea overhead di comunicazione, cosa che rendeva poco efficente il tutto, per di più nel tempo ha generato altre problematiche sviluppate con l’anzianità del protocollo tra cui il fatto che non si riesca a scrivere dei driver video degni di questo nome, il fatto che X vada a renderizzare solo gli elementi che al momento sono visualizzati nella schermata e quindi il render viene svolto passo passo, cosa che con i vecchi sistemi e l’hardware dell’epoca aveva senso, ma oggi è solo brutto e poco elegante. Adotta molte soluzioni che risultano poco funzionali al giorno d’oggi tra cui il fatto che non implementi direttamente tra cui la gestione delle periferiche che fanno un rigiro per diverse librerie e programmare un app per X non è particolarmente pratico, tanto che negli anni sono nati i toolkit, visto che le librerie non sono ben pensate sul fronte degli strumenti dati gli sviluppatori. Questo modello ovviamente ha dei pregi, tra cui il fatto che possa esser utilizzato per sua natura con il protocollo SSH per utilizzare direttamente le finestre su una macchina remota in modo sicuramente più pratico di VNC o TeamViewer, infatti, basterà aver installato un client X sulla propria macchina e sarà possibile disegnare le finestre partendo dalle coordinate che vengono inviate dall’host, ma oltre questo se vediamo all’effettivo tutti i pregi che al momento gli utenti trovano sono dovuti alla semplice vecchiaia del suddetto protocollo, cosa che con il passare del tempo si sta sempre più assottigliando con il suo successore Wayland. Altra cosa da non sottovalutare è il fatto che non ci siano stato più aggiornamenti concreti dal 2012 cosa che comunque non è affatto positiva, se poi si prende anche in considerazione il fatto che il lock screen sia solo un app a schermo intero gli esiti nel caso in cui il codice dello stesso non sia solidissimo sono sufficentemente risibili con tanto di macchina utilizzabile al 100% da chiunque.2.2 Wayland
Wayland nasce nel 2008, l’autore originale è Kristian Høgsberg che in precedenza lavorò anche al X Window System e che poi vedendo l’avanzamento dei tempi, scelse di progettare un sistema che fosse meno dispendioso dichiamate, infatti, già da un po’ di tempo girava l’idea che bypassando il server grafico le prestazioni fossero migliori (cosa dimostrata empiricamente), per questo motivo nasce il concetto di composite manager autonomo cioè che deve gestire eventuali comportamenti di periferiche di input/output oppore la trasparenza delle finestre, il loro posizionamento e l’interazione a più livelli, remdendo più istantaneo e meno verboso il tutto. Quindi funziona direttamente con un ottica client molto più minimale, nel frattempo viene adottato dal gruppo freedesktop che ad oggi continua a svilupparlo. Ora, non che questo modello sia privo di problemi, ma sicuramente vedendo il suo attuale sviluppo sta andando ad introdurre sempre nuove feature che stanno rendendo Linux sempre più piacevole a lato desktop e anche mobile, se davvero dobbiamo trovare il diffetto è che in se e per se Wayland scarica davvero tutto il barire sul composite manager offrendogli solo gli strumenti per accedere alle risorse, per questo motivo se il suddetto non è scritto in modo idoneo i problemi che si riscontrano sono difersi, che possono andare dal più stupido problema con alcune app al non riuscire proprio a far comunicare corretamente i propri dispositivi.2.2.1 XWayland e le soluzioni di retro compatibilità
Visto che comunque al momento l’utenza si trova in una fase di transizione sono nate soluzioni di comodo come per l’appunto XWayland, un micro server X ultra minimale che consente di far girare tutte quelle app non native che altrimenti non si potrebbero avviare, questa soluzione come qualunque emulazione potrebbe avere qualche piccolo problemino, anche se comunque ormai è abbastanza stabile, infatti, al giorno d’oggi non c’è più quella fatica nel utilizzare app pensate per X su Wayland.2.2.2 PipeWire e Portal
La vera svolta che ha consentito un utlizzo dei protocolli wayland alla massa è proprio il fatto che sia nato il progetto PipeWire un servizio o demone che gestisce a bassissima latenza e in modo lineare il suono facendo funzioni di consumer audio e anche proAudio, cosa che ha consentito di avere un miglioramento notevole nell'usabilità di Linux, oltrettutto lo stesso gestisce pure la condivisione delle periferiche video (webcam, fotocamere e schermi) con tanto di un modulo chiamato portal che si occupa di consentire con WebRTC la condivisione del proprio desktop in video conferenza o tremite chrome remote, cosa che ti porta a livello di tutti gli altri comuin mortali, infatti, prima lo user wayland faceva la figura del disadattato non potendo presentare il desktop e non potendo sfruttare correttamente quel boost di prestazioni che il nuovo window system gli offriva.2.3 tabella riassuntiva
| Caratteristica | X11 | Wayland |
| Autore | Project Athena | Kristian Høgsberg |
| Sviluppatori | X.Org Foundation | freedesktop.org |
| Modello | Clint/server | Gestione diretta delle risorse tramite un composite manager |
| Anno del primo rilascio | 1984 | 2008 |
| Ultimo update | 2012 | ancora in sviluppo attivo |
| implementazione di rifermento | TWM | Weston |
| Defetti | overhead di comunicazione | tutto deve venir implmentato dal composite manager o chi per lui |
Wayland sono una serie di protocolli pensati per poter costruire un compositor manager, quindi al contrario di x11 che ha nel proprio environment per essere funzionale:
- Window manager;
- Composite manager;
- gestore della tastiera;
- Gestore dei display;
- Window decorator;
- etc.
Su wayland troviamo solo:
- comopositor manager - server;
- applicazioni - client.
3 Video dedicato
4 Conclusioni
Wayland ha tante possibilità e potenzialità, per alcune cose non è totalmente pronto, ma comunque siamo a buon punto, già nello stato attuale è più che utilizzabile e per il 99% delle operazioni va perfettamente, le app native sono sempre di più e tutto è ormai ad uno stadio di sviluppo più che avanzato, tanto che GNOME, Red Hat e tanti altri stanno deprecando X dalle loro distro, da RHEL 10 non ci sarà più la sessione X11 e si andrà solo con wayland. Devo dire che nonostante in questo periodo sia strapieno di impegni tanto da non scrivere di mio pugno un po' da ormai 3 mesi questo è stato un buon passatempo, ho aiutato nei retroscena altri dello staff a scriver qualcosa e anche fatto la semplice moderazione accentando o rifiutando post, spero che comunque questa discussione sia di vostro intrattenimento e che qui sotto nasca una fiorente discussione visto che l'argomento riguarda tutti noi Linuxari e power user Linux. Grazie...
Fatto per Inforge.net 