Suggestions on implementing Wayland Protocol Dumper.

Srivardhan sri.hebbar at
Tue Jun 10 21:21:36 PDT 2014

Thanks All for the suggestions... Will do it in the 2nd way...


> -----Original Message-----
> From: wayland-devel [mailto:wayland-devel-
> bounces at] On Behalf Of Bryce W. Harrington
> Sent: Tuesday, June 10, 2014 2:58 AM
> To: Srivardhan
> Cc: wayland-devel at
> Subject: Re: Suggestions on implementing Wayland Protocol Dumper.
> On Mon, Jun 09, 2014 at 11:17:20AM +0530, Srivardhan wrote:
> > Hi,
> >
> > The following are the ways in which a Protocol Dumper can be
> implemented:
> > 1. Just before sending a message or when a message is received, the
> > message can be written to a file. This change can be done in
> > libwayland under #ifdef DEBUG. So when built enabling DEBUG, we should
> > get all the protocol messages.
> > 2. We can introduce another layer in Weston for monitoring. This layer
> > would act as Man in the middle. This layer would listen to a socket to
> > which all the Wayland clients would attach and this layer would in
> > turn attach to the server socket. This layer would print the messages
> > it received from the client and would transfer to the server and vise
> > a versa. This could be included in #ifdef DEBUG, so that it is enabled
only in
> DEBUG builds.
> >
> > I feel the 1st approach is simpler, What are your thoughts?
> When I worked at Canonical, us X guys would periodically get called on to
> help troubleshoot issues where a client app was getting an X11 error, and
> needed to utilize xtrace to identify the protocol error.  In some cases
> debugging was done on production or embedded hardware where we
> couldn't quite so easily recompile or reinstall X, and in one case was
> commercial software for which we didn't have source access.  So for this
> case, having the protocol dumper configurable as a separate (packaged and
> pre-compiled) application was advantageous.
> So, while #1 does indeed sound simpler, based on experience debugging
> similar issues in X, I think #2 is going to prove more flexible in the
long term.
> Bryce
> _______________________________________________
> wayland-devel mailing list
> wayland-devel at

More information about the wayland-devel mailing list