IAfter discussing this a bit on irc today I've been looking into a potential fix for this. A big problem here seems to be that the fix will likely be desktop environment specific.

There are 2 different solutions:
1) inhibit the screensaver when we've grabbed the keyboard
2) release the keyboard grab when the screensaver wants it.

1) Makes the most sense to do when fullscreen, whereas 2) makes more sense when running windowed.

Both 1 and 2 require interacting with the screensaver, Gnome has its own org.gnome.ScreenSaver dbus interface, which KDE more or less mirrors as org.freedesktop.ScreenSaver. I've not further investigated the KDE implementation, see here for the gnome interface:
http://people.gnome.org/~mccann/gnome-screensaver/docs/gnome-screensaver.html

Unfortunately at least for the Gnome implementation the "ActiveChanged" signal gets emitted after the
screensaver has grabbed the keyboard, so we cannot use it as a hint to know when to release the
keyboard grab,

The gnome-screensaver determines when it should screensave / lock based on a dbus signal from the gnome session manager, this is documented here:
http://people.gnome.org/~mccann/gnome-session/docs/gnome-session.html#org.gnome.SessionManager.Presence::StatusChanged

When the status goes to '3' (idle) then gnome-screensaver will try to activate the screensaver, so we
(spice-gtk) could listen to the StatusChanged signal and when the status becomes 3 release our keyboard grab.

The problem with this is that it is highly desktop environment specific ...

Also interesting in the light of this bug is:
http://live.gnome.org/GnomeScreensaver/FrequentlyAskedQuestions

Hans,

 I haven't really looked into this, this is just off the top of my head. I'm aware of the problem: when going out of a spice fullscreen session that's been active for a long time in fullscreen you would suddenly get the client's screensaver come into affect, unexpectedly.

 It seems to be we should be relaying all the key events we grab - at least in a sense that a "no-action" key has been pressed. If such a mythological key existed it would postpone any watches for screensavers in the client's environment (and not be system specific, except in somuch as finding this mythical no-action key).

 Does that sound remotely plausible?

Alon

(In reply to comment #1)
> There are 2 different solutions:
> 1) inhibit the screensaver when we've grabbed the keyboard
> 2) release the keyboard grab when the screensaver wants it.

Or when the idle-time is reached? (ie get that information somewhere, and monitor inputs?)

> When the status goes to '3' (idle) then gnome-screensaver will try to activate
> the screensaver, so we
> (spice-gtk) could listen to the StatusChanged signal and when the status
> becomes 3 release our keyboard grab.
> 
> The problem with this is that it is highly desktop environment specific ...

That should not prevent us from implementing a solution for the platforms we care about. At the same time, it would be nice to push the freedesktop spec for this requirement, but I am afraid it could take a lot of effort. (I think Wayland people are a bit more open for this kind of changes screensaver/grab behaviours)

Hi,

(In reply to comment #3)
> (In reply to comment #1)
> > There are 2 different solutions:
> > 1) inhibit the screensaver when we've grabbed the keyboard
> > 2) release the keyboard grab when the screensaver wants it.
> 
> Or when the idle-time is reached? (ie get that information somewhere, and
> monitor inputs?)

Right, this is actually what my proposed solution for 2) under gnome does, it
monitors the gnome-session's status, and would release the keyboard grab when
that status goes to idle (which is what gnome-screensaver triggers on).

Note I believe that this is only the proper behavior when running windowed, I
believe that in fullscreen mode we should simply inhibit the screensaver,
relying on the guest's screensaver / locking.

> > The problem with this is that it is highly desktop environment specific ...
> 
> That should not prevent us from implementing a solution for the platforms we
> care about.

Agreed, but it is less then ideal which is why I mentioned this.

Regards,

Hans

(In reply to comment #4)
> Note I believe that this is only the proper behavior when running windowed, I
> believe that in fullscreen mode we should simply inhibit the screensaver,
> relying on the guest's screensaver / locking.
> 

I think that this is only true for safe and not valuable client systems - for example, locked-down thin clients. For fat clients, this is perfect opportunity for evil maids to switch spice-client out of full-screen mode (no matter if the guest is locked or not) and do harm on client computer.

> > > The problem with this is that it is highly desktop environment specific ...
> > 
> > That should not prevent us from implementing a solution for the platforms we
> > care about.
> 
> Agreed, but it is less then ideal which is why I mentioned this.
> 

When we start interacting with client DE wrt screen lock functionality, it might be worth also to find out all keys that lock screen (including Fn-based ones on laptops), pass these keys to the client machine and create dynamically 'send key' menu options for passing of these key combos to the guest. First part is actual behaviour with Ctrl-Alt-Del combos on Win7 clients so users already expect this behaviour on some clients.

WRT guest screen lock, if there is a generic way to send command to lock screen (the keycode of Fn-F2 on my Thinkpad T510 comes to my mind), it might make sense to implement a spice-server feature to lock guest screen after client disconnect or before client connect. ovirt-agent (rhev-agent) currently implements such feature but spice-server is a better place for it IMO.

Hans, can you update on this one? I think you have pushed a solution in gnome. Can you write here what's done and what's left?

(In reply to comment #6)
> Hans, can you update on this one? I think you have pushed a solution in
> gnome.

I've pushed changed related to automount inhibiting into gnome, no screensaver related
changes...

> Can you write here what's done and what's left?

What I've done is research the various API-s available under Gnome/KDE for dealing with the screensaver, what is left is doing something with this knowledge.

The API-s boil down to us (spice-gtk) being capable of inhibiting the screen-saver and uninhibiting it. There is not much else we can do unfortunately.

Note that the original problem is gone under GNOME-3 since that simply aborts locking the screen if it cannot get the screen-grab, rather then keep trying forever, and then as soon as we release the keyb-grab because the user moves the mouse out of the client window go to screensaver mode.

Instead now if you leave your machine with ie remote-viewer with the keyb focus, it will never lock, which from a security pov is certainly less then ideal.

So the questions are:

1) What do we want do to ?

Ideally we would be able to get the idle status from the DE and when the desktop goes idle, we release the keyb grab and then the screensaver can kick in.

But what if a movie is playing inside the guest, so in this scenario we would also need to be able to get
the guests sceensaver inhibit status (through the agent) and forward this to the client.

2) How do we implement this ?

Under gnome3 we can get notified of the session manager considering things idle, and then ungrab, but this may race with the screensaver trying to kick in, fixing the race may require some changes to gnome-sheel but should be doable

Likewise under gnome3 we can check if a screensaver inhibit is active.

So this ideal situation may be achievable assuming both guest and client are gnome-3, but otherwise it is going to be very hard :|

3) What are the alternatives?

One alternative would be to fix the issue of playing a movie inside the guest (as example) by inhibiting the screensaver as soon as we have focus, but this means no auto-lock when a user leaves a machine which from a security pov is less then ideal. Note that we are already more or less in this situation since the keybgrab we've conflicts with the screen locking too :|

thanks for the update (the gnome3 change is what I was vaguely refering too)

Hi,

(In reply to comment #8)
> thanks for the update (the gnome3 change is what I was vaguely refering too)

You're welcome. So I would like to eventually do something wrt spice-gtk <-> screensaver interaction. Do you have any inpuy (based on my last comment), and which direction we should go?

Regards,

Hans

I've been pointed (correctly) to this bug from the list.  My issue adds another wrinkle.  I run spice full-screen on one monitor (actually two) but the other monitor is "local".  So inhibiting the screensaver means leaving all that information visible - indefinitely.

Additionally, since there is no activity being sent to local screensaver, the minute the mouse moves out of the "spice monitor" the screensaver locks, even though I typed a key 1 second ago.

Maybe this all works in GNOME, but I use MATE.  I should test it.  Anyway, since this bug is open, I assume it's still a problem everywhere.

I think two things fix this:

1) "poke" the local screensaver when there is "activity" in the spice window.  this could be a) every mouse and keyboard event, b) once per "time quantum", or c)"just-in-time" before local screensaver locks, but I think c) sounds horrendously difficult for no benefit

2) via the guest agent, integrate with guest screensaver.  when it blanks and/or locks, release mouse/keyboard grab.  if the local screensaver is ready, it will immediately lock simultaneously.  Yes, the user will have a double screen-unlock to deal with. Maybe another agent message could take care of that and unlock the guest screensaver when local is unlocked, but that is a feature for another day.

One additionaly thing: the guest agent should lock the guest screensaver on disconnect.

Ok. I'm half wrong, #1 already works - I just had different timings on the two screensavers, so it seemed like the "local" was not receiving "activity" when in fact it is.  So now it comes down to the fact that the inhibit of the screensaver should be released when the guest screensaver activates.

(In reply to David Mansfield from comment #11)
> Ok. I'm half wrong, #1 already works - I just had different timings on the
> two screensavers, so it seemed like the "local" was not receiving "activity"
> when in fact it is.  So now it comes down to the fact that the inhibit of
> the screensaver should be released when the guest screensaver activates.

So you would have 2 nested screensavers in this case?

(Hans proposed something different in comment #7 I think: to release the grab when client screensavers wants to kick in - it would need new screensaver API I guess, and to inhibit client screensaver when guest screensaver is inhibited, which would need new agent messages)

I think we shouldn't prevent client screensaver either if spice is in fullscreen mode, the client screensaver should have "bigger priority". The client see the activity also when we are in the fullscreen mode and do not start the screensaver if there is any activity (also there could be also different local screens as mentioned in comment #10). The client screensaver should be disabled by the administrator if the client is used only for "remote desktop". So, we should release grab if client screensaver wants to run. Only case when we should prevent client screensaver is when the screensaver is inhibited in the guest (e.g. when playing movie).

Is this problem also in other desktop environments, or it is gnome-specific? What about Windows?

There has been recent changes in mutter/gnome-shell during about last year: the screen locks itself even when the grab is taken by spice-gtk (or other widget).

There seem to be a consensus that  spice-gtk should not attempt to inhibit the client screensaver/lock. The "double" guest screensaver is a user settings issue to me, that spice probably shouldn't have to touch.

Resolving as "notourbug"