Configuração do modo de kernel vs. framebuffer?

Com o KMS, os drivers gráficos são movidos para o kernel. Como o framebuffer já estava no kernel, eu não esperaria que isso afetasse a operação do framebuffer. No entanto, li que o KMS substitui o fb, aumenta o fb, requer o fb e exige que o suporte ao fb seja removido. O que o diabo? A resposta que estou procurando é uma explicação da relação entre o KMS e o framebuffer.

Eu tenho usado o uvesafb para obter resolução nativa no tty. Meu objetivo aqui é entender como isso funcionará em um sistema com o KMS. Também ajudaria a cobrir coisas como ... A rolagem é mais rápida com o KMS? Utilitários como fbterm e fbida funcionam da mesma maneira? A estabilidade é melhor?

Primeiro de tudo, existem basicamente dois tipos de drivers de buffer de quadros clássicos:

• Drivers genéricos de hardware e firmware (por exemplo, vga, vesafb / uvesafb, efifb)
• Drivers específicos de hardware (por exemplo, rivafb, atyfb)

Todos os drivers clássicos do buffer de estrutura tinham suporte básico à configuração de modos, mas expuseram pouco ou nenhum suporte à aceleração de hardware.

Com o design clássico do X, isso não era realmente um problema: para obter a aceleração 2D, o servidor X era executado como root e podia acessar o hardware diretamente. Ele basicamente ignorou o driver do buffer de quadros completamente. Para 3d (e suporte 2D em placas mais recentes), ele também usaria um driver DRM do kernel que media o acesso e gerencia a memória de vídeo.

Nessa configuração, havia dois locais onde a configuração de modos era feita: no driver do buffer de estrutura do kernel e no servidor X do espaço do usuário. Essa duplicação de código (e brigas ocasionais entre motoristas, por exemplo, no comutador VT) não era ideal.

Além disso, havia dois drivers separados no kernel para a mesma peça de hardware: o driver framebuffer e o driver DRM. Em alguns casos (por exemplo, pré-kms intelfb), você pode carregar um ou outro, mas não os dois ao mesmo tempo.

KMS foi a solução para esses problemas. Isto:

• Mescla o driver framebuffer e o driver drm específicos do hardware do kernel em um único driver.
• Fornece uma interface para o servidor X usar para controlar a configuração de modo, para que o servidor X não precise acessar diretamente o hardware. (De fato, com o KMS, o servidor X não precisa mais de permissões de root.)

Algumas observações interessantes: A migração para o que é agora o KMS começou na verdade por volta de 2004; consulte o email de Jon Smirl no console rearchitecture .

Para responder suas perguntas mais específicas:

• A velocidade geralmente não será pior do que um dos drivers genéricos não acelerados (por exemplo, VGA, vesafb), mas o console de texto KMS framebuffer foi projetado para conveniência e uso de emergência, em vez de velocidade, e o console não é totalmente acelerado em alguns drivers. As longas filas embrulhadas são muito ruins em placas intel, por exemplo.
• Os aplicativos projetados para usar as interfaces do framebuffer antigos ainda funcionarão em um framebuffer KMS.

O KMS define a resolução e a profundidade da exibição no espaço do kernel, em vez do espaço do usuário. Então, sim, substitui-o. Permite resolução nativa no buffer de quadros.

Configuração do modo kernel