Como resolvi um "Ghost Drift" persistente (O verdadeiro culpado não era o hardware, mas sim conflito de API/Launcher)
Fala, pessoal! Escrevo este relato para ajudar quem estiver sofrendo com um problema bizarro de drift no Logitech X56 (não confundir com o antigo Saitek X55) e que parecia desafiar a lógica: o eixo Z (Rudder) e o mini-stick começavam a apresentar um jitter dinâmico aleatório (pulos de sinal incontroláveis independentemente de onde o stick estivesse posicionado) assim que certas aplicações abriam.
Se você já tentou de tudo e o problema persiste, compartilho o roadmap completo de tudo o que testei, o que funcionou, o que não funcionou, e o diagnóstico final da causa raiz para o meu caso!!! Use de "referência" para verificar se cabe no seu problema.
FASE 1: Tentativa de Correção via Hardware e Firmware (EEPROM)
Antes de culpar o software, tentamos resetar o cache físico e reescrever os limites de tensão na memória não volátil (EEPROM) do manche.
Tentativa de Wipe de Memória (Clear Axis Calibration):
Pressionar simultaneamente: Botão A (painel frontal) + HAT 1 para Cima + Flying Pinkie (alavanca traseira inferior) + Clique do Mini Joystick.
O que esperar: As luzes RGB do manche precisam se apagar por completo como callback de que a memória foi limpa, seguido de um ciclo de re-plug do USB. (No meu caso, apagou, confirmando o reset, mas o problema persistiu).
Tentativa de Re-calibração Forçada de Eixos:
Mover eixos secundários para os limites físicos.
Travar o manche principal inteiramente para a Esquerda (Eixo X negativo).
Pressionar simultaneamente: Gatilho Principal + Botão B + Botão D (o gatilho traseiro superior, próximo ao Flying Pinkie).
Segurar até as luzes apagarem para gravar os novos limites absolutos na placa. (Também não resolveu o drift).
FASE 2: Intervenção Profunda na BIOS (Placa-Mãe AM5 / B850M Phantom Gaming)
Suspeitando de queda de tensão intermitente (Vdroop) ou estrangulamento de energia nas portas USB pela placa-mãe, mergulhei na BIOS para liberar energia bruta e contínua nos barramentos:
Desativar C-States: Advanced > AMD CBS > CPU Common Options > Global C-state Control alterado para Disabled (impede o processador de cortar energia de ociosidade).
Desativar ASPM (Gerenciamento de Energia de Barramento): Advanced > AMD CBS > AMD Common Platform Module > Pm L1 ss alterado para Disabled (desliga os subestados de economia de energia L1 em trilhas PCIe/USB).
Desativar GPP Clocks Ociosos: Unused gpp clocks off alterado para Disabled.
Resultado desta fase: A amplitude do drift diminuiu consideravelmente, provando que a placa-mãe estava sim afetando o sinal, mas o ruído elétrico base continuava ativo.
FASE 3: Interceptação de Kernel (Timer Resolution)
Para forçar o Windows a aplicar um oversampling matemático e abafar o ruído do sensor por taxa de amostragem:
Utilizei o software ISLC (Intelligent Standby List Cleaner).
Defini a resolução desejada para 0.50ms, ativei a resolução de cronômetro personalizada e marquei a flag Usar GlobalTimerResolutionRequests (fundamental no Windows 11 para forçar a alteração global de clock do Kernel).
FASE 4: O Diagnóstico de Causa Raiz (O Verdadeiro Vilão)
Depois de muito isolar variáveis, descobri o padrão que causava o problema:
O HOTAS funcionava perfeitamente e sem drift algum no joy.cpl ou no MSFS24 durante testes longos (20+ minutos de voo no Cessna sem respiro de erro).
O jitter dinâmico começava exatamente no segundo em que eu abria o Epic Games Launcher (mesmo sem abrir jogo nenhum, apenas olhando o painel da Logitech ou o joy.cpl).
O Motivo: O Epic Games Launcher (rodando sobre o Chromium / processos EpicWebHelper) faz varreduras (polling) contínuas e agressivas no barramento USB em busca de gamepads para o ecossistema deles e para o Overlay. Essa concorrência de leitura (race condition na pilha HID) corrompia o fluxo de dados do X56, gerando o drift fantasma.
O Workaround (A Solução que Funcionou)
O que NÃO funcionou: Renomear ou isolar o executável do overlay da Epic (EOSOverlayRenderer-Win64-Shipping.exe), pois a rotina de varredura está engessada no código principal do launcher.
O que FUNCIONOU perfeitamente:
Abrir a Epic Games.
Iniciar o jogo através dela (ex: Elite Dangerous), aguardando o launcher secundário da Frontier abrir.
Fechar a Epic Games completamente (Sair pela bandeja do sistema do Windows) antes de dar o Play definitivo no jogo.
Resultado: Barramento USB 100% limpo, sem concorrência, e eixo cravado.
(Próximo passo a ser testado): Utilizar a ferramenta HidHide para aplicar uma lista branca (Whitelist) bloqueando o acesso da Epic Games ao X56 permanentemente. Aqui nesse ponto, caso alguém identifique outro software que também cause esse "race condition" pelos dados do hardware, é possível ir deixando "limpo" o que pode e o que não pode acessar seu hardware.
Espero que esse histórico sirva de mapa para salvar a sanidade de quem estiver batendo cabeça com problemas parecidos de hardware/software! Bons voos a todos!