[prev in list] [next in list] [prev in thread] [next in thread]
List: kde-panel-devel
Subject: Re: kscreen daemon race
From: Mark Gaiser <markg85 () gmail ! com>
Date: 2016-05-31 22:05:10
Message-ID: CAPd6JnFEWA2QtaCW69xp+GRxtT8_mTWrfXjBW+K=hD5RMjyvAw () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
On Tue, May 31, 2016 at 2:29 PM, Sebastian Kügler <sebas@kde.org> wrote:
> Discussed with mgraesslin on IRC, preliminary conclusion below...
>
> On dinsdag 31 mei 2016 14:05:06 CEST Sebastian Kügler wrote:
> > https://bugs.kde.org/show_bug.cgi?id=358011 dual screen not setup after
> > reboot
> >
> > This bugreport seems to be a common problem, and it's a good example for
> > what's wrong with the screen configuration on startup.
> >
> > TL;DR: We have a race condition when the kscreen daemon starts. It looks
> up
> > a known config, then applies it and subsequently resaves the config. The
> > same happens on config changes, it writes, then re-reads and then
> re-writes
> > the config change.
> > I've managed to prevent this from happening by adding a timer that avoids
> > saving the config as a direct reaction to our own config changes.
>
> So what we want to try is the same mechanism that KWin uses. Kwin watches
> for
> configuration changes for 100ms, if any change takes longer than 100ms,
> it's
> considered unrelated. Basically, what we want to do in kscreen daemon is:
>
> - start a timer in kscreen daemon for 100ms after
> SetConfigOperation::finished
> and
> - restart it for every configChanged that arrives while the timer is still
> running,
> - if the timer has timed out in the meantime, react to configChanged as
> usual
>
> That should achieve the same effect as the "current" timer approach (which
> was
> just a proof of concept to prove my point, anyway.
>
> Let's see how this goes.
>
>
Perhaps blockSignals can help you out [1]?
object->blockSignals(true);
// ...
Write your changes
// ...
object->blockSignals(false);
Object should be the object that currently receives the notification that
the config file has been changed i think.
[1] http://doc.qt.io/qt-5/qobject.html#blockSignals
[Attachment #5 (text/html)]
<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, May 31, 2016 \
at 2:29 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:0px 0px 0px \
0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">Discussed \
with mgraesslin on IRC, preliminary conclusion below...<br> <span class=""><br>
On dinsdag 31 mei 2016 14:05:06 CEST Sebastian Kügler wrote:<br>
> <a href="https://bugs.kde.org/show_bug.cgi?id=358011" rel="noreferrer" \
target="_blank">https://bugs.kde.org/show_bug.cgi?id=358011</a> dual screen not setup \
after<br> > reboot<br>
><br>
> This bugreport seems to be a common problem, and it's a good example for<br>
> what's wrong with the screen configuration on startup.<br>
><br>
> TL;DR: We have a race condition when the kscreen daemon starts. It looks up<br>
> a known config, then applies it and subsequently resaves the config. The<br>
> same happens on config changes, it writes, then re-reads and then re-writes<br>
> the config change.<br>
> I've managed to prevent this from happening by adding a timer that \
avoids<br> > saving the config as a direct reaction to our own config changes.<br>
<br>
</span>So what we want to try is the same mechanism that KWin uses. Kwin watches \
for<br> configuration changes for 100ms, if any change takes longer than 100ms, \
it's<br> considered unrelated. Basically, what we want to do in kscreen daemon \
is:<br> <br>
- start a timer in kscreen daemon for 100ms after SetConfigOperation::finished<br>
and<br>
- restart it for every configChanged that arrives while the timer is still<br>
running,<br>
- if the timer has timed out in the meantime, react to configChanged as usual<br>
<br>
That should achieve the same effect as the "current" timer approach (which \
was<br> just a proof of concept to prove my point, anyway.<br>
<br>
Let's see how this goes.<br><br></blockquote><div><br></div><div>Perhaps \
blockSignals can help you out \
[1]?</div><div><br></div><div>object->blockSignals(true);</div><div>// \
...</div><div>Write your changes</div><div>// \
...</div><div><div>object->blockSignals(false);</div></div><div><br></div><div>Object \
should be the object that currently receives the notification that the config file \
has been changed i think.</div><div><br></div><div>[1] <a \
href="http://doc.qt.io/qt-5/qobject.html#blockSignals">http://doc.qt.io/qt-5/qobject.html#blockSignals</a> \
</div></div><br></div></div>
[Attachment #6 (text/plain)]
_______________________________________________
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic