[RFC] Screensaver/blanking inhibition

[Christopher Michael]

On 11/19/2015 05:28 AM, Christopher Michael wrote:
> 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
>

After a little more thought, it could potentially work ok with dbus 
...assuming the requests end up being some form of dbus method/signal 
combo where a compositor could listen and client could talk (or 
vice-verse). Having said that tho, I (personally) would rather see dbus 
avoided here and just have it be "wl/weston protocol" (just seems more 
pure to me)...

KR,
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
>
> _______________________________________________
> wayland-devel mailing list
> wayland-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/wayland-devel