Impostazione modalità kernel vs Framebuffer?

Con KMS, i driver grafici vengono spostati nel kernel. Dato che il framebuffer era già nel kernel, non mi aspetto che ciò influisca sul funzionamento del framebuffer. Tuttavia, ho letto che KMS sostituisce l'fb, aumenta l'fb, richiede l'fb e richiede il supporto dell'fb per essere rimosso. Che diamine? La risposta che sto cercando è una spiegazione della relazione tra KMS e il framebuffer.

Ho usato uvesafb per ottenere la risoluzione nativa al tty. Il mio scopo qui è capire come funzionerà su un sistema con KMS. Aiuterebbe anche a coprire cose come .. Lo scorrimento è più veloce con KMS? Le utility come fbterm e fbida funzionano allo stesso modo? La stabilità è migliore?

Prima di tutto, ci sono fondamentalmente due tipi di driver framebuffer classici:

• Driver hardware e firmware generici (ad es. Vga, vesafb / uvesafb, efifb)
• Driver specifici dell'hardware (ad es. Rivafb, atyfb)

I classici driver del framebuffer avevano tutti il ​​supporto di base per la modifica delle impostazioni, ma hanno mostrato poco o nessun supporto per l'accellerazione dell'hardware.

Con il classico design X, questo non era un vero problema: per ottenere l'accelerazione 2D, il server X funzionava come root e poteva accedere direttamente all'hardware. Fondamentalmente ha bypassato completamente il driver del framebuffer. Per 3d (e supporto 2d su schede più recenti), userebbe anche un driver DRM del kernel che mediava l'accesso e gestiva la memoria video.

In questa configurazione, c'erano due posti in cui veniva fatta la modalità: sia nel driver del framebuffer del kernel, sia nel server X dello spazio utente. Questa duplicazione di codice (e occasionali combattimenti tra i conducenti, ad esempio su switch VT) non era l'ideale.

Inoltre, c'erano due driver separati nel kernel per lo stesso componente hardware: il driver framebuffer e il driver DRM. In alcuni casi (ad es. Pre-kms intelfb), è possibile caricare l'uno o l'altro, ma non entrambi contemporaneamente.

KMS era la soluzione a questi problemi. It:

• Unisce il driver framebuffer specifico dell'hardware del kernel e il driver drm in un singolo driver.
• Fornisce un'interfaccia che il server X può utilizzare per controllare la modalità di impostazione, quindi il server X non deve accedere direttamente all'hardware. (In effetti, con KMS, il server X non ha più bisogno dei permessi di root.)

Alcune note interessanti: la migrazione verso l'attuale KMS è iniziata intorno al 2004; vedi l'e-mail di Jon Smirl sulla console di ricerca .

Per rispondere alle tue domande più specifiche:

• La velocità generalmente non sarà peggiore di uno dei driver generici non accelerati (ad es. VGA, vesafb), ma la console di testo framebuffer KMS è stata progettata per la comodità e l'uso di emergenza piuttosto che la velocità e la console non è completamente accelerata su alcuni driver. Le linee lunghe avvolte sono piuttosto cattive sulle carte Intel, ad esempio.
• Le applicazioni progettate per utilizzare le vecchie interfacce framebuffer continueranno a funzionare su un framebuffer KMS.

KMS imposta la risoluzione e la profondità di visualizzazione nello spazio del kernel anziché nello spazio utente. Quindi sì, lo sostituisce. Abilita la risoluzione nativa nel framebuffer.

Impostazione della modalità kernel