Skip to content

Stack the cursor's plane at the top of what the CRTC blends (P-106) - #127

Merged
jwinarske merged 1 commit into
mainfrom
fix/cursor-zpos
Oct 20, 2026
Merged

jwinarske merged 1 commit into
mainfrom
fix/cursor-zpos

Conversation

@jwinarske

Copy link
Copy Markdown
Owner

Follows up #121 on drm-cxx#384, from the SA8155P re-test.

The problem: neither drmkit nor drm-cxx wrote the cursor plane's zpos. An overlay taken for the cursor kept whatever value it had. Left at the 0 every overlay starts at, it shared the primary's blend stage. The SA8155P refuses two overlapping planes on one stage (_sde_crtc_validate_src_split_order "invalid coordinates, stage:0"), so the cursor never committed there at any position.

The fix: the cursor's plane is now written with the top of its zpos range, capped below the CRTC's blend-stage limit. That's the rule drm-cxx's in-progress cursor fix for #384 uses.

  • Nothing is written where the plane has no zpos or a fixed one, so i915, amdgpu and vkms are unchanged.
  • The size probe's test commits carry it.
  • It survives a pause and resume.

The tests:

  • New unit test: the_cursor_stacks_at_the_top_of_what_the_crtc_can_blend.
  • The cursor device tests now probe their plane registry (PlaneRegistry::probe). The hand-built one had no zpos ranges or blend limit for the renderer to stack from.
  • The rotation test now expects the hardware to be asked for the turn when the probed plane can do it. vkms's cursor plane can; the hand-built registry hid that.

SA8155P, DP-4 (stale SDE plane state cleared first, every plane's zpos reset to 0):

main this PR
a_cursor_off_the_top_left_corner_commits_vkms refused: "invalid coordinates, stage:0 l:0-64 r:0-1280" passes

Without the zpos reset, main passed too on this boot. Whether main fails depends on the zpos values weston leaves behind, which vary by boot.

One test still fails on the board on both builds: the_cursor_leaves_an_overlay_this_crtc_shows_vkms. It lights a 4K mode, which the board's shared-display layer refuses ("roi 4096x2160 exceeds base mode 1280x720"). That's a rig limitation, not this change.

Docs:

  • P-106 row and a CHANGELOG entry.
  • The P-101 row now records the divergence agreed with the drm-cxx side: drm-cxx clips an overlay-backed cursor's geometry, while drmkit shifts the sprite on every plane type. Same pixels and pointer alignment.

Checks: clippy over the workspace with all features, workspace tests, the cursor tests on vkms and rustdoc all pass. semver-checks reports no update needed.

Neither side wrote the cursor plane's zpos, so an overlay taken for the
cursor kept whatever it had. Left at the 0 every overlay starts at, it
shared the primary's blend stage, and the SA8155P refuses two
overlapping planes on one stage ("invalid coordinates, stage:0"), so
the cursor never committed there at any position.

The plane is now written with the top of its zpos range, capped below
the CRTC's blend-stage limit, as drm-cxx's in-progress cursor fix for
one. The size probe's test commits carry it too, and it survives a
pause and resume.

The cursor device tests now probe their plane registry rather than
build one without zpos ranges or a blend limit, which the renderer
could not have stacked from. The rotation test follows: it expects the
hardware to be asked for the turn when the probed plane can do it.

The P-101 row records the agreed divergence from drm-cxx's cursor fix,
which clips an overlay-backed cursor's geometry where drmkit shifts the
sprite.

Signed-off-by: Joel Winarske <joel.winarske@linux.com>
@jwinarske
jwinarske merged commit a20cf9f into main Oct 20, 2026
10 checks passed
@jwinarske
jwinarske deleted the fix/cursor-zpos branch October 20, 2026 19:31
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant