Wayland è un protocollo di comunicazione nato dalla volontà di fornire un sistema grafico moderno costruito sopra alle nuove tecnologie del kernel linux (Kernel Mode Setting e Direct Rendering Manager). Lo scopo prefissato dal suo ideatore Kristian Høgsberg è quello di creare un nuovo display server che implementasse soltanto la piccola parte delle tantissime feature del protocollo X11 che vengono realmente utilizzate nei moderni gestori di finestre che utilizzano un qualche sistema di compositing.
Il protocollo attualmente utilizzato da tutte le distribuzioni GNU/Linux è il vecchio X. La prima apparizione dell’ultima revisione del protocollo (X11) risale addirittura al 1987. Ovviamente negli anni il protocollo è stato aggiornato e modificato aggiungendo man mano nuove caratteristiche e migliorandone l’implementazione di riferimento. Se da una parte questo dimostra come le scelte di design iniziali siano state abbastanza lungimiranti da far sopravvivere il progetto così a lungo (in questo momento sto digitando in una finestra disegnata grazie al server X) dall’altra è innegabile che tutti gli anni che sono passati si facciano sentire.
Per capire le differenze tra i due protocolli e i motivi dello sviluppo di Wayland in questa serie di articoli mi occuperò di tradurre e dove possibile integrare l’esempio del sito ufficiale del progetto in cui si analizza il flusso di interazioni tra le varie componenti dall’occorrenza di un evento di un dispositivo di input (il classico click del mouse) a quando i cambiamenti che questo evento porta vengono rappresentati su schermo (per esempio il ridimensionamento di una finestra).
Nel nostro primo appuntamento vedremo cosa avviene attualmente nello scenario in cui si stia utilizzando X server ed un composite manager.
- Il kernel riceve un evento da un dispositivo di input e lo spedisce ad X attraverso il driver evdev. Il kernel compie tutto il lavoro necessario per gestire la periferica e tradurre la comunicazione specifica del dispositivo in nello standard per gli eventi evdev.
- Il server X determina quale finestra è interessata all’evento e spedisce l’evento ai client selezionati per lo specifico evento su quella determinata finestra. Il server X in realtà non sa come farlo in maniera corretta poiché la posizione della finestra sullo schermo è controllata dal compositor e potrebbe essere trasformata in un modo che il server non ha modo di conoscere (pensate alle finestre tremolanti di e ad i vari effetti grafici di compiz o kwin).
- Il client analizza l’evento e decide cosa fare. Spesso l’interfaccia utente deve riflettere dei cambiamenti in risposta ad un evento, di conseguenza il client manderà indietro una richiesta di rendering al server X.
- Quando il server riceve la richiesta, la spedisce al driver che si occupa di programmare l’hardware per il rendering. Il server calcola anche i confini della regione interessata dal rendering e la invia al compositor sotto forma di “damage event”
- Il “damage event” dice al compositor che qualcosa è cambiato nella finestra e quindi deve ricomporre la parte di schermo dove la finestra è visibile. Il compositor è il responsabile per il rendering dell’intero contenuto dello schermo in base al proprio scenegraph e al contenuto delle finestre. Ancora una volta bisogna ripassare attraverso l’X server per renderizzare la scena.
- Il server X riceve la richiesta di rendering dal compositor . A questo punto o copia il back buffer del compositor sul front buffer o fa un pageflip. Nel caso generale, il server X deve fare questo passaggio per poter considerare le finestre sovrapposte che potrebbero necessitare il clipping e determinare se può o non può fare il pageflip. Per un compositor che funziona a tutto schermo questo passaggio è non necessario.
Un approccio di questo tipo porta con se diversi problemi. Il server X non ha le informazioni per decidere quale finestra deve ricevere l’evento, e non può trasformare le coordinate dello schermo in coordinate locali della finestra. Inoltre, nonostante X abbia delegato la responsabilità di disegnare lo schermo al compositing manager, ancora controlla il frontbuffer e il mode setting.
La maggior parte della complessità che veniva in passato gestita dal server X è attualmente gestita all’interno del kernel o in altre librerie. Nella pratica, il server X è ormai un entità che non fa altro che inserire uno strato non necessario tra l’applicazione ed il compositor e tra il compositor e l’hardware.
La prossima settimana vedremo le scelte fatte nella progettazione di Wayland.
