Weird dispatch ordering of display events
alexl at redhat.com
Tue Apr 21 04:26:21 PDT 2015
On tis, 2015-04-21 at 14:23 +0300, Pekka Paalanen wrote:
> On Tue, 21 Apr 2015 11:17:17 +0200
> Alexander Larsson <alexl at redhat.com> wrote:
> > I just spent some time debugging the wrong thing due to a weird change
> > in wayland 1.5. A new queue was introduced for the display itself,
> > handling things like delete_id. This queue is always dispatched,
> > independent of what other queues are dispatched.
> > However, it is always dispatched *before* the regular queue. This can
> > look pretty weird in the client side WAYLAND_DEBUG output, because if
> > you do an operation like bind()+display_roundtrip, you will see the
> > delete_id for the roundtrip callback before you see any results from the
> > bind.
> > This doesn't seem to be a problem in practice, because we resolve the
> > ids at event queue time, not dispatch time, so the events dispatch to
> > the right place anyway, but it is very confusing when debugging.
> > Maybe we can move the dispatching of the display queue to after
> > dispatching the regular queue in wayland-client.c:dispatch_queue(), to
> > make this a bit less confusing?
> but that would only solve it for the default queue, right? If you had
> another user wl_event_queue, then looking at those events would still
> be confusing.
True. And it would still reorder the events, just move delete_id later
rather than earlier.
> I can't say off-hand whether that change would be ok. Instead, I'd like
> to suggest other forms of protocol dumping (see to the end):
Yeah, i'll use these from now on instead. Thanks.
Alexander Larsson Red Hat, Inc
alexl at redhat.com alexander.larsson at gmail.com
He's a short-sighted umbrella-wielding vagrant plagued by the memory of
his family's brutal murder. She's a scantily clad antique-collecting
archaeologist who believes she is the reincarnation of an ancient
Egyptian queen. They fight crime!
More information about the wayland-devel