On Mon, Jun 06, 2016 at 10:08:00AM -0500, Yong Bakos wrote: > On Jun 6, 2016, at 7:18 AM, Pekka Paalanen <[email protected]> wrote: > >> I don't believe this is a good choice. Imagine the case of a surface-less > >> 'inhibitor daemon.' > > > > An ordinary client must not be able to do that. > > > >> There may be no visible surface (is my thinking out > >> of scope here?). Imagine another case, that of a "caffeine" widget. This > >> widget's surface would be hidden when another app is fullscreen. > > > > If you cannot see the widget anyway, it must not be able to affect > > screen saving. Therefore by definition, surfaceless clients must not be > > able to inhibit. > > > >> Furthermore, I don't believe that inhibition should be coupled to outputs. > >> See below. > > > > It should work per-output. If there is important info on just one > > output, why should the other outputs also stay on for no good reason? > > Just because I'm looking at info on one monitor doesn't mean I want my other > monitors to go to sleep.
Not quite, there's actually three different situations to consider First is if you're watching one monitor and doing something else on the other. Like watching a movie while browsing emails. In this case, your other usage is going to be generating input activity, and the system isn't going to be idling to sleep in the first place, so inhibition simply isn't relevant. Next consider if you're passively watching two things at once, one client on one screen and another client on the other. Maybe you're monitoring a security camera on one screen and watching live stock tickers on the other or something. Well, this is completely in scope of the idle inhibit design - each client issues an idle inhibit request and you're good to go. Finally consider you're watching something on one and *not* doing anything on the other. In this case, the second head *should* power save when appropriate. State of the art for most screensaver inhibitor tech addresses the second situation, but leaves the third unsolved. We should be able to handle the set. > I can imagine this being specified via a shell's > screensaver/power savings config panel, with a checkbox enabling "idle per > screen" or "idle > all screens in unison." So I think this is a moot point. Exactly - in practice there are generally out-of-band ways to control screensavers and DPMS and so forth. I'm trying to avoid making any assumptions that they exist or are usable, but at least for cases in where a given client hasn't implemented idle inhibition, or is broken for some other reason, the user is going to have options. The protocol doesn't need to design for non-supporting clients. > However, I don't believe that just because a surface is occluded, that > it's ability to inhibit idling should be suppressed. It's entirely possible; I don't claim to be prescient about all the various use cases that may exist. But that would be a pretty fundamental change, so lets only consider it if there are likely use cases that just can't be addressed with what we've got so far. Like I mentioned earlier, we've actually taken a few things *out* of the protocol because we just lacked rational use cases for them, and because its easy to add more functionality later but much much harder to remove functionality that proves unnecessary later. > >> I don't believe that inhibition should /only/ be coupled to outputs. > >> In the case of a "caffeine" widget or daemon, the use case is to > >> prevent /all/ outputs from idling, regardless of what output the widget's > >> surface resides upon. > > > > That is explicitly not what we want to enable. > > > > What is this "caffeine" you talk about? I've never heard of it. Maybe I > > never had to fight against screen saving. > > Here's a screenshot of the Gnome-flavored implementation of the widget: > http://tinyurl.com/caffeine-widget-2 > > OSX and others have something similar. This program visually resides in the > menubar/taskbar of the shell. It has two states, on and off. On (caffeinated) > overrides the configured screensaver/sleep idle timeout, preventing /all/ > monitors from idling. In the off (un-caffeinated) state, the system behaves > according to configuration. > > Use case: I've configured my system to screensave at 5 minutes and put the > monitors to sleep at 10 minutes. But sometimes, I want to override this > without going in and changing my config, only to have to change it back > later. I run the caffeine widget, turn it on, and all my monitors remain on > despite me not interacting with my machine. This behavior remains valid > even if I am running a program fullscreen, which occludes the visibility > of the widget. > > It sounds like, from what Bryce had wrote in a separate reply, such a > widget would use a different API and not this idle inhibitor protocol. I > might be misunderstanding his point. Right, idle-inhibit is a functionality that is automatic and per-client. What you're describing here is a *manual* and *global* way of letting the user change the screensaver settings. So like imagine in weston this would effectively be a run-time API for setting --idle-time. So, maybe in the same class as idle-inhibit but a totally different functionality. I'd like to imagine idle-inhibit makes such a functionality unnecessary, but regardless it'd be a different discussion. (As an aside, such a function *probably* should not be made available to arbitrary clients since it is changing a global setting; it probably would fall in the same category as screen reconfiguration or screen capture and require special privileges. And as such it would almost certainly have to be a compositor-specific thing, and thus likely implemented over DBUS or however else the compositor handles config setting type functionality.) > >> Forgive me if I didn't quite grok prior conversations about this protocol. > > > > It seems like your mindset is tuned to fighting against bad > > screensaving policies in a compositor, while Bryce's goal with the > > extension is to allow implementing proper and good screensaving policies > > *in the first place*, so that no fighting is needed. > > > > We want the compositor to behave correctly, not offer tools to override > > the compositor behaviour. Bugs should be fixed at their source, not > > worked around at every other place. > > I hear you. Not fighting, per se, but rather 'temporarily override'. > I'm just stating that an application should be able to inhibit idling: > > a) On all outputs > b) Whether it is visible or not > > Per the use case I described above. Whether it uses this inhibitor protocol > or some other API is fine. But if such a use case /should/ use the inhibitor > protocol, then the per-output constraint and visibility constraint in the > protocol would make this functionality 'impossible'. That's a really good indication that these are two distinct functionalities, and shouldn't be conflated together. Bryce _______________________________________________ wayland-devel mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/wayland-devel
