[RFC wayland v2 0/2] Wayland protocol dumper

Boyan Ding stu_dby at 126.com
Fri Jul 25 20:37:47 PDT 2014


Hi,

Thanks for all the advice. I also found integrating the code in wayland
repository is not very comfortable. Actually I had to make a separate
branch to keep track of my own development and format patches before
sending them here. So I set up a self-contained repository on github [1]
and my development will continue there.

The code now is identical to v2 patches I sent, with stripped (to avoid
unneeded depenencies) version of wayland utilities.

As for the choice between reusing and duplicating, I prefer to reuse a
little code about low level connection handling and duplicate others.
I'll keep my code as clean as possible. My point is to keep code simple
and not to make reusing code a burden.

Regards,
Boyan Ding

[1] https://github.com/dboyan/wayland-tracer

On Fri, 2014-07-25 at 15:53 +0300, Pekka Paalanen wrote:
> On Wed, 23 Jul 2014 16:21:19 +0800
> Boyan Ding <stu_dby at 126.com> wrote:
> 
> > The v2 of patches sees a lot of new code and the most notable change
> > is the introduction of "server mode". Under server mode, the program
> > will act as a wayland server and can accept multiple clients via
> > WAYLAND_DISPLAY variable. An interesting usecase of this feature is to
> > trace all clients of a compositor.
> > 
> > To make it run under server mode, run
> > shell> wayland-tracer -S SOCKET_NAME
> > SOCKET_NAME is a value like wayland-0 or so. If we set WAYLAND_DISPLAY
> > environment variable to SOCKET_NAME and launch a wayland app, that app
> > will be traced.
> > 
> > To make it run under default mode (now called "single mode"), run
> > shell> wayland-tracer -- program arguments ...
> > 
> > Also, EPOLLHUP is handled correctly in this version.
> > 
> > The next step will be adding xml protocol parsing and wire data
> > analysing according to protocol files. This will be much tougher but I
> > hope I can finish that.
> > 
> > Boyan Ding (2):
> >   connection: Move definitions
> >   Add a wayland protocol dumper wayland-tracer
> > 
> >  .gitignore            |   1 +
> >  Makefile.am           |  10 +
> >  configure.ac          |   7 +
> >  src/connection.c      |  18 +-
> >  src/tracer.c          | 689 ++++++++++++++++++++++++++++++++++++++++++++++++++
> >  src/wayland-private.h |  18 +-
> >  6 files changed, 727 insertions(+), 16 deletions(-)
> >  create mode 100644 src/tracer.c
> > 
> 
> Hi,
> 
> excellent work! :-)
> 
> As I understand there are also other people writing protocol dumpers,
> and I do not see any technical reason why it should live in the wayland
> repository, I would suggest creating your own project. I believe it
> will be much more comfortable for you, being in total control, not
> having to rebase/merge and so on. This is also what I tried to refer to
> with the "self-contained project" in my original call-out.
> 
> You can freely pick your dependencies and frameworks there, which is
> not something you can easily do in the wayland repository.
> 
> It would also be nicer for your users, as they don't need two different
> checkouts of libwayland, other one just for building the dumper.
> 
> In any case you are welcome to post news on your progress to
> wayland-devel. A bit of competition might be insipiring, and I wouldn't
> want to announce the winner on the starting line by merging this
> too soon. :-)
> 
> I think you should rather duplicate than re-use the few bits from
> libwayland internals, I feel that would be a cleaner approach and it's
> not that much code anyway (is it?). You are free copy anything you need
> from Wayland and Weston code bases under the given licence (don't
> forget to copy the copyrights).
> 
> If all goes well and you are happy with the work, you could very soon be
> running a FOSS project of your own! Or if you just want to develop this
> once, push it upstream, and then move on, that is ok too. Or maybe
> someone else would like to take over the project later. Do you have
> plans in this regard?
> 
> I think your project should live for a while so we see where it is
> going, and at least do the decoding with XML into text form before we
> look into merging it into wayland repository. I think anything with a
> GUI (which would be awesome!) is getting beyond the scope of the wayland
> repository.
> 
> 
> Thanks,
> pq





More information about the wayland-devel mailing list