Hi!

Currently there is no way through xdg-shell for a surface to inhibit the screensaver/blanker/locker (an idleness inhibitor).

It's important that a surface be able to inhibit idleness only on the screen(s) it appears on, so that the compositor could blank other screens.  The compositor can either avoid blanking all screens if any surface is inhibiting -or- just the screens that aren't inhibited.  I think it's important that it be part of the protocol to associate the lock with a specific surface - as the compositor knows where the surface is, on which screen.  The lock also needs to disappear if the surface disappears.  I'm proposing this be part of xdg-shell because I think it would need to depend on the surface PONGing to keep the lock.

There is a dbus spec that jadahl on #wayland linked but I think it fails a few of this requirements, I am not sure - it needs review by someone more experienced than I :-)

http://people.freedesktop.org/~hadess/idle-inhibition-spec/index.html

From what was said I don't think it can inhibit idleness on a per-screen basis and tracking if the surface disappears is somewhat trickier.  I put a log of the discussion about it below.

I have a few less important ideas for weston (and other compositors):
- config option (boolean): If a surface is inhibiting idleness don't blank that screen specifically but blank all others -- or don't blank any screens (traditional behavior).
- config option (boolean): Fullscreen surfaces automatically inhibit idleness (so the application doesn't have to know about this spec in transition).
- config option (boolean): Waking screens is done individually when that screen detects input, or all screens are woken at the same time (traditional behavior).

The IRC log about all this:

(07:58:06) < Sleepy_User> hrrm.  when running gnome-mplayer the screensaver/locker still triggers in weston - I was just wondering, is this something xwayland doesn't currently handle or is this something that someone would add to xdg-shell at another project to block the 
(08:02:07) < Sleepy_User> how are screensavers traditionally inhibited when you're watching a movie or playing something?
(08:03:23) < pq> Sleepy_User, we have no protocol to inhibit screensavers yet.
(08:04:17) < pq> I suppose that's on the TODO for after we have stabilized the first version of xdg-shell.
(08:04:23) < Sleepy_User> pq: if you're not busy -- how would it work?
(08:05:00) < Sleepy_User> I mean does the client inform the compositor it's doing something that shouldn't be covered/locked over, or does the compositor just "know" somehow from the type of application it is
(08:05:20) < Sleepy_User> (like the .desktop files that provide information about what is installed)
(08:05:29) < jadahl> why not just use dbus for that?
(08:05:40) < jadahl> like http://people.freedesktop.org/~hadess/idle-inhibition-spec/re01.html
(08:06:10) < pq> ah, if there is already a standard dbus interface for it and it is compatible with wayland, then sure.
(08:06:33) < Sleepy_User> that seems cool :D
(08:06:40) < pq> jadahl, just not sure how you'd associate the inhibit with a specific window, so that the compositor can clean up properly if the window gets destroyed.
(08:07:20) < Sleepy_User> it'd be interesting if you had multiple monitors up to track which surface is on what screen inhibiting the idleness so you can lock/screensave the other screens
(08:07:38) < Sleepy_User> configurable somewhere of course ~
(08:08:49) < jadahl> pq: is it really necessary to bind it to awindow?
(08:09:23) < pq> jadahl, it would allow nice things, like the automatic clean-up and what Sleepy_User said: blanking outputs where the window is not on.
(08:09:36) < Sleepy_User> i am credit to team :D
(08:09:53) -!- NICK You are now Sleepy_Creator
(08:10:47) < jadahl> isn't there automatic cleanup (if the application dies I mean)?
(08:11:10) < pq> jadahl, no, if it only destroys that one window.
(08:11:21) < pq> not disconnect
(08:11:54) < pq> jadahl, actually, if you used dbus, can you even associate the inhibit to any connection either?
(08:12:14) < jadahl> is it really worth writing protocol and having all toolkits etc support such a thing when the benefit is clients that forget to uninhibit?
(08:12:42) < jadahl> skimming through some g-s-d code it looks like it handles the case where the application disappears at least
(08:13:07) < pq> Correcting the forget to uninhibit is just a minor feat. Blanking other outputs seems like it might be worth it.
(08:13:34) < jadahl> that sounds more like an extra feature to some set_fulscreen thing
(08:13:56) < pq> I often run TV shows from my laptop to a real TV, and would be nice if the laptop screen could blank.
(08:14:22) < jadahl> ah, you mean per-output-inhibit
(08:14:29) < pq> yes
(08:14:50) < pq> but automatic per-output, since the compositor knows where the window is
(08:14:54) < jadahl> I usually use the blank-screen-button on the keyboard for that, but I suppose it'd be nice if it was automatic
(08:17:09) < pq> jadahl, so how does a compositor associate a dbus connection to a Wayland connection?
(08:17:51) < jadahl> pq: it doesn't. it looks if the "name" on dbus disappears and uninhibits that way
(08:21:19) < pq> jadahl, so an app does not even need a window to be able to inhibit? Is that really ok?
(08:23:26) < jadahl> pq: seems so
(08:23:52) < pq> I have hunch we'll discuss that again after the more pressing matters are done.
(08:24:08) < jadahl> yes, it doesn't feel very high up on the priority list