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