Incredibly strange wl_pointer enter events on layer shell surfaces

[Mabi19]

I'm not 100% sure if this is a bug, but it's really weird.

Hyprland version

0.49.0 (from the Arch Linux repos)

Regression

No, as far as I'm aware

Describe the bug

I'm making an app which works similarly to slurp, in that it spawns fullscreen layer shell surfaces on each output for selection. But I'm experiencing strange behavior with the wl_pointer.enter events I get initially (before moving the mouse).

For context, I have two monitors connected:

• a 2560x1440@180 at position 0, 0, scale 1 (ID 0)
• a 1680x1050@60 at position 2560, 250, scale 1 (ID 1)

1. Both the surfaces get created, receive their initial configure, and attach buffers.
2. The surface on monitor 0 gets its wl_pointer enter event: wl_pointer#20.enter(3006992, wl_surface#26, 2217.18750000, 1018.29687500) This event is, as far as I can tell, perfectly normal (I have the pointer on monitor 0 at that position).
3. The surface on monitor 1 gets a wl_pointer enter event, even though the cursor wasn't moved and is still on monitor 0: wl_pointer#20.enter(3006997, wl_surface#34, -2902.80859375, 518.29687500). The coordinates are not only not inside the surface, but also at the wrong position relative to the monitor 1 surface - they should be at (-342, 768), and thus are offset by (2560, 250).

Here's the full WAYLAND_DEBUG=1 log from my app:
wl-debug-pointer-events.log

Reproduction steps

I can also reproduce the weird enter event with WAYLAND_DEBUG=1 slurp -o with my two monitors connected, although slurp's functionality is unaffected because it gets the pointer events in the reverse order for some reason.

System info and config

hyprland-sysinfo.txt

[vaxerski]

that is odd indeed. Can you post a link to the app for repro?

[Mabi19]

https://github.com/Mabi19/spaceshot
needs a C23 compiler and the vala toolchain (the vala part can be disabled via build option)
easiest to see on the output-picker branch (run spaceshot output, the wrong screen should be highlighted before moving the mouse)
the process will remain active after screenshotting; that's normal because it also copies and thus has to wait until the selection cancels

The weird event also appears in the log for WAYLAND_DEBUG=1 slurp -o, but slurp's functionality isn't affected by it because it always gets the events in the other order.

Occasionally my app will get the events in the reverse order, like slurp - that seems to suggest a race of some kind. Although this wouldn't be an issue without the weird second enter event anyway

[vaxerski]

that seems to suggest a race of some kind

likely which surface is created first.

[Mabi19]

I just tried it again out of curiosity and now I can reproduce it on slurp. Something's probably changed between 0.49 and 0.50 such that the race now ends badly for slurp as well.

Running slurp -o with my cursor on my left monitor (ID 0) will make no screen initially selected (the bad wl_pointer.enter is not above any monitor after all), but when it's run with the cursor on the 1680x1050 the other monitor will be initially selected.

That second case is interesting, so here are the relevant events.
wl_surface#3 is the surface on the left monitor (ID 0), wl_surface#13 is the surface on the right monitor (ID 1). The cursor is at global position (3715, 870), or on the right monitor (the one with surface 13)

# enters at correct position but wrong surface
[2889955.335] {Default Queue} wl_pointer#17.enter(3688834, wl_surface#3, 3714.67968750, 870.14843750)
[2889958.504] {Default Queue} wl_pointer#17.leave(3688838, wl_surface#3)
# enters at correct surface but wrong position (huh???)
# the correct position relative to this surface is (1155, 620)
# BUT this position relative to surface 13 is on the left monitor, which is why (I assume) slurp thinks the cursor is over there
[2889958.507] {Default Queue} wl_pointer#17.enter(3688839, wl_surface#13, -1405.31640625, 370.14843750)

[Mabi19]

sorry but WHAT THE FUCK
after restarting HL it goes back to working properly (at least with slurp I didn't test mine). BUT dpms off causes shenanigans
namely, my left monitor cannot really DPMS and seems to just turn off instead
this reverses the monitor order in hyprctl monitors: on a fresh boot of HL, the order is

1. DP-1, or the left monitor (ID 0)
2. HDMI-A-1, or the right monitor (ID 1)

but after I toggle DPMS off and on, the order's like this:

1. HDMI-A-1, or the right monitor (ID 1)
2. DP-1, or the left monitor (ID 0)
   The bug this issue is about only happens when the monitors are in the second order.

[vaxerski]

but after I toggle DPMS off and on, the order's like this:

some monitors physically simulate a poweroff for whatever god-forsaken reason and that might mess with IDs

the fact that issues happen with the order reversed just suggests a race even more