O suporte a gráficos do Linux tem sido altamente mutante durante a maior parte da vida útil do kernel. Inicialmente, o kernel só falava com a placa gráfica para fins de modo de texto. Naquela época, o X usava seus drivers para fazer tudo, então funcionava como um grande kernel fora do kernel.
Mais tarde, com a Infraestrutura de Renderização Direta (DRI) , parte do código para recursos gráficos acelerados foi movido para o lado do 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 para ter um módulo DRM do lado do kernel carregado. Mas se você não tiver uma, é provável que sua sessão X retorne ao 3D renderizado por software, que é consideravelmente mais lento e com mais fome do que o hardware 3D. A execução de glxinfo mostrará 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 apenas como outra coisa. Wayland assume os deveres de falar com o hardware (X falando com Wayland). Como o projeto ainda está em grande desenvolvimento, não há como saber aonde ele vai acabar, mas a forma como o entendo é que ele ainda precisa do suporte do kernel para renderização em 3D.
Também é óbvio a partir dos diagramas de arquitetura de Wayland: esquerda é o atual estado de coisas para uma moderna área de trabalho X, certo é o proposto projeto de Wayland. O compositor Wayland substitui o X Server como a coisa que fala com o hardware, mas ele não substitui a infra-estrutura kernel - então você ainda precisa do suporte adequado ao kernel. De fato, dados os objetivos do projeto, mais coisas devem passar para o kernel para uma melhor abstração. O Wayland, como o servidor X, ainda depende do hardware gráfico.
