[PATCH 2/2] winex11: track glx windows per thread

[Miklós Máté]

On 08/02/2016 03:37 AM, Alexandre Julliard wrote:
> Miklós Máté <mtmkls at gmail.com> writes:
>
>> I did some further testing, and it doesn't work. Mesa glx maintains
>> its state per-display, and creating a drawable with one display
>> connection but makecurrent with an other one can lead to bad things.
>> Unfortunately, wine-csmt likes to do those from separate threads, so
>> the thread-specific display connections cannot be used instead of the
>> global gdi_display.
> So why does it work when we use the window as drawable directly?
>
Sorry, I noticed now that I made a little mistake there. The problem is 
createwindow vs. createcontext, because makecurrent uses the display 
connection remembered in the glx context (on its creation).

Mesa glx remembers things per-display: basically every glx call starts 
with struct glx_display *const priv = __glXInitialize(dpy).

When an X window is made current to a context (glx 1.0 style), Mesa 
creates the glx and dri drawables, stores them with the display of the 
context, and when an other window is made current, finds them with the 
display of the context, and destroys them. No problem. Except that 
SW:KotOR wants the contents of its window to be kept even when it is not 
current to a glx context, and Mesa only supports that with glx 1.3.

When a glx window is created (glx 1.3 style), Mesa glx remembers it with 
the display specified in glXCreateWindow. If makecurrent is called with 
a glx window and a glx context that were created with different display 
connections, Mesa doesn't find anything about that window on the display 
of the context, so it assumes that it's an X window a-la glx 1.0. It 
tries to assign glx and dri drawables to it, and it ends up bad. 
Sometimes the X server just rejects the drawing calls, but most of the 
time it also sends fatal error.

I checked the glx specification, and I don't see anything on using 
multiple display connections. I'm also limited to using Mesa, and can't 
check how the proprietary drivers handle this issue.

MM