Can not deal with multiple connections when parsing libwayland's WAYLAND_DEBUG=1 output

[wmww]

Currently there is no possible solution to this problem (workarounds below). I'm creating this issue as an explanation.

Background

Any Wayland client or server built with libwayland produces Wayland messages on stderr when run with the environment variable WAYLAND_DEBUG=1 set. The produced output is similar to wayland-debug's unfiltered output, but uglier and with less context. There is one critical missing piece: there is no info about which connection a message is on.

wayland-debug fails when parsing WAYLAND_DEBUG=1 output with multiple connections. I will not put effort into making it continue to syntax highlight in this case, as most of it's other features would still be impossible. Instead, you can try...

Workarounds

GDB mode

If you can run as a GDB extension (./main.py -g some_wayland_compositor), this problem goes away. GDB mode is great, and has extra features (breakpoints on Wayland messages!), but you need libwayland debug symbols installed and it can be slow in some cases.

Run wayland-debug on the client you care about

Clients generally only make a single Wayland connection, so using the WAYLAND_DEBUG=1 output from a client instead of a compositor might fix the problem.

Only spew client or server messages

Instead of WAYLAND_DEBUG=1, you can also run a libwayland app with WAYLAND_DEBUG=client or WAYLAND_DEBUG=server. This will only show messages from that type of connection. This usually won't work, as the most common problem is when a compositor has multiple client connections. Even if you are only running one client, wallpaper and panels may use Wayland internally.

[nickdiego]

Hi @wmww

First, thanks for this nice tool!
I've been using it to analyze Chromium Wayland logs in my devel workflow, and it's really helpful. Chromium happens to fall in this multi-connection case (GTK's one + its own connection), and I've just come across this issue and couldn't find a way to filter the log messages by connection in 'piping mode'. Could you confirm if that's the case or am I missing something? I've ended up digging into the code and hacked it a bit to get this connection filter working, would that be upstreamable or would you have any suggestion for a better approach/impl?

I'd appreciate your feedback.

[wmww]

That will only work with a patched libwayland. Are you using a libwayland with the patches? The normal way to do that is use the wayland-debug snap and wayland-debug --run chromium.

The way you implemented it isn't quite what I would want to upstream. As noted in #56 we already sort of have this feature, but it's implemented in the wrong place. You could work on that if you want, or just use your patch if it works for you. I should fix #56 at some point.

[wmww]

@nickdiego never mind I fixed it. A simple -f 'B:' should work with latest master. Please test when you get a chance and let me know if it works/if it breaks anything else. Hopefully I'll get some feedback before I get around to making a new release. It won't make it into the snap until then so you'll have to build a patched libwayland (as described here, it's easy)

[nickdiego]

That will only work with a patched libwayland. Are you using a libwayland with the patches?

Yes, but in my case I patch directly chromium's in-tree libwayland fork. I'm considering even to propose to merge those patches there. Unless you're planning to try to upstream them in the near future, is that the case?

The normal way to do that is use the wayland-debug snap and wayland-debug --run chromium.

Yup, I've tried that out, though (before your today's patches) it used to follow the most recent connection. Is that correct? or was the X: matcher syntax already supposed to work?

The way you implemented it isn't quite what I would want to upstream. As noted in #56 we already sort of have this feature, but it's implemented in the wrong place. You could work on that if you want, or just use your patch if it works for you. I should fix #56 at some point.

@nickdiego never mind I fixed it. A simple -f 'B:' should work with latest master. Please test when you get a chance and let me know if it works/if it breaks anything else. Hopefully I'll get some feedback before I get around to making a new release. It won't make it into the snap until then so you'll have to build a patched libwayland (as described here, it's easy)

Cooool! :) Thanks for doing that. I'll for sure test that asap and report back here. Thanks a lot!

[nickdiego]

Yay! Just checked and it works really well! And it doesn't seem to have broken anything else (haven't tested so much though). Thanks again!

[wmww]

Fantastic. Yeah previously there was always one "current" connection, which you could manually switch but this was only really practical in GDB mode. Now it shows messages from all connections unless one is explicitly selected.