[PATCH wayland 0/3] Add a debug handler for printing protocol

[Jason Ekstrand]

Pekka,
Thanks for looking at them!


On Thu, Dec 19, 2013 at 2:17 AM, Pekka Paalanen <ppaalanen at gmail.com> wrote:

> On Wed, 18 Dec 2013 20:56:17 -0600
> Jason Ekstrand <jason at jlekstrand.net> wrote:
>
> > This series adds a wl_debug function and associated handler that can
> > be set by the uesr.  The first patch is merely a rename to prepare
> > for the third. The second adds a useful helper function used by the
> > third.
> >
> > Jason Ekstrand (3):
> >   Rename wl_debug to debug_server/client
> >   Add a wl_array_printf function for easy string formatting
> >   Add a debug handler and use it to print out protocol debug messages
>
> Hi,
>
> this all looks nice. I guess the intention is that all compositors
> implement a debug logger, and then WAYLAND_DEBUG=1/server cause it to
> get filled. Clients OTOH are usually supposed to not have their own
> handler, so that the debug spew gets to stderr as usual. Something like
> that?
>

My reason is fairly simple: I'm embedding libwayland into an Android
application and I don't have access to stderr so I needed a way to re-route
things.  That said, I didn't put too much effort into thinking about the
symantics.  I think we have three options:

1) make the debug handler only for re-routing and still use the environment
variable as before.  (This is how it is implemented in my patch)

2) make the wl_debug_set_cleint/server_handler enable debugging.  The
environment variable enables debugging and installs a default handler if
none is found.

3) add an explicit mechanism for enabling debugging possibly even on a
per-client basis.  The environment variable would then be a legacy fallback.


> Some further (old) ideas:
>
> - For server prints, it would be nice to be able to identify the
> connection or the client.
>
> - For client prints it would be nice to be able to identify the current
> connection or process.
>
> - wl_arrays might be nice to print out in the dump somehow.
>
> - Strings are not escaped properly, so it is near impossible to write an
>   automatic dump parser that would get string arguments always right
>   regardless of their content.
>
> Though, if this output is never intended to be machine-read, the latter
> two don't matter


Those are all great ideas.  Unfortunately, they're kind of out of the scope
of what I'm trying to accomplish.  Hopefully someone will work on them some
day.  Digging through weston logs is a pain because there's always multiple
clients embedded in it.

Thanks,
--Jason Ekstrand
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/wayland-devel/attachments/20131219/704e6815/attachment.html>