Hardware Support

Drivers on NextBSD arrive as kernel extensions — .kext bundles managed with kextload, kextunload and kextstat, matched to hardware by the in-kernel IOKit registry rather than by devd rules.

There is no .ko module tree to fall back on: /boot/kernel holds only the kernel itself, so anything not compiled in must arrive as a kext. See Filesystem Layout for why.

What ships per architecture

Both architectures package kexts, in NextBSD-kernel-extensions:

	amd64	arm64
Kexts	17	7
Graphics	virtio-gpu, Bochs, VirtualBox, Intel, AMD, Radeon, NVIDIA	virtio-gpu
Network	Intel wireless + Ethernet	—

Graphics (KMS)

Kernel mode-setting drivers, built from Linux 6.12 DRM sources layered on drm-kmod.

Virtual GPUs

The best-supported path today, because it is what CI boot-tests on every change.

Kext	Binds	amd64	arm64
VirtIOGraphics.kext	virtio-gpu — QEMU, KVM, UTM	✓	✓
BochsGraphics.kext	QEMU / Bochs VGA	✓	—
VBoxGraphics.kext	VirtualBox (80ee:beef)	✓	—

BochsGraphics is the reference driver: CI boots a VM and verifies it binds. VirtIOGraphics is the one that matters on Apple Silicon, since virtio-gpu is what UTM gives an arm64 guest.

Most people run NextBSD in a VM, and one of these is what puts a console on the screen when they do.

Physical GPUs

All amd64 only.

Kext	Hardware
IntelGraphics.kext	Intel integrated (i915)
AMDGraphics.kext	AMD (amdgpu)
RadeonGraphics.kext	older AMD/ATI (radeon)
NVIDIAGraphics595.kext, NVIDIACore595.kext, NVIDIAModeset595.kext	NVIDIA, 595 series

Shared support kexts

The small virtual-GPU drivers rest on a helper layer that drm-kmod does not ship, vendored and built as its own kexts so two drivers cannot collide on exported symbols:

These ship on both architectures.

Kext	Provides
IOGraphics.kext	The DRM core
IOGraphicsExtras.kext	Simple-KMS, VRAM GEM and shadow-plane helpers
IOGraphicsShmem.kext	shmem GEM plus fbdev-over-shmem
TTM.kext	The TTM memory manager
DMABuf.kext	Buffer sharing between drivers
LinuxVirtIO.kext	The LinuxKPI virtio shim — FreeBSD's LinuxKPI has no virtio at all

As the graphics work puts it: the cost of a small virtual-GPU driver is the helper layer, not the driver.

Networking

amd64 only.

Kext	Hardware
IntelWiFi.kext	Intel wireless (iwlwifi)
IntelEthernet.kext	Intel Ethernet (em / e1000)

Both have their IOKit matching tables generated directly from the driver source at build time — the PCI ID list the in-kernel matcher reads is derived from drv.c and e1000_hw.h rather than hand-maintained, so it cannot drift from the driver it binds.

Beyond these, everything the FreeBSD-derived kernel supports natively still works; kexts are for drivers that are loadable rather than compiled in.

Bluetooth

Not supported yet, and nothing to work around. There is no Bluetooth in the kernel and no daemon in userland — pairing a device is not currently possible.

It is being designed from scratch rather than ported. launchd, configd and mDNSResponder all came from open Darwin source; Apple's Bluetooth stack is blued behind the closed IOBluetooth framework, so there is nothing to vendor. The likely shape is FreeBSD's netgraph Bluetooth stack underneath a NextBSD-shaped daemon and CLI, following the same split wland and wlan(8) already use for wireless — see Wireless Networking for what that looks like in practice.

Design and phasing are tracked in nextbsd#412. Keyboards and mice (HID) come before headsets — Bluetooth audio has no FreeBSD stack to inherit, so it is a project of its own.

If you have opinions on BLE versus classic, or hardware you want working, the ticket and Discussions are both open.

How drivers load

You do not configure drivers. There is no loader.conf entry, no rc.conf line, no module list — FreeBSD's if_em_load="YES" and kld_list have no equivalent, and neither does anything in rc.conf, which does not exist at all. A supported card works because it is present, not because you declared it.

The chain, from build to boot:

1. Each kext carries IOKitPersonalities — the table of PCI device IDs it claims. For the Intel drivers these are generated from the driver source at build time rather than hand-written, so they cannot drift from the driver.
2. kextd(8) starts from launchd and pushes those personalities into the in-kernel IOKit catalogue.
3. On every push the kernel actively rescans the live PCI tree and requests a load for any device that is present, driver-less, and claimed by the catalogue.
4. The kext loads and the device attaches.

Step 3 matters more than it looks. An earlier design only re-checked devices that a device_nomatch event had queued at boot, which was unreliable on real chipsets — a laptop could boot with its Ethernet and Wi-Fi both present and neither driver loaded, while qemu worked fine and CI stayed green. The present scan is authoritative: it looks at what is actually on the bus.

Graphics work the same way

This is worth stating separately, because on FreeBSD graphics is the one driver everybody configures by hand: install drm-kmod from ports, then kld_list="i915kms" in rc.conf or i915kms_load="YES" in loader.conf.

None of that applies. The DRM core and the GPU drivers are kexts with generated IOKitPersonalities like any other, and they go through the same match → kextd → load → bind path. In a VM, card0 appears with nothing loaded by hand — the CI boot test asserts exactly that, failing if the device only shows up after a manual kextload.

One consequence to expect: autoload is asynchronous. The kernel matcher hands kextd a load request and kextd services it on its own schedule, so a GPU may take a second or two after boot to appear rather than being present the instant userland starts. That is normal, not a fault.

And the display server usually needs no setup either — for a reason specific to this project. drm-kmod builds the DRM core plus i915, amdgpu and radeon, but ships no bochs, virtio-gpu or vmwgfx driver. On FreeBSD that means a VM has no KMS driver for its virtual GPU at all, and X falls back to scfb or VESA, usually with a hand-written xorg.conf to say so.

NextBSD vendors those missing drivers, so a virtual GPU gets real KMS with a card0 DRM node. A display server can take the ordinary modesetting path instead of a fallback, which in practice means no xorg.conf to write and no driver to name — the same "it just works" the physical-GPU case gets on FreeBSD, extended to the virtual GPUs that are how most people actually run this.

So the diagnostic question is never "did I load the module?" but "does anything claim this device?":

pciconf -lv | grep -B3 none     # devices with no driver attached
kextstat                        # what did load

If your card shows as none and kextstat has nothing for it, there is no kext claiming that device ID — see the tables above for what exists.

Working with kexts

Loading by hand is for development and debugging; normal operation needs none of it.

kextstat                                        # what's loaded right now
kextload   /System/Library/Extensions/Foo.kext
kextunload /System/Library/Extensions/Foo.kext

Remember that kldload and kldstat do not exist here — they were deliberately removed.

Current limits

Worth knowing before you plan around any of this:

• The graphics kext series is explicitly experimental. It builds and boot-tests in CI, and BochsGraphics is verified binding inside a booted VM, but it is young code under active development.
• arm64 gets graphics, not much else. Its seven kexts are the virtio-gpu stack; the Bochs and VirtualBox drivers, every physical-GPU kext, and the Intel network kexts are amd64 only. That is the right shape for now — an arm64 NextBSD overwhelmingly runs under UTM or QEMU, where virtio-gpu is the GPU.
• Coverage is narrow by BSD standards. This is a young project — the driver list above is the list, not a sample.
• Kexts are built against the exact kernel config and source they will load into, so stock FreeBSD kmod packages will not load reliably.

See also

• Command Reference — kextstat, kextload, ioreg
• Filesystem Layout — why /boot/kernel is empty
• Project Repositories — nextbsd-kernel-modules builds all of the above