From button to pixel.
Choose a step to see responsibility, evidence, and typical failure. Use the arrow keys to move through the flow.
Physical input
Buttons, analog sticks and panel start with the hardware described by the correct profile.
- Responsibility
- Deliver signals and parameters compatible with the physical variant to the kernel.
- Evidence
- Model, DTB, hash, review and observation on the device.
- Typical failure
- Missing entry, incorrect panel, or different behavior between clones.
Kernel and display
Drivers transform the profile into devices available for user space.
- Responsibility
- Expose input, storage, audio, and a usable display session.
- Evidence
- Kernel logs, connector, mode, DRM master and first scanout observed.
- Typical failure
- The system starts, but there is no valid screen session or the panel remains black.
Runtime
The file system only grows as much as necessary to deliver the experience.
- Responsibility
- Assemble data, start services, and maintain reproducible dependencies.
- Evidence
- Rootfs inspected, services active and versions pinned.
- Typical failure
- Unavailable library, missing service or different image configuration.
Events and status
The loop reads events, moves focus, and updates only the necessary state.
- Responsibility
- Keep input, screens, and integrations within small, testable boundaries.
- Evidence
- Focus test, screen contract, limited resources and predictable return.
- Typical failure
- Lost focus, I/O blocking or business rule hidden in a visual component.
Composition
Texts, covers, icons and surfaces form the framework within the time budget.
- Responsibility
- Reuse textures, limit visible work, and display complete states.
- Evidence
- Frametime, limited cache, blank screen, verifiable loading and error.
- Typical failure
- Irregular frames, growing memory, or interface that doesn't explain its state.
Presentation
The frame is delivered to the DRM and finally needs to appear on the glass.
- Responsibility
- Display the frame in the mode and panel associated with the profile.
- Evidence
- Technical capture helps, but the final proof is visual in the hardware.
- Typical failure
- The process ends without error and still no image is visible.
The flow does not replace the physical test. It serves to locate the right question before changing the system.
Symptom is not diagnosis.
- 01Observe
Describe what happened without assigning a cause.
- 02Find
Find the last layer that produced reliable proof.
- 03Measure
Choose the smallest signal capable of separating the hypotheses.
- 04Validate
Repeat on the device and record scope, result and limit.
Deepen a part of the system.
Diagnosis
Start with the last reliable evidence and change one variable at a time.
Interface and rendering
Understand the boundaries between input, state, design and display.
Performance and FPS
Measure pace, cost, and stability before activating a fit.
C and shell
Use each language where its nature reduces risk and complexity.
Local AI and RAG
See when the search responds, when Gemma enters and where the system should decline.