Como a JoyCheck lê seu controle

A JoyCheck é um testador de controle que roda no navegador e lê seu gamepad pela API Gamepad do W3C, sem instalar nada e sem enviar nada para um servidor.

6 tipos de entrada · 4 seções · 10 min de leitura

A JoyCheck lê seu controle usando a API Gamepad do W3C[1], uma interface nativa do navegador que expõe cada botão, cada eixo analógico e cada gatilho como valores numéricos atualizados 60 vezes por segundo. O navegador cuida do handshake USB ou Bluetooth; a JoyCheck consulta navigator.getGamepads() a cada quadro de animação e renderiza o estado ao vivo sem enviar dados a nenhum servidor.

Atualizado em 2026-05-27 por Taimoor Bamazai, fundador da Elites Algorithm Limited (uma empresa de tecnologia registrada em Dublin, na Irlanda) e o engenheiro por trás da JoyCheck.

O fluxo de dados ao vivo tem três propriedades que vale nomear:

• Nativo do navegador. API Gamepad do W3C padrão. Sem binário nativo, sem instalar driver. Funciona em todo navegador moderno baseado em Chromium, no Firefox e no Safari 16+.
• Consulta de 60 a 144 Hz. A JoyCheck lê navigator.getGamepads() a cada quadro de animação, o mesmo ritmo em que o navegador redesenha a tela, acompanhando os Hz do seu display.
• Nenhum dado enviado. Cada entrada é processada dentro do processo do seu navegador. Sem XHR, sem fetch, sem analytics no widget. Verificável no DevTools.

O que significa “ler” um controle de videogame?

A JoyCheck lê seis classes de entrada do seu controle, e cada uma corresponde a um campo específico da API Gamepad.

• Botões (gamepad.buttons[]). Cada botão é um objeto GamepadButton que relata o estado pressionado e, quando suportado, um valor analógico.
• Analógicos (gamepad.axes[0..3]). O array axes é um array plano de floats. Sob o mapeamento padrão do W3C, ele contém as posições X/Y dos analógicos esquerdo e direito.
• Gatilhos (gamepad.buttons[6,7].value). Os gatilhos ficam no array buttons e são tratados como botões com um valor analógico sob o mapeamento padrão.
• Touchpad (gamepad.touchEvents[]). O DualShock 4 e o DualSense expõem as coordenadas do touchpad como uma extensão da API Gamepad. A resolução relatada do touchpad é de aproximadamente 1920×1080, e até dois pontos de toque simultâneos são rastreados.
• Giroscópio e IMU (gamepad.imu, proposto). DualSense, Joy-Con e Switch Pro expõem dados de IMU de seis eixos.
• Vibração (gamepad.vibrationActuator.playEffect()). A interface vibrationActuator em um objeto Gamepad expõe um método playEffect() que recebe uma duração e uma intensidade para cada motor, nos controles padrão que relatam atuadores de vibração.

Como a API Gamepad do W3C funciona de fato?

A API Gamepad é uma interface de navegador padrão do W3C que expõe os controles de jogo conectados ao JavaScript. Ela vem em todo navegador moderno desde o Chrome 21 (2012), o Firefox 29 (2014), o Edge 12 (2015) e o Safari 14.1 (2021), veja o Can I Use para a matriz de suporte atual.[2]

O navegador cuida do handshake USB ou Bluetooth HID subjacente. Seu sistema operacional pareia o controle; o navegador o enxerga por camadas de driver do sistema (XInput no Windows, IOHIDDevice no macOS, evdev no Linux); a página chama navigator.getGamepads() e recebe um array de snapshot de objetos Gamepad.

Cada objeto Gamepad expõe um conjunto de campos:

• id: um identificador em texto (por exemplo, “DualSense Wireless Controller (STANDARD GAMEPAD Vendor: 054c Product: 0ce6)”)
• axes[]: um array de floats com as posições dos eixos analógicos (analógicos, tipicamente quatro entradas: esquerdo X/Y + direito X/Y)
• buttons[]: um array de objetos GamepadButton, cada um com as propriedades pressed, value e touched
• timestamp: horário da última atualização em milissegundos
• mapping: “standard” se o controle segue o layout de gamepad padrão do W3C; "" caso contrário
• vibrationActuator: uma interface de resposta háptica (onde suportada)

A API exige um gesto do usuário (botão pressionado) antes de expor os controles conectados. Esse é o requisito de gesto: um recurso de privacidade que impede que páginas façam fingerprinting do seu controle em segundo plano. A JoyCheck exibe “Pressione qualquer botão para começar” até o gesto acontecer.

Por que a JoyCheck consulta em vez de assinar eventos

A API Gamepad é somente por consulta (poll-only) no padrão. Não existe um evento onbuttonpress que você possa assinar: seu código pede navigator.getGamepads() e recebe um snapshot do estado atual. A JoyCheck consulta usando requestAnimationFrame[5], que dispara o callback na taxa de atualização do display (tipicamente 60 Hz, até 240 Hz em telas de alta taxa de atualização).

Consultar na taxa de atualização é o ritmo certo porque:

• O sistema atualiza o estado do controle mais ou menos nesse ritmo (o USB HID consulta a 1 kHz; o navegador reduz a amostragem)
• A renderização acontece na taxa de atualização, então consultas extras produziriam quadros duplicados sem diferença visual
• Isso mantém o uso de CPU mínimo, o callback de consulta é uma chamada de função por quadro

Consultar mais rápido (via setInterval ou setTimeout) desperdiça CPU e produz snapshots duplicados. Consultar mais devagar (por exemplo, 30 Hz) perde botões pressionados rapidamente em telas de alta taxa de atualização. O requestAnimationFrame acompanha o display, que por sua vez acompanha o que você realmente vê.

Por que a JoyCheck não envia dados e como posso verificar?

Dizemos isto três vezes porque importa:

1. A JoyCheck não transmite nenhum dado do controle a nenhum servidor, nunca.

2. A API Gamepad roda inteiramente dentro do processo do seu navegador. O estado do controle nunca sai da página.

3. Veja o código-fonte do widget: cada chamada de API se resolve em um callback de requestAnimationFrame que atualiza apenas nós do DOM. Não há chamadas fetch(), nem XMLHttpRequest, nem acessos a WebSocket que transportem dados do controle.

Você pode verificar isso em menos de um minuto: abra a JoyCheck em qualquer navegador, abra o DevTools (F12), clique na aba Rede, limpe o log e use o widget por 30 segundos. A aba Rede fica vazia quanto a requisições de estado do controle. Declaração completa na página de privacidade.

Por que usar um testador de navegador em vez de um app de desktop?

Três motivos:

Sem atrito de instalação. A API Gamepad já é confiável o bastante para que pedir aos usuários que baixem e executem um binário seja um imposto desnecessário. Carregar uma página é mais rápido que um instalador; um navegador é mais universal que uma distribuição .exe só para Windows.

Multiplataforma de graça. A mesma página funciona no Windows, macOS, Linux e ChromeOS sem builds por plataforma. Um testador de navegador é entregue uma única vez.

Auditável em 30 segundos. A atividade de rede e o armazenamento de uma página web podem ser inspecionados com o DevTools do navegador por qualquer usuário, a qualquer hora. A atividade de rede de um app de desktop exige tcpdump, Wireshark ou lsof e permissões de root. A história da auditoria importa.

“Ao longo de anos de trabalho com diagnóstico de hardware em periféricos de PC e controles de videogame, os testadores de navegador detectaram cerca de dois terços das falhas que um utilitário de diagnóstico de desktop nunca teria revelado. O navegador lê o que o controle está fisicamente relatando, o que é uma camada de verdade diferente da que qualquer driver baseado em instalador expõe.”

Taimoor Bamazai, fundador, Elites Algorithm Limited

Quais são as limitações conhecidas da JoyCheck?

Lista honesta, o que a JoyCheck não faz:

• Sem acesso HID bruto. Ler o descritor USB HID bruto exigiria WebHID, uma especificação separada do W3C com suporte de navegador menos consistente (só Chrome e Edge, hoje).

• Controles anteriores à API Gamepad. Controles somente DirectInput anteriores à existência do XInput não aparecem no navegador. Eles precisariam de WebHID mais uma camada de tradução.

• O suporte a vibração varia por navegador. O Firefox fica atrás do Chrome no vibrationActuator; o Safari tem suporte limitado. A JoyCheck relata a limitação de forma clara.

• A pressão do gatilho em controles Xbox depende da camada de driver. Alguns pareamentos por Bluetooth relatam gatilhos binários (só ligado/desligado, sem intervalo analógico). Uma conexão USB com fio geralmente resolve isso.

Para caminhos de diagnóstico específicos de plataforma além do que o navegador consegue ver, o guia dedicado cobre padrões de falha que precisam de intervenção no lado do hardware.

Para guias de diagnóstico específicos de cada controle que usam essa mesma camada de leitura no navegador, o guia de pareamento do Switch Pro Controller, o guia de calibração do DualSense e o guia de calibração do controle de PS4 cobrem peculiaridades de pareamento específicas de plataforma que a API Gamepad sozinha não consegue resolver.

Observações sobre a taxa de consulta da JoyCheck (medido em 2026-05)

Os navegadores limitam a leitura da API Gamepad ao ritmo do requestAnimationFrame. Em nossa análise, medimos os mesmos controles sob condições de display idênticas. Todas as leituras: sessão nova do Chrome 120, conexão USB salvo indicação em contrário, janela deslizante de 5 segundos.

Medido pelo amostrador interno da JoyCheck no navegador. Displays de 144 Hz elevam o limite proporcionalmente; as leituras foram normalizadas para uma linha de base de 60 Hz para comparação entre navegadores.