On 12/07/2015 01:05 PM, Pekka Paalanen wrote:
On Mon, 7 Dec 2015 11:21:15 +0100
Marek Chalupa <[email protected]> wrote:
Hi,
I like this idea, it can be handy when debugging just a part of code (I
wrote similar patch once actually, but then I forgot about it and never
sent it to the list). However, the implementation could be better IMHO:
I don't think we should move the variables to wayland-util.c. You don't
need debug_server in wl_debug_client_enable() and vice versa, so you can
keep the original variables in place. Also the functions declarations
shouldn't be in wayland-private.h, since this file is not installed and
you WL_EXPORT them. If it is a public API it should be in
wayland-client/server-core.h (and implementation in client/server.c files)
And the patch does not apply due to some binary blob
Hi,
do you think this is really an appropriate approach?
If I as a developer debugging a problem want to use WAYLAND_DEBUG, I
would be very upset if the program touched it behind my back.
I don't suppose programs would use it as a regular feature, just
developers when debugging (manually putting it into the code). True is
that in that case you don't need it as a public API.
There is also the problem, that you cannot toggle this when a
connection has already been created, because you would have lost
information necessary to interpret the following messages.
Is there really something that the debug tools listed in
http://wayland.freedesktop.org/extras.html
cannot easily offer?
Nope, I use only these :) I just remember that toggling the debug flag
in libwayland worked well before for me (when I did't want to use
WAYLAND_DEBUG for some reason). Nowadays I just use wldbg and set up
filters there.
Also, one must be *very* careful when using WAYLAND_DEBUG to inspect
timings, because it is *not* telling you when a message crosses the
wire.
yep
Enhancing WAYLAND_DEBUG has been discussed before. Simply adding PID
and/or connection identification to the prints would help a lot, and
IIRC there were even some patches drafted. It is better to filter
afterwards than during capture, because if you miss something on
capture, the whole trace may be useless. One problem with this was that
we do not have any identifier to match a connection in the server side
to a client automatically and reliably.
Perhaps even a new WAYLAND_DEBUG mode that would write files per
connection and server vs. client? But you want to be careful to avoid
creating security risks.
Thanks,
pq
On 11/13/2015 11:33 AM, 박성진 wrote:
Hello,
I added two apis in wayland-util to enable/disable display of wayland debug
information at runtime.
I had a difficulty to see wayland debug information at runtime when I'd
like to debug both a compositor and client(s).
And I found that there is no proper apis yet to enable/disable wayland
debug information at runtime.
Actually, we already know that we can see wayland debug information by
setting WAYLAND_DEBUG environment to 1.
But the environment will merely check when a compositor creates a wayland
display or a client tries to connect to an wayland display.
IMO, it's better to have the additional apis to enable/disable wayland
debug information at runtime.
It would also help if we are to catch the problems associated with timing.
Plz kindly review this patch.
Thanks,
Sung-Jin Park
_______________________________________________
wayland-devel mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
