On Mon Jan 29 15:58:18 2024 +0000, Jinoh Kang wrote:
If `desktop->cursor.win` became invisible or transparent since the last cursor update, `update_desktop_cursor_pos` may set another window, which will cause `update_desktop_cursor_window` to emit `WM_WINE_SETCURSOR` (previously, it didn't).
- Is this actually possible? (If not, is there anything that eagerly
switches the cursor window once the old window becomes invisible or transparent?) 2. If this is the case, could this lead to some kind of deadlock? 3. Are such side effects tolerable?
The message is going to be sent, sooner or later, when the hardware message is queued. Though this is currently *after* ll-hooks have been called, and this indeed changes things a bit.
I don't think it's too much trouble, `WM_WINE_SETCURSOR` is for the user driver internal purpose only and should not trigger any kind of loopback. It's maybe even more correct that way, I don't think ll-hooks are able to prevent the desktop cursor from being physically moved.
Then I'll just drop this for now, and instead update the time alone for now using the shared writes, I think this was historically using the helper mostly for convenience.