4231301896559c90ba4f6b7e7407fde9be2f827b
3
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
 Daniel Samson
|
4231301896 |
display: runtime mode-setting, EDID, and fenced (vsync) present (v2 V5)
The native backend can now change resolution and presents tear-free.
Mode-setting without churn. The driver sizes its scanout resource + shared surface to the
largest mode it offers and treats a mode change as re-pointing the scanout rectangle within
that surface — so the resource, its backing, and the shared mapping never change, and the
surface's row stride (the max width) is fixed while the active width/height move. The
compositor is handed that stride in the announce and composes at it; a smaller mode just
paints the top-left rectangle. This sidesteps the surface re-share a true resolution change
would otherwise need (the service harness can't reply with a capability).
- scanout-protocol gains get_modes + set_mode; the driver offers {640x480, 800x600} and
re-points set_scanout on set_mode.
- backend.VirtioGpu carries the surface stride, exposes modes()/setMode(), and reports
canModeSet = hasVsync = true.
- runtime.display gains modes()/setMode() (display-protocol get_modes/set_mode, forwarded to
the backend) — the client-facing API.
- EDID: the driver negotiates VIRTIO_GPU_F_EDID when the device offers it, reads the monitor's
EDID, and logs its preferred mode (parsed from the first detailed timing descriptor).
- vsync: every resource_flush is fenced (VIRTIO_GPU_FLAG_FENCE); the device signals the fence
when the frame is on screen, which the used-ring ack the synchronous present already waits
on gates — so a completed present is a tear-free one.
After the native upgrade the compositor runs a one-shot mode-set self-check: query the modes,
switch to a different one, re-composite, and confirm the backend reports the new geometry —
the gate's markers.
Gate: python3 test/qemu_test.py display-modeset (reuses the display-native boot) — "display:
mode set to 800x600, verified" + "display: vsync present ok", passing 3/3. host tests,
display-service, display-demo, shm, virtio-gpu, and display-native still pass.
|
||
|
Daniel Samson
|
58927ed7e5 |
display: hot-attach a virtio-gpu native backend over the GOP floor (v2 V4)
The compositor now boots on the GOP framebuffer and upgrades to the virtio-gpu driver the moment it announces itself — the pluggable-scanout payoff. The shared surface. The scanout resource is an shm region the driver creates (shm_physical, a new syscall, hands it the guest-physical for attach_backing) and passes to the compositor as a capability. The compositor maps it and composites straight into it: on x86 DMA is cache-coherent, so the cacheable shared pages the CPU paints are exactly what the device transfers-and-flushes — no copy, no explicit flush. The handshake. After bring-up the driver looks up .display and sends attach_scanout with the geometry + the surface capability. The compositor maps the surface, looks up the driver's .scanout endpoint itself (the driver registered it — no need to pass it), switches to backend.VirtioGpu, and re-composites the current frame. present() over the native backend is a present request on .scanout -> transfer-to-host + resource flush. The first native present is deferred to a one-shot timer: presenting inline from the announce handler would deadlock, since the driver is still blocked on our reply and not yet serving .scanout. After it lands, the compositor reads a pixel back from the shared surface to confirm the frame reached the device's backing. - shm_physical (syscall 36) + runtime.shm.physical. - scanout-protocol (the compositor->driver present channel), separate from the client-facing display protocol; the display protocol gains attach_scanout. - backend.VirtioGpu joins backend.Gop in the tagged union; select() still boots GOP. - the virtio-gpu driver's scanout backing is now shm (was DMA); it announces + serves .scanout present requests (transfer-to-host + flush of the shared surface). Also fixes a latent framebuffer-geometry corruption the display service hit only when it enumerated the device tree alongside a busy device-manager: Gop.init now captures the geometry into a small value the instant device_enumerate returns (rather than re-reading the 328-byte descriptor across the later claim/mmio_map syscalls) and retries on a zero geometry. The underlying device-table clobber is a separate kernel bug, tracked apart. Gate: python3 test/qemu_test.py display-native (QEMU -device virtio-gpu-pci) — "display: scanout upgraded to virtio-gpu" + "display: native present verified" + "display-demo: ok", passing 3/3. host tests, display-service, display-demo, shm, and virtio-gpu still pass. |
||
|
Daniel Samson
|
6e0e0a62c6 |
virtio-gpu: a modern virtio 1.0 display driver, bring-up to a flushed frame (v2 V3)
The first native scanout backend's driver half. The device manager matches the
virtio-gpu PCI function by its Display/Other class triple and spawns the driver,
which claims the device, confirms vendor 0x1AF4/device 0x1050 from config space,
enables memory-space + bus mastering, and walks the virtio vendor capabilities to
find the common-config and notify structures in its BAR.
From there it is the standard modern-virtio bring-up: reset, negotiate VERSION_1,
stand up the control virtqueue in coherent DMA, then drive the GPU end to end —
RESOURCE_CREATE_2D, ATTACH_BACKING (a coherent DMA buffer; V4 swaps in the shm-
shared surface), SET_SCANOUT, paint a known pattern, TRANSFER_TO_HOST_2D,
RESOURCE_FLUSH, and wait for the device's used-ring ack. Reading the backing back
proves it is CPU-visible RAM; the ack proves the device consumed the frame —
together the automated stand-in for "it's on screen", no screenshot.
- system/drivers/virtio-gpu/: the driver, plus virtio-gpu-protocol.zig (control
commands) and virtio-pci.zig (the 1.0 PCI transport + split-virtqueue), both with
host-tested struct sizes.
- device-manager matches the display/other class triple to "virtio-gpu"; the driver
self-confirms the vendor/device id, since the class alone cannot distinguish it.
- ServiceId.scanout (11): the driver registers it so the compositor finds it in V4.
Gate: python3 test/qemu_test.py virtio-gpu (QEMU -device virtio-gpu-pci) — the
device-manager stack discovers the function, the driver brings up a 640x480 scanout
and flushes a test pattern: "virtio-gpu: scanout 640x480 online" + "flush acked,
pixel check ok". host tests, display-service, shm, and device-list still pass.
Note: the pre-existing pci-scan case triple-faults on main (verified at
|