[PATCH v2 0/1] MR4068: server: Send WM_WINE_SETCURSOR with the thread input cursor handle.

[Rémi Bernon (＠rbernon)]

Which may be different from the last desktop cursor handle.

This makes the behavior better match the old winex11 behavior, which queried
the current thread input cursor handle on every mouse move to sync it with X11,
although it contradicts MSDN documentation which states that the cursor handle
is global.

This fixes the X11 cursor being visible in "Deus Ex: GOTY Edition".

--
  v2: server: Send WM_WINE_SETCURSOR with the thread input cursor handle.

https://gitlab.winehq.org/wine/wine/-/merge_requests/4068

[PATCH v2 1/1] server: Send WM_WINE_SETCURSOR with the thread input cursor handle.

[Rémi Bernon]

From: Rémi Bernon

Which may be different from the last desktop cursor handle.

This makes the behavior better match the old winex11 behavior, which queried
the current thread input cursor handle on every mouse move to sync it with X11,
although it contradicts MSDN documentation which states that the cursor handle
is global.

This fixes the X11 cursor being visible in "Deus Ex: GOTY Edition".
---
 server/queue.c | 13 +++++++++++--
 1 file changed, 11 insertions(+), 2 deletions(-)

diff --git a/server/queue.c b/server/queue.c
index fcc946ff0cb..89434570205 100644
--- a/server/queue.c
+++ b/server/queue.c
@@ -429,13 +429,22 @@ static void queue_cursor_message( struct desktop *desktop, user_handle_t win, un
     queue_hardware_message( desktop, msg, 1 );
 }

-static int update_desktop_cursor_window( struct desktop *desktop, user_handle_t win )
+static int update_desktop_cursor_window( struct desktop *desktop, user_handle_t win, int x, int y )
 {
     int updated = win != desktop->cursor.win;
     user_handle_t handle = desktop->cursor.handle;
     desktop->cursor.win = win;
     if (updated)
     {
+        struct thread *thread;
+
+        if ((thread = window_thread_from_point( win, x, y )))
+        {
+            struct thread_input *input = thread->queue->input;
+            if (input) handle = input->cursor_count < 0 ? 0 : input->cursor;
+            release_object( thread );
+        }
+
         /* when clipping send the message to the foreground window as well, as some driver have an artificial overlay window */
         if (is_cursor_clipped( desktop )) queue_cursor_message( desktop, 0, WM_WINE_SETCURSOR, win, handle );
         queue_cursor_message( desktop, win, WM_WINE_SETCURSOR, win, handle );
@@ -458,7 +467,7 @@ static int update_desktop_cursor_pos( struct desktop *desktop, user_handle_t win
     if (!win && (input = desktop->foreground_input)) win = input->capture;
     if (!win || !is_window_visible( win ) || is_window_transparent( win ))
         win = shallow_window_from_point( desktop, x, y );
-    if (update_desktop_cursor_window( desktop, win )) updated = 1;
+    if (update_desktop_cursor_window( desktop, win, x, y )) updated = 1;

return updated;
 }

[Alexandre Julliard (＠julliard)]

Alexandre Julliard (@julliard) commented about server/queue.c:
> +static int update_desktop_cursor_window( struct desktop *desktop, user_handle_t win, int x, int y )
>  {
>      int updated = win != desktop->cursor.win;
>      user_handle_t handle = desktop->cursor.handle;
>      desktop->cursor.win = win;
>      if (updated)
>      {
> -
>    struct thread *thread;
> -
> -
>    if ((thread = window_thread_from_point( win, x, y )))
> -
>    {
> -
>        struct thread_input *input = thread->queue->input;
> -
>        if (input) handle = input->cursor_count < 0 ? 0 : input->cursor;
> -
>        release_object( thread );
> -
>    }
> -

It shouldn't be necessary to find the exact child window, they all share the same thread input.

[Rémi Bernon (＠rbernon)]

On Wed Oct 11 09:21:37 2023 +0000, Alexandre Julliard wrote:
> It shouldn't be necessary to find the exact child window, they all share
> the same thread input.

Hmm, even with child windows from a different thread? I got that from `find_hardware_message_window` fwiw.

[Rémi Bernon (＠rbernon)]

On Wed Oct 11 09:31:08 2023 +0000, Rémi Bernon wrote:
> Hmm, even with child windows from a different thread? I got that from
> `find_hardware_message_window` fwiw.

I guess the difference is that `find_hardware_message_window` also needs the right thread queue, which may be different. I'll make this simpler, thanks.