If one wants to use the software renderer to create a graphical shell for launching a collection of retro games and control the entire user experience from booting the computer, one could have a window backend for treating the framebuffer as a forced fullscreen window. Writing pixels to /dev/fb0 and getting mouse and keyboard input from /dev/input/event0.
The program then has to be launched from CLI mode when no conflicting compositor is running, or automatically from a boot script replacing the default X11/Wayland server. If the program can detect an X11 or Wayland server, those should be used instead when launching the normal way. One would not get tied up to a specific operating system, because the same program can simply run in full screen over a compositor on systems not having a direct framebuffer backend.
Implementing a Wayland backend is a higher priority, because most programs should allow other programs to run next to them.
If one wants to use the software renderer to create a graphical shell for launching a collection of retro games and control the entire user experience from booting the computer, one could have a window backend for treating the framebuffer as a forced fullscreen window. Writing pixels to /dev/fb0 and getting mouse and keyboard input from /dev/input/event0.
The program then has to be launched from CLI mode when no conflicting compositor is running, or automatically from a boot script replacing the default X11/Wayland server. If the program can detect an X11 or Wayland server, those should be used instead when launching the normal way. One would not get tied up to a specific operating system, because the same program can simply run in full screen over a compositor on systems not having a direct framebuffer backend.
Implementing a Wayland backend is a higher priority, because most programs should allow other programs to run next to them.