[PATCH wayland] add apis to enable/disable wayland debug at runtime

[Marek Chalupa]

On 12/07/2015 01:05 PM, Pekka Paalanen wrote:
> On Mon, 7 Dec 2015 11:21:15 +0100
> Marek Chalupa <mchqwerty at gmail.com> 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