From kde-panel-devel Mon Jan 14 11:32:13 2013 From: Dario Freddi Date: Mon, 14 Jan 2013 11:32:13 +0000 To: kde-panel-devel Subject: Re: XDpms in screenlocker Message-Id: X-MARC-Message: https://marc.info/?l=kde-panel-devel&m=135816316030746 MIME-Version: 1 Content-Type: multipart/mixed; boundary="--===============6779617768398129103==" --===============6779617768398129103== Content-Type: multipart/alternative; boundary=047d7b6d911621db0104d33dffeb --047d7b6d911621db0104d33dffeb Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi everyone, 2013/1/14 Oliver Henshaw > On 13 January 2013 22:57, Thomas L=FCbking > wrote: > > ** please keep me in cc as well as likely dario ** > > > > I looked into the powerdevil sources, reactivated the turnOffScreen dbu= s > > method, implemented it and that works - more or less (screeen turns bla= ck > > for a moment and then comes back up) > > > > // Let's pretend we're resuming > > core()->onResumeFromSuspend(); > > > > Commenting that away works just as expected. > > The same fix is in https://git.reviewboard.kde.org/r/106795/ which I > forgot about, sorry. Note that I think this is really due to an X bug, > if you 'sleep 10; xset -q' before asking powerdevil to turn off the > screen you can see that X11 thinks that the screen is still off when > it has come back on. > Indeed. The reason why that call was put into place was to set the idle timer to zero whenever a trigger came up. I clearly remember it used to solve also another problem, which I don't recall now (blame on me for not commenting on that part), but it's apparently safe to get that out of the way. I also agree with Oliver's analysis. Needless to say that if we all agree that commenting out that method should fix this issue, that RR is good to merge. > [1] There's actually an explanation for that behavior which might be > > relevant in this case: > > * The calls to usleep below are necessary to > > * delay the actual DPMS mode setting briefly. > > * Without them, it's likely that the mode will be > > * set between the Down and Up key transitions, in > > * which case the Up transition may immediately > > * turn the display back on. > > I think it's more than that, as mentioned above. Or maybe xset is > papering over the same bug? > --047d7b6d911621db0104d33dffeb Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi everyone,

2013/1/14 Oliver Henshaw <oliver.henshaw@gmail.com&= gt;
On 13 January 2013 22:57, = Thomas L=FCbking <thomas.lu= ebking@gmail.com> wrote:
> ** please keep me in cc as well as likely dario **
>
> I looked into the powerdevil sources, reactiva= ted the turnOffScreen dbus
> method, implemented it and that works - more or less (screeen turns bl= ack
> for a moment and then comes back up)
>
> // Let's pretend we're resuming
> core()->onResumeFromSuspend();
>
> Commenting that away works just as expected.

The same fix is in https://git.reviewboard.kde.org/r/106795/ which I=
forgot about, sorry. Note that I think this is really due to an X bug,
if you 'sleep 10; xset -q' before asking powerdevil to turn off the=
screen you can see that X11 thinks that the screen is still off when
it has come back on.

Indeed. The = reason why that call was put into place was to set the idle timer to zero w= henever a trigger came up. I clearly remember it used to solve also another= problem, which I don't recall now (blame on me for not commenting on t= hat part), but it's apparently safe to get that out of the way.

I also agree with Oliver's analysis.

Needless to say that if we all agree tha= t commenting out that method should fix this issue, that RR is good to merg= e.

> [1] There's actually an explanation for that behavior which might = be
> relevant in this case:
> * The calls to usleep below are necessary to
> * delay the actual DPMS mode setting briefly.
> * Without them, it's likely that the mode will be
> * set between the Down and Up key transitions, in
> * which case the Up transition may immediately
> * turn the display back on.

I think it's more than that, as mentioned above. Or maybe xset is=
papering over the same bug?

--047d7b6d911621db0104d33dffeb-- --===============6779617768398129103== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel --===============6779617768398129103==--