Drag source icon not centered on mouse cursor during DnD (possibly wayland surface offsets unsupported?)

[pdf]

Already reported ? *

• I have searched the existing open and closed issues.

Regression?

Probably not a regression / I don't remember it happening before

System Info and Hyprland Version

System/Version info

Hyprland 0.47.2 built from branch  at commit 882f7ad7d2bbfc7440d0ccaef93b1cdd78e8e3ff  (version: bump to 0.47.2).
Date: Sun Feb 2 00:47:17 2025
Tag: v0.47.2, commits: 5767
built against:
 aquamarine 0.7.2
 hyprlang 0.6.0
 hyprutils 0.5.0
 hyprcursor 0.1.11
 hyprgraphics 0.1.2


no flags were set


System Information:
System name: Linux
Node name: hostname
Release: 6.13.5-zen1-1-zen
Version: #1 ZEN SMP PREEMPT_DYNAMIC Thu, 27 Feb 2025 18:09:27 +0000


GPU information:
00:02.0 VGA compatible controller [0300]: Intel Corporation TigerLake-H GT1 [UHD Graphics] [8086:9a60] (rev 01) (prog-if 00 [VGA controller])
01:00.0 VGA compatible controller [0300]: NVIDIA Corporation GA104M [GeForce RTX 3070 Mobile / Max-Q] [10de:249d] (rev a1) (prog-if 00 [VGA controller])
NVRM version: NVIDIA UNIX Open Kernel Module for x86_64  570.124.04  Release Build  (archlinux-builder@hostname)


os-release: NAME="Arch Linux"
PRETTY_NAME="Arch Linux"
ID=arch
BUILD_ID=rolling
ANSI_COLOR="38;2;23;147;209"
HOME_URL="https://archlinux.org/"
DOCUMENTATION_URL="https://wiki.archlinux.org/"
SUPPORT_URL="https://bbs.archlinux.org/"
BUG_REPORT_URL="https://gitlab.archlinux.org/groups/archlinux/-/issues"
PRIVACY_POLICY_URL="https://terms.archlinux.org/docs/privacy-policy/"
LOGO=archlinux-logo


plugins:

Description

When dragging a DnD item in a GTK4 application, the surface representing the dragged item is displaced right and down from the mouse cursor position (potentially off-screen near screen edges).

How to reproduce

1. Open a GTK4 application (e.g. Nautilus)
2. Initiate drag-and-drop
3. Note drag icon position

Attach not paste

• I understand that all text files must be attached, and not pasted directly. If not respected, this issue will likely get closed as spam

Checklist of files to include below

• Hyprland config - hyprctl systeminfo -c (always include)
• Crash report (always include in case of crash)
• Video (always include in case of a visual bug)
• Logs (might contain useful info such as errors)

Additional info & File uploads

hyprland_config_dump.txt

WAYLAND_DEBUG.txt

The above WAYLAND_DEBUG output snippet is from a toy app I put together to reproduce - wl_surface#48 is the dragsource, and it can be seen in the output that GTK requests wl_surface#48.offset(-43, -564) but this doesn't seem to be honored under Hyprland.

[nnyyxxxx]

When dragging a DnD item in a GTK4 application, the surface representing the dragged item is displaced right and down from the mouse cursor position (potentially off-screen near screen edges).

can you send a video, this is probably fixed in -git; mind trying that as well?

[pdf]

Kooha-2025-03-08-20-35-10.mp4

I'll try to make time to install/test against -git.

[nnyyxxxx]

that looks normal to me, what does it normally look like?

[pdf]

The icon should be under the mouse cursor, not shifted down and to the right. Maybe this shows it a little more clearly:

Kooha-2025-03-08-21-09-07.mp4

In the above I have a dock on the right of the screen, and the dragged icon appears mostly off-screen because the offset is not respected.

When setting the icon for a dragsource in GTK, you specify coordinates for the image to be shifted by, relative to the mouse hotspot. GTK implements this under wayland by sending an offset request with a negative offset on the wayland surface for the icon (you can see the offset request being sent in the wayland debug output above, and wayland docs suggest this is correct), however this doesn't appear to have any effect under Hyprland - the icon always appears as if it's rendered at 0,0 offset, and the wl_surface.offset request appears to be ignored.

[nnyyxxxx]

i'm not sure to be honest, i dont really use a file manager / dnd

try going back a couple releases to see if it still happens, this probably has always been like this

[pdf]

Yes, quite possible it's always been like this. Looks like this likely affects all drag source icons - QT also appears to issue an offset request for the icon.

No different on -git.

[vaxerski]

yes, we always render the item to the bottom right of the cursor, no matter what. Does the spec mandate something?

[pdf]

The documentation for wl_data_device::wl_drag_start says:

The icon surface is an optional (can be NULL) surface that provides an icon to be moved around with the cursor. Initially, the top-left corner of the icon surface is placed at the cursor hotspot, but subsequent wl_surface.offset requests can move the relative position. Attach requests must be confirmed with wl_surface.commit as usual. The icon surface is given the role of a drag-and-drop icon. If the icon surface already has another role, it raises a protocol error.

So with Hyprland rendering at the bottom-right, there are two issues:

• The top-left corner of the icon should be rendered at the cursor hotspot, not the bottom-right of the cursor bounds
• Subsequent wl_surfoce.offset requests for the icon surface should be honored

[vaxerski]

personal opinion: I like it the way it is.

[pdf]

One of the problems with the current implementation (besides just not operating as expected/documented in the protocol) is that near right or bottom screen edges (e.g. when iteracting with panels/docks) the icon gets pushed off-screen, with no way for the application to do anything about it.

[nnyyxxxx]

meh, what is it like on kde? can you send a vid?

[nnyyxxxx]

we could just dynamically adjust the icon so it never goes out of bounds

[pdf]

meh, what is it like on kde? can you send a vid?

Do you mean with a QT application, or under the kwin compositor? For the former, the icon is rendered exactly the same as for GTK under Hyprland, though QT also sends an offset request when the application specifies one. For the latter, I don't have a KDE install currently, but I assume they implement the spec correctly, based on their own apps (e.g. Dolphin) sending an offset req.

we could just dynamically adjust the icon so it never goes out of bounds

Wouldn't that be more complicated than just doing what the protocol says - render at hotspot initially, and then honor offset requests (if any)?

I can also imagine a scenario where an application author expects the drag icon to be displayed at the requested location for e.g. slotting an image into a hole on a surface visually.

[nnyyxxxx]

Wouldn't that be more complicated than just doing what the protocol says

meh, under 15 loc change probs

[nnyyxxxx]

patch.txt

check this out

[pdf]

But like... why not just do the correct thing?

[nnyyxxxx]

i dont know, i ahven't read like 99% of this issue to be honest, i would like to see a video of how kde does dnd that would make me not have to read all the mountain of words. my brain is a bit smol

[pdf]

I'm not sure this can be implemented correctly without some words being involved, but in as few words as possible the protocol docs say:

• Initially render top-left of icon at mouse hotspot
• If client sends wl_surfoce.offset for icon surface, apply offset

[pdf]

I don't have KDE installed atm, but under GNOME this is what it looks like:

nautilus.mp4

dolphin.mp4

I also tested under Weston and it produces the same positiong, as both compositors both follow the protocol docs and apply the offset requested by the application(s).

[nnyyxxxx]

okay, ill check it out : ) and see what i can do