O suporte a gráficos do Linux tem sido uma coisa fortemente mutante durante a maior parte da vida do kernel. Inicialmente, o kernel conversava apenas com a placa gráfica para fins de modo texto. Naquela época, o X usava seus drivers para fazer tudo, por isso funcionava como um enorme kernel fora do kernel.
Posteriormente, com o Direct Rendering Infrastructure (DRI) , alguns dos códigos para recursos gráficos acelerados foram movidos para o kernel (chamado Direct Rendering Manager, DRM - nada a ver com gerenciamento de direitos digitais) para fornecer uma interface consistente e abstrata aos recursos de aceleração 3D.
Atualmente, você não precisa ter um módulo DRM do lado do kernel carregado. Mas se você não tiver uma, as chances são de que a sua sessão do X retorne ao 3D renderizado por software, que é consideravelmente mais lento e com maior consumo de energia do que o hardware 3D. A corrida glxinfomostrará informações sobre isso.
Wayland é uma história um pouco diferente . Ele fica entre o kernel e os aplicativos clientes. Com o Wayland, o servidor X é outro aplicativo cliente, exibindo sua janela raiz como apenas mais uma coisa. Wayland assume o dever de conversar com o hardware (X falando com Wayland). Como o projeto ainda está em desenvolvimento, não há como saber onde ele vai acabar, mas, pelo que entendi, ele ainda precisa de suporte do kernel para renderização em 3D.
Também é óbvio nos diagramas de arquitetura de Wayland: esquerda é o estado atual das coisas para um desktop X moderno; direita é o projeto de arquitetura proposto por Wayland. O compositor de Wayland substitui o X Server como o que fala com o hardware, mas não substitui a infraestrutura do kernel - portanto, você ainda precisa de suporte apropriado do kernel. De fato, dados os objetivos do projeto, mais coisas devem passar para o kernel para uma abstração ainda melhor. Wayland, como o servidor X, ainda depende do hardware dos gráficos.
pnginfono arquivo de origem: otEXtpedaço sugere que foi feito com o Inkscape.