GNOME Bugzilla – Bug 368704
ConsoleKit support
Last modified: 2011-03-20 04:28:01 UTC
GDM in CVS HEAD now has ConsoleKit <http://gitweb.freedesktop.org/?p=ConsoleKit.git;a=summary> support. It would be nice to think about how this can benefit FUSA. The way I see it working is that FUSA can first ask ConsoleKit what session it is running in: org.freedesktop.ConsoleKit.Manager.GetCurrentSession (OUT ssid) This session-id (ssid) is a D-Bus object reference that can be used to get information about the session, like the "seat" ID it is attached to: org.freedesktop.ConsoleKit.Session.GetSeatId (OUT sid) If this seat-id (sid) is not set then the session is not attached to a seat. We haven't fully spec'ed what a seat is but we know that: * seat has a physical location * seat generally corresponds to an input device and monitor * can generally only switch to a user attached to the same seat * only one session can be active on a seat at a time At the moment we have implemented two kinds of seats: static and dynamic. There is one static seat that is defined to contain all user sessions that originate from the local system. Each remove session is allocated its own seat that exists only for the duration of that session. Examples of remote sessions are: GDM XDMCP logins, ssh logins. It might be interesting to offer FUS for XDMCP sessions but that will likely require some further work. So, for the time being, FUS is only really possible on the local (static) seat. If the current session is not on this type of seat then FUSA should probably not be shown. To get the list of sessions attached to this seat: org.freedesktop.ConsoleKit.Seat.GetSessions (OUT ssid-array) will return an array of session-IDs. For each of these ssid it is possible to get information about the session or to activate the session. Here is an example of this in python: http://gitweb.freedesktop.org/?p=ConsoleKit.git;a=blob_plain;h=3ac7921426b47cee17d67d2b2629b66b66a1bc3d;f=src/test-fus
This is really exciting. I'm looking forward to getting this working with FUSA.
Okay, I've been playing with this. One problem I've run into (and it's certainly just me not understanding well enough) is that even when I run it under console-kit-daemon and then a recent gdm, the Python script you gave doesn't run unless it can find the environment variable XDG_SESSION_COOKIE. Now, I can grep through /proc for another process which has this variable, but how *should* it be supplied to the script?
At least for now, the XDG_SESSION_COOKIE environment variable is used by the daemon to determine which session the calling process belongs to. The variable is set by GDM when the session is initiated. It will be inherited by all child processes unless explicitly asked not to be. So, basically it should be already set. env | grep XDG_SESSION_COOKIE I think we want to consider this variable an implementation detail so that we will be able to replace it with something else if other OSs have a better way or when we add a better way to Linux. Does that answer your question? Thanks for looking into this. Also, this probably won't be able to solve bug 172912 directly. We'll still need to enhance GDM for that and perhaps rethink how we use the GDM flexiservers.
Hi, Just wondering if you have had any luck with this or if you have any questions.
Been a little busy with the compositor problems, but I think I'll get to it before the end of the month.
Has it been fixed? In Fedora 7 FUSA looks so.
I'll talk to the Fedora people, find out what they're doing, and get back to you.
*** Bug 323954 has been marked as a duplicate of this bug. ***