Painting with framebuffer

on a Raspberry Pi

Since I learned that ther is such a thing called a framebuffer, which one can use to write pixels on the screen, I knew I had to try this out. I was always interested in seeing how I can draw arbitrary graphics on a screen purely by writing to memory, and this was it! This would simplify my tiny game console development project, if I ever finish it. So I started experimenting on old my Raspberry Pi 3, so that I can get my workflow on a normal screen figured out, before I move to a smaller OLED display or such.

I started with a Python script I took from Seena's blog and dumped data into /dev/fb0, and that worked, to a degree. The colours were all off and seemed like the values were overflowing / cycling? Also I was suprised to see pi user that comes default with the Raspberry Pi OS is by default part of the video group. The members of the video group have RW access to /dev/fb* as far as I have learned. Also, I am using an X11-less installation of Raspberry Pi OS.

Colours overflowing, maybe?

Then I tried to make the rust-framebuffer examples work, when I got over cross-compilation issues by using statically linked musl target, those programs also seemed to have colour issue. It was also one ordeal to run it, because I had no idea there is such a thing called a virtual terminal. One can trigger a process in it with openvt command; I am not entirely sure how this virtual terminal works, yet. Maybe something I will figure out in the future. But when I finally managed to run the Rust example, it was also broken in terms of colour. But on the bridge side, I was impressed by the cross compilation, even though it was a bit of work to figure it out.

The original bitmap file looks nothing like this

Then I ended up on this blog, where the person wrote really nicely how to use the Framebuffer in Raspberry Pi. Really helpful, and really comprehensive. Wish more technical blog posts were like this. But when I compiled the code and ran it, it also seemed to have some sort of colour issue. But funny enough, this time I didn't need any of that virtual terminal shenanigans. Maybe something to figure out as well for my future self.

It really shouldn't look like this

In between all of this, I tried using the fbi utility to load a pictures onto the framebuffer. And the colours there worked perfectly fine.

How it was supposed to look like

The fbi utility seemed to be working as expected

So, after an evening of trying to figure stuff out, going in between cross-compilation, Ubuntu machine and a Raspberry Pi, I am guessing some of these documentations, some library implementation & data format for /dev/fb0 framebuffer is out-of-date. Maybe something for future me.