← Back · sub-plan of the NextBSD graphics plan, which covers the shipped amd64 stack (bochs, vboxvideo, Intel/AMD/Radeon, NVIDIA)

NextBSD arm64 KMS: six routes to /dev/dri/card0 in an ARM virtual machine

The amd64 graphics stack is done — BochsGraphics and VBoxGraphics ship, Intel and AMD bind on real hardware. arm64 has nothing, and neither does anyone else: two independent research sweeps of the FreeBSD mailing lists, Bugzilla, Phabricator, forums and GitHub found zero reports of /dev/dri in any arm64 FreeBSD VM, ever. This page lays out every route to changing that, with honest costs, so the choice can be made from evidence rather than from my summary of it.

2026-08-16. Written after a 3-agent research sweep (upstream drm-kmod virtio enablement; the ravynsoft fork; arm64 KMS state of the art). Citations to Linux v6.12/v6.16 drivers/gpu/drm, freebsd/drm-kmod 6.12-lts, freebsd/freebsd-src main and releng/15.1, FreeBSD Phabricator, Bugzilla, and QEMU/UTM/EDK2 sources. Two claims made earlier in this project are corrected below.

1. What is already measured

Facts, not plans. Each was verified directly rather than inferred.

2. The decisions to make

Everything below this section is evidence. These are the calls that evidence does not make for you — each one changes what gets built next. Marked blocking where work cannot start until it is answered.

D1 — Is software-rendered, fixed-resolution KMS acceptable on arm64? blocking

This single answer picks the whole near-term route.

• Yes → Option B. Weeks, no licence cost, works on every UEFI arm64 VM, Wayland and Xorg both run. No 3D, and resizing the VM window will not resize the guest.
• No — dynamic resolution and/or 3D are required → Option E. Months, three prerequisites before the driver is even reached, and the one previous attempt died at drm_dev_alloc().

These are not mutually exclusive in the long run — B is a stepping stone that E does not invalidate — but they compete for the next block of effort.

D2 — Is GPL-2.0-only code acceptable inside NextBSD? blocking for C and E

Everything vendored so far is GPL-2.0-or-later, and graphics/README.md states that as an invariant. drm_gem_shmem_helper.c, simpledrm.c and the whole sysfb/ family are GPL-2.0-only.

• Not acceptable → Option C is out entirely, Option E needs a clean-room shmem replacement, Option B is unaffected (it is written, not imported).
• Acceptable → C becomes viable and E gets materially cheaper.

Worth deciding deliberately rather than by accident: the stated long-term direction for this code is migration toward FreeBSD base, and that is exactly the conflict evadot raised on PR #119. A decision here should also either amend or reaffirm the README invariant.

D3 — Take the free interim unblock? independent, recommended

Option D costs nothing and is orthogonal to everything else: hint.virtio_pci.1.disabled="1" keeps efifb (which has vd_fb_mmap) instead of letting vtgpu displace it, giving working X11-on-llvmpipe in UTM today. The only argument against is that it may mask the problem a real driver should solve.

D4 — Which GEM backing for Option B? only if D1 = yes

Decide before writing, because it is hard to change later and one choice silently breaks Wayland:

• TTM system-domain GEM — recommended. drm-kmod already compiles ttm/ and drm_gem_ttm_helper.c; adds no new code.
• drm_gem_vram_helper — already built and shipping, but a VRAM pool over the EFI aperture is exactly one screen's worth: fine for Xorg modesetting, fatal for Wayland compositors that want two or more buffers.
• Bespoke ~200-line GEM — most control, most to maintain.

D5 — Does arm64 ship RadeonGraphics? low stakes

It builds and resolves cleanly on aarch64, but only matters for a discrete AMD card in a physical PCIe slot — never in a VM. Ship it (costs build time, serves ARM server hardware) or drop it (keeps the arm64 package to what VMs use). Currently shipped in PR #33.

D6 — What to do about the upstream amdgpu/aarch64 defect? outward-facing

drm-kmod's DRM_AMD_DC_FP gating produces an amdgpu.ko that builds clean and cannot load on aarch64, and nothing upstream checks for it. Options: report it upstream, fix it locally and carry a patch, or leave it and keep the guard in PR #33. Reporting is a project-representation decision, so it is being left alone pending a call.

D7 — Confirm the two blocking unknowns first? cheap, high information

• The arm64 kldload hang reported against drm-kmod 6.12 (dsl@ and evadot, Jan 2026). If it is a drm.ko core path rather than amdgpu-specific, every option here is blocked until it is understood. Testable now by loading our arm64 IOGraphics.kext in a VM.
• The Fusion PCI ID on Apple Silicon — one lspci -nn in an ARM guest decides whether Option F is addressable at all.

Both are hours of work and could invalidate weeks of it.

3. Where the work belongs: three layers

drm-kmod is FreeBSD's out-of-tree port of Linux's DRM subsystem. Driver source is copied from Linux and patched as little as possible; branches track Linux LTS releases (5.4-lts … 6.12-lts); FreeBSD Makefiles replace Kbuild. The Linux kernel API those files call is not in drm-kmod — it comes from LinuxKPI, which lives in FreeBSD base at sys/compat/linuxkpi. The project's stated preference is to add to LinuxKPI rather than patch drivers, so a fix is not applied twice.

So any missing piece can live in one of three places, and choosing wrongly means either carrying a patch forever or waiting on someone else:

Everything shipped so far is layer 3. graphics/drm_extra_helpers now carries four files that drm-kmod either does not ship or ships and never compiles:

drm_simple_kms_helper.c      not shipped by drm-kmod
drm_gem_vram_helper.c        not shipped by drm-kmod
drm_gem_atomic_helper.c      header is a 15-line stub; zero shadow-plane code
drm_format_helper.c          IN drm-kmod's tree, EXPORT_SYMBOLs intact,
                             named by no Makefile anywhere — dead code upstream

That last one is worth remembering when estimating any option below: a file being present in drm-kmod does not mean it is built, and a driver building does not mean it loads. Both traps have already cost this project a CI cycle each.

4. The licensing line — GPL-2.0-only vs or-later

This is a genuine decision input, and it is not the one stated earlier in this project. There is no maintainer edict against any specific file. What exists is a licence boundary that our own repo already promises to respect — graphics/README.md states “Sources are GPL-2.0-or-later, as is the rest of the vendored Linux DRM code.”

5. The six options

efifb = (struct efi_fb *)preload_search_info(preload_kmdp,
    MODINFO_METADATA | MODINFOMD_EFI_FB);
info->fb_stride = efifb->fb_stride * (info->fb_bpp / NBBY);
info->fb_pbase  = efifb->fb_addr;

6. Side-by-side comparison

* Option A's mode-setting works, but is moot given the boot-time blackout.

7. Prior art, assessed

8. Corrections to earlier claims

9. Other hypervisors: Hyper-V and Xen

Both have real DRM drivers upstream; neither is in drm-kmod, and neither was in this plan's original six options. Verified against Linux v6.12.

Hyper-V — drivers/gpu/drm/hyperv/ cheapest follow-on

Five files, in Linux since 5.14. A proper KMS driver for Hyper-V synthetic video, and critically it is shmem-backed, not VRAM:

#include <drm/drm_gem_shmem_helper.h>
DRM_GEM_SHMEM_DRIVER_OPS,
drm_fbdev_shmem_setup(dev, 0);

That places it on the same side of the line as virtio-gpu: it would not hit the device-memory defect (nextbsd-kernel#71) that stops every VRAM-backed driver, and it needs the same prerequisite — drm_gem_shmem_helper, the 782-line GPL-2.0-only file drm-kmod omits.

Why it is the cheapest follow-on: it shares virtio-gpu's single largest cost, so once that helper exists Hyper-V is mostly the driver itself. And unlike virtio, the transport is not starting from zero — FreeBSD ships Hyper-V support in base (hv_vmbus and friends), where LinuxKPI has no virtio bus at all.

Xen / Citrix — drivers/gpu/drm/xen/ not recommended

Fourteen files: a paravirtual DRM frontend over Xen's display protocol, with its own event channels (xen_drm_front_evtchnl.c), config layer, and a bespoke GEM implementation (xen_drm_front_gem.c).

The graphics driver is the small part of this job. It sits on Xen guest infrastructure — grant tables, xenbus — which is an entire KPI surface that does not exist, and which nothing else we want would reuse. Citrix Hypervisor guests can in any case use the standard emulated devices, so this buys little that is not already covered.

10. Driver candidate survey — what the helper work unlocks

Recorded for later consideration, not proposed now. The question this answers: having built the VRAM/KMS helper layer for bochs and vboxvideo, which other upstream drivers become cheap?

What this changes about the shmem helper

It is not virtio-gpu's private cost. One prerequisite gates six drivers — virtio-gpu, hyperv, ast, mgag200, cirrus and simpledrm — including the BMC driver that matters on real arm64 server hardware. That is a materially stronger argument for paying it than “virtio-gpu needs it”.

qxl: cheap, with one caution

qxl needs no new helper layer at all. The caution: drm-kmod issue #62 records someone's qxl attempt panicking inside ttm_bo_vm_fault. Now that the device-memory defect is understood (nextbsd-kernel#71), that reads like the same bug — qxl has VRAM and would need the same vm_phys_fictitious_reg_range() registration. Suggestive, not proven.

Not in this category: SoC display controllers

Raspberry Pi (vc4), Rockchip, Allwinner and friends are a different problem, and none of the helper work applies. vc4's Kconfig alone:

depends on ARCH_BCM2835
depends on RASPBERRYPI_FIRMWARE      # VideoCore firmware mailbox
depends on SND && SND_SOC            # ALSA, for HDMI audio
depends on COMMON_CLK                # Linux clock framework
select DRM_GEM_DMA_HELPER            # CMA -- a third backing type
select DRM_DISPLAY_HDMI_STATE_HELPER

659 KB, needing a CMA GEM helper, the common clock framework, device-tree attachment, an ALSA/SoC binding and a firmware mailbox — none of which exists here. The only working precedent for DRM on FreeBSD/arm64 is bsd-sbc-drm (jsm@), whose Rockchip drivers are exactly this shape. If SBCs ever become a target, that is a separate track with its own prerequisites and should be scoped as one.

11. Unconfirmed — check before committing effort

• Whether the arm64 kldload hang reported against drm-kmod 6.12 (dsl@ and evadot, Jan 2026) is amdgpu-specific or touches drm.ko core paths. This one matters for Option B — if it is a core path, every option here is blocked until it is understood.
• The numeric PCI ID VMware Fusion presents on Apple Silicon. 15ad:0406 is a strong inference from the Kconfig and Rusin's commit, but no lspci -nn dump was found. Decides whether Option F is even addressable.
• Whether Apple's VZVirtioGraphicsDeviceConfiguration exposes virtio-gpu over PCI or MMIO, and whether FreeBSD arm64 boots under AVF with graphics at all.
• bsd-sbc-drm/drm-subtree's modules/Makefile internals — not read. It is the one place someone else has solved “build a DRM kmod for aarch64 against drm-kmod”.

12. Proposed per-arch target set

Reflecting the stated preference that arm64 carry only what an ARM VM can actually use, rather than everything that happens to compile.

Sub-plan of the NextBSD graphics plan. Written 2026-08-16 from a three-agent research sweep; every factual claim above was checked against a primary source (repository file, commit, review, mailing-list post or CI log) rather than inferred, and the items that could not be confirmed are listed in §8 rather than smoothed over. Where this page contradicts something said earlier in the project, §7 says so explicitly.