nextbsd-research: nest the three graphics sub-plans under the graphics plan

The arm64 KMS options page and the two plans it produced were reachable only
from nextbsd-graphics-plan.html, so they did not appear in the research tree
at all. Nested them under the graphics plan entry, three levels deep, matching
the monorepo -> driver-delivery -> firmware-candidates -> kext-naming pattern:

  NextBSD graphics
    arm64 KMS - six routes to /dev/dri/card0     (decision record)
      virtio-gpu DRM - accelerated OpenGL        (execution plan, priority)
      Fallback graphics - KMS with no supported GPU  (scoping plan)

The nesting reflects how the work flowed: the arm64 question produced a
decision record, which produced two independent plans. Descriptions note that
neither outcome is arm64-only -- virtio-gpu serves amd64 VMs equally, and the
fallback driver is a hardware-coverage problem on every architecture.

Author: pkgdemon

nextbsd-research.html

@@ -220,6 +220,22 @@ <h2>NextBSD</h2>
   <li>
     <a href="nextbsd-graphics-plan.html?v=20260609">NextBSD graphics &mdash; virtual-GPU DRM kexts, an end-to-end CI test, and the NVIDIA/VirtualBox tracks <span class="pill pill-warn">Porting plan</span></a>
     <span class="desc">The drm-kmod &rarr; Intel/AMD/Radeon kexts autoload via the in-kernel matcher, but that path is untested end-to-end &mdash; qemu emulates no real GPU. Port a <em>virtual</em>-GPU DRM driver (bochs first &mdash; it binds qemu&rsquo;s default <code>-vga std</code> as a raw <code>IOPCIPrimaryMatch</code> node) to unlock KMS-in-VMs <em>and</em> the first true match&rarr;autoload&rarr;bind CI test. Scopes bochs/vboxvideo/virtio-gpu/vmwgfx, the shared blocker (drm-kmod&rsquo;s missing <code>drm_gem_vram</code>/<code>shmem</code> helpers &rarr; a <code>drm_extra_helpers.ko</code>), the repo split (unmodified <code>drm-kmod</code> fork + a <code>nextbsd-graphics</code> kext factory + a recipe-only NVIDIA-legacy repo), and a phased roadmap. From a 7-agent scope.</span>
+    <ul>
+      <li>
+        <a href="nextbsd-arm64-kms-options.html?v=20260816">arm64 KMS &mdash; six routes to <code>/dev/dri/card0</code> in an ARM virtual machine <span class="pill info">Decision record</span></a>
+        <span class="desc"><strong>The graphics plan's &ldquo;virtio-gpu and vmwgfx are larger follow-ons&rdquo; framing held for amd64 &mdash; bochs and vboxvideo both ship now &mdash; but not for arm64, where neither binds anything an ARM VM presents.</strong> Two independent research sweeps found <strong>zero reports of <code>/dev/dri</code> in any arm64 FreeBSD VM, ever</strong>. Six routes costed with evidence: bochs on arm64 (ruled out &mdash; <code>ArmVirtQemu</code> ships no <code>QemuVideoDxe</code>, so the screen is black from power-on until <code>kldload</code>), a native firmware-framebuffer driver, porting Linux's <code>simpledrm</code>, D55012's scfb path, virtio-gpu, and vmwgfx. Also settles that the DRM core <em>does</em> build on aarch64 (PR&nbsp;#33) and documents an upstream defect found doing it: drm-kmod gates <code>DRM_AMD_DC_FP</code> to amd64 while leaving the references compiled, so its <code>amdgpu.ko</code> builds clean and cannot <code>kldload</code> on aarch64. Corrects two claims made earlier in the surrounding work.</span>
+        <ul>
+          <li>
+            <a href="nextbsd-virtio-gpu-plan.html?v=20260816">virtio-gpu DRM &mdash; accelerated OpenGL in virtual machines <span class="pill pill-warn">Execution plan</span></a>
+            <span class="desc"><strong>The chosen route, and the priority work &mdash; the real driver, not a framebuffer stand-in:</strong> <code>/dev/dri/card0</code> <em>and</em> a render node, dynamic resolution, and hardware-accelerated OpenGL through Mesa's virgl. Serves amd64 VMs as much as arm64. Two findings make it far smaller than first costed: <strong>the LinuxKPI virtio shim needs no FreeBSD base change</strong> (FreeBSD's public <code>virtqueue_notify()</code> already <em>is</em> Linux's <code>virtqueue_kick()</code>, suppression check included, and virtio-gpu never calls the un-split form &mdash; so the two <code>static</code> helpers that stalled D32371 for five years are simply not needed), and <strong>the entire userland half already ships</strong> (<code>graphics/mesa-dri</code> builds the virgl Gallium driver unconditionally on every arch; libdrm installs <code>virtgpu_drm.h</code>). Includes an explicit &sect;4 comparison of <em>extending base's <code>virtio_gpu(4)</code> vs building on drm-kmod vs a native BSD driver on drm-kmod's core</em> &mdash; decided on uapi fidelity, since Mesa's virgl talks an ABI we do not control. Plus the shim symbol map, the depth-1 <code>MODULE_DEPEND</code> constraint, a six-phase plan, and three risks that would each pass a smoke test while being wrong (including an <code>sglist</code> coalescing trap that would silently give the device write access to our command buffer).</span>
+          </li>
+          <li>
+            <a href="nextbsd-fallback-graphics-plan.html?v=20260816">Fallback graphics &mdash; KMS on machines with no supported GPU <span class="pill info">Scoping plan</span></a>
+            <span class="desc"><strong>Not an arm64 problem &mdash; a hardware-coverage one.</strong> A machine whose GPU is in none of our match tables (364 Intel ids, 308 amdgpu, 550 radeon) gets a text console and nothing else: no <code>card0</code>, so no Wayland and no Xorg <code>modesetting</code>. Linux solved this with <strong>SimpleDRM</strong>, which binds the framebuffer the <em>firmware</em> already set up. The surprising part is the trigger: Linux does <em>not</em> gate the load on &ldquo;has anything else claimed the display?&rdquo; &mdash; it loads unconditionally and lets the real driver <strong>evict</strong> it, so there is never a window without KMS. Four candidate triggers costed against our IOKit matcher, whose match-form support was read directly from <code>iokit_catalogue.c</code>: only the vendor:device form exists, but the scan already reads <code>pci_get_class()</code>, already tests <code>PCIC_DISPLAY</code>, already carries <code>probe_score</code>, and already answers &ldquo;does this display device have DRM bound?&rdquo; via <code>iocat_drmn_bound()</code>. Also: this is <strong>not EFI-only</strong> &mdash; FreeBSD's <code>efifb</code>/<code>vbefb</code>/<code>ofwfb</code>/<code>simplefb</code> map one-to-one onto Linux's <code>efidrm</code>/<code>vesadrm</code>/<code>ofdrm</code>/<code>simpledrm</code>, so legacy BIOS is a front-end branch, not a second driver.</span>
+          </li>
+        </ul>
+      </li>
+    </ul>
   </li>
   <li>
     <a href="nextbsd-nvidia-kext-porting-plan.html?v=20260711">NextBSD graphics &mdash; porting the NVIDIA driver as per-branch co-existing kexts <span class="pill pill-warn">Porting plan</span></a>