This is a technical deep dive into how V\OS gets pixels from application code to your display. The display pipeline in V\OS inherits from Haiku (which inherits from BeOS) but adds Linux DRM/GBM integration, per-window compositing, and an optional GPU compositor. Understanding the layers helps explain why certain design decisions were made and where the system is heading.

the BeOS/Haiku display model

BeOS had an elegant display architecture. The app_server owned the entire display pipeline. Applications communicated with it via IPC ports (message queues). There was no X11, no Wayland, no separate compositor process. One server, one buffer, one path from application draw call to screen pixel.

I have been a BeOS fan for a long time. Watched it come and go, followed the community through Zeta and into Haiku, and always felt like there was something unfinished there. An OS that got the fundamentals right but never got its shot at the mainstream. I only recently started contributing to VitruvianOS (V\OS) but I am all in on it. It is an operating system built on the Linux kernel that brings the BeOS desktop experience to modern hardware, and I think it has a real chance at finishing what BeOS started.