Come è organizzata la pila grafica di Linux?


31

Qualcuno può spiegare (si spera con una foto), come è organizzata la pila grafica di Linux? Ho sempre sentito parlare di X / GTK / GNOME / KDE ecc., Ma non ho davvero idea di cosa facciano realmente e di come interagiscono tra loro e con altre parti dello stack. Come si inseriscono Unity e Wayland?


1
Video dello sviluppatore di Xorg Keith Packard sul futuro della grafica Linux su linux.conf.au nel gennaio 2011: linuxconfau.blip.tv/file/4693305 Questo riguarda sia il modello attuale sia i piani per il prossimo e medio futuro.
Mattdm,

arstechnica.com/open-source/guides/2011/03/… è anche un articolo recente che va oltre lo stack e che elogia l'impegno di Ubuntu a Wyland.
apoorv020,

- sì, sebbene l'articolo sia pieno di pezzi mancanti e persino inesattezze e, a mio giudizio, non è terribilmente coerente.
Mattdm,

@mattdm - Anche se è incoerente, ecc., entra nel quadro più ampio dell'argomento, che non viene trattato direttamente nelle risposte di seguito.
apoorv020,

Risposte:


29

Il sistema X Window utilizza un'architettura client-server. Il server X viene eseguito sulla macchina che ha il display (monitor + dispositivi di input), mentre i client X possono essere eseguiti su qualsiasi altra macchina e connettersi al server X utilizzando il protocollo X (non direttamente, ma piuttosto utilizzando una libreria, come Xlib, o il più moderno XCB guidato dagli eventi non bloccante). Il protocollo X è progettato per essere estensibile e ha molte estensioni (vedi xdpyinfo(1)).

Il server X esegue solo operazioni di basso livello, come la creazione e la distruzione di finestre, l'esecuzione di operazioni di disegno (al giorno d'oggi la maggior parte del disegno viene eseguita sul client e inviata come immagine al server), invio di eventi a Windows, ... Puoi vedere quanto poco esegue un server X eseguendo X :1 &(utilizzare qualsiasi numero non già utilizzato da un altro server X) o Xephyr :1 &(Xephyr esegue un server X incorporato sul server X corrente) e quindi eseguendo xterm -display :1 &e passando al nuovo server X (potrebbe essere necessario impostare l'autorizzazione X utilizzando xauth(1)).

Come puoi vedere, il server X fa ben poco, non disegna barre del titolo, non minimizza / iconizza le finestre, non gestisce il posizionamento delle finestre ... Naturalmente, puoi controllare il posizionamento delle finestre manualmente eseguendo un comando come xterm -geometry -0-0, ma di solito avrai un client X speciale che fa le cose sopra. Questo client si chiama window manager . Può esserci un solo gestore finestre attivo alla volta. Se avete ancora aperto il X Server Bare dei comandi precedenti, si può provare a eseguire un gestore di finestre su di esso, come twm, metacity, kwin, compiz, larswm, pawm, ...

Come abbiamo detto, X esegue solo operazioni di basso livello e non fornisce concetti di livello superiore come pulsanti, menu, barre degli strumenti, ... Questi sono forniti da librerie chiamate toolkit , ad esempio: Xaw, GTK, Qt, FLTK, ...

Gli ambienti desktop sono raccolte di programmi progettati per fornire un'esperienza utente unificata. Pertanto, gli ambienti desktop in genere forniscono pannelli, lanciatori di applicazioni, vassoi di sistema, pannelli di controllo, infrastruttura di configurazione (dove salvare le impostazioni). Alcuni ambienti desktop ben noti sono KDE (creato usando il toolkit Qt), Gnome (usando GTK), Enlightenment (usando le sue librerie toolkit), ...

Alcuni effetti desktop moderni sono ottimizzati utilizzando l'hardware 3d. Quindi appare un nuovo componente, il gestore composito . Un'estensione X, l'estensione XComposite, invia i contenuti della finestra al gestore composito. Il gestore composito converte tali contenuti in trame e utilizza l'hardware 3d tramite OpenGL per comporli in molti modi (fusione alfa, proiezioni 3d, ...).

Non molto tempo fa, il server X ha parlato direttamente con i dispositivi hardware. Una parte significativa di questa gestione dei dispositivi si è spostata nel kernel del sistema operativo: DRI (che consente l'accesso all'hardware 3d da parte di X e client di rendering diretto), evdev (interfaccia unificata per la gestione dei dispositivi di input), KMS (impostazione della modalità grafica in movimento nel kernel) , GEM / TTM (gestione della memoria delle trame).

Quindi, con la complessità della gestione dei dispositivi ora per lo più al di fuori di X, è diventato più facile sperimentare sistemi di finestre semplificati. Wayland è un sistema di finestre basato sul concetto di gestore composito, ovvero il sistema di finestre è il gestore composito. Wayland si avvale della gestione del dispositivo che si è spostato da X e esegue il rendering utilizzando OpenGL.

Per quanto riguarda Unity, è un ambiente desktop progettato per avere un'interfaccia utente adatta ai netbook.


Non sono d'accordo sull'ultima frase, ma una risposta molto ricca di informazioni. +1.
missingfaktor il

"(al giorno d'oggi la maggior parte dei disegni viene eseguita sul client e inviata come immagine al server)" Questo non è proprio vero, molti di loro eseguiranno il rendering con l'estensione xgl, anche senza un compositore.
Adam D. Ruppe,

13

Lo stack tradizionale è basato su 3 componenti principali:

  • X server che gestisce la visualizzazione
  • Il gestore di finestre che inserisce le finestre in cornici, gestisce le finestre minimizzando ecc. Fa parte della separazione del meccanismo dalla politica in Unix
  • Clienti che svolgono attività utili come visualizzazione di siti Web stackexchange. Possono usare direttamente il protocollo X (suicidio), usare xlib o xcb (leggermente più semplice) o usare toolkit come GTK + o QT.

L'architettura X è stata creata in rete, consentendo quindi ai client di trovarsi su un host separato e quindi su un server.

Fin qui tutto bene. Comunque quella era l'immagine di ritorno. Oggi non è la CPU a gestire la grafica ma la GPU. Ci sono stati vari tentativi di incorporarlo nel modello - e posizionarlo quando il kernel entra in vigore per estenderlo.

Innanzitutto sono state fatte alcune ipotesi sull'uso della scheda grafica. Ad esempio, è stato assunto solo il rendering su schermo. Non riesco a trovare queste informazioni su Wikipedia in questo momento, ma DRI 1 ha anche ipotizzato che una sola applicazione userà OpenGL contemporaneamente (non posso citare subito ma posso scavare il bug dove era vicino come WONTFIX con nota per aspettare DRI 2).

Sono state proposte alcune soluzioni temporanee per il rendering indiretto (necessario per WM composito):

  • XGL - proposta iniziale che supporta le applicazioni che parlano direttamente con la scheda
  • AIGLX - proposta accettata che utilizza le proprietà di rete del protocollo OpenGL
  • Soluzione proprietaria di NVidia

Sono stati avviati i lavori sull'architettura più recente (DRI 2). Questo includeva:

  • Supporto nel kernel per la gestione della memoria (GEM / TTM)
  • Kernel modi di impostazione (KMS) che consente di modificare la risoluzione nel kernel evitando quindi ritardi nel passaggio tra X e console e poche altre funzionalità (come la visualizzazione di messaggi in panico anche se X è in esecuzione - che IIRC è pianificato per essere implementato).

In qualche modo ortogonale per passare al kernel sono stati avviati i lavori sui driver di Gallio. La libreria Mesa è iniziata come implementazione di OpenGL su CPU e poi ha iniziato a utilizzare l'accelerazione GPU. È sempre stato stretto a OpenGL. In OpenGL 3.0 il modello è cambiato in modo significativo e la riscrittura della libreria era inevitabile. Tuttavia stanno cogliendo l'opportunità di dividere il codice in più livelli estraendo codice comune e fornendo API di basso livello che consentono di implementare varie API 3D su di esso - consentendo ad esempio Wine di fornire DirectX parlando direttamente con Gallio invece di passare attraverso OpenGL Livello API (che potrebbe non avere chiamate 1-1 dirette).


Wayland è un progetto che considera quanto sopra un po 'complicato e con troppa "storia". Il design del 1984 (sebbene fortemente modificato e adattato) non corrisponde all'inizio del 21 c. secondo i sostenitori.

Si suppone che offra maggiore flessibilità e migliori prestazioni anche se mancano ancora alcune funzionalità importanti come il supporto completo OpenGL (e importante per alcuni - il supporto di rete).


Un po 'di più su ambienti desktop e gestori di finestre. Il gestore di finestre è un'applicazione responsabile di come si comporterà la finestra, ad esempio è responsabile della gestione delle aree di lavoro, del disegno della barra del titolo (la cosa nella parte superiore dello schermo con titolo windo e pulsanti minimizza / massimizza / chiudi) ecc.

In primo luogo è stato utilizzato solo WM minimo, ma in seguito l'utente ha iniziato a desiderare ambienti desktop - ovvero versioni più funzionalità, che includevano l'avvio del menu, lo sfondo del desktop ecc. Tuttavia, la maggior parte delle parti dell'ambiente desktop non è un gestore di finestre sebbene siano spesso integrate.

Dopo qualche tempo sono stati introdotti i WM compositi che utilizzano OpenGL e il rendering indiretto per fare il loro lavoro. Forniscono non solo effetti grafici, ma consentono anche una più facile implementazione di alcune funzionalità di accessibilità (come la lente d'ingrandimento).


Quindi un framework come QT consente a un'applicazione di disegnarsi da sola, e ambienti desktop come Gnome e KDE decidono come disegnare più finestre sullo stesso desktop?
apoorv020,

Non proprio. QT consente all'applicazione di disegnare se stessa (ovvero consente all'applicazione di specificare come si comporta). WM come metacity (per Gnome) o kwin (per KDE) specifica come si comporta la finestra nell'ambiente. L'ambiente desktop è un pacchetto che contiene WM, pannelli e altre applicazioni come PIM che offrono un'esperienza globale per l'utente.
Maciej Piechotka,

9

Prima di tutto, non esiste davvero uno stack grafico Linux. Linux non ha capacità di visualizzazione grafica.

Tuttavia, le applicazioni Linux possono usare display grafici e ci sono diversi sistemi per farlo. I più comuni sono tutti costruiti su X windows.

X è un protocollo di rete perché nel mezzo di uno stack di protocollo X è possibile avere una rete come componente standard. Diamo un'occhiata a un caso d'uso specifico. Un fisico a Berlino vuole condurre un esperimento al CERN in Svizzera su uno dei collettori di particelle nucleari. Accede da remoto ed esegue un programma di analisi dei dati su uno degli array di supercomputer del CERN e traccia il grafico dei risultati sul suo schermo.

A Berlino, il fisico ha un dispositivo X-terminal che esegue alcuni software X-server che fornisce una funzionalità di visualizzazione grafica per le applicazioni remote. Il software X-server ha un framebuffer che comunica con il driver di dispositivo specifico per l'hardware specifico. E il software X-server parla il protocollo X. Quindi i layer potrebbero essere dispositivo grafico-> driver di dispositivo-> frame buffer-> server X-> protocollo X.

Quindi, in Svizzera, l'applicazione si collega a un display usando il protocollo X e invia comandi grafici come "disegna rettangolo" o "fusione alfa". L'applicazione utilizza probabilmente una libreria grafica di alto livello e tale libreria sarà, a sua volta, basata su una libreria di livello inferiore. Ad esempio, l'applicazione può essere scritta in Python usando il toolkit WxWidget che si basa su GTK che utilizza una libreria chiamata Cairo per i principali comandi di disegno grafico. Potrebbe esserci anche OPENGL anche in cima al Cairo. I livelli potrebbero essere così: WxWidgets-> GTK-> Cairo-> X Toolkit-> X protocol. Chiaramente è il protocollo nel mezzo che collega le cose, e poiché Linux supporta anche socket UNIX, un trasporto completamente interno per i dati, questi due tipi di cose possono essere eseguiti su una macchina se lo si desidera.

X si riferisce al protocollo e tutto ciò che è fondamentale per l'architettura come l'X-server che esegue il display grafico, il dispositivo di puntamento e la tastiera.

GTK e QT sono due librerie GUI generiche che supportano finestre, finestre di dialogo, pulsanti, ecc.

GNOME e KDE sono due ambienti desktop che gestiscono le finestre sul desktop grafico, forniscono utili applet e cose come le barre dei pulsanti. Consentono inoltre a più applicazioni di comunicare attraverso l'X-server (dispositivo X-terminal) anche se le app sono in esecuzione su computer remoti diversi. Ad esempio, copia e incolla è una forma di comunicazione tra applicazioni. GNOME è basato su GTK. KDE si basa su QT. Ed è possibile eseguire app GNOME su un desktop KDE o app KDE su un desktop GNOME perché funzionano tutti con lo stesso protocollo X sottostante.


7
Questa risposta è obsoleta. Il kernel è stato coinvolto nella grafica per molto tempo ormai.
mattdm,

5
Per espandere il commento di mattdm, anche quando la grafica è guidata da driver esterni all'albero del kernel, usano ancora i servizi del kernel per controllare l'accesso alle risorse grafiche. Il kernel si trova sempre nella parte inferiore dello stack.
dmckee,

Non sarei d'accordo sul fatto che il kernel sia in fondo allo stack. Naturalmente, i driver di dispositivo usano i servizi del kernel per ottenere un accesso privilegiato all'hardware, ma un'applicazione X sta comunicando la rete, quindi ci sono più livelli oltre la scheda di rete.
Michael Dillon,

Il fatto che X sia costruito sulla rete, sebbene importante per alcune configurazioni su molti è il dettaglio dell'implementazione (specialmente per i desktop) e ci sono estensioni come MIT-SHM. Il kernel gioca un ruolo importante nello stack corrente sia fornendo driver DRM, KMS sia gestendo trame.
Maciej Piechotka,

DRM e KMS riguardano maggiormente i driver di dispositivo che ora devono comunicare tramite una connessione di rete interna dedicata a una CPU con rendering grafico sulla scheda grafica. Questo può far parte dello stack grafico e potrebbe non (ad esempio Amazon EC2 Linux).
Michael Dillon,

2

Questa è la sua organizzazione, imparerai di più da questa immagine che da diverse pagine di testo:

inserisci qui la descrizione dell'immagine


1
Da dove viene? Ci sono alcuni numeri cerchiati, cosa significano? E questo sembra specifico per Wayland, mentre penso che solo X o Mir avrebbero organizzazioni diverse.
Muru,

1
@muru facendo una ricerca inversa ho trovato questo .... en.wikipedia.org/wiki/EGL_%28API%29 ... sebbene sia attualmente ospitato su imgur, dal momento che sembra essere un upload? Ma sono d'accordo nel collegare l'immagine di origine e dove viene visualizzato è il modo giusto per farlo?
Jmunsch,

1
Questa immagine non spiega davvero nulla oltre l'xserver? Guardarti è X11-clientsolo una chiazza, ma c'è molto da fare in quella chiazza. Come spiegato dalle altre risposte davvero fantastiche.
Jmunsch,

1

Linux su desktop e alcuni server sono ancora tutti grafici X e frame buffer. Sotto X-Window: arriva GTK + e Qt, SÌ ENTRAMBI utilizza il sistema X, anche in questo caso ci sono molti ambienti desktop: Gnome, KDE usa il display X e le loro shell, ecc.

A proposito, c'è stato un video recente da Linux Conf (http://blip.tv/file/4693305/). Keith Packard di Intel ha parlato di X e GL * È stato interessante.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.