MKT Code

Um Prefácio Necessário

Antes de começar, preciso ser transparente: este artigo não é sobre desenvolvimento web. A MKTCode nasce do código, das APIs, dos componentes Vue e das boas práticas de engenharia. Mas hoje vou falar sobre algo completamente diferente.

No entanto, acho que vale a pena compartilhar essa jornada.

Por quê? Porque desenvolvedor também é solucionador de problemas (conserta minha impressora?). E esta é a história de como eu me recuso a aceitar que "não funciona" como resposta final.

Ato 1: O Dual Boot Miserável

Há anos eu vivia em um dual boot miserável.

Sexta à noite: Vou desenvolver no Windows, tá bom
Sábado de manhã: Por que o npm não instala?
Sábado à tarde: Vou para o Linux
Domingo: Por que meu mouse "não funciona" no Linux?
Segunda: De volta ao Windows

Esse ciclo se repetiu muitas vezes.

Até que no fim de 2024 eu tomei uma decisão que mudou tudo: 100% Fedora. Sem volta.

Por que Fedora?

Se você nunca trabalhou com Linux para desenvolvimento, deixe-me explicar por quê Fedora é especial:

Está na Fronteira das Novidades

Fedora 43 vem com Kernel 6.18, PipeWire, GNOME 49, Wayland como padrão
Isso significa você está sempre um passo à frente
Para desenvolvimento é perfeito — você testa as novas tecnologias antes de virarem standard

Escolha de Interface

KDE Plasma: Para quem vem do Windows e sente falta daquele workflow
GNOME: Para quem prefere algo mais limpo, similar ao macOS, iOS e Android
Ambas rodam como manteiga no Fedora

Comunidade de Desenvolvimento

Fedora é basicamente "Red Hat em beta testing"
A comunidade é focada em desenvolvedores e usuários casuais
Problemas são resolvidos RÁPIDO

Eu escolhi GNOME + Wayland porque queria testar o futuro. E foi a melhor decisão.

Ato 2: O Problema que Ninguém Resolveu

Então chega o meu Redragon Cerberus M703.

Bonito, confortável, e com botões laterais.

No Windows? Funcionava perfeitamente. Eu configurei para controlar o volume com os botões. Era perfeito.

No Fedora 43? Não funcionava.

Por que isso importa?

Porque eu passo praticamente todo o dia com fone, ouvindo:

Música (Spotify)
Conteúdo (YouTube)
Chamadas de voz (Discord — sim, fico conectado em uma sala o dia inteiro)

E eu não quero ter que largar o mouse, achar o teclado, e apertar a tecla de volume.

Eu quero apenas clicar o botão do mouse. Como no Windows.

A Tentativa Óbvia: Perguntar ao Fabricante

A resposta veio rápida:

"Desculpe, não temos suporte para Linux."

Fim da conversa.

O Passo Desesperado: Procurar na Comunidade

Googlar "Redragon M703 Linux" retorna... basicamente nada.

Há plugins, drivers, soluções, fóruns... mas nenhuma especificamente para meu mouse em meu hardware.

Eu encontrei:

Xbindkeys (não funciona em Wayland)
Remappers genéricos (precisam dos botões como teclas, que não era meu caso)
Soluções que requeriam recompilar o kernel (extremo demais)

Tudo falhava.

Então eu decidi fazer diferente. Em vez de procurar uma solução pronta, eu investigaria como meu mouse se comporta em meu hardware, do zero.

Ato 3: A Investigação

Passo 1: Confirmar o Hardware

A primeira coisa que fiz foi simples:

lsusb | grep -i mouse

Resultado:

Bus 003 Device 003: ID 258a:1007 SINOWEALTH Game Mouse

OK. Linux viu o mouse. Mas por que os botões não funcionam?

Aqui é onde a maioria das pessoas desiste.

Aqui é onde eu comecei.

Passo 2: Testando /dev/input/eventX

O Linux tem um conceito confuso para quem vem do Windows: onde estão meus periféricos?

Tudo aparece em arquivos. Periféricos são arquivos.

Sob /dev/input/eventX estão seus devices de entrada.

Comecei a testar cada um:

sudo evtest

Testei event16 (SINOWEALTH Game Mouse): Nada
Testei event22 (SINOWEALTH Game Mouse Keyboard): Nada
Testei event15, event17, event18... Nada

Passo 3: Investigando /dev/hidraw

Depois testei com dados brutos:

for i in {0..9}; do
    echo "=== /dev/hidraw$i ==="
    cat /sys/class/hidraw/hidraw$i/device/name 2>/dev/null || echo "N/A"
done

E comecei a monitorar cada um com hexdump:

sudo hexdump -C /dev/hidraw6

E então... algo inesperado aconteceu.

Ato 4: O Plot Twist

Os botões não estavam no device do SINOWEALTH.

Estavam em: HDA ATI HDMI HDMI/DP,pcm=7

Sim. Um device de áudio HDMI.

Por quê?

Ninguém sabe ao certo. Provavelmente:

Firmware do mouse mal programado
Chip genérico roteando eventos para o barramento errado
Problema de enumeração USB no kernel com meu hardware específico

O importante era: eu encontrei onde estavam.

E não é porque o fabricante sabia disso. É porque eu investiguei metodicamente até encontrar.

Ato 5: O Avanço

Com o hexdump rodando em /dev/hidraw6, pressionar os botões revelou:

Botão Frontal (Volume +):
  Padrão: 02 40 00 00 ... 02 00 00 00
Botão Traseiro (Volume -):
Padrão: 02 80 00 00 ... 02 00 00 00

Agora eu tinha exatamente o que procurava.

Números mágicos. Bytes que significavam "o usuário pressionou o botão lateral".

Ato 6: A Solução

Aqui é onde a mágica acontece.

Criei um script Python que:

Monitora /dev/hidraw6 esperando por esses padrões
Detecta quando os botões são pressionados
Emite teclas virtuais de volume usando a biblioteca evdev
GNOME captura essas teclas e mostra seu OSD nativo de volume

#!/usr/bin/env python3
from evdev import UInput, ecodes as e
import time
HIDRAW_FILE = "/dev/hidraw6"
BTN_UP = b'\x02\x40'
BTN_DOWN = b'\x02\x80'
BTN_REL = b'\x02\x00'
ui = UInput({e.EV_KEY: [e.KEY_VOLUMEUP, e.KEY_VOLUMEDOWN]},
name="virtual-volume-keys",
bustype=e.BUS_VIRTUAL)
with open(HIDRAW_FILE, "rb") as f:
buffer = b''
last = 0
debounce = 0.15
while True:
    chunk = f.read(8)
    if not chunk:
        continue

    buffer += chunk
    now = time.time()

    # Detecta botão de aumentar volume
    if BTN_UP in buffer and BTN_REL in buffer:
        i1 = buffer.find(BTN_UP)
        i_rel = buffer.find(BTN_REL, i1)
        if i_rel &gt; i1 and (now - last) &gt; debounce:
            print(&quot;Volume +&quot;)
            ui.write(e.EV_KEY, e.KEY_VOLUMEUP, 1)
            ui.write(e.EV_KEY, e.KEY_VOLUMEUP, 0)
            ui.syn()
            last = now
            buffer = buffer[i_rel+2:]

    # Detecta botão de diminuir volume
    if BTN_DOWN in buffer and BTN_REL in buffer:
        i2 = buffer.find(BTN_DOWN)
        i_rel = buffer.find(BTN_REL, i2)
        if i_rel &gt; i2 and (now - last) &gt; debounce:
            print(&quot;Volume -&quot;)
            ui.write(e.EV_KEY, e.KEY_VOLUMEDOWN, 1)
            ui.write(e.EV_KEY, e.KEY_VOLUMEDOWN, 0)
            ui.syn()
            last = now
            buffer = buffer[i_rel+2:]

    if len(buffer) &gt; 100:
        buffer = buffer[-20:]

Pronto. Funcionava.

Os botões do meu mouse agora funcionam exatamente como no Windows. Melhor ainda: o OSD do GNOME aparece automaticamente.

Ato 7: Automação com systemd

Mas um script que você executa manualmente toda vez é inútil.

Configurei um systemd user service:

[Unit]
Description=SINOWEALTH Mouse Volume Control
After=graphical-session-started.target
PartOf=graphical-session.target
[Service]
Type=simple
ExecStart=%h/bin/sinowealth-volume-mapper.py
Restart=on-failure
RestartSec=5s
[Install]
WantedBy=graphical-session.target

Agora, sempre que faço login no GNOME, o serviço inicia automaticamente.

Meu mouse funciona. E eu não preciso fazer nada.

Por Que Estou Contando Isso?

Porque isto não é sobre remapear botões de mouse.

É sobre recusar aceitar limitações arbitrárias.

É sobre investigar profundamente em vez de desistir.

É sobre usar as ferramentas disponíveis de forma criativa.

Como desenvolvedores, isso é o que fazemos todo dia:

Uma framework tem uma limitação? Investigamos
Uma API não documenta bem um comportamento? Debugamos
Algo "não funciona"? Procuramos por quê

Eu levei essa filosofia do desenvolvimento web para um problema de hardware. E funcionou.

A Lição Maior: Por Que Distros Linux São Especiais

Deixe-me ser claro: você NÃO pode fazer isso no Windows.

Windows é uma caixa preta. Você não pode inspecionar como dispositivos se comportam a nível de bytes.

Mas no Linux, você pode:

Ver todos os devices em /dev/
Ler dados brutos com hexdump
Criar dispositivos virtuais com evdev
Integrar tudo com o sistema com systemd
Entender como tudo funciona

Isso é liberdade de verdade.

Por isso Fedora é perfeito para desenvolvimento:

Você não está apenas usando ferramentas
Você entende como as ferramentas funcionam
Você pode customizar tudo para suas necessidades

Bônus: Easy Effects e Dinâmica de Áudio

Já que mencionei — meu setup de áudio é basicamente ciência.

Uso Easy Effects para:

Spotify em 30% de volume no app
Mas com 100% de ganho no Easy Effects
Se no Discord alguém fala, o ganho do Spotify diminui

É dinâmico. Automático. Perfeito.

E agora, com os botões do mouse, eu controlo tudo isso de forma fluida.

Conclusão

Meu Fedora agora é perfeito.

Não por causa do fabricante. Não por causa de drivers oficiais.

Mas porque eu investigui, descobri, debugei e consertei.

E você pode fazer o mesmo.

Se você está considerando migrar para Linux, mas tem uma "lista de coisas que não funcionam":

Investigue.

Metade da lista provavelmente tem solução. Você só precisa escavar fundo o suficiente.

Bem-vindo ao Linux.