Daniel Samson
4231301896
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.
50 lines
1.9 KiB
Zig
50 lines
1.9 KiB
Zig
//! The scanout wire protocol — what the compositor says to a native scanout driver (e.g.
|
|
//! virtio-gpu) over its well-known `.scanout` endpoint to put a composited frame on screen.
|
|
//! The driver owns the panel and the shared scanout surface it handed the compositor (via the
|
|
//! display service's `attach_scanout`); the compositor composites into that surface, then asks
|
|
//! the driver to present a damaged rectangle. Tiny by design — one present request. Separate
|
|
//! from the display protocol because the directions differ: clients call the compositor over
|
|
//! `.display`; the compositor calls the driver over `.scanout`. See docs/display-v2.md.
|
|
|
|
const std = @import("std");
|
|
|
|
pub const Operation = enum(u32) {
|
|
/// present(x, y, width, height): put the given rectangle of the shared scanout surface on
|
|
/// the panel (on virtio-gpu: transfer-to-host of the region, then a fenced resource flush).
|
|
present = 0,
|
|
/// get_modes() -> ModesReply: the display modes this scanout can switch to (V5).
|
|
get_modes = 1,
|
|
/// set_mode(width, height): change the scanout resolution — the shared surface is sized to
|
|
/// the largest mode, so this just re-points the scanout rectangle; the surface is unchanged.
|
|
set_mode = 2,
|
|
};
|
|
|
|
pub const Request = extern struct {
|
|
operation: u32,
|
|
x: u32 = 0,
|
|
y: u32 = 0,
|
|
width: u32 = 0,
|
|
height: u32 = 0,
|
|
};
|
|
|
|
pub const Reply = extern struct {
|
|
status: i32, // 0 on success, negative on failure
|
|
reserved: u32 = 0,
|
|
};
|
|
|
|
/// One offered display mode.
|
|
pub const Mode = extern struct { width: u32, height: u32 };
|
|
pub const max_modes = 4;
|
|
|
|
/// The reply to `get_modes`: a small fixed list of modes.
|
|
pub const ModesReply = extern struct {
|
|
status: i32,
|
|
count: u32,
|
|
modes: [max_modes]Mode,
|
|
};
|
|
|
|
pub const message_maximum: usize = 64;
|
|
pub const request_size: usize = @sizeOf(Request);
|
|
pub const reply_size: usize = @sizeOf(Reply);
|
|
pub const modes_reply_size: usize = @sizeOf(ModesReply);
|