A interface do rogpOS não começa no desenho de um botão. Ela começa no perfil correto do aparelho e termina quando o quadro realmente aparece na tela. Entre esses pontos, cada camada tem uma responsabilidade pequena e uma prova própria.
Do botão ao pixel
- Entrada física: o kernel recebe o estado do direcional, botões e analógicos descritos pelo perfil.
- Evento: SDL2 transforma a entrada em eventos consumidos pelo loop do launcher.
- Foco: a tela ativa decide qual componente recebe a ação. Navegação e regra de negócio permanecem separadas.
- Estado: o modelo atualiza somente o necessário para a tela corrente.
- Composição: componentes desenham texto, ícones, capas e superfícies usando o renderer compartilhado.
- Apresentação: SDL2 entrega o quadro ao driver KMSDRM; DRM e o perfil do painel levam esse quadro ao display.
As fronteiras que mantêm o launcher legível
- App: ciclo de vida, troca de telas e loop principal.
- Screens: composição e navegação de cada tela. Não devem executar processos ou possuir integrações de sistema.
- Components: elementos reutilizáveis, sem regras de negócio escondidas.
- Core: biblioteca, IA, configuração e outras integrações testáveis fora da tela.
- Boot e emulação: início do sistema e sessão de jogo em limites explícitos.
- UI: tokens, renderer, foco, ícones e primitivas compartilhadas.
O launcher gráfico é o launcher-v2, compilado como rogpos-shell. O launcher textual de recuperação é outro caminho e só deve aparecer quando o sistema entra deliberadamente nesse modo.
Quadro, estado e tempo
O loop precisa processar entrada, atualizar o estado e renderizar dentro do orçamento do quadro. Para 60 Hz, esse orçamento é cerca de 16,67 ms. Isso não significa redesenhar ou reler tudo a cada passagem. Índices, texturas e listas visíveis devem ser limitados, reutilizados ou atualizados quando a fonte muda.
KMSDRM não é a tela inteira
KMSDRM é o driver de vídeo do SDL2 para acesso direto ao subsistema DRM no Linux. A sessão precisa obter DRM master para configurar e desenhar no display. O dispositivo DRM escolhido também importa quando o sistema expõe mais de um.
Ainda assim, uma chamada bem-sucedida ou um encerramento limpo não prova que o painel mostrou o quadro. O teste completo inclui modo, conector, timings, polaridades, iluminação e observação física.
Boas práticas da interface
- foco visível e previsível;
- botão B como saída coerente;
- estados vazio, carregando e erro desenhados como parte do fluxo;
- componentes com API pequena, sem dezenas de flags;
- I/O e processos fora da camada visual;
- cache com limite conhecido e invalidação explícita;
- texto legível na resolução nativa de 640 × 480;
- animação curta, interrompível e removida com
prefers-reduced-motion.
Como provar uma alteração
Uma mudança de interface passa pela verificação de arquitetura, contrato visual, testes do launcher e inspeção do rootfs. Depois, precisa ser observada no aparelho: foco, entrada, primeiro quadro, retorno da sessão de jogo e ausência de regressão no caminho de recuperação.