[FlareCoding]

Summary

When the open file controlling gfxfb's buffers (the one file at a time that may create and present them) closes, it presents the base buffer (the pixels an output was lit with) on each output that shows a created buffer and whose base buffer gfxfb recorded, before another file can take control.

Changes

• Give the screen back when the controlling file closes: once its own presents have ended, gfxfb_node::on_close() drops the file's unread events (the records of its presents' ends), presents the whole base buffer of each output showing another buffer and waits for those presents the device accepts. An output with no base buffer recorded, or one where the present does not latch, as on a dark output or a failed device, keeps showing the buffer it showed.
• Keep other files out while the outputs are given back: control ends only after on_close() has waited for the file's own presents and the base buffers', so another file's creation or present that passes gfxfb's own checks fails with EBUSY meanwhile. No file receives the events of the close's presents, and a file that does not control the buffers presents nothing when it closes.
• Tests: a controller's close presents both outputs' base buffers naming no region, with its events unread and one buffer's handle destroyed, and waits through a kill with control kept until those presents end, whose events reach no other file, while a bystander's close presents nothing. A close presents only once its queued present has ended, waits for no present the display refuses on a dark output, and never calls the display on an output holding a failed present or one with no base buffer recorded.
• Boots: in QEMU on x86_64 and aarch64, the desktop came up as on pr/gfxfb-regions 08f0c02, on virtio-gpu and on the firmware's framebuffer. No program creates or presents a buffer, so no boot runs the close's presents.

---

Note

Medium Risk
Changes kernel display teardown ordering, locking around controller release, and present/event lifetime on close—timing-sensitive graphics driver behavior with broad test coverage but real regression risk if handback races with other clients.

Overview
When the controlling /dev/gfxfb client closes, gfxfb now restores each output that was showing a non-base buffer by queueing a handle-0, full-frame present of that output’s recorded base buffer, after waiting for the client’s own in-flight presents to finish.

on_close() is split into wait_for_unended_presents and give_outputs_back: the controller drops unread present events, issues those base-buffer presents only where shown != base, waits again for accepted presents (events are not delivered to any fd), and releases buffer control only after both waits so rivals still get EBUSY. Non-controllers and edge cases (no recorded base, dark/refused/failed present, stuck failed hardware) behave as documented in gfxfb_abi.h / gfxfb_node.h.

Tests add deadline-based close/create helpers, per-output present recording, and new cases for multi-output handback, queued presents, dark outputs, and outputs without a base buffer; many existing tests now use closes_before_deadline / closes_giving_output_back instead of bare fs::close.

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