Re: 3.6 Feature: Lock Screen

[Giovanni Campagna <scampa giovanni gmail com>]

(sorry it took me this long to reply...)

2012/5/12 Marina Zhurakhinskaya <marinaz redhat com>:
> The overall plan sounds good. Some comments are inline.
>
>
>[...]
>
>> It then listens for
>> GrabBroken events and immediately grabs keyboard and mouse in sync
>> mode.
>
> GrabBroken is something that is sent by gdk within each process. So gnome-shell would receive it if something causes the composite overlay window to loose the grab or the guardian process would receive it if something causes its window to loose the grab (see http://developer.gnome.org/gdk/stable/gdk-Event-Structures.html#GdkEventGrabBroken ) - but the guardian process would not receive a GrabBroken event when a gnome-shell window looses the grab. (Besides, a process would only receive GrabBroken if it is running past the time when one of its windows looses the grab, so when gnome-shell crashes it would not receive GrabBroken event itself either :).
>
> What the guardian process can do is watch for the gnome-shell name on DBus going away, so that it is notified if gnome-shell stops running.

Ugh - that's a problem. Weird X has no notification of grabs going
away. In any case watching dbus is probably the right thing to do (or
may be looking for EnterNotify on the guardian window, which would be
syntethized by X upon removing the grab?)

>> It is controlled by g-shell via dbus (possibly dbus-activated
>> too), and would relinquish grabs and replay events when gnome-shell
>> is
>> ready to take them again, or when the fail whale is displayed from
>> g-session.
>
> I think it's ok for the events that happen while gnome-shell is down to be lost. So the keyboard and mouse can be grabbed asynchronously and the events don't need to be replayed.

Ok. I don't think it makes much difference, although it avoids us
going down to Xlib.

Btw, for now I'm concentrating on the PAM/gdm stuff, so this extra
locking part will come later.

Giovanni