I reproduced the deadlock using my build of Qt 5.3.1 on RHEL 6 and
checked in a patch to trunk that addresses the issue, but I'm still
tripping up on exactly how that deadlock is occurring. Qt5 doesn't ever
call XPending(). It uses the XCB event handling functions directly.
On 11/20/14 5:28
Never mind. I put it in a debugger and figured out exactly what was
happening. XNextEvent() is being called by glib, within the body of
QEventDispatcherGlib::processEvents(). XNextEvent() locks the display,
then calls xcb_wait_for_event(), which was previously querying the atom
on the same d
Another note on this-- it seems like we may be duplicating effort in
some cases by interposing both XNextEvent() and xcb_wait_for_event().
At the moment, as long as no obvious problems are caused by this, I'm OK
with it, but in the future, it may be necessary to somehow set a
property on the di
