Bug 108008 - XEventQueued reports 0 event when event is received
Summary: XEventQueued reports 0 event when event is received
Status: RESOLVED MOVED
Alias: None
Product: xorg
Classification: Unclassified
Component: Server/General (show other bugs)
Version: unspecified
Hardware: All Linux (All)
: medium normal
Assignee: Xorg Project Team
QA Contact: Xorg Project Team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2018-09-20 20:38 UTC by Yuxuan Shui
Modified: 2018-09-23 01:42 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:


Attachments

Description Yuxuan Shui 2018-09-20 20:38:43 UTC
compton is a composite manager that uses the damage event to detect when it is necessary to repaint the screen. it creates a damage on each window, with event report type "NonEmpty", every time an event is received, it clears the damage with DamageSubtract, and repaint the screen.

Sometimes, the X server seems to buffer the damage event, thus prevent any further event from being generated. Causing the screen to freeze until some other event flushes the buffer.

Using RawRectangles seems to solve this problem, but that causes excessive damage reports to be sent, sometimes resulting in lag, because apparently WriteToClient can be expensive with some GPU drivers.
Comment 1 Yuxuan Shui 2018-09-20 23:29:17 UTC
After some investigation, the problem might be in the client library.

Packet capturing shows the damage event is indeed sent by the server, but not processed by the client.

So I added

    assert(XEventsQueued(ps->dpy, QueuedAlready) == 0);

before calling select() in compton. Freezes still happen, but this assert never fails. This seems to indicate a bug in Xlib.
Comment 2 Yuxuan Shui 2018-09-22 16:46:10 UTC
In the packets capture, I found out that X server assigned the same sequence number to a reply and an event. I think this is not supposed to happen.
Comment 3 Yuxuan Shui 2018-09-22 18:13:24 UTC
(In reply to Yuxuan Shui from comment #2)
> In the packets capture, I found out that X server assigned the same sequence
> number to a reply and an event. I think this is not supposed to happen.

Sorry, this is irrelevant.

Looks like, int xcb_in_read, an event is read. But then xcb_poll_event returned NULL in Xlib poll_for_event
Comment 4 Yuxuan Shui 2018-09-22 18:20:43 UTC
(In reply to Yuxuan Shui from comment #3)
> 
> Looks like, int xcb_in_read, an event is read. But then xcb_poll_event
> returned NULL in Xlib poll_for_event

This is not true. The event is received in xcb_poll_for_reply64 (which calls xcb_in_read). At this point in Xlib poll_for_response, poll_for_event is already called and won't be tried again. Result in the event being left in xcb's queue.
Comment 5 Yuxuan Shui 2018-09-23 01:42:42 UTC
Moved to https://gitlab.freedesktop.org/xorg/lib/libx11/issues/79


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.