Created attachment 36357 [details]
Modified test case from bug 27595.
1. Run "cnee --record --mouse" or the attached minimal test case.
2. Move your mouse.
1. Cnee displays motion event data.
2. Test case prints "got something" whenever MotionNotify or other events are received.
Both Cnee and test case are silent.
Reverting commit "Fix Xlib/XCB for multi-threaded applications (with caveats)" (933aee1d5c53b0cc7d608011a29188b594c8d70b) makes recording work again.
With latest X server you should also apply the following fix first before using record extension:
Jamey and I fixed this in commit c115095d7f2bc4f5a4fb26380e3698fefdad7611. Turned out we had a bug in the async-reply handling in poll_for_response. Nobody noticed until someone tried to use async replies, like RECORD does. :)
The commit message:
poll_for_response: Really handle xcb_poll_for_reply getting a reply.
Don't lose async replies. That's bad.
`xlsfonts -l`, which uses XListFontsWithInfo, worked fine, because the
_XReply path worked; that path waited for replies, rather than polling.
However, XRecordProcessReplies, which does nothing but call XPending,
relied on the event-handling path to process async replies, and that was
Signed-off-by: Jamey Sharp <email@example.com>
Signed-off-by: Josh Triplett <firstname.lastname@example.org>
Record extension is now fixed, but after applying the patch, rendercheck is always dumping core.
Render extension version 0.10
Window format: r5g6b5
Segmentation fault (core dumped)
(In reply to comment #4)
> Record extension is now fixed, but after applying the patch, rendercheck is
> always dumping core.
> # rendercheck
> rendercheck 1.3
> Render extension version 0.10
> Window format: r5g6b5
> Segmentation fault (core dumped)
OK, fixed that one in commit 4a8b6528ff69f6feb8c0e119939b4ce6c088f29e. Apparently we had never tested the case where an application calls _XReadEvents and gets an I/O error and doesn't have any async replies to wait for.
I'm not sure whether rendercheck is supposed to get an I/O error there, though. You'll have to tell me if that's normal. If not, please open a new bug about it.
This should have been a separate bug, by the way. It's harder to keep track of which patch fixes what if they all have the same bug number.
OK, Josh and I botched the original fix, and the followup fix I pushed was masking the symptom, not fixing the problem. So I've reverted both and pushed a commit that actually seems to work for the RECORD test case and rendercheck and my Gnome desktop. Sorry for the confusion. Let me know if I got it right this time.
(In reply to comment #6)
> OK, Josh and I botched the original fix, and the followup fix I pushed was
> masking the symptom, not fixing the problem. So I've reverted both and pushed a
> commit that actually seems to work for the RECORD test case and rendercheck and
> my Gnome desktop. Sorry for the confusion. Let me know if I got it right this
Thanks, it seems to work now.