[Xcb] Getting time since server started and `XIfEvent'

[Travis Spencer]

On 8/8/05, Jamey Sharp <jamey at minilop.net> wrote:
> Hi Travis!

Hey, Jamey.

> I've spent the last six hours trying to reply to your e-mail, and it's
> making my head hurt. 

Thank you so much for the help, Jamey.

> I don't believe it's actually specified anywhere that X timestamps are
> "milliseconds since server started" -- I think they're only expected to
> be monotonically increasing over time. 

No, it does.  Check in the glossary at the end of the spec under Timestamp:

A timestamp is a time value, expressed in milliseconds. It typically
is the time since the last server reset....One timestamp value (named
CurrentTime) is never generated by the server. This value is reserved
for use in requests to represent the current server time.

Those last two sentences are interesting.  I wonder if that means
there is some constant that I can simply return.  That would be nice. 
I'll have to check that out.

> When using both Xlib and XCB on the same connection, only one library
> can own the event queue. By default it's Xlib. If you access XCB's event
> queue when Xlib owns it, the results are entirely uncertain; and you may
> mis-process some events if you switch ownership after events start
> arriving. (Events cannot be put back into XCB's event queue.) Your
> servertime.c test app will probably run fine since you don't make any
> Xlib calls between calling XCBChangeProperty and XCBWaitEvent, but in
> general you need to use this function from xcl.h:
> 
> enum XEventQueueOwner { XlibOwnsEventQueue = 0, XCBOwnsEventQueue };
> void XSetEventQueueOwner(Display *dpy, enum XEventQueueOwner owner);

That's an interesting name for that function.  It isn't an X function
is it?  If not, shouldn't it be called XCLSetEventQueueOwner?

So, the pattern of using XSetEventQueueOwner would be something like this:

XSetEventQueueOwner(dpy, XCBOwnsEventQueue);
XCBChangeProperty(...);
XCBFlush(c);

while ((e = XCBWaitEvent(c)))
{
    if ((e->response_type & 0x7f) == XCBPropertyNotify)
    {
        XCBPropertyNotifyEvent *event = (XCBPropertyNotifyEvent *)e;
        ....
    }
}

XSetEventQueueOwner(dpy, XlibOwnsEventQueue);

If I have the idea right, then one problem: when this static function
is called, it doesn't have a Display pointer; it only has a
connection, but XSetEventQueueOwner needs a Display.  I could pass a
Display along also or instead of the XCBConnection, but, since its
static, I'm trying to use only XCB types.  It is times like these that
I yearn for `XCLDisplay(XCBConnection *)'.

> Also, the XCBSync isn't necessary since you're using XCBWaitEvent: an
> XCBFlush should be sufficient. Actually I'm very confused now because it
> seems like XCBWaitEvent should flush if no events are in the queue, but
> it doesn't. 

Ya, the app just hung, so I added the call to XCBSync.  I will switch
it to XCBFlush though.

>         if (e->response_type & 0x7f)
> should check that response_type actually equals XCBPropertyNotify after
> masking.

Ah, got ya:

if ((e->response_type & 0x70) == XCBPropertyNotify) {
    ....
}

This masking is never covered in the tutorial's event section:
http://cvs.freedesktop.org/*checkout*/xcb/xcb/doc/tutorial/index.html#xevents.
 I think it probably should be.

> > The thing that I am especially unsure about is the port of XIfEvent in
> > the function get_server_time_xcb.  I replaced that function with a
> > call to XCBSync and a loop that processes all of the events.  If I'm
> > not mistaken, XIfEvent leaves all events in the queue except the one
> > for which the predicate returns true.  My port, however, is removing
> > all events including the one that is being sought after.
> 
> Yes, you haven't ported it exactly. As you say, you're only supposed to
> remove the event that matched.
> 
> What to do instead? Six hours on that question and counting... I'll get
> back to you.

I'm not exactly sure, but it seems to me that Xlib's event queue isn't
really a queue at all.  Its a list that masquerades as a queue.  On
the other hand, XCB's event queue is a bona fide queue in every sense.
 As a result, porting Xlib apps that are used to calling functions
that access the events willy-nilly require some major reworking.

> > If it looks good or after it does, I'll write up a little blurb about
> > it and add it to the porting guide that I'm working on.
> 
> Great! I wonder how "little" the blurb will turn out to be
> though...? :-)

If we cover it all in this thread, it will be real short -- a link to
the list's archive ;-)

-- 

Regards,

Travis Spencer