Be explicit that GPUs need no setup, display servers usually included
Graphics is the one driver a FreeBSD user expects to configure by hand --
install drm-kmod, then kld_list="i915kms" or i915kms_load="YES" -- so
"nothing to configure" is not believable unless graphics is named.
It goes through the same match -> kextd -> load -> bind path as any other
kext, and the CI boot test asserts card0 appears with no kextload, failing
if the device only shows up after a manual one.
Two things follow that are worth telling users:
- Autoload is asynchronous. The matcher hands kextd a request that kextd
services on its own schedule, so a GPU can take a second or two to
appear. Normal, not a fault.
- Display servers usually need no setup either. drm-kmod ships no bochs,
virtio-gpu or vmwgfx, so on FreeBSD a VM has no KMS for its virtual GPU
and X falls back to scfb/VESA with a hand-written xorg.conf. NextBSD
vendors those drivers, so a virtual GPU gets real KMS and a card0 node,
and the display server takes the ordinary modesetting path.
Explain that drivers are not configured anywhere, and how kextd does it
Home's second surprise covered the missing kldload CLI but not the thing a
FreeBSD user reaches for next: loader.conf. There is no if_em_load="YES",
no kld_list, and no rc.conf to put either in.
Hardware-Support gains "How drivers load" with the actual chain: kexts
carry IOKitPersonalities (generated from driver source for the Intel
drivers, so they cannot drift), kextd pushes them into the in-kernel IOKit
catalogue, and each push triggers an active rescan of the live PCI tree
that requests a load for every present, driver-less, claimed device.
The section says why the active scan exists, because it is the difference
between working and silently not working: the earlier design only
re-checked devices a device_nomatch event had queued, which was unreliable
on real chipsets -- a laptop could boot with Ethernet and Wi-Fi present and
neither loaded, while qemu was fine and CI stayed green (nextbsd#267).
Ends with the diagnostic that follows from all this: the question is not
"did I load the module" but "does anything claim this device", which is
pciconf -lv | grep -B3 none plus kextstat.
Hardware-Support: add a Bluetooth section pointing at the design ticket
Says plainly that Bluetooth does not work yet and offers no workaround,
then explains why it is a from-scratch design rather than a port -- Apple's
blued sits behind the closed IOBluetooth framework, so unlike launchd or
configd there is no Darwin source to vendor.
Links nextbsd#412 for the design and phasing, notes that HID lands before
audio, and points readers at Discussions if they have hardware or an
opinion on BLE vs classic.
Drop the leading H1 from every page
GitHub renders the page name as a heading on every wiki page, so a file
that also opens with "# Page Name" prints its title twice. All eleven
pages did.
Home's H1 read "NextBSD" rather than "Home", so it was not a literal
duplicate, but it goes too -- eleven pages with one convention beats ten
plus an exception, and the bold opening sentence works as the lead.
Section headings inside the pages are untouched.
Reword the two "meet" sentences in plain terms
"the virtual GPUs you actually meet in a VM" and "which is how most
people meet it" both used meet in a sense that does not survive a first
reading. Now: "the GPUs a VM presents" and "Most people run NextBSD in a
VM".
Hardware: arm64 ships kexts too; drop Nmdm, which ships nowhere
NextBSD-kernel-extensions publishes for both arches -- verified by unpacking
today's packages from the continuous-<arch> release tags rather than reading
the pkg README, which still carries the stale amd64-only table.
arm64 7 kexts: VirtIOGraphics, IOGraphics, IOGraphicsExtras,
IOGraphicsShmem, TTM, DMABuf, LinuxVirtIO
amd64 17 kexts: the above plus BochsGraphics, VBoxGraphics,
IntelGraphics, AMDGraphics, RadeonGraphics,
NVIDIAGraphics595 + NVIDIACore595 + NVIDIAModeset595,
IntelWiFi, IntelEthernet
So arm64 has the complete virtio-gpu stack, which is the driver that
matters there -- UTM and QEMU give an arm64 guest virtio-gpu.
Also corrected from the same evidence: TTM and DMABuf were missing from
the shared-helpers table, NVIDIA is three kexts rather than one, and the
per-arch columns on the virtual-GPU table were guesswork.
Nmdm.kext is gone entirely. It appears in the CI workflow's kext PoC boot
test, which is where I originally read it, but it is in neither shipped
package -- zero matching entries in the amd64 archive.
Installing-Packages carried the same amd64-only claim in its package table.
Add Hardware Support; drop the duplicated Home entry from the sidebar
Hardware-Support covers what the kext story actually is: KMS graphics for
the virtual GPUs (BochsGraphics, VirtIOGraphics on both arches,
VBoxGraphics), the physical-GPU kexts (Intel, AMD, Radeon, NVIDIA), the
shared DRM helper kexts that drm-kmod does not ship, and IntelWiFi /
IntelEthernet whose matching tables are generated from driver source.
It states the limits plainly -- the graphics series is experimental, the
kernel-extensions package is amd64-only today, and coverage is narrow.
Home's intro gains a matching sentence, since hardware was the one part of
the stack the opening paragraph never mentioned.
The sidebar listed Home under "Start here", which duplicated the page title
GitHub renders on every wiki page and read oddly besides -- Home is the
root, not a step. It becomes a standalone link above the sections.