Take into account that we will likely need access to wayland_surface from within many of the pointer handlers anyway
What will we need it for exactly?
We will need per-surface info to be able to properly translate between Wayland per-surface coordinates and wine coordinates, when we introduce support for surface scaling (needed for hidpi and also mode change emulation). This is mainly needed for pointer motion (and in the future, relative motion) events. The goal of this item was to ensure that I had at least thought about this and didn't end up with a design that made it difficult to access such information (`wayland_surface_lock_hwnd()` should be fine for this, especially given the relaxed robustness requirements, see below).
My impression is that you're trying to make it unnecessarily robust.
I think this is indeed the core difference of the approaches we have been discussing. My goal has been maximizing robustness because 1. this would be my default approach lacking additional information and 2. I was under the impression that it would be a requirement for the driver.
If robustness (against the kind of edge cases discussed in this thread) is not a strict requirement, then that provides me with the necessary perspective shift to make me more comfortable selecting a simpler solution. In such a case, I just want to make sure that the trade-offs have been properly explored and understood both by me and the reviewer(s).
What about keeping a single "last used" surface for the cursor and use it on enter event,
Yes, this will help simplify the code, thanks. This approach could (statistically) lead to transitionally using the wrong cursor on enter a bit more often compared to maintaining a per-surface cursor, but I think that's an acceptable compromise.
In light of all the above I have prototyped a much simpler solution (with relaxed robustness guarantees) here:
https://gitlab.winehq.org/afrantzis/wine/-/commits/wayland-part-6-no-double-... (changes in the last commit)
If given all the discussion in this thread you find such a solution acceptable, then I would be fine going forward with it. And I guess we can always increase robustness (or some particular aspects of it, as needed) in the future if we have any issues. Thanks!