[FlareCoding]

Summary

A program presents one of its buffers, or an output's base buffer (the pixels the output was lit with, which it shows until another buffer presented on it takes their place at a vertical blank), on an output with GFXFB_PRESENT, and gfxfb keeps each buffer allocated while an output shows it or holds it for a present.

Changes

• Presenting a buffer: GFXFB_PRESENT hands the buffer to the display's present() and returns without waiting for the vertical blank, and the display reports to gfxfb_node::present_done() how each present it accepted ended. An output holds one present at a time, so another present on it fails with EBUSY until the first latches (the output shows it from that vertical blank) or the output goes dark, and for good if the device fails first.
• No buffer freed while the hardware may read it: gfxfb records every lit output's base buffer and holds a reference to the buffer each output shows and the one it holds for a present, so destroying a handle never frees either. A latch drops the replaced buffer, a present that ends because its output went dark drops its own, and one that ends because the device failed keeps both, since the failed hardware may still read them.
• Presents take control as creations do: a present that succeeds gives its file control of the buffers, and while one file controls or reserves control another file's present fails with EBUSY. gfxfb's own refusals come first and take no control: EINVAL for a request it cannot read, for an output index of the output count or more and for a handle the file does not hold, and EAGAIN for handle 0 on an output gfxfb recorded no base buffer for (one dark when the device started, or any output when no memory was left to record the lit outputs' base buffers).
• The boot display and virtio-gpu present nothing: both refuse every present that passes gfxfb's checks and control with ENOTTY, and the refusal takes no control, so their outputs keep showing their base buffers.
• Tests: twelve gfxfb tests, eleven on the fake display and one on the boot display, pin which buffers an output keeps through each way a present ends and that presents for one output reach the display one at a time. They also pin each refusal's errno and whether it comes before control or before the display call, and what each present's result does to control, alone or during a creation.
• Boots: in QEMU on x86_64 and aarch64, the desktop came up as on pr/gfxfb-control 6f85161, on virtio-gpu and on the firmware's framebuffer. No program presents a buffer, so no boot reaches a present.

---

Note

Medium Risk
New kernel/user ABI and refcount/lifecycle rules around scanout buffers; incorrect present_done timing could free memory still read by the GPU, though behavior is heavily tested.

Overview
Adds buffer presentation to /dev/gfxfb: userland can call GFXFB_PRESENT to swap what an output shows at the next vertical blank, using a client buffer handle or handle 0 for that output’s recorded base buffer.

The kernel extends the display contract with present() and gfxfb_node::present_done() (latched / dark / failed), tracks per-output base / shown / queued buffer records (up to GFXFB_OUTPUTS_MAX), and records every lit output’s base buffer at show time—not only the primary. Presents share the same single-file control model as buffer creation, allow one in-flight present per output (serialized with per-output mutexes), and keep buffers alive while hardware or a pending present may still read them.

Boot and virtio-gpu displays stub present() as unsupported; the user ABI and docs in gfxfb_abi.h describe errors and semantics. A large gfxfb test suite covers latching, refcounts, control/EBUSY paths, and concurrent presents.

^{Reviewed by Cursor Bugbot for commit cd45ce1. Bugbot is set up for automated code reviews on this repo. Configure here.}