As I understand it, with the DRM/KMS subsystems, if you are running either an X server or Wayland, then effectively the framebuffer is "evicted" viewtopic.php?t=342871#p2054195 from the display and will not show up.
If you are running a lite version with no X or Wayland running, this isn't the case.
Is there no way around this?
At the moment I am writing some UI stuff (mainly in C++) which uses the framebuffer for simple graphics display, since that works on all models of Pi running bookworm lite, and I want the software (in either armhf or aarch64 flavours) to continue to do that, but this means that if I am doing development on, say, a Pi5, I then use scp to copy the test image to a different machine which doesn't run a desktop.
I understand that at some point framebuffer support may/will disappear, but I do not want to replace perfectly adequately powered machines just so that I can run what is, in this context, an over-engineered GUI layer containing lots of features I don't really need.
Failing that, is there a lightweight way of rendering on a connected screen (either DSI or HDMI) that offers the same pixel-level access as the framebuffer without significantly bloating the code?
My UI is fairly simple, using the event interface for touch/mouse, tty for keyboard input (although it could use event for that, it would just be a wee bit more complex if there are multiple keyboards), and an X by Y pixel display of whatever bit-depth it happens to be (which is generally 16, but the original work is done on 32bpp and mapped down to 16bpp.
My output stuff is pretty solid, having basic graphics (point, line, circle, rectangle, fonts, images) capabilities and allows me to reduce work by supporting clipping (either inclusion or exclusion rectangle lists) and the like, and output is to a memory-based surface which is finally rendered by copying to the mapped framebuffer's space, so adapting it to a different output mechanism shouldn't be too difficult, should it?
If you are running a lite version with no X or Wayland running, this isn't the case.
Is there no way around this?
At the moment I am writing some UI stuff (mainly in C++) which uses the framebuffer for simple graphics display, since that works on all models of Pi running bookworm lite, and I want the software (in either armhf or aarch64 flavours) to continue to do that, but this means that if I am doing development on, say, a Pi5, I then use scp to copy the test image to a different machine which doesn't run a desktop.
I understand that at some point framebuffer support may/will disappear, but I do not want to replace perfectly adequately powered machines just so that I can run what is, in this context, an over-engineered GUI layer containing lots of features I don't really need.
Failing that, is there a lightweight way of rendering on a connected screen (either DSI or HDMI) that offers the same pixel-level access as the framebuffer without significantly bloating the code?
My UI is fairly simple, using the event interface for touch/mouse, tty for keyboard input (although it could use event for that, it would just be a wee bit more complex if there are multiple keyboards), and an X by Y pixel display of whatever bit-depth it happens to be (which is generally 16, but the original work is done on 32bpp and mapped down to 16bpp.
My output stuff is pretty solid, having basic graphics (point, line, circle, rectangle, fonts, images) capabilities and allows me to reduce work by supporting clipping (either inclusion or exclusion rectangle lists) and the like, and output is to a memory-based surface which is finally rendered by copying to the mapped framebuffer's space, so adapting it to a different output mechanism shouldn't be too difficult, should it?
Statistics: Posted by SteveSpencer — Tue Jul 23, 2024 5:29 pm