QXcbEventReader uses a non-recursive mutex (one might call this begging for trouble, but well...) and KWin calls QX11Info::getTimestamp() when activating a window after the active window closed (see backtrace) This sucks a bit, we either need to defer activation to the end of the eventloop (bad idea, since we're gonna loose the formerly active client until then) or avoid fetching the X11 timestamp while we're in the eventloop. Latter will inevitably collide w/ any solution reg. bug #348569 *AND* it's pretty hard to assure we're not causing other access to the eventreader from the eventfilter. => Maybe ask Qt to use a recursive mutex in 5.6? Other ideas? Reproducible: Always
Created attachment 97250 [details] Backtrace by Jürgen Scholz, originating from unrelated bug #358245 The backtrace that made me aware of the problem, it's not related to the bug it was originally filed on.
(In reply to Thomas Lübking from comment #0) > => Maybe ask Qt to use a recursive mutex in 5.6? Sounds like the best idea. The API Qt offers shouldn't dead-lock in a correct usage.
They might argue that our "correct usage" is a native event filter ;-) Maybe we'll have to -steal- "borrow" QXcbConnection::getTimestamp()
(In reply to Thomas Lübking from comment #3) > They might argue that our "correct usage" is a native event filter ;-) > > Maybe we'll have to -steal- "borrow" QXcbConnection::getTimestamp() No need to steal, I wrote the code (9c45260942c0ee32267e651d981bfa33a6acb64d) ;-) And the reason for that was that it's impossible to implement it in a native event filter (at least back then).
Thank you for the bug report. As this report hasn't seen any changes in 5 years or more, we ask if you can please confirm that the issue still persists. If this bug is no longer persisting or relevant please change the status to resolved.
No idea whether that's still reelvant, this "bug" discusses working around a threading issue in Qt's X11 code that existed in 2016
Lets assume not given we're talking about a hypothetical many years later