XDpms in screenlocker
Thomas Lübking
thomas.luebking at gmail.com
Sun Jan 13 22:57:05 UTC 2013
** please keep me in cc as well as likely dario **
Hi Dario, Aaron and everybody else.
I looked into the powerdevil sources, reactivated the turnOffScreen dbus method, implemented it and that works - more or less (screeen turns black for a moment and then comes back up)
I checked the xset sources and the unconditionally enable dpms and usleep before forcing the level[1], but what's more important is that the dpms implementation as is does not get the display down (regardless of the state) and the cause is the call to:
// Let's pretend we're resuming
core()->onResumeFromSuspend();
Commenting that away works just as expected.
-> is that really required for anything?
In case i'd rather add a 2nd argument to omit it, but atm. it seems to break things in general.
Cheers,
Thomas
[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.
On Sonntag, 13. Januar 2013 19:22:09 CEST, Aaron J. Seigo wrote:
> On Sunday, January 13, 2013 13:55:54 Thomas Lübking wrote:
>> ** please keep me in CC **
>>
>> While stepping across the ksmserver/screenlocker/greeter/* code i noticed
>> that there's (intended) support to show the screensaver on pressing esc,
>> but no equivalent to re/activate dmps (DPMSForceLevel, "xdpms force off")
>
> ha! i was JUST looking at this right now and came to kontact to
> send an almost
> *identical* email.
>
>> Should there be (and i don't point Frameworks here):
>> - an extension to the powerdevil workspace lib API (which will either make
>> use of the Dpms lib or call xdpms internally; i don't know, but it's
>> configurable through the kcm)
> - a prop. implementation in the locker preferably using
>> * xdpms (pro: runtime resolution. con: we call a different process;
>> security flaw) * the Dpms lib (con: compile time dependency)
>
> personally, i'd like to see a PowerDevil call as it means we
> keep all the code
> handling this exact feature in *one* place and if/when platform
> changes under
> us we only need to make changes in one place as well.
>
More information about the Plasma-devel
mailing list