[RFC] Screensaver/blanking inhibition

[Christopher Michael]

On 11/19/2015 05:04 AM, 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.  But I'm sketchy on where exactly this
> should be placed initially, so am hoping to get some advice there.
>

Fair enough. My question was more out of curiosity than anything ;)

>>> 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...
>

Well, having it inside it's own xml/protocol file would allow easier 
adoption (IMO) as you (read: implementors) do not have to go back and 
modify "existing" code (read: potentially large files) to support it. 
Also, those that do not wish to support it (or they cook up their own), 
can safely ignore it. Storing it in an existing protocol file 
potentially means that they cannot avoid it (thinking protocol version 
number gets bumped, other unrelated things in that protocol file get 
changed, etc, etc)...

Cheers,
Chris


>>> 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
>