Bug 107568 - XSYNC extension: AlarmNotify events never being received from alarm created using SERVERTIME with XSyncPositiveTransition
Summary: XSYNC extension: AlarmNotify events never being received from alarm created u...
Status: RESOLVED MOVED
Alias: None
Product: xorg
Classification: Unclassified
Component: Server/General (show other bugs)
Version: 7.7 (2012.06)
Hardware: All Linux (All)
: medium major
Assignee: Xorg Project Team
QA Contact: Xorg Project Team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2018-08-14 12:00 UTC by i336_
Modified: 2018-12-13 22:40 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments
XSYNC alarm event test demonstration program (see bug report text or consult code for arguments) (2.95 KB, text/x-csrc)
2018-08-14 12:00 UTC, i336_
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description i336_ 2018-08-14 12:00:07 UTC
Created attachment 141080 [details]
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.
Comment 1 i336_ 2018-08-14 13:08:49 UTC
Edit/Update: Ignore my question about IDLETIME at the end. I specifically need a consistently increasing counter, only SERVERTIME would work.
Comment 2 i336_ 2018-08-15 03:58:43 UTC
ARGH.

So, I decided to bite the bullet; meson was less difficult to figure out than I feared. Good thing, too, because autoconf was producing broken Makefiles. Anyway.

"Mechanism not policy" MY FOOT.

- SERVERTIME's SyncCounterType is XSyncCounterNeverDecreases.

- SyncComputeBracketValues() ONLY allows XSyncPositiveTransition alarms to respond to NON-XSyncCounterNeverDecreases counters!! (XSyncPositiveComparison, conversely, only works WITH XSyncCounterNeverDecreases counters.)
  
  ...
  } else if (pTrigger->test_type == XSyncPositiveTransition && ct != XSyncCounterNeverDecreases) {
  ...

- If I change the != to == above, or remove the 2nd comparison entirely, I get my alarm just fine.

- Wat.

- WAT.

- ...Why :(

- Whoever appropriate really needs to update the documentation, which is *wildly* inaccurate.

I think I have to go back to the drawing board now because, as I noted in my first message, using XSyncPositiveComparison returns an absolute flood of events until I can manage to eke out an XSyncChangeAlarm to set events=0. Over TCP or on slow systems, this approach is untenable.

I welcome suggestions for alternative ways to get an X server to kick a client's network socket periodically, because that's my high-level goal(/problem).
Comment 3 GitLab Migration User 2018-12-13 22:40:40 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/xorg/xserver/issues/546.


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.