Re: Getting time since server started and `XIfEvent'

On Mon, 2005-08-08 at 18:17 -0700, Travis Spencer wrote:
> On 8/8/05, Jamey Sharp <jamey-sH+B+fTmh7PR7s880joybQ@xxxxxxxxxxxxxxxx> wrote:
> > 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 clearly needed to write this stuff down anyway.

It's become an all-day project, aside from a couple breaks for food and
a half-hour spent listening to a homeless woman talking about her life,
which was kind of interesting.

> > 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:

Huh. Good to know. :-)

> 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.

If CurrentTime were a legitimate value for this function's callers, they
presumably wouldn't incur the expense of the server round-trip and would
just use CurrentTime.

> > 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?

Um... It modifies the state of a Display object, and is in Xlib, so I
think it's reasonable to consider it a new Xlib function.

The name XCL refers to the old library that I tried building first, and
arguably shouldn't appear anywhere in new code. The fact that I named
the header xcl.h... well, I don't feel *that* strongly about avoiding
the old name. :-)

> So, the pattern of using XSetEventQueueOwner would be something like this:
> 
> XSetEventQueueOwner(dpy, XCBOwnsEventQueue);
> XCBChangeProperty(...);
> ...
> XSetEventQueueOwner(dpy, XlibOwnsEventQueue);

No, as I said you can't switch event-queue owners mid-stream. You really
have to pick one or the other when the Display is opened, and stick with
it. This means that all event handling has to be ported all at once.

> 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 *)'.

OK, but gdk_x11_get_server_time is called with a GdkWindow, and you can
get the Display from that.

> >         if (e->response_type & 0x7f)
> > should check that response_type actually equals XCBPropertyNotify after
> > masking.
> 
> Ah, got ya:
> 
> if ((e->response_type & 0x70) == XCBPropertyNotify) ...

Well, 0x7f will work better than 0x70, but otherwise yeah. ;-)

> 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.

Seems reasonable.

> > 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.

Yep, you've got it exactly. I have a specific model in my head for how
the reworking *should* go, and that's what I've been trying to write
down.

The quick fix, though, is to implement your own event queue with exactly
the search and traversal primitives that you need. That's not very hard.

--Jamey

signature.asc
Description: This is a digitally signed message part

_______________________________________________
xcb mailing list
xcb-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@xxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/xcb