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

Miklós Máté mtmkls at gmail.com
Thu Jul 21 13:44:00 CDT 2016


On 07/21/2016 12:12 PM, Alexandre Julliard wrote:
> Miklós Máté <mtmkls at gmail.com> writes:
>
>> On 07/21/2016 05:39 AM, Alexandre Julliard wrote:
>>> Miklós Máté <mtmkls at gmail.com> writes:
>>>
>>>> XCloseDisplay in thread_detach() closes all X windows, but the GLX windows
>>>> remain, and become zombies. If a new X window is created with the same XID,
>>>> Mesa refuses to attach a GLX window to it because of the zombie. Observed
>>>> in the ddraw test.
>>> Is there a reason that creating the GLX window on the window thread
>>> wouldn't work?
>>>
>> The problem is that Wine uses XCloseDisplay to destroy all X windows
>> created in that thread, but there is no equivalent functionality for
>> GLX. If gdi_display = windata->display, it would remove the need for
>> XSync, but the problem of zombie GLX windows would remain. I hope I
>> understood your question correctly.
> The ID should be invalidated once the display connection is closed,
> otherwise it's a Mesa bug. Have you tested it?
>
Hmm, you are right. Mesa does set an XCloseDisplay callback to clean 
things up for the display connections it encounters. If I use 
data->display instead of gdi_display for pglXCreateWindow in line 1358 
of opengl.c, the tests pass, and no zombie glx windows remain. I don't 
know if I should dare to take responsibility for this change, though, as 
I know almost nothing about GDI.

Note that the zombies cause set_pixel_format to fail, but the tests 
treat that as skip, and not fail. I don't know if anything actually 
fails due to the zombie glx windows.

Meanwhile I noticed that patch 1/2 I submitted wasn't the final version. 
opengl.c line 1430 should be Window old_client_window = None; to avoid 
the uninitialized variable warning. Should I submit a fixed version?

MM




More information about the wine-devel mailing list