No one wants window management in the kernel, so yeah, the assumption is that there is one master that decides what buffer(s) are scanned out. That said, DRM is the only way to use the hardware compositors found on many mobile chips, which allow you to rotate, resize and blend together multiple buffers on the fly to produce the final display.

A minimal DRM example isn't much more, by the way:

https://github.com/yuq/gfx/blob/master/drm/main.c

And this does a lot more stuff that you want, like what connectors (think HDMI or LVDS internally) does my hardware have, which of those have displays connected, what modes are supported by those displays, and it can be very easily extended to do 3D rendering.

Beyond the HW planes, there is lots of stuff DRM enables that you simply can't do with /dev/fb but absolutely want, like true VSync synchronized rendering.

My somewhat equivalent code for working with double-buffered version of display code using DRM is about 200 lines of C. But that includes some abstraction and a lot of error checking/logging.

I'm not sure why you'd need to replicate anything complicated like wayland. You can use DRM API just like you'd use /dev/fb0, it just has more options/features.

As for cairo, obviously it's a heavier solution, but also more featureful, optimized and output neutral.

I guess the main question is can you simply overlay stuff on top of Linux console (presumably fbcon) with DRM? That is kinda the key thing here, and the examples I've seen have always just done full-screen stuff.

Show us the code. :)