Nice read. I wouldn’t have minded more technical details about the implementation and challenges, but that’s probably because I’ve had to write generic SVGA drivers to support generic graphics cards before. (I’m not clear on what was the more convenient alternative to VMs that the author ended up using, though?)<p>Side-bar but still on-topic: It <i>really</i> irks me to no end that Windows 3.x and Windows 95 could get a fairly hardware-agnostic (fallback) software-rendered GUI fully up and running and exposed to user space in the early 90s and even today Linux/BSD can’t manage that (even just in SVGA mode) without vendor specific drivers. Xfree86 and then Xorg with the fb driver were attempts at doing the same but I can attest they never achieved that same universality. I had hoped EFI fb could finally give us the same for modern PCs but the chances of open source efifb drivers <i>in userland</i> working on a chipset/implementation they haven’t been tested against are a real crapshoot.<p>I had “success” (compared to the status quo, not compared to the situation on Windows) writing X drivers that wrote to the kernel framebuffer but that broke when everything was rewritten or deprecated in order to support EFI. Even then, the support for listing supported modes and changing to them was very poor (which make sense given how little serious use the kernel frame buffer sees), never mind figuring out what modes intersected with those the display supported. Laptops with integrated plus discrete graphics cards (or desktop motherboards with the same) were also problematic for various reasons.