Por anos, falar em HDR no desktop Linux foi um daqueles assuntos que sempre vinham com um “quase”: o monitor era capaz, a GPU tinha blocos de hardware dedicados, o Wayland já era o caminho, mas faltava o ingrediente mais básico de todos, uma forma padronizada de dizer ao kernel exatamente como programar o pipeline de cores. Nesta semana, esse “quase” encolheu de verdade. A tão aguardada Color Pipeline API foi integrada ao drm-misc-next, marcando a chegada oficial, dentro do Linux Kernel, de uma infraestrutura moderna para gerenciamento de cores no nível do DRM/KMS.
O resultado não é “HDR amanhã” no GNOME ou no KDE. O resultado é mais importante e mais fundamental: agora existe uma linguagem comum, uma API que permite que compositores como KWin, Mutter e Gamescope descrevam, passo a passo, como a GPU deve tratar a imagem antes de chegar aos seus olhos. E quando a base fica sólida, o resto finalmente pode evoluir rápido.
O fim da espera: uma API padronizada para HDR de verdade
O Linux já tinha peças de gerenciamento de cor espalhadas: curvas simples, propriedades para alguns ajustes, caminhos específicos por driver. O que estava faltando era a capacidade de montar pipelines complexos de forma uniforme, com operações encadeadas como LUTs (1D e LUT 3D) e CTM (Color Transformation Matrix), além de curvas de transferência ligadas a HDR.
Na prática, é a diferença entre “ter um botão de brilho” e “ter uma mesa de correção de cor”. HDR não é só mais brilho, ele é um conjunto de regras matemáticas para mapear valores digitais para luminância real na tela, com gama, mapeamento de tons, conversões de espaço de cor e preservação de detalhes em sombras e highlights. Sem uma API padrão para programar os blocos de hardware, cada compositor virava um caso especial, e cada driver inventava o próprio dialeto.
O que é a API prescritiva?
Vale um detalhe para alinhar expectativas: esta mudança acontece no Linux Kernel (DRM/KMS), mas HDR “de ponta a ponta” também depende do Wayland ter um protocolo para os clientes declararem como o conteúdo foi criado (espaço de cor, primárias, curva, metadata HDR) e para o compositor decidir o que fazer com isso. A boa notícia é que esse lado também vem amadurecendo, e a chegada da Color Pipeline API dá o alicerce que faltava para padronizar o que realmente deve ir para o hardware.
Aqui entra a mudança filosófica, e ela é histórica: a Color Pipeline API é “prescritiva”. O kernel não tenta mais “adivinhar” como deve converter cores. Em vez disso, ele expõe os blocos do hardware e deixa o compositor descrever a receita exata.
Vale a analogia da cozinha do chef: antes, pedir cores ao Linux era como pedir um prato em fast-food. Você escolhia entre poucas opções prontas (sRGB, talvez uma curva, e olhe lá). Agora o kernel vira uma cozinha profissional, e o compositor é o chef que passa a receita detalhada para a GPU, o cozinheiro: “aplique esta curva aqui, multiplique acolá, passe por uma matriz 3×4, depois por uma LUT 3D”. O prato final (a imagem) sai muito mais próximo do planejado.
Isso importa porque cada ambiente gráfico sabe o contexto real: qual monitor está ativo, qual perfil ICC o usuário escolheu, qual aplicação pede HDR, se é um jogo em tela cheia ou uma timeline de vídeo. O kernel só precisa oferecer controles confiáveis e previsíveis.
LUT, CTM e EOTF: traduzindo o “idioma” das cores
Se você nunca precisou trabalhar com isso, alguns termos parecem intimidadoras, mas dá para pensar de forma bem concreta:
- LUT (Look-Up Table) é como uma tabela de conversão. Imagine um “dicionário” que diz: “se entrar o valor X, devolva o valor Y”. Uma LUT 1D faz isso por canal, ótimo para curvas e ajustes de gama. Já uma LUT 3D é como uma biblioteca de receitas para misturas complexas de cor: ela olha para R, G e B ao mesmo tempo e devolve uma nova cor considerando a interação entre canais, o que é essencial para correção de gamut e transformações avançadas.
- CTM (Color Transformation Matrix) é uma matriz 3×4 que faz uma transformação linear do espaço de cor. Pense nela como um “mixer matemático” que mistura os canais para mudar de um espaço de cor para outro.
- EOTF (Electro-Optical Transfer Function) é a regra que traduz o sinal digital para brilho real emitido pelo display. Em HDR, isso é crucial. É o “manual de instruções” que diz como transformar números em luz.
HDR não existe sem EOTF e sem a capacidade de encadear essas operações com precisão.
Por baixo do capô: drm_colorop e o encadeamento de operações
Tecnicamente, a API introduz o conceito de operações de cor encadeáveis via um novo objeto de uAPI, o drm_colorop. A ideia é representar o pipeline como uma sequência de “blocos” expostos pelo hardware. No caso da AMD, a implementação inicial mira GPUs com DCN 3.0+ e descreve um pipeline de múltiplas etapas que espelha o que já vinha sendo explorado no ecossistema do Steam Deck, com o Gamescope.
Outro ponto importante é o escopo: este primeiro passo foi desenhado para cobrir bem o uso por drm_plane, ou seja, operações de cor aplicadas por plano. Isso combina com a realidade de compositores e do Gamescope, mas não encerra a história. Parte do trabalho que vem a seguir é ampliar como o ecossistema lida com operações “pós-blend” (após a composição), que são especialmente relevantes para calibração geral do monitor e para cenários mistos de conteúdo SDR e HDR na mesma cena.
Um exemplo de pipeline anunciado para GPUs DCN 3+ inclui blocos como curvas 1D, CTM 3×4, multiplicadores e LUTs 3D, em um encadeamento que permite montar caminhos completos para HDR, wide gamut e calibração fina. Esse encadeamento é exatamente o que faltava para transformar “suporte parcial” em “infraestrutura séria”.
E tem um detalhe importante: não é só “ter LUT 3D”. É padronizar o mecanismo para o compositor programar esse bloco e, ao mesmo tempo, permitir que futuros drivers descrevam capacidades diferentes (tamanhos de LUT, métodos de interpolação, limitações do hardware) sem quebrar o modelo.
Hardware suportado: AMD lidera, VKMS garante testes
O suporte inicial não é “todo mundo”. Ele começa onde havia equipe, necessidade e hardware com blocos bem definidos: AMD (DCN 3.0+) e VKMS. O VKMS é especialmente valioso aqui porque serve como laboratório: ele permite validar a uAPI, exercitar testes automatizados e garantir que os compositores consigam falar com a API sem depender de uma GPU específica.
O VKMS entra aqui como algo mais valioso do que “um driver fake”: ele permite automatizar testes de regressão. A série veio acompanhada de testes (IGT) que checam transformações com comparação pixel a pixel, aceitando pequenas variações porque o objetivo é correção perceptual, não identidade bit a bit. É o tipo de cuidado que evita que uma API tão sensível acabe virando um castelo de cartas.
Essa combinação é o que torna o merge no drm-misc-next mais do que um marco simbólico. Com VKMS e uma implementação real em hardware, dá para criar uma trilha de testes e evoluir a API com menos risco de regressões, que é sempre o fantasma de qualquer mudança grande em DRM/KMS.
Também vale lembrar que a API não transforma hardware antigo em hardware novo. Ela padroniza o acesso: o compositor recebe uma lista de operações disponíveis, e essa lista varia por GPU e driver. Em uma placa, pode existir LUT 3D e matrizes mais completas; em outra, o pipeline pode ser mais simples. O ganho é que todo mundo passa a falar o mesmo idioma para descobrir e programar esses blocos.
O impacto no usuário: jogos HDR, vídeo profissional e wide gamut com precisão
Para quem só quer jogar, o impacto é direto: HDR no Linux deixa de ser “hack por driver” e passa a ter um caminho padrão que compositores podem usar para entregar brilho e contraste de forma correta, com mapeamento de tons consistente e cores sem aquele aspecto “lavado” ou “explodido”.
Para quem trabalha com imagem, a promessa é ainda maior: wide gamut bem gerenciado é o tipo de coisa que você não percebe quando está correto, mas que destrói um fluxo de trabalho quando está errado. Compositor e apps precisam de previsibilidade para que o vermelho hoje seja o mesmo vermelho amanhã, em outro monitor, em outra sessão, sem gambiarra.
O ponto-chave é este: a API dá controle. E controle é o pré-requisito para precisão.
Quando chega no meu PC?
Em 26 de novembro de 2025, a implementação foi integrada ao drm-misc-next, o que é um grande marco. Ainda assim, por causa do calendário do subsistema DRM (e do corte para envio ao DRM-next durante um ciclo), isso não garante que a novidade entre já na janela de merge imediatamente seguinte. Em outras palavras: a base está no lugar, mas pode levar mais um ciclo até aparecer de forma padrão nas builds que chegam ao usuário comum.
Por timing, a expectativa discutida publicamente é que a integração tenha perdido a janela imediata e acabe entrando em um ciclo seguinte, com chegada ao kernel estável em um horizonte mais distante do que uma ou duas releases. Em paralelo, mesmo depois de estar no kernel, você só “vê” HDR se o seu compositor Wayland adotar a API e expor as peças na prática. Weston e KWin já aparecem como candidatos naturais para liderar esse uso, e Gamescope é um dos motivadores técnicos mais óbvios dessa padronização. O recado é simples: o kernel entregou a chave, agora a porta precisa ser aberta no user space.
