Conectar um dock USB Type-C com múltiplas funções — vídeo DisplayPort, túnel Thunderbolt/USB4, energia e dados — está prestes a ficar mais previsível (e até mais seguro) no Linux. Uma nova série de patches em RFC propõe centralizar, no driver da porta, a decisão de qual Alternate Mode ativar primeiro, com base em prioridades e políticas do sistema. Em vez de cada driver de altmode “puxar” a conexão para si, o kernel passaria a reger a negociação como um maestro: tenta USB4/Thunderbolt, se não rolar tenta DisplayPort, e assim por diante — tudo de forma ordenada e observável pelo userspace.
O problema: drivers de modo alternativo em competição
Hoje, assim que você pluga um parceiro Type-C com múltiplas capacidades, os drivers de altmode (por exemplo, o de DisplayPort e o de Thunderbolt) podem tentar se ativar de forma autônoma. Isso gera uma corrida: quem conseguir primeiro “entra” no modo — o que às vezes resulta em comportamento não determinístico, especialmente em plataformas com políticas mais rígidas. A própria documentação de typec explica que cada modo expõe um diretório em sysfs e pode ser ativado via o atributo active, mecanismo historicamente usado por daemons/policies no espaço do usuário; mas, na prática, isso não resolve a disputa entre drivers quando ambos querem ser “o escolhido”.
A proposta: seleção centralizada por prioridade, com feedback do driver
A série de patches do Andrei Kuchynski introduz um “motor” de seleção de modo no driver da porta Type-C. Em vez de decisões espalhadas, o kernel monta uma lista de tentativas ordenada por prioridade — USB4/Thunderbolt, Thunderbolt altmode, DisplayPort, etc. — e aciona cada driver de altmode sequencialmente. O modo só é considerado “negociado com sucesso” quando o driver correspondente reporta explicitamente status positivo; se falhar ou estourar timeout, o kernel segue para a próxima opção. A série também expõe um novo atributo mode_selection em sysfs para (re)disparar a negociação quando políticas mudarem (ex.: o usuário desbloqueou a sessão). Testes iniciais foram feitos em Android com kernel 6.16.
Essa proposta vem “montada” sobre outra série complementar: alternate mode priorities, que adiciona controle de prioridade por altmode (via sysfs) — isto é, quem o sistema prefere primeiro quando há várias possibilidades válidas. Juntas, as duas peças permitem que o kernel execute a seleção de forma estável, mas ainda alinhada às preferências do sistema/política.
Por quê isso importa (muito) nos Chromebooks
O gatilho para essa mudança é bem concreto: políticas de segurança em Chromebooks. Como explicou Abhishek Pandit-Subedi, há cenários em que o sistema prefere DisplayPort (apenas vídeo) a Thunderbolt/USB4 (que abre PCIe e, portanto, um vetor mais poderoso) — por exemplo, quando a tela está bloqueada ou o usuário está deslogado. Quando o usuário desbloqueia, a preferência pode voltar para Thunderbolt. A nova mecânica permite que o userspace ajuste prioridades e peça uma nova negociação de modo sem depender de re-plug ou “forçar” manualmente active em cada altmode. Em suma: políticas dinâmicas, com o kernel executando a orquestração.
Debate no upstream: kernel orquestra tudo, ou userspace manda?
Como toda boa mudança de arquitetura no kernel, há discussão. Heikki Krogerus (mantenedor chave de USB Type-C no Linux) questiona se vale a pena introduzir um “meio do caminho” — parte no kernel, parte acionada pelo userspace — em vez de deixar tudo para o userspace via active quando a plataforma precisar de controle fino. A preocupação é escalabilidade e evitar APIs que pareçam frágeis no longo prazo. Em paralelo, defensores da proposta lembram que não existe um daemon genérico “oficial” para Type-C, e que, em muitas plataformas (ex.: UCSI), o kernel já tem as informações mais frescas para orquestrar o timing da entrada em Alternate Mode. O consenso ainda está em construção — é RFC, e os mantenedores estão explicitamente pedindo iterações para acertar a API final.
Como fica a interação com userspace e políticas
A ideia não “desliga” o userspace — ao contrário. Com prioridades em sysfs e o gatilho mode_selection, um policy-daemon pode alternar preferências conforme o estado do sistema: tela bloqueada → prioriza DisplayPort; sessão ativa e dock confiável → prioriza Thunderbolt/USB4. Se algo falhar, os drivers reportam o resultado de entrada de modo de volta ao núcleo da seleção, que então tenta a próxima opção ou publica o erro para o userspace decidir. Essa é uma diferença importante em relação ao status quo: hoje, muito da coordenação fica distribuída entre drivers e scripts/serviços; a proposta traz um ponto único de verdade para a negociação.
Detalhes que desenvolvedores vão querer saber
- Sinalização via sysfs: além de
activepor modo (já existente), entra omode_selectionno parceiro (/sys/class/typec/<port>-partner/), que liga/desliga o ciclo de negociação segundo a ordem de prioridades configurada. É um gatilho para refazer a seleção quando uma política muda sem hotplug. - Prioridades por altmode: configuráveis via atributo de sysfs introduzido na série “alternate mode priorities” (ex.: dar peso menor/maior a DisplayPort vs Thunderbolt).
- Feedback explícito: os drivers de altmode passam a notificar sucesso/falha da entrada de modo (inclusive propagando erros vindos de UCSI / VDM) — isso remove ambiguidades e permite timeouts/retentativas bem definidos antes de cair para a próxima opção.
- Compatibilidade e escopo: nada disso “engessa” quem prefere controle 100% no userspace; a documentação oficial de Type-C continua prevendo ativação de modo via
activepor modo, e o ecossistema segue podendo escolher o modelo de governança ideal por plataforma.
Onde isso entra no ciclo do kernel
Por ser RFC, estamos falando de uma proposta para uma janela de merge futura — ainda sem garantia de entrar tal como está. O patchset de seleção cita testes em Android (6.16) e depende da série de prioridades enviada na semana anterior; a discussão pública continua ativa na lkml e em resumos do LWN, o que indica que as próximas revisões podem ajustar nomes de atributos, responsabilidades entre kernel e userspace e até dividir a lógica em “conjuntos” de modos, como alguns mantenedores sugerem. Em outras palavras, a direção é clara (centralizar e tornar previsível), enquanto a forma final ainda está sendo lapidada em colaboração.
Em termos práticos para você, usuário ou admin: quando isso aterrissar, conectar um monitor ou dock ao seu laptop Linux USB Type-C deve ficar mais “óbvio”: se a política disser “vídeo simples quando bloqueado”, você verá DisplayPort; se disser “desbloqueou? puxa o máximo do dock”, o kernel tentará Thunderbolt/USB4 primeiro — e, se não der, cairá graciosamente para a próxima melhor opção, sem truques ou corridas entre drivers.
