<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Jul 26, 2016 at 3:09 PM, Mark Gaiser <span dir="ltr"><<a href="mailto:markg85@gmail.com" target="_blank">markg85@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 dir="ltr"><div><div class="h5"><div class="gmail_extra"><div class="gmail_quote">On Tue, Jul 26, 2016 at 2:03 PM, Sebastian Kügler <span dir="ltr"><<a href="mailto:sebas@kde.org" target="_blank">sebas@kde.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hey,<br>
<br>
[Please keep both lists addressed.]<br>
<br>
Debugging multiscreen issues is a nightmare:<br>
<br>
- there are at least 4 different processes involved (kded, kcmshell /<br>
systemsettings, kscreen_backend_launcher and plasmashell)<br>
- some are critical during log in<br>
- they IPC with each other<br>
- especially the backend launcher's debug is really hard to get at<br>
<br>
This means that:<br>
- it's hard (almost impossible) for users to get us good and useful logs<br>
- it's hard for ourselves to debug and find out what's exactly going on,<br>
especially when multiple components need to play in tune<br>
<br>
Yesternight, after debugging the so-many-th issue, it occurred to me that we<br>
need to make this way easier to debug. Q(C)Debug falls short in that we get<br>
logs of individual components, if we're lucky. If we're really lucky, we get<br>
timestamps, so we can get a rough idea of what is going down when.<br>
<br>
All of these problems can be solved with a relatively simple, shared log file.<br>
<br>
So I'd like to switch most of (lib)kscreen's debug output to logging to a<br>
file. The files has then logs from multiple processes and will be much easier<br>
to go through.<br>
<br>
API-wise, my main thing is having log messages and a bit of context, so it'd<br>
look like this:<br>
<br>
Log::instance()->setContext("handling resume event");<br>
// ...<br>
Log::log("Enabled output" + output->name());<br>
<br>
In the log, we'd then get<br>
<br>
[TIMESTAMP] (kded: handling resume event) Enabled output eDP-1<br>
<br>
<br>
The key here is that we get a mostly correct sequence of things, that all the<br>
info is there right away, and that it's easier for the user to annotate the<br>
log ("Now plugging in my external display as HDMI-2").<br>
<br>
The file is simple enough that even plasmashell could log to the file (at<br>
least until we've fixed the interaction between screen handling and<br>
plasmashell), so we get the full picture.<br>
<br>
libkscreen[sebas/log] has a basic implementation. It's incomplete in the sense<br>
that it needs a bit of autotesting (just haven't gotten to it yet), review and<br>
then switching over the code-base. (For now it's on by default, but can be<br>
disabled using a env var.)<br>
<br>
I hope that this makes it much more straight-forward for us (and even users)<br>
to figure out where their multiscreen headaches are coming from, and that it<br>
gives us a one-stop shop (pretty much) to tell users what info we need to fix<br>
their bugs. ("Just send me the logfile in ~/.local/share/kscreen.log").<br>
<br>
What do you think? If you like the idea, I'll polish up my branch and will<br>
post it for review, so we can discuss the actual implementation.<br>
<br>
Cheers,<br>
<span><font color="#888888">--<br>
sebas<br>
<br>
<a href="http://www.kde.org" rel="noreferrer" target="_blank">http://www.kde.org</a> | <a href="http://vizZzion.org" rel="noreferrer" target="_blank">http://vizZzion.org</a><br>
_______________________________________________<br>
Plasma-devel mailing list<br>
<a href="mailto:Plasma-devel@kde.org" target="_blank">Plasma-devel@kde.org</a><br>
<a href="https://mail.kde.org/mailman/listinfo/plasma-devel" rel="noreferrer" target="_blank">https://mail.kde.org/mailman/listinfo/plasma-devel</a><br>
</font></span></blockquote></div><br></div></div></div><div class="gmail_extra">Hi,</div><div class="gmail_extra"><br></div><div class="gmail_extra">Just a quick idea that might help you.</div><div class="gmail_extra"><br></div><div class="gmail_extra">I'm not sure if the logging of those applications is already visible in journalctl, but if it is then you can do something like this:</div><div class="gmail_extra">journalctl -u <unit> -u <another unit> -u <third one> -u <etc...> -f</div><div class="gmail_extra"><br></div><div class="gmail_extra">-u would be the "units". Like plasmashell i guess.</div><div class="gmail_extra">-f means following the log (new entries appear on your screen).</div><div class="gmail_extra"><br></div><div class="gmail_extra">Lastly, i would suggest to use a second pc independent of the one that you're debugging. On that second machine just ssh into the one you're debugging and execute the logging command from above.</div><div class="gmail_extra"><br></div><div class="gmail_extra">This all obviously only works if you everything is already visible in journalctl.</div><div class="gmail_extra"><br></div><div class="gmail_extra">Good luck!</div><div class="gmail_extra">I hope this makes logging and debugging easier for you.</div><div class="gmail_extra"><br></div><div class="gmail_extra">Cheers,</div><div class="gmail_extra">Mark</div></div>
</blockquote></div><br></div><div class="gmail_extra">This idea was not an option?</div><div class="gmail_extra"><br></div><div class="gmail_extra">It seems - to me, but i'm biased since i proposed it.. - like an idea with minimal effort and probably gets the job done, no?</div></div>