On 8 March 2016 at 17:01, Jacek Caban jacek@codeweavers.com wrote:
Signed-off-by: Jacek Caban jacek@codeweavers.com
If we call XGrabPointer on a window belonging to a different thread, we may end up handling its events with different display and being unable to associate X11 window with HWND.
Is calling SetCapture() on a window from a different thread really supposed to be valid? Assuming it is, wouldn't it then be easier to grab the window from the correct thread instead? (Similar to how e.g. WM_X11DRV_CLIP_CURSOR works.)
Hi Henri,
On 03/09/16 16:02, Henri Verbeet wrote:
On 8 March 2016 at 17:01, Jacek Caban jacek@codeweavers.com wrote:
Signed-off-by: Jacek Caban jacek@codeweavers.com
If we call XGrabPointer on a window belonging to a different thread, we may end up handling its events with different display and being unable to associate X11 window with HWND.
Is calling SetCapture() on a window from a different thread really supposed to be valid?
Yes, I think so. Also note that the HWND we're capturing is not necessary the same as X11 window we grab (it may be its child belonging to a different thread than its parent), so Windows restrictions don't apply here.
Assuming it is, wouldn't it then be easier to grab the window from the correct thread instead? (Similar to how e.g. WM_X11DRV_CLIP_CURSOR works.)
Yes, we could do that, although I'm not sure this sort of complication is the right thing in this case. I thought more about this and I think that another solution will be better.
I should add that even if we call XGrabPointer from a different thread, we don't necessary end up receiving events in a different thread (or a different connection to be precise). According to my testing, in most cases we still receive events in the thread owning the window. There are, however, some cases when we don't. I can reproduce receiving in a different thread with my tests, but even then it's not consistent. When I tried to trace X11 calls, it started to behave differently and received events in owning thread. It sounds like some sort of race on X11side. My previous patch fixed it by accepting both behaviours in Wine. Instead, we could try harder to get a consistent behaviour from X server. I will send a patch that achieves that.
Thanks, Jacek