[RFC] Screensaver/blanking inhibition

Thu Nov 19 12:06:43 PST 2015

On Thu, Nov 19, 2015 at 05:38:34AM -0500, Christopher Michael wrote:
> 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)...

Jonas can correct me if I'm interpreting his comment wrong, but I
understood him to mean, "For inhibition of things that aren't directly
relevant to displays or surfaces or input devices, leave those out of
this proposal; they can be done using dbus or whatnot."  I didn't take
his suggestion to mean that the screensaver inhibition itself would be
done via DBUS.

Of course, there's no reason there couldn't be a higher level wrapper
available through DBUS that handles the Wayland calls, if someone
decided it'd be convenient or whatever.

Bryce

> 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