On Wednesday 15 May 2024 03:12:26 GMT-7 Ilya Fedin wrote: > > But I still can't explain why XInternAtom would block. You'd need to > > get a backtrace of the X.org process to see if it is blocked. What > > does it mean to intern an atom? Does it send something to the root > > window to register it? > > As far as I understand it just registers a string as an integer ID > referred to as atom. So it's apparently just some string-integer map > inside X server.
Also note that other tests ran fine after these deadlocked. So if the X server had had a major bug, we should be seeing everything after this test failing. It's possible the bug does exist, just causing the reply to get dropped for this connection. But as it's that simple an implementation as you say, it isn't likely. > Yeah. Given that the event loop is in GTK code, it means it either > successfully handled the event in Qt code or haven't got to it yet. > None of which really explain the hang (other than a possibility of > triggering some bug inside X server). You said that GDK is using a different libxcb and libX11 connection from Qt. That means the Qt XCB code could not handle event sent to GDK nor vice-versa. > By the way, high DPI works ok for me on Plasma 6 with both X11 and > Wayland. I forgot to mention: add a second, high-DPI monitor to the right. I had patched Qt 5 to hack around the positions in second monitor, but the patch doesn't apply in Qt 6. So things fail there, with positions for sub-menus or windows not to correct. Beyond that, both for kwin- and plasmashell-provided components (titlebar, status bar), the icons were wrong because they were not scaled up. I think those two override the scale factor somehow. -- Thiago Macieira - thiago.macieira (AT) intel.com Principal Engineer - Intel DCAI Fleet Engineering and Quality
smime.p7s
Description: S/MIME cryptographic signature
-- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
