Weird dispatch ordering of display events

[Pekka Paalanen]

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?

Hi,

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.

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):
http://wayland.freedesktop.org/extras.html

These tools show you the correct message order on the wire, while
WAYLAND_DEBUG=client shows you the dispatch order.


Thanks,
pq