ctrl-alt-delor's answer gives you a good overview of the general architecture. For a more hands-on approach, I give you an answer regarding "nothing but the linux kernel and programming in C".

I like writing to the frame-buffer directly every now and then. The frame-buffer device driver will do all the tedious close-to-the-hardware "how will this eventually end up on a screen" stuff for you. You can do so right away with a root shell:

echo -n -e '\x00\x00\xFF' > /dev/fb0 

It sets the very first (top left) pixel to red on my 32 bit framebuffer:

You can totally do so from within C by opening /dev/fb0 and write bytes. Memory mapping can become your friend. This does only work without an X server or in a virtual console. Press Ctrl+Alt+F1 to access it.

PS: Visualising random data like your mouse movement can also be fun:

cat /dev/input/mouse0 > /dev/fb0 

ctrl-alt-delor's answer gives you a good overview of the general architecture. For a more hands-on approach, I give you an answer regarding "nothing but the linux kernel and programming in C".

I like writing to the frame-buffer directly every now and then. The frame-buffer device driver will do all the tedious close-to-the-hardware "how will this eventually end up on a screen" stuff for you. You can do so right away with a root shell:

echo -n -e '\x00\x00\xFF' > /dev/fb0 

It sets the very first (top left) pixel to red on my 32 bit framebuffer:

You can totally do so from within C by opening /dev/fb0 and write bytes. Memory mapping can become your friend. This does only work without an X server or in a virtual console. Press Ctrl+Alt+F1 to access it.

PS: Visualising random data like your mouse movement can also be fun:

cat /dev/input/mouse0 > /dev/fb0 

PPS: Please also note that virtually any real-world desktop application wants more direct access to the hardware for some fancy stuff like hardware acceleration for drawing, 3D and video rendering. The simple frame-buffer device won't do any of this well.