Drag icon hotspot is lost after the first commit (wl_surface offset applied as absolute, not accumulated)

[BurningTreeC]

Drag icon hotspot is lost after the first commit

wl_surface.offset / wl_surface.attach dx,dy are relative deltas, but Hyprland
stores them as an absolute offset. A client that sets a drag-icon hotspot once and
then draws any further frame loses the hotspot, and the icon snaps to top-left-at-cursor
for the rest of the drag.

Reproduction

Hyprland 0.56.2. Drag an image out of Chromium (native Wayland), grabbing it away from
its top-left corner. The drag icon jumps so its top-left corner sits under the cursor
instead of staying anchored at the grab point.

Protocol trace

WAYLAND_DEBUG=1 chromium, dragging a 320x220 image grabbed near its bottom-right:

1829: wl_data_device#6.start_drag(wl_data_source#78, wl_surface#36, wl_surface#80, 5578)
1834: wl_surface#80.attach(wl_buffer#91, -197, -134)   <- hotspot delta, correct
1837: wl_surface#80.commit()
1866: wl_surface#80.attach(wl_buffer#93, 0, 0)          <- 3ms later, zero DELTA = "don't move"
1869: wl_surface#80.commit()
      ... 20+ further attach(<buf>, 0, 0) + commit() over the rest of the drag

Chromium asks for (-197, -134), which matches the grab point exactly. The very next
frame carries a (0, 0) delta, which per spec means "stay where you are".

Cause

wl_surface.attach overwrites the stored offset rather than accumulating:

// src/protocols/core/Compositor.cpp:98-101
m_resource->setAttach([this](CWlSurface* r, wl_resource* buffer, int32_t x, int32_t y) {
    m_pending.updated.bits.buffer = true;
    m_pending.updated.bits.offset = true;
    m_pending.offset = {x, y};

and the DND renderer consumes that single stored value as if it were the total offset:

// src/protocols/core/DataDevice.cpp:843
surfacePos += m_dnd.dndSurface->m_current.offset;

So the second commit replaces (-197, -134) with (0, 0) and the hotspot is gone.

This is the remaining half of #9892 / PR #9895: that PR made the offset apply at all,
but it applies only the latest commit's delta rather than the running sum. main
(0bd11c7) still has the identical line.

Note this is invisible in apps that never request a hotspot -- GTK4/Nautilus, for
instance, sends an explicit wl_surface.offset(0, 0), so top-left-at-cursor is
correct there and the bug does not show.

Suggested fix

Accumulate the delta into DND state, guarded on updated.bits.offset so commits that
don't carry an attach/offset aren't double-counted, and render from the accumulator.
Patch below (compiles untested).

System

Hyprland 0.56.2 built from branch v0.56.2 at commit efb5099 clean
Tag: v0.56.2, commits: 7661
Aquamarine 0.14.0, Hyprutils 0.14.1, Hyprlang 0.6.8, Hyprcursor 0.1.13, Hyprgraphics 0.5.1
GPU: AMD Cezanne [Radeon Vega Series] (1002:1638)
Kernel: 7.1.8-arch1-3

diff --git i/src/protocols/core/DataDevice.cpp w/src/protocols/core/DataDevice.cpp
index 458bdee..2ab5484 100644
--- i/src/protocols/core/DataDevice.cpp
+++ w/src/protocols/core/DataDevice.cpp
@@ -577,9 +577,17 @@ void CWLDataDeviceProtocol::initiateDrag(WP<CWLDataSourceResource> currentSource
     m_dnd.currentSource = currentSource;
     m_dnd.originSurface = origin;
     m_dnd.dndSurface    = dragSurface;
+    m_dnd.iconOffset    = {};
     if (dragSurface) {
         m_dnd.dndSurfaceDestroy = dragSurface->m_events.destroy.listen([this] { abortDrag(); });
         m_dnd.dndSurfaceCommit  = dragSurface->m_events.commit.listen([this] {
+            // wl_surface.offset (and the dx,dy of wl_surface.attach) move the icon
+            // relative to where it already is. Accumulate, don't overwrite: a client
+            // that sets a hotspot once and then keeps drawing frames with a (0, 0)
+            // delta must keep that hotspot.
+            if (m_dnd.dndSurface->m_current.updated.bits.offset)
+                m_dnd.iconOffset += m_dnd.dndSurface->m_current.offset;
+
             if (m_dnd.dndSurface->m_current.texture && !m_dnd.dndSurface->m_mapped) {
                 m_dnd.dndSurface->map();
                 return;
@@ -714,6 +722,7 @@ void CWLDataDeviceProtocol::updateDrag() {
 
 void CWLDataDeviceProtocol::cleanupDndState(bool resetDevice, bool resetSource, bool simulateInput) {
     m_dnd.dndSurface.reset();
+    m_dnd.iconOffset = {};
     m_dnd.dndSurfaceCommit.reset();
     m_dnd.dndSurfaceDestroy.reset();
     m_dnd.mouseButton.reset();
@@ -834,7 +843,7 @@ void CWLDataDeviceProtocol::renderDND(PHLMONITOR pMonitor, const Time::steady_tp
 
     Vector2D   surfacePos = POS;
 
-    surfacePos += m_dnd.dndSurface->m_current.offset;
+    surfacePos += m_dnd.iconOffset;
 
     CBox                         box = CBox{surfacePos, m_dnd.dndSurface->m_current.size}.translate(-pMonitor->m_position).scale(pMonitor->m_scale).round();
 
diff --git i/src/protocols/core/DataDevice.hpp w/src/protocols/core/DataDevice.hpp
index 715c655..8a40cfc 100644
--- i/src/protocols/core/DataDevice.hpp
+++ w/src/protocols/core/DataDevice.hpp
@@ -174,6 +174,10 @@ class CWLDataDeviceProtocol : public IWaylandProtocol {
         WP<CWLSurfaceResource>  dndSurface;
         WP<CWLSurfaceResource>  originSurface;
         std::optional<Vector2D> touchPos;
+        // Accumulated wl_surface.offset / wl_surface.attach dx,dy of the drag icon.
+        // Per spec these are deltas relative to the icon's current position, so they
+        // must be summed across commits rather than treated as an absolute offset.
+        Vector2D                iconOffset;
         bool                    overriddenCursor = false;
         CHyprSignalListener     dndSurfaceDestroy;
         CHyprSignalListener     dndSurfaceCommit;

[BurningTreeC]

Verified: patch builds and fixes the placement (measured, not eyeballed)

Updating the "compiles untested" note in the original post -- it's now built and measured.

Setup. Patch applied on top of v0.56.2 (applies unchanged to main), built via the
Arch PKGBUILD, run as a nested compositor inside an existing Hyprland session. Chromium
ran inside the nested session under WAYLAND_DEBUG=1 so the requested hotspot is known
exactly, and a watcher sampled hyprctl cursorpos + grim together while the drag was held.

Ground truth for the measured drag (from the nested Chromium's own protocol log):

wl_data_device#6.start_drag(wl_data_source#79, wl_surface#35, wl_surface#80, 6)
wl_shm_pool#88.create_buffer(new id wl_buffer#89, 0, 237, 163, 948, 0)
wl_surface#80.attach(wl_buffer#89, -195, -133)     <- hotspot
wp_viewport#82.set_destination(237, 163)
wl_surface#80.attach(wl_buffer#91, 0, 0)           <- zero delta; must NOT reset the hotspot

So the icon's top-left should render at cursor - (195, 133).

Result. The test image places a marker dot exactly on each corner of the drag icon,
so the icon's corners can be located in the screenshot and compared against the cursor
position sampled at the same moment:

frame	cursor	predicted TL	measured TL	error	measured BR	predicted BR
2	(1168,854)	(973,721)	(976,724)	+3,+3	(1212,886)	(1210,884)
3	(1265,905)	(1070,772)	(1072,773)	+2,+1	(1308,935)	(1307,935)
4	(1267,905)	(1072,772)	(1073,773)	+1,+1	(1309,935)	(1309,935)
5	(1267,905)	(1072,772)	(1073,773)	+1,+1	(1309,935)	(1309,935)
6	(1267,905)	(1072,772)	(1073,773)	+1,+1	(1309,935)	(1309,935)

On the three static-cursor frames the bottom-right corner lands on the predicted pixel
exactly. The +1 on top-left is the colour threshold dropping the antialiased outer row of
the marker, not a real offset. Frame 2's +3 is sampling skew -- the cursor is read, then
grim runs a few ms later while the pointer is still moving.

Without the patch the top-left renders at the cursor itself, i.e. off by the full
(195, 133).

Caveats, stated plainly:

• Measured at monitor scale 1, in a nested session. renderDND does
  .scale(pMonitor->m_scale).round(), so on a fractionally scaled output the position
  quantises to whole device pixels (at 1.5x, up to 1/3 logical px). Not measured there.
• One client (Chromium). GTK4/Nautilus sends an explicit wl_surface.offset(0, 0) and so
  never exercises this path at all -- worth knowing when reproducing, since it looks
  identical but for an unrelated reason.
• Separately, and not a compositor issue: Chromium renders the ghost at 237x163 from a
  320x220 source, so the ghost is 0.74x the size of the thing grabbed. The hotspot is
  proportionally faithful, but the image around it is smaller. No compositor change
  affects that.

[tekstryder]

Bot blog.

Discussions bypassing the template should be auto-closed.

[wabarTM]

we discussed that on discord, but vax no read(