The rogpOS interface doesn't start with drawing a button. It starts with the correct device profile and ends when the frame actually appears on the screen. Between these points, each layer has a small responsibility and proof of its own.
From button to pixel
- Physical input: the kernel receives the state of the directional pad, buttons and analog sticks described by the profile.
- Event: SDL2 transforms the input into events consumed by the launcher loop.
- Focus: the active screen decides which component receives the action. Navigation and business rules remain separate.
- State: the model updates only what is necessary for the current screen.
- Composition: Components draw text, icons, skins, and surfaces using the shared renderer.
- Presentation: SDL2 delivers the frame to the KMSDRM driver; DRM and panel profile bring this frame to the display.
The borders that keep the launcher readable
- App: life cycle, screen switching and main loop.
- Screens: composition and navigation of each screen. They must not run processes or have system integrations.
- Components: reusable elements, without hidden business rules.
- Core: off-screen testable library, AI, configuration, and other integrations.
- Boot and emulation: system start and game session at explicit limits.
- UI: tokens, renderer, focus, icons and shared primitives.
The graphical launcher is the launcher-v2, compiled as rogpos-shell. The recovery textual launcher is another way and should only appear when the system deliberately enters this mode.
Frame, state and time
The loop needs to process input, update state, and render within the frame budget. For 60 Hz, this budget is about 16.67 ms. This doesn't mean redesigning or rereading everything with each pass. Visible indexes, textures, and lists must be limited, reused, or updated when the source changes.
KMSDRM is not full screen
KMSDRM is the SDL2 video driver for direct access to the DRM subsystem on Linux. The session needs to get DRM master to configure and draw on the display. The chosen DRM device also matters when the system exposes more than one.
Still, a successful call or a clean close doesn't prove that the panel showed the picture. The complete test includes mode, connector, timings, polarities, lighting and physical observation.
Interface good practices
- visible and predictable focus;
- button B as coherent output;
- empty, loading and error states drawn as part of the flow;
- components with a small API, without dozens of flags;
- I/O and processes outside the visual layer;
- cache with known limit and explicit invalidation;
- readable text at native resolution of 640 × 480;
- short, interruptible, removed animation with
prefers-reduced-motion.
How to prove a change
An interface change goes through architecture verification, visual contract, launcher tests and rootfs inspection. Then, it needs to be observed on the device: focus, input, first frame, return from the game session and absence of regression on the recovery path.