[FlareCoding]

Summary

Builds the register writes that show one unscaled image through the display engine (the GPU's unit that scans images out to monitors), for the driver's first lit screen and every later image to share.

Changes

• Showing an image takes NVIDIA's flip methods: a head (the unit timing one monitor) shows an image through a window (a unit reading one surface for it), whose channel carries its methods (the display engine's register writes) and the update applying them. build_window_image_methods (window_methods.h) gives, in order, the 54 methods NVIDIA's modesetting module writes for a flip (a change of a window's image) of one X8R8G8B8 surface in rows, shown whole and unscaled where the window already lies, from a vertical blank for at least a frame, asking no notifier event, timestamp, semaphore, flip lock, variable refresh rate, rotation, reflection, tone mapping, color matrix, look-up table or blending of its own, each method re-declared in rm.h from NVIDIA's window class.
• A method carries up to two values: window_method holds both halves of the update timestamp (a time not to show the image before) in one method, as NVIDIA writes them, so the methods take 109 words with their headers. A method of the core channel (the display channel that sets up heads, links and which head owns each window) keeps one value in display_method.
• The color pipeline is the one NVIDIA sets for that state: after the format the builder writes the identity format matrix, two input scaler taps, the last color space conversion (CSC) matrix disabled, the input look-up table read directly by 10-bit color from the start of the look-up table surface, and an opaque composition at the depth of a head's main layer, 8.
• The caller decides how the update reports and interlocks: window_image_update names the window notifier's context DMA and 16-byte slot, or none, and whether the update takes effect only with the core channel's next update. The window's own channel is always in its interlock, and the update sets the bit NVIDIA sets in every window update (RELEASE_ELV).
• The look-up table's entry counts move to display_light.h: LOOK_UP_TABLE_HEADER_ENTRIES and LOOK_UP_TABLE_ENTRIES move from display_light.cpp into display_light.h, beside the look-up table surface's size, so the builder sizes the input table with its header, 1029 entries.
• Departure, the other CSC stages: the other CSC stages' controls (CSC00, CSC0LUT, CSC01, CSC10 and CSC1LUT) are not written, so they keep what the window holds. NVIDIA writes them disabled only for a window whose capabilities report those stages, and the driver reads no window capabilities.
• Departure, bounds in place of masks: window_image and window_image_update state what their values must keep to fit their methods' fields (both handles nonzero, a window below 32, a width and height below 65536, a pitch a multiple of 64 below 512 KiB, a slot below 256), where NVIDIA's module cuts a value to its field. The two agree on every value within the bounds.
• Departure, the present interval: the present control keeps each image at least one frame (MIN_PRESENT_INTERVAL 1), where NVIDIA's flips take the interval their caller asks.
• Lands ahead of its callers: the builder is pure, so its tests are its first user, and it lands whole, the notifier fields included. The first light (the driver lighting its first monitor) calls it in a later pull request, and the presents (each later image handed to a lit monitor), which first use the notifier fields, come after that.
• Card: no boot path changes, since nothing outside the tests calls the builder and the kernel's symbols differ from master's only by the builder and its six helpers. On the RTX 3080, ab4faca5 (the light's draft, which calls this builder) wrote window 0's first image with these methods in runs land-light5-card-4 (the card's own display) and land-light5-vga-4 (QEMU's VGA), the core channel reading the update lighting head 0 with its completion notifier finished, with no error-log event or Xid (NVIDIA's error report) from the GSP (the card's firmware processor), 0 IOMMU or PCIe faults on the host and the screen not captured.
• Tests: nvidia_window_methods checks that the light's image (window 2, 2560 by 1440, interlocked with the core channel, no notifier, its handles past 16 bits as the driver's are) is NVIDIA's flip method for method and value for value, in 109 words. It checks that a present differs only by its notifier, named by its slot in 16-byte units, and its core interlock left out, that a slot with no notifier leaves the notifier's control 0, that the size, a padded pitch and the interlock bit follow the image (window 5, 1920 by 1080, pitch 16384), and that the largest values within the bounds fill their fields whole.

---

Note

Low Risk
Pure method-building logic with no runtime callers yet; display behavior unchanged until a later change submits these methods to hardware.

Overview
Adds build_window_image_methods, which emits the 54 window-channel register methods (109 push-buffer words) NVIDIA's modesetting stack uses for a simple flip: unscaled X8R8G8B8 surface in rows, present at vblank for at least one frame, identity color path, input LUT at the LUT surface, opaque main-layer composition, optional notifier slot, and core/window interlock flags ending in RELEASE_ELV.

rm.h gains the NVC67E method offsets and field encodings; LUT header/entry counts move from display_light.cpp to display_light.h for shared sizing. nvidia_window_methods tests assert method order/values match NVIDIA's flip, notifier/interlock variants, pitch encoding, and field limits. Nothing in the boot/display path calls the builder yet—tests are the only consumer.

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