--===============3651828618582994790== Content-Type: multipart/alternative; boundary=001a1145b6863eb84505342a9286 --001a1145b6863eb84505342a9286 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, May 31, 2016 at 2:29 PM, Sebastian K=C3=BCgler wrot= e: > Discussed with mgraesslin on IRC, preliminary conclusion below... > > On dinsdag 31 mei 2016 14:05:06 CEST Sebastian K=C3=BCgler wrote: > > https://bugs.kde.org/show_bug.cgi?id=3D358011 dual screen not setup aft= er > > reboot > > > > This bugreport seems to be a common problem, and it's a good example fo= r > > what's wrong with the screen configuration on startup. > > > > TL;DR: We have a race condition when the kscreen daemon starts. It look= s > up > > a known config, then applies it and subsequently resaves the config. T= he > > 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 avoi= ds > > 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 stil= l > 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 (whic= h > 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 --001a1145b6863eb84505342a9286 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= ue, May 31, 2016 at 2:29 PM, Sebastian K=C3=BCgler <sebas@kde.org> wrote:
Discussed with mgraesslin on IRC, preliminary= conclusion below...

On dinsdag 31 mei 2016 14:05:06 CEST Sebastian K=C3=BCgler wrote:
> https://bugs.kde.org/show_bug.cgi?id=3D358011 = dual screen not setup after
> reboot
>
> This bugreport seems to be a common problem, and it's a good examp= le for
> what's wrong with the screen configuration on startup.
>
> TL;DR: We have a race condition when the kscreen daemon starts. It loo= ks up
> a=C2=A0 known config, then applies it and subsequently resaves the con= fig. The
> same happens on config changes, it writes, then re-reads and then re-w= rites
> 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 wa= tches for
configuration changes for 100ms, if any change takes longer than 100ms, it&= #39;s
considered unrelated. Basically, what we want to do in kscreen daemon is:
- start a timer in kscreen daemon for 100ms after SetConfigOperation::finis= hed
=C2=A0 and
- restart it for every configChanged that arrives while the timer is still<= br> =C2=A0 running,
- if the timer has timed out in the meantime, react to configChanged as usu= al

That should achieve the same effect as the "current" timer approa= ch (which was
just a proof of concept to prove my point, anyway.

Let's see how this goes.


Perhap= s blockSignals can help you out [1]?

object->bl= ockSignals(true);
// ...
Write your changes
/= / ...
object->blockSignals(false);

Object should be the object that currently receives the notificati= on that the config file has been changed i think.


--001a1145b6863eb84505342a9286-- --===============3651828618582994790== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KUGxhc21hLWRl dmVsIG1haWxpbmcgbGlzdApQbGFzbWEtZGV2ZWxAa2RlLm9yZwpodHRwczovL21haWwua2RlLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL3BsYXNtYS1kZXZlbAo= --===============3651828618582994790==--