fix(kvm): route explicit-Linear scanout reads through gbm #123

Merged

Claude-Run merged 1 commit from fix/VA-121-vram-linear-scanout-through-gbm into main

2026-07-07 12:54:33 +02:00

Claude-Run commented

2026-07-07 12:39:25 +02:00

Member

A Linear modifier describes a scanout buffer's TILING (untiled row-major layout), not its memory RESIDENCY. capture_rgb and read_cursor_rgba gated on is_explicit_linear and took the raw-mmap read_linear_rgb / read_linear_rgba path first for any explicit-Linear plane. On a real GPU whose linear scanout is VRAM-resident (desktop-03: AMD, XR24, modifier=Linear, pitch=width*4) that mmap does not fail with EPERM; it succeeds and returns garbage, so the Ok(garbage) is streamed and the gbm fallback (which only fires on Err) never runs, producing a horizontally sheared frame. VA-106's premise that an explicit Linear modifier is guaranteed CPU-linear and safe to mmap is false for a VRAM scanout.

Drop the is_explicit_linear fast path from both capture sites. capture_rgb now calls read_scanout_or_linear unconditionally and read_cursor_rgba calls the gbm read first; both keep the raw mmap only as the gbm-unavailable fallback (software renderer, some VMs), where the scanout is genuinely CPU-linear. The gbm blit stages a tiled OR VRAM-resident scanout into a CPU-visible linear buffer and handles a genuinely-linear buffer too, so it is the correct path for desktop-03's linear-but-VRAM buffer, as it already is for desktop-02's tiled buffer.

is_explicit_linear is retained only for the informational explicit_linear field on the DRM/KMS scanout selected journal line; it no longer gates capture. Doc comments updated to state that a Linear modifier denotes tiling, not residency.

#VA-121

A `Linear` modifier describes a scanout buffer's TILING (untiled row-major layout), not its memory RESIDENCY. capture_rgb and read_cursor_rgba gated on is_explicit_linear and took the raw-mmap read_linear_rgb / read_linear_rgba path first for any explicit-Linear plane. On a real GPU whose linear scanout is VRAM-resident (desktop-03: AMD, XR24, modifier=Linear, pitch=width*4) that mmap does not fail with EPERM; it succeeds and returns garbage, so the Ok(garbage) is streamed and the gbm fallback (which only fires on Err) never runs, producing a horizontally sheared frame. VA-106's premise that an explicit Linear modifier is guaranteed CPU-linear and safe to mmap is false for a VRAM scanout. Drop the is_explicit_linear fast path from both capture sites. capture_rgb now calls read_scanout_or_linear unconditionally and read_cursor_rgba calls the gbm read first; both keep the raw mmap only as the gbm-unavailable fallback (software renderer, some VMs), where the scanout is genuinely CPU-linear. The gbm blit stages a tiled OR VRAM-resident scanout into a CPU-visible linear buffer and handles a genuinely-linear buffer too, so it is the correct path for desktop-03's linear-but-VRAM buffer, as it already is for desktop-02's tiled buffer. is_explicit_linear is retained only for the informational explicit_linear field on the DRM/KMS scanout selected journal line; it no longer gates capture. Doc comments updated to state that a Linear modifier denotes tiling, not residency. #VA-121

Claude-Run added 1 commit

2026-07-07 12:39:25 +02:00

fix(kvm): route explicit-Linear scanout reads through gbm

Check / fmt + clippy + tests (pull_request) Successful in 14m35s

Details

Create release / Create release from merged PR (pull_request) Has been skipped

Details

edae50666d

A `Linear` modifier describes a scanout buffer's TILING (untiled row-major layout), not its memory RESIDENCY. capture_rgb and read_cursor_rgba gated on is_explicit_linear and took the raw-mmap read_linear_rgb / read_linear_rgba path first for any explicit-Linear plane. On a real GPU whose linear scanout is VRAM-resident (desktop-03: AMD, XR24, modifier=Linear, pitch=width*4) that mmap does not fail with EPERM; it succeeds and returns garbage, so the Ok(garbage) is streamed and the gbm fallback (which only fires on Err) never runs, producing a horizontally sheared frame. VA-106's premise that an explicit Linear modifier is guaranteed CPU-linear and safe to mmap is false for a VRAM scanout.

Drop the is_explicit_linear fast path from both capture sites. capture_rgb now calls read_scanout_or_linear unconditionally and read_cursor_rgba calls the gbm read first; both keep the raw mmap only as the gbm-unavailable fallback (software renderer, some VMs), where the scanout is genuinely CPU-linear. The gbm blit stages a tiled OR VRAM-resident scanout into a CPU-visible linear buffer and handles a genuinely-linear buffer too, so it is the correct path for desktop-03's linear-but-VRAM buffer, as it already is for desktop-02's tiled buffer.

is_explicit_linear is retained only for the informational explicit_linear field on the DRM/KMS scanout selected journal line; it no longer gates capture. Doc comments updated to state that a Linear modifier denotes tiling, not residency.

#VA-121