XSYNC extension: AlarmNotify events never being received from alarm created using SERVERTIME with XSyncPositiveTransition
Submitted by i336_
Assigned to Xorg Project Team
Link to original bug (#107568)
Description
Created attachment 141080 XSYNC alarm event test demonstration program (see bug report text or consult code for arguments)
Tested with: 1.17.2 (X :0); 1.14.0 (TigerVNC 1.8.0). I THINK I'm on 7.7?
I'm currently building a small X client library from scratch for research purposes. I'm up to implementing support for creating XSYNC alarms and getting notify events, and have gotten stuck on an inconsistency I can't figure out.
Essentially, I can't seem to get any AlarmNotify events if I use SERVERTIME as the counter source, IF I'm using a test-type of XSyncPositiveTransition.
If I use XSyncPositiveComparison, I get events from SERVERTIME or IDLETIME; indeed, I am promptly drowned in them until I hastily Change the alarm to be in the future again.
If I use IDLETIME, both XSyncPositiveTransition and XSyncPositiveComparison work fine and deliver notify events.
But with SERVERTIME, only XSyncPositiveComparison works. XSyncPositiveTransition confusingly leaves me hanging.
In other ASCII,
+------------+----------+
| SERVERTIME | IDLETIME |
+-------------------------+------------+----------+ | XSyncPositiveComparison | Yup | Yup | +-------------------------+------------+----------+ | XSyncPositiveTransition | Crickets | Yup | +-------------------------+------------+----------+
The event basically never appears - in fact, no events come through. I'm just using Xlib and (as yet) have no windows mapped.
I've attached a fairly straightforward test/demo program that allows you to pick the counter source and test-type using commandline arguments:
-i use IDLETIME -s use SERVERTIME
-c use XSyncPositiveComparison -t use XSyncPositiveTransition
Suggestions include -i -t to begin with, then -i -c, then -s -c, then [the dreaded] -s -t .
The program specifies a timeout of 1 second beyond the counter's current value (the exact usage scenario I have in mind for a target application), then force-exits 1 second after that (it uses XPending() so XNextEvent() doesn't stall). Note that -c will result in a bit of a verbose event flood between the event receipt and the exit.
I am very interested to hear comments and feedback, and very hopefully news about something I missed!
IIUC, SERVERTIME is truncated to 32 bits (?), but I don't think wraparound is affecting anything, at least not in terms of client-side math.
I've had a bit of a look at https://gitlab.freedesktop.org/xorg/xserver/blob/master/Xext/sync.c, but I haven't been able to discern anything. In fact I've only become even more confused: line 541 notes how the protocol documentation states that timers are deactivated if their delta is 0 and XSyncPositiveComparison is used, and the code following the comment does indeed seem to back that up. But I'm using a delta of 0 in the attached demo program, and it appears to work anyway. Some understanding would be awesome.
Also, if anyone has any suggestions for alternative ways the X server can periodically kick a network idle loop (in situations where access to a timeout parameter is not possible.....), I am VERY interested to hear ideas. (I'm motivated enough to dig up obscure extensions nobody's used in 27 years, so...)
How prevalent is the IDLETIME counter? Will I find it "everywhere"? Did it exist in the original XSYNC rcs checkin circa 1994? The documentation guarantees SERVERTIME's ubiquity, and I want to be portable.
Attachment 141080, "XSYNC alarm event test demonstration program (see bug report text or consult code for arguments)":
xsync-alarm-test.c
Version: 7.7 (2012.06)