[PR #53] [MERGED] fix(comp): subtract the cursor hotspot when rendering client cursor surfaces #54

New issue

Closed

opened 2026-10-15 12:47:57 +00:00 by bsakaguchi · 0 comments

bsakaguchi commented

2026-10-15 12:47:57 +00:00

Owner

📋 Pull Request Information

Original PR: https://github.com/games-on-whales/gst-wayland-display/pull/53
Author: @dnvang
Created: 8/2/2026
Status: ✅ Merged
Merged: 9/7/2026
Merged by: @ABeltramo

Base: stable ← Head: fix/cursor-hotspot

📝 Commits (1)

445cbed fix(comp): subtract the cursor hotspot when rendering client cursor surfaces

📊 Changes

1 file changed (+28 additions, -8 deletions)

View changed files

📝 wayland-display-core/src/comp/rendering.rs (+28 -8)

📄 Description

Problem

When a client sets a custom cursor (wl_pointer.set_cursor), the compositor renders the cursor surface at the raw pointer location and ignores the hotspot the client submitted with it. Any cursor whose hotspot is not (0,0) is drawn offset by exactly the hotspot, while input lands at the true pointer position.

Conventional arrow cursors put the hotspot at the tip (~0,0), so most apps look fine. Games shipping centre-hotspot cursors are visibly broken: Mindustry (libGDX/arc Graphics.newCursor) uses 64x64 cursors with a (32,32) hotspot, so under Wolf its cursor renders 32px down-right of where clicks actually land.

Fix

Read the hotspot out of the surface's CursorImageAttributes and render at pointer_location - hotspot, the same way smithay's own anvil example does. (0,0)-hotspot cursors are unaffected. The extra whitespace reflows in the diff are cargo fmt reacting to the new lines.

Verification

Built at current main (b15285a) with the same cargo features as the Wolf image and bind-mounted the resulting libgstwaylanddisplaysrc.so over the stock one in the digest-pinned Wolf image: gst-inspect-1.0 waylanddisplaysrc reports identically to stock (0.4.0-b15285a), and in Moonlight, Mindustry's cursor now sits exactly on its click target.

_{🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.}

## 📋 Pull Request Information **Original PR:** https://github.com/games-on-whales/gst-wayland-display/pull/53 **Author:** [@dnvang](https://github.com/dnvang) **Created:** 8/2/2026 **Status:** ✅ Merged **Merged:** 9/7/2026 **Merged by:** [@ABeltramo](https://github.com/ABeltramo) **Base:** `stable` ← **Head:** `fix/cursor-hotspot` --- ### 📝 Commits (1) - [`445cbed`](https://github.com/games-on-whales/gst-wayland-display/commit/445cbedad312c38973e59d919d6d02f8c8492663) fix(comp): subtract the cursor hotspot when rendering client cursor surfaces ### 📊 Changes **1 file changed** (+28 additions, -8 deletions) <details> <summary>View changed files</summary> 📝 `wayland-display-core/src/comp/rendering.rs` (+28 -8) </details> ### 📄 Description ## Problem When a client sets a custom cursor (`wl_pointer.set_cursor`), the compositor renders the cursor surface at the raw pointer location and ignores the hotspot the client submitted with it. Any cursor whose hotspot is not (0,0) is drawn offset by exactly the hotspot, while input lands at the true pointer position. Conventional arrow cursors put the hotspot at the tip (~0,0), so most apps look fine. Games shipping centre-hotspot cursors are visibly broken: Mindustry (libGDX/arc `Graphics.newCursor`) uses 64x64 cursors with a (32,32) hotspot, so under Wolf its cursor renders 32px down-right of where clicks actually land. ## Fix Read the hotspot out of the surface's `CursorImageAttributes` and render at `pointer_location - hotspot`, the same way smithay's own anvil example does. (0,0)-hotspot cursors are unaffected. The extra whitespace reflows in the diff are `cargo fmt` reacting to the new lines. ## Verification Built at current main (b15285a) with the same cargo features as the Wolf image and bind-mounted the resulting `libgstwaylanddisplaysrc.so` over the stock one in the digest-pinned Wolf image: `gst-inspect-1.0 waylanddisplaysrc` reports identically to stock (0.4.0-b15285a), and in Moonlight, Mindustry's cursor now sits exactly on its click target. --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>

bsakaguchi

2026-10-15 12:47:57 +00:00