On Tue, 14 May 2024 11:44:24 -0700 Thiago Macieira <thiago.macie...@intel.com> wrote:
> On Tuesday 14 May 2024 09:23:50 GMT-7 Ilya Fedin wrote: > > I fail to imagine how that could be... gtk shouldn't care how Qt > > gets DPI and especially it shouldn't make it hang on XInternAtom > > (which makes X server either to get an integer from its internal > > string-integer map or increment the internal counter and add it to > > the aforementioned map with the supplied string, as far as I > > understand, no client-to-client messaging here). > > Think in terms of side-effects. It doesn't care how Qt does it, but > the side- effect of what we are doing could be important, since we're > sharing libxcb internal state, the xcb_connection (I think), and the > X11 server itself. It doesn't share xcb connection nor xlib display. If the trace was with debug symbols for gtk, it would be easier to find what gtk does when the side effect happens... > Have you tried running a simple test like tst_qguichronotimer in a > loop to see if it is indeed a race condition? I remember I was trying to run cmptest lots of time, with different environment variables, trying to recreating CI environment... > In any case, if all else fails, declare it an undiagnosed GDK bug and > detect whether our dispatcher is QXcbGlibEventDispatcher. If it is, > then don't use the new feature. That would disable the code for everyone as the glib dispatcher is always used, even on KDE. -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development