Display: flip-only framebuffer that adopts the firmware's mode (NMIntelFB) #9

Upstream scout, 2026-10-22: what other projects have learned about the panel.

• VedCloud's Meteor Lake port keeps the panel on the firmware framebuffer: i915 runs with display discovery skipped and a small framebuffer kext (LatitudeMTLFB) scans out. Their kernel 1.0.15 reads the firmware console's address, pitch and size and starts i915's stolen-memory allocator after it, which is what got them a GPU-composited desktop. That's the same shape as NMIntelFB here. README, v1.0.14
• kitsuneislife/nmx-intel lit a Raptor Lake panel with i915 through NullMoth's port, then parked it because compositing ran in software; their live route copies frames composited elsewhere to the Intel panel. repo
• Linux's firmware-framebuffer checks (drop the BIOS fb on a wrong depth/bpp, disable the plane when the readout fails, keep new framebuffers out of stolen) landed in lutzbichler/drm-kmod's pr/7.3 branch: 2b20606b8b, 9eb4720580, b63eb2f992. They're 7.3 code and we build on 6.12, so read them as a checklist rather than a backport.
• WhateverXe 0.4.0 drives Tiger Lake laptop panels by retraining eDP through Apple's driver (VBT panel facts, scrambler and framing bits matched to DPCD 0x10A). It doesn't adopt the firmware mode and doesn't cover Meteor/Arrow Lake ("Not Planned"). 0.4.0
• NootedGreen #21/#22: the Apple Tiger Lake donor approach stops before a modeset on real Tiger Lake and freezes on Raptor Lake. More reason to keep the panel on the firmware's mode. #21

Full write-up: https://github.com/watchthelight-labs/research/blob/main/scout/xe/2026-10-22.md

Two requirements from other ports, to settle before i915 is allowed near the display:

1. Keep i915's stolen-memory allocator off the firmware console. i915 placed rings over the live framebuffer's stolen pages on both VedCloud's Meteor Lake port and nmx-intel's Raptor Lake work. VedCloud's kernel 1.0.15 reads the console's address, pitch and size and starts the stolen allocator after that image, and disables it if the console data looks wrong (ROADMAP Phases 9 and 11). nmx-intel reserves the boot framebuffer's GGTT range and stolen pages first (pitfalls.md, patches 0007 and 0014). Our stage 4 runs with display off, but the allocator is not display code, so this applies to stage 4 too. Our display check (the GGTT entry behind PLANE_SURF) would catch it after the fact.
2. IOFBDependentID. Without it the IOFramebuffer has no controller until open(), and nmx-intel saw freezes from that (same pitfalls file). NMIntelFB should set it from the start.

nmx-intel has no licence, so both are ideas only. We write our own code and credit them.

Status: the panel runs on XeGfxIntelFB now (NvGfx xe-2.6.2, kexts/XeGfxIntelFB), not NMIntelFB. It keeps the firmware's mode, WindowServer composites into it on the Intel GPU through Metal, and since 0.7 it reads the panel's EDID and offers HiDPI 1280x800 (CHANGELOG). It is not flip-only yet: frames are still copied rather than flipped, and ArrowWhatever's GGTT zero-copy scanout with a deferred flip is the lead for that. Scaled sizes above 1280x800 are in NvGfx #19.