Nell’appuntamento della scorsa settimana abbiamo visto come funziona l’infrastruttura grafica attuale in un ambiente X11. Nell’articolo di oggi analizzeremo l’architettura di wayland.
Mentre nell’attuale architettura il compositor comunica con il server grafico in wayland il compositor è il vero e proprio server grafico. Il controllo del Kernel Mode Setting e degli eventi viene gestito direttamente dal compositor. Gli eventi in input sono spediti direttamente ai client e i client mandano il “damage event” direttamente al compositor.
La figura rappresenta cosa avviene nello scenario presentato nel precedente articolo, 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).
- Il kernel registra un evento e lo invia al compositor in maniera analoga a quanto avviene con X. Il fatto che la gestione degli eventi sia analoga a quella di X permette di riutilizzare tutti i driver di input del kernel senza doverli riscrivere.
- Il compositor analizza lo scenegraph per determinare la finestra bersaglio dell’evento. Lo scenegraph è una struttura dati che contiene al suo interno la rappresentazione ti tutto ciò che viene mostrato a schermo. In questo modo il compositor, conoscendo le possibili trasformazioni che sono state applicate, è in grado di selezionare la finestra giusta e trasformare le coordinate globali dello schermo in coordinate locali della finestra. L’unica limitazione al tipo di trasformazioni è ovviamente la capacità del compositor di calcolare la trasformazione inversa per gli eventi di input.
- Come nel caso di X, alla ricezione dell’evento il client aggiornerà l’interfaccia grafica. A differenza di X nel caso di wayland, il rendering avviene lato client, e al compositor viene mandata una richiesta che contiene soltanto la regione che è stata aggiornata.
- Il compositor raccoglie le varie “damage request” dai client e ricompone la scena. A questo punto attraverso una system call di tipo ioctl può schedulare un pageflip grazie al KMS.
Naturalmente la fase più delicata è il rendering lato client. La parte del rendering avviene con lo stesso meccanismo del “direct rendering” attualmente presente in X. Il direct rendering consiste nella condivisione tra server e client di un buffer di memoria. Attraverso l’utilizzo di librerie come OpenGL il client renderizza direttamente nel buffer condiviso. A questo punto il compositor può prendere il buffer e utilizzarlo come texture in fase di composizione del desktop.
Dopo la fase di inizializzazione, il client ha solo il compito di dire al compositor quale buffer utilizzare e quando e dove ha renderizzato il nuovo contenuto al suo interno.
In questo modo una applicazione ha 2 modi per aggiornare il contenuto della propria finestra.
- Renderizzare il contenuto in un nuovo buffer e comunicare al compositor di utilizzarlo al posto del vecchio. L’applicazione può allocare un nuovo buffer ogni volta che si renda necessario aggiornare la finestra o in alternativa mantenere due o più buffer su cui lavorare. La gestione dei buffer è quindi interamente sotto il controllo dell’applicazione.
- Renderizzare il nuovo contenuto nel buffer passato precedentemente al compositor. Nonostante sia possibile renderizzare direttamente all’interno del buffer condiviso con il compositor, si potrebbero avere situazioni di corsa critica. Una tipica situazione è quella in cui il ridisegno della finestra venga interrotto dal compositor che sta ridisegnando il desktop. Se l’applicazione dopo l’inizializzazione ma prima che abbia finito il repaint il compositor utilizzerà per la scena un frame bianco o incompleto causando l’effetto conosciuto come “flickering”. Il metodo tradizionale per evitare questo comportamento è quello di utilizzare un backbuffer per i nuovi contenuti che verrà poi copiato nel front buffer del compositor. Anche in questo caso il controllo è sempre lato client.
In entrambi i casi, l’applicazione deve comunicare al compositor quale zona della superficie contiene dati aggiornati. Quando l’applicazione renderizza direttamente nel buffer condiviso, il compositor deve essere avvisato della presenza di nuovi contenuti. Anche nel caso di scambio di buffer, il compositor non assume mai che qualcosa sia cambiato e necessita di una richiesta esplicita dell’applicazione prima di ridisegnare il desktop. Questa scelta è stata fatta considerando che spesso anche passando un nuovo buffer al compositor solo una piccola parte può essere diversa (Pensate ad un cursore che lampeggia o ad un menu a tendina).
Il secondo appuntamento finisce qui. Nella prossima puntata vedremo di fare il punto della situazione tenendo conto delle sfide che attendono questo giovane e promettente progetto.
Veniamo al dunque. Attualmente sulle ubuntu basate ancora su xorg sto notando questo: se è attiva la composizione del desktop, spesso e volentieri i video si rifiutano di farsi vedere lasciando un bel buco nero. Soluzione al problema, tenersi il desktop senza uno straccio di supporto dalla gpu (il che non implica solo la perdita di effetti discutibili ma proprio di una maggior pulizia dei colori sullo schermo, come passare da un dipinto visto dal vivo alla sua copia sbiadita su carta patinata).
Con Wayland si potrà finalmente avere l’uovo e la gallina o gli amanti dei cubi rotanti devono ancora andare avanti a script per disattivare al volo le cose ?
@D
Quel fatto non è necessariamente legato ad Xorg ma ai driver video. Comportamenti del genere non sono assolutamente presenti nel mio caso con X + driver intel e GMA 945. Anche la situazione con Nvidia (driver proprietarti) + X è buona da questo punto di vista. Per quanto riguarda ATI e i driver proprietari invece la faccenda è più delicata ma a quanto pare con la versione 10.10 dei driver fglrx le cose stiano migliorando. Per non avere assolutamente problemi del genere con schede ATI il consiglio è quello di utilizzare driver open che hanno il supporto a tutte le tecnologie necessarie per un esperienza soddisfacente, anche se le prestazioni in 3d non sono comparabili con quelle dei driver proprietari.
Se avrai la pazienza di aspettare una settimana ho in progetto un articolo finale in cui metterò le mie considerazioni riguardo al futuro. ;-)
“quello di utilizzare driver open”
Mi pare di aver utilizzato proprio i driver open perchè avevo attivato la composizione senza connettere il sistema alla rete ed era appena installato, quindi a meno che i driver proprietari “brutti-sporchi-e-cattivi” non fossero finiti nella iso ufficiale la cosa non me la so spiegare.
Certo che viene proprio da chiedersi quali sono le ragioni profonde di questi problemi su linux.
Solo colpa dei driver proprietari ? Non credo proprio…
@D
assolutamente no. Tanto che i driver nvidia proprietari hanno un supporto eccellente e funzionano bene. Alcuni driver proprietari non riescono (non possono, non hanno convenienza) a stare al passo con le diverse novità quindi nel caso specifico quelli open garantiscono una migliore esperienza globale. Poi tutto dipende anche dal tipo di hardware in considerazione. In pratica quello che voglio dire è che purtroppo non è facile dare la responsabilità di tutti i problemi ad una specifica componente (in quel caso sarebbe semplice capire dove
andare a incidere) ma spesso i problemi sono un “concorso di colpa”.
“a stare al passo con le diverse novità”
Il che è abbastanza grave ma a sto punto, alla luce di “oscenità” come tutto l’eccessivo proliferare di “sistemi” per l’audio (oss,alsa,pulse, più vari ed eventuali a livello dei vari DE) mi chiedo qual’è il ritmo di introduzione di “novità” all’interno del kernel e delle distribuzioni.
Cioè è sempre proprio necessaria questa corsa ? C’è una mancanza generale di lungimiranza verso il futuro che ogni tot anni si ritrovano che manca qualcosa e per implementarla devono smontare e rimontare tutto ogni volta (quindi fanno prima e reinventano la ruota da zero) o è sempre il solito discorso dei fork provocati ad hoc con l’intento di creare delle sacche di assistenza a pagamento ?
Cioè io credo che si sia esagerato e si sia superato il limite della decenza da un bel po’ di tempo. Troppe distribuzioni, troppe librerie che servono a fare gli stessi compiti, troppi framework che praticamente cercano di sovrapporsi in parte nel fare le stesse cose, finendo per fregarsi il terreno sotto le scarpe a vicenda: quando ce ne sono due o più installati, quasi sempre e succedono casini, o si incappa in qualcosa di particolarmente conosciuto e google ci imbocca la risposta o è peggio che una caccia al tesoro, a mettere insieme indizi perchè non si trova qualcuno con una mappa mentale chiara di come funzionano le cose neanche a pagarlo oro.
Teoricamente linux dovrebbe essere la pacchia dei piccoli installatori di pc perchè ci sarebbe sempre lavoro ed invece si finisce allo stesso modo degli avvocati che ad ogni minima modifica del codice devono ricomprarsi fior di costosissimi libri per rimanere sempre aggiornati ed alla fine si rompono perchè un po’ di scelta, anche un minimo di casino va bene ma non un bordello che si protrae per decenni.
@Emanuele
per forza non ti capita più quel problema con i video. Nel pc dei miei (munito di una bella distro, tanto per il loro uso molto saltuario….) c’è un GMA950 come hai tu (il 945 è il chipset, lo sai). Da quando il passaggio a DRI2+UXA fu ultimato ho solo scorto progressi non da poco. Prima Google Earth era impallato, ora gira come una trottola :o
Mi chiedo, Wayland usa Mesa ? (son abbastanza profano fuori dalla componentistica nuda e cruda) Perché vorrei vedere il Gallium3D pienamente a regime.
[D]
E’ veramente curioso che, anche con un articolo meramente tecnico e scritto veramente bene, trovi l’occasione di esibire sempre le medesime critiche ormai ritrite che dato il contesto sono anche decisamente OT.
E’ veramente curioso che quando qualcuno cerca di indagare dove stanno i problemi in modo di tentare di avviare un processo di risoluzione serio ed efficace, puntualmente spunta fuori il tizio inutile che fa di tutto per affossare il tutto.
Dì un po’ è solo un problema tuo o tieni degli interessi in proposito ? Fai assistenze in giro ? Realizzi una tua distribuzione (ovviamente il tutto in nome della libertà di espressione, non di legare a te eventuali utenze, sia mai eh… tutto il nome di San Stallman e fratel coniglietto) ?
E’ chiaro che se linux negli anni ha raccolto tante sconfitte sicuramente ci sono dei motivi alla base quindi chi non li vuole vedere o ha seri problemi di masochismo (dev’essere una gioia perdere intere giornate a volte pure settimane per sistemare ogni problemino, rivoltare google come un calzino, spesso e volentieri in altre lingue, nella speranza di incrociare qualcuno che ci sia già passato vero ? Meglio che farsi una vita fuori dalla stanzetta e pensare che gli sfigati di Big Bang Theory dovrebbero essere solo una macchietta del nerd…) o ha solo da guadagnarci.
Per favore non andiamo O.T. In questo posto si parla di wayland e non di presunti manovratori nel mondo del business delle assistenze (mondo che non è affatto legato solo al mondo open tra le altre cose).
Questo tipo di attacchi personali verso persone che nemmeno si conoscono è altamente sgradito quindi ti chiedo cortesemente di evitarlo in futuro.
@densou
Ho mischiato il chipset con la scheda video (a mia discolpa 945 e 950 sono numeri molto vicini :P). Infatti quello che dicevo a D è che i driver open che utilizzano le nuove infrastrutture (dri2 etc etc…) anche se con prestazioni in termini di velocità pura inferiori a quelli proprietari generalmente garantiscono una migliore esperienza d’uso.
Si. Basta abilitare i giusti switch in fase di compilazione di mesa (EGL e GLES2).
./configure –enable-egl –enable-gles2
sono completamente ignorante però, vorrei sapere come mai Wayland non può avere la network transparency, guardando lo schema non mi sembra impossibile, voglio dire che il server grafico può sempre girare nel computer client, come con X.
P.S. se ho detto delle castronerie scusatemi
temp 04-05-10
da http://lists.freedesktop.org/archives/wayland-devel/2010-November/000028.html
dove direct rendering = ogni applicazione, quando è il suo turno o in risposta a un evento esterno, renderizza la sua parte di schermo (come texture offscreen che poi il compositor rasterizzerà insieme ad altre in base al scene graph, quando verrà il suo) inviando comandi alla scheda grafica (quindi passando solo per i driver di questa e il kernel) e non a server intermedi che si occupino di inviarli essi stessi al kernel dopo averli ricevuti dalle applicazioni (come avveniva invece, in AIGLX)
per wayland il direct rendering, già possibile sotto X con adeguati WM e driver (ma che sotto X in sostanza bypassa parecchie funzioni dell’ X server), diviene parte del design – e il fatto di svolgere il rendering delle primitive 2d lato client (giacchè non abbiamo più bisogno di farlo fare al server) è per design spinto al cercare di delegare anche altre funzionalità (le window decoration, ma anche spostamento e ridimensionamento delle finestre) ai client (che quindi in effetti sarebbero responsabili non solo delle loro finestre, ma dell’ intero loro layer, comprensivo di tutto ciò che le circonda – e il server farebbe poco più che loopare sul redraw della pila di layer e redirigere l’ input)
ora, non sarebbe impossibile avere applicazioni client in remoto, ho letto qualche altra discussione a proposito giusto ieri, ma:
1) comunque si svilupperebbe un server ad hoc per il protocollo di comunicazione e remoting scelto, ma client del wayland display server che continuerebbe a occuparsi della gpu del sistema e delle surfaces su cui renderizzare
2) al momento non è una priorità