[rfc] ConsoleKit enhancements

[David Zeuthen]

On Mon, 2007-02-12 at 13:18 -0500, William Jon McCann wrote:
> > So I was thinking about some of the races that Bill brought up in
> > another thread and I think we need some kind of interface to allow
> > applications to sanely and race-free release/acquire resources on
> > session switching.
> 
> Yeah.  Without getting into the details yet I agree that using some
> kind of two phase transition is desirable.  I guess that is pretty
> much what OS X does [1].
> 
> One tricky part is how we define "pre-switch" and "post-switch".
> Ideally, I suppose, we'd like to know when the switch is initially
> requested.  And by requested I mean:
> 
>   1. Direct kernel request (eg. VT_ACTIVATE ioctl)
>   2. System level tools (eg. chvt)
>   3. Hot keys (CTRL-ALT-Fn)
>   4. ConsoleKit D-Bus API
>   5. Login Managers (eg. GDM)
>   6. Desktop tools (eg. GNOME fast-user-switch-applet)
> 
> A while ago I tried to get the kernel to give us this pre-switch
> notification via ioctl VT_SETMODE and setting struct vt_mode relsig (a
> signal to raise on VT release requests).
> 
> However, it seemed like only one pid may register for this at a time
> at least from my cursory look through the kernel sources.  And the
> xserver already claims it.
> 
> So the only indication we get in ConsoleKit is the return from VT_WAITACTIVE.
> 
> Anyway, that's just a little background.
> 
> Whatever kind of two phase notification we use must be robust against
> the kernel switching VTs again by any of the above mechanisms.
> 
> So, we just have to be careful.  I'll still need to think about it a bit more.

Yeah. It's worth keeping in mind that it's not super important to make
sure that session.is_active is perfectly timed to what the video outputs
- and some day we're going to use some better than the Linux VT
subsystem.

Anyway, I started looking at just adding a hook for SessionAdded - the
thinking is that I want this kind of interaction

 0. HAL registers with CK: Manager.RegisterSessionAddedHook() -> cookie1
 1. gdm -> session -> CK.OpenSession(...)
 2. CK receives method call but doesn't reply yet
 3. CK emits Manager.SessionAddedHook(cookie2)
 4. HAL catches this and gives ACL to the devices
 5. HAL does CK.SessionAddedHookDone(cookie1, cookie2)
 <other hooks run too)
 6. CK sees that all hooks for cookie2 have run (or a timeout
    have been reached) and now replies to the original
    OpenSession() caller

but it's a little tricky how to do this nicely; e.g. the session object
needs some kind of job queue in order to handle situations like the
caller of OpenSession() disappering between e.g. step 3. and 6. The
semantics for handling that, btw, should probably be SessionAdded() and
then SessionRemoved() so e.g. HAL can remove ACL's granted in response
to SessionRemoved() in response to the SessionAddedHook(). Hmm, tricky.

Anyway, attached is a patch for registration of hooks just for something
to base this on (not meant for HEAD yet). It's not much but when I got
this far I realized more thinking is required :-)

     David

-------------- next part --------------
A non-text attachment was scrubbed...
Name: ck-add-registration-hooks.patch
Type: text/x-patch
Size: 7679 bytes
Desc: not available
Url : http://lists.freedesktop.org/archives/hal/attachments/20070217/b6c7ae9b/ck-add-registration-hooks.bin