mi pare abbastanza condivisibile che finché non si avrà un recovery automatico del compositor senza alcuna perdita di dati, non si potrà dire che Wayland è alla pari con Xorg
Errore comune e ignoranza di molti che criticano Wayland senza sapere il suo design. Non è compito di Wayland fare queste cose, Wayland è solo un protocollo, il compito per fare queste cose è del compositor e toolkit (client).
Kwin ha già il supporto per il riavvio della sessione in caso di crash:
https://invent.kde.org/plasma/kwin/-/merge_requests/483
Non è che Xorg era messo bene, eh:
(Incollo tutta quella parte che lo spiega e tradotto in Italiano con Google, nella speranza che questa volta venga letto)
Il prologo
In questo momento, se riavvii pulseaudio il tuo suono potrebbe essere tagliato, riavviare NetworkManager e perdere il wifi, riavviare un gestore di finestre X11 e le decorazioni scompaiono.
Ma in un secondo è tutto tornato alla normalità esattamente da dove hai lasciato tutto in fase di recupero.
Questo non è vero per i server di visualizzazione. Se X11 si riavvia si è di nuovo al prompt di accesso. Tutte le bozze hanno perso, partite non salvate, hanno sprecato il lavoro.
In passato
Per X11 questo era infissabile; i clienti si affidavano alla memoria archiviata dall'Xserver, facevano chiamate sincrone che dovevano restituire i valori e più clienti parlavano con i client multple.
Questo era un vero problema nei miei primi giorni di Linux, X11 si bloccava abbastanza frequentemente che la maggior parte delle distribuzioni aveva una chiave di scelta rapida per riavviare il server e inviarti al prompt di accesso.
È meno un problema ora come X11 è stato in un lungo periodo di congelamento delle funzionalità.
Il presente
Wayland permette di risolvere tutto questo. Le allocazioni di memoria sono lato client, tutte le operazioni sono async, tutti i protocolli sono progettati che il compositore ha sempre il controllo completo.
Tuttavia, l'attuale stato rivolto all'utente è notevolmente peggiore:
I compositori e i server di visualizzazione sono ora lo stesso processo, raddoppiando lo spazio per gli errori
I compositori sono in genere estensibili con plugin e script di terze parti
Il modello di sicurezza del traslocco significa che il compositor assorbe ancora più funzioni dalle scorciatoie globali al screencasting e alla gestione del metodo di input
L'ecosistema della terra non è in un periodo di congelamento delle funzionalità con i protocolli di wayland in continua evoluzione per coprire le caratteristiche mancanti e le nuove idee.
Anche se c'era un compositore perfetto:
Il 40% delle segnalazioni di bug di crash di kwin sono cause a monte o a valle
L'attuale esperienza di sviluppo compositor è limitata con gli sviluppatori che devono reinlogin e riavviare le loro app e la configurazione di sviluppo solo per testare le loro ultime modifiche.
Il piano
La soluzione per questo? Invece di uscire quando il compositore si chiude, semplicemente... non farlo!
Se potessimo collegarci a un nuovo compositor, dobbiamo solo inviare la giusta quantità di informazioni per portarle in sincronia e notificare il codice dell'applicazione di eventuali modifiche per portare questo in sincronia.
Per le applicazioni Qt tutte queste informazioni sono gestite nel backend, nel Wayland Qt Platform Abstraction (QPA).
Qt deve già gestire schermi e dispositivi di input rimossi, gli appunti vengono revocati e trascinati e cancellati. Supportare un intero reset non è introdurre alcun nuovo lavoro, dobbiamo solo attivare tutte queste azioni contemporaneamente, quindi riconnetterci al compositore appena ripristinato e ripristinare i nostri contenuti.
Le applicazioni devono già supportare tutti questi eventi e gestire i callback ai buffer ridisegnati. Non sono necessarie modifiche a un livello di codice dell'applicazione, tutto è fatto nel modo più trasparente possibile.
Gestire OpenGL è una sfida, in questo momento non abbiamo un modo per tenerlo in vita. Fortunatamente abbiamo fatto un sacco di sforzi in precedenza nel supporto dei reset della GPU in tutto lo stack Qt. Il backend QtWayland falsia le applicazioni che un reset GPU si è verificato attraverso le astrazioni Qt.
Per la maggior parte delle applicazioni, compresi tutti gli utenti QtQuick, ciò avviene automaticamente e perfettamente, basandosi sul lavoro che abbiamo fatto in precedenza.
Mentre i concetti complessivi potrebbero sembrare invasivi, la richiesta finale di fusione per supportare tutto questo per tutte le applicazioni Qt era inferiore rispetto al supporto della pasta con clic centrale.
Quasi nessun lavoro deve fare sul lato del compositore. Per un compositore non c'è differenza tra un nuovo client e un client che stava eseguendo in precedenza riconnessione. L'unico grande cambiamento che abbiamo fatto all'interno di Kwin è avere un processo di aiuto in modo che l'intero processo possa sembrare senza guida e senza razza.
Per chi vuole approfondire:
http://blog.davidedmundson.co.uk/blog/q ... obustness/
Se domani (per assurdo) si invertissero le % e tutti usassero Linux, allora forse ci sarebbe da temere un po' di più.
