<div dir="ltr">Pekka,<br>Thanks for looking at them!<br><div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Dec 19, 2013 at 2:17 AM, Pekka Paalanen <span dir="ltr"><<a href="mailto:ppaalanen@gmail.com" target="_blank">ppaalanen@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On Wed, 18 Dec 2013 20:56:17 -0600<br>
Jason Ekstrand <<a href="mailto:jason@jlekstrand.net">jason@jlekstrand.net</a>> wrote:<br>
<br>
> This series adds a wl_debug function and associated handler that can<br>
> be set by the uesr.  The first patch is merely a rename to prepare<br>
> for the third. The second adds a useful helper function used by the<br>
> third.<br>
><br>
> Jason Ekstrand (3):<br>
>   Rename wl_debug to debug_server/client<br>
>   Add a wl_array_printf function for easy string formatting<br>
>   Add a debug handler and use it to print out protocol debug messages<br>
<br>
</div>Hi,<br>
<br>
this all looks nice. I guess the intention is that all compositors<br>
implement a debug logger, and then WAYLAND_DEBUG=1/server cause it to<br>
get filled. Clients OTOH are usually supposed to not have their own<br>
handler, so that the debug spew gets to stderr as usual. Something like<br>
that?<br></blockquote><div><br></div><div>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:<br>
<br>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)<br><br>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.<br>
<br></div><div>3) add an explicit mechanism for enabling debugging possibly even on a per-client basis.  The environment variable would then be a legacy fallback.<br></div><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

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