[Proposal] Linux framebuffer support for embedded devices

[maikebing]

Hi Aprillz,

We have been experimenting with MewUI as the UI stack for a small Linux embedded badge / appliance device, and we wanted to start a discussion about first-class Linux framebuffer support for embedded targets.

Our use case

• Single-screen device, no X11 / Wayland, rendering directly to /dev/fb0
• Touch input from evdev (/dev/input/event*)
• Tight memory / startup constraints
• NativeAOT / trimming friendliness is still important

Why we think this fits MewUI well

• MewUI already has a small-footprint, explicit, AOT-friendly architecture
• For embedded appliances, a code-first UI with low startup cost is very attractive
• A framebuffer target can extend the current Linux story beyond desktop X11 without requiring a full window system

What we have already prototyped in our fork

We built a working experimental port in our fork here:
https://github.com/maikebing/MewUI_fb

Current prototype scope:

• Aprillz.MewUI.Platform.Framebuffer
• Aprillz.MewUI.Backend.Framebuffer
• Direct rendering to /dev/fb0
• Touch input via evdev
• Basic options for touch calibration / axis swap / inversion / throttling
• Sample app running on our ARM Linux device

The goal is not to turn MewUI into a giant embedded stack. We are thinking about a narrow and practical target:

• one fullscreen surface
• one top-level window
• no window manager assumptions
• best-effort platform services for dialogs / clipboard
• touch-first interaction, but still compatible with existing pointer-based controls

Our current design direction

1. Keep it as an optional platform/backend pair

   • Platform.Framebuffer
   • Backend.Framebuffer
   • no impact on Win32 / X11 / macOS paths unless referenced

2. Preserve MewUI's existing mental model

   • keep Application, Window, render loop, and controls unchanged as much as possible
   • route framebuffer touch into the existing pointer/touch pipeline rather than inventing a separate control model

3. Keep the embedded scope intentionally limited

   • fullscreen only
   • no multi-window expectations
   • no dependency on X11 / Wayland / SDL
   • avoid introducing a large native dependency chain

4. Stay NativeAOT / trim conscious

   • source-generated interop where possible
   • avoid reflection-heavy additions
   • keep the new path pay-for-play

Our proposed incremental plan

Phase 1

• keep this as an experimental port discussion
• align on scope and non-goals
• reduce the patch so the core platform/backend is easier to review

Phase 2

• upstream only the minimal fullscreen framebuffer host + software framebuffer backend
• keep device-specific tuning and riskier parts out of the first PR

Phase 3

• follow up with:
  • touch input improvements
  • more tests
  • packaging/docs/sample for embedded Linux

A few implementation notes from our side

• We found that direct /dev/fb0 output is enough for our class of devices
• evdev touch works reasonably well for appliance-style UIs
• A small amount of touch-oriented behavior in controls, especially scrolling, makes a noticeable difference on real hardware
• We are trying to keep this path small rather than aiming for a general compositor or kiosk framework

If this direction is interesting to you, we are happy to:

• clean up the prototype further
• split it into smaller reviewable pieces
• prepare a minimal PR against the dev branch
• document clear non-goals so the maintenance burden stays bounded

Thanks. We think MewUI has a very nice shape for embedded appliance UIs, and we'd love to align with upstream rather than carrying a long-term fork.