[RFC] Screensaver/blanking inhibition

Thu Nov 19 02:28:36 PST 2015

On 11/19/2015 05:15 AM, Jonas Ådahl wrote:
> On Thu, Nov 19, 2015 at 02:04:36AM -0800, Bryce Harrington wrote:
>> On Thu, Nov 19, 2015 at 04:20:11AM -0500, Christopher Michael wrote:
>>> Just some random thoughts inlined below...
>>>
>>> On 11/19/2015 03:05 AM, Bryce Harrington wrote:
>>>> A "screensaver inhibition protocol" is on the set of needed enhancements
>>>> for Wayland.  This should turn off screen blanking and any running
>>>> screensaver for a period, then re-enabling it later.
>>>>
>>>> An obvious use case is giving presentations.  Other use cases include
>>>> games, kiosk, automotive infotainment systems.
>>>>
>>>> I'd like to take a shot at defining the protocol for this and
>>>
>>> Yay !! :)
>>>
>>>> implementing it for Weston.  The design I have in mind mostly follows
>>>> xdg-screensaver and the DBUS screensaver API[1], which provide a
>>>> desktop-neutral 'inhibit' mechanism to temporarily disable the
>>>> screensaver/screenblanker on a per-process basis, except that it will be
>>>> per-surface instead of per-process.
>>>>
>>>
>>> Is the protocol going to be in "wayland" or in "weston" ??
>>
>> I imagine like other protocols it'll gestate in weston (actually
>> probably the new wayland-protocols repository), and hopefully eventually
>> move into the wayland repository.
>
> Actually, the intention is to keep stable protocols in
> wayland-protocols. The only protocol type of things that would be added
> to the wayland repository are core protocol additions, and except for
> new requests/events to existing interfaces I don't have an example or
> idea of what type of protocol that would be.
>

Ahh ok. Thank you for clearing that bit up :)

>
>> But I'm sketchy on where exactly this
>> should be placed initially, so am hoping to get some advice there.
>
> I'd say a screensaver-inhibit if its just about screenblank/lock/.. or
> inhibiter if its about inhibiting anything. I don't see a need of
> making it "xdg" because its can just as well, as you already mentioned,
> be usable for ivi and other things where there is no desktop but still
> clients who should inhibit the screen blanking.
>

Certainly. It does not need (or really even desired) to have it named 
"xdg" .... I actually wrote that (relatively) the same time I was 
writting another email wrt xdg-shell lol. (ie: typo basically). Guess I 
had xdg on the brain ;)

>>
>>>> So, after issuing the inhibit request for a surface, the screensaver
>>>> (and screenblanking) will be blocked until the surface is destroyed,
>>>> disabled, or otherwise loses visibility or becomes occluded.
>>>>
>>>> In X11, various getter functions are provided for the application to
>>>> poll inhibition status.  For Wayland, instead of getters, the current
>>>> state is just be pushed to the client when the inhibitor global is
>>>> bound, and then updates pushed if/when the status changes.
>>>>
>>>
>>> This makes sense, and follows "standard" wayland practice
>>>
>>>> A corresponding uninhibit API will be added as well.  For example, a
>>>> movie player may wish to inhibit while a video is playing but uninhibit
>>>> when it is paused.
>>>>
>>>> Inhibition can be specified as display-specific or global.  If it is set
>>>> as display-specific, then only the display(s) the surface is visible on
>>>> will be inhibited and other displays will powersave normally.  If it is
>>>> global, then it affects all displays.  We don't give clients the ability
>>>> to set inhibition arbitrarily on displays - it will only take effect for
>>>> display(s) where the surface is actually shown.
>>>>
>>>> Questions:
>>>>
>>>> a.  Which protocol file should this stuff be added to?  Weston's
>>>>      desktop-shell.xml (soon to be renamed weston-desktop-shell.xml) has
>>>>      a screensaver interface, but that is only weston-specific, yet we
>>>>      want this functionality to work on multiple compositor
>>>>      implementations.
>>>>
>>>
>>> xdg-screensaver.xml maybe ??
>>
>> Ah, I was thinking the requests should be added to one of the existing
>> protocol files, but hadn't thought maybe it should go into its own xml
>> file.  Hmm...
>
> Yes I think it makes sense to add this to its own extension. A
> "wp_inhibiter" in a inhibiter XML file that inhibit things.
>

Makes sense ("potentially" could inhibit other things depending on scope 
and how it grows)

> Not so sure about the scope though. If its not about surfaces on outputs
> or input devices or focus or display protocol things it should just be a
> D-Bus protocol.
>

Unsure if dbus would be sufficent. Not saying it isn't .. just saying 
"unsure". The reason I say unsure is (essentially) a simple request to 
"inhibit the screen" or "start the screensaver" would (in theory) I 
assume need to talk to the compositor, potentially for permission checks 
(ie: is this client Allowed to do this ?, is the compositor doing 
something else that second which is slightly more important and thus 
this request needs to be delayed ?, etc, etc).

For various reasons (and perhaps unforseen ones), I would "think" that 
it would chat with the compositor (in some form). IF that is the case, I 
don't believe dbus would be sufficient as the compositor may need to 
talk to the client (give me your credentials, who is the user requesting 
this, etc, etc).

But... these are just my random, rambling thoughts on the subject ;)

Cheers,
Chris

>
> Jonas
>
>>
>>>> b.  Do we need to handle inhibition for screensavers (i.e. the interface
>>>>      in desktop-shell.xml) separately from screen blanking.  I don't see
>>>>      anyone needing to inhibit one without also wanting to inhibit the
>>>>      other too, so it would be nice to have a single request that covers
>>>>      any sort of screen obscurement.
>>>>
>>>
>>> I think that as long as what you come up with can handle
>>> screensaver, blanking, (and maybe dimming ??) then it should be
>>> sufficient.
>>>
>>>> c.  For X, in addition to inhibition, several other methods are provided
>>>>      to client applications to control aspects of the screensaver and
>>>>      display power savings.  E.g. 'Poke' to simulate user activity,
>>>>      deliberately activating the screensaver, or locking, or power
>>>>      savings, etc.  Do we need/want any of these for Wayland too?
>>>>
>>>
>>> Perhaps a "request" to activate, lock, etc, etc .. then maybe it's
>>> up to the compositor to allow or not ?
>>>
>>>> d.  When giving a presentation, there are several other things one may
>>>>      want to inhibit besides the screensaver, such as notifications,
>>>>      sound effects, background music, etc.  The above proposal assumes
>>>>      inhibition of each of these is handled separately some other way,
>>>>      but do we want to consider some more generalized solution?
>>>>
>>>
>>> My initial thought would be a generic "inhibit" request, or perhaps
>>> an "inhibit all" ... then let the compositor deal/decide.
>>>
>>> Cheers,
>>> Chris
>>
>> Thanks,
>> Bryce
>> _______________________________________________
>> wayland-devel mailing list
>> wayland-devel at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/wayland-devel