<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>Vitruvianos on slopistry</title>
    <link>https://blog.slopistry.com/tags/vitruvianos/</link>
    <description>Recent content in Vitruvianos on slopistry</description>
    <generator>Hugo</generator>
    <language>en-us</language>
    <lastBuildDate>Sat, 04 Apr 2026 00:00:00 +0000</lastBuildDate>
    <atom:link href="https://blog.slopistry.com/tags/vitruvianos/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>vitruvianos display pipeline: from pixels to screen</title>
      <link>https://blog.slopistry.com/posts/vitruvianos-display-pipeline-deep-dive/</link>
      <pubDate>Sat, 04 Apr 2026 00:00:00 +0000</pubDate>
      <guid>https://blog.slopistry.com/posts/vitruvianos-display-pipeline-deep-dive/</guid>
      <description>&lt;p&gt;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.&lt;/p&gt;&#xA;&lt;h2 id=&#34;the-beoshaiku-display-model&#34;&gt;the BeOS/Haiku display model&lt;/h2&gt;&#xA;&lt;p&gt;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.&lt;/p&gt;</description>
    </item>
    <item>
      <title>vitruvianos: from software blitting to gpu compositing</title>
      <link>https://blog.slopistry.com/posts/vitruvianos-gpu-compositing-progress/</link>
      <pubDate>Sat, 04 Apr 2026 00:00:00 +0000</pubDate>
      <guid>https://blog.slopistry.com/posts/vitruvianos-gpu-compositing-progress/</guid>
      <description>&lt;p&gt;The last few days have been a deep dive into V\OS&amp;rsquo;s graphics pipeline. What started as &amp;ldquo;make the DRM backend boot in QEMU&amp;rdquo; turned into building out per-window GPU compositing, fixing Haiku&amp;rsquo;s menu rendering, writing a gears demo, and learning more about virtio-gpu&amp;rsquo;s limitations than I ever wanted to know.&lt;/p&gt;&#xA;&lt;h2 id=&#34;where-we-started&#34;&gt;where we started&lt;/h2&gt;&#xA;&lt;p&gt;V\OS had a DRM display backend from x512&amp;rsquo;s Haiku work. It could put pixels on screen via dumb buffers and page flips. But there was no cursor, windows flickered when dragged, the GBM/EGL code had never been tested on a running system, and the whole thing only worked with &lt;code&gt;-vga std&lt;/code&gt; in QEMU.&lt;/p&gt;</description>
    </item>
    <item>
      <title>vitruvianos: building the os that beos promised</title>
      <link>https://blog.slopistry.com/posts/vitruvianos-building-the-human-centric-os/</link>
      <pubDate>Wed, 01 Apr 2026 00:00:00 +0000</pubDate>
      <guid>https://blog.slopistry.com/posts/vitruvianos-building-the-human-centric-os/</guid>
      <description>&lt;p&gt;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.&lt;/p&gt;</description>
    </item>
  </channel>
</rss>
