Created attachment 159735 [details] [review]
pkg-config diff file

Let me explain how GDM uses GConf since it is a real corner case.  Although normally GDM only runs a single login GUI for the main console, it can run multiple simultaneous login GUI's (e.g. if one user is on the console, and other users via XDMCP or Xvnc).  GDM starts a separate D-Bus session bus for each login GUI so this caues each greeter to get a separate gconfd daemon.

With GDM 2.30.1 there is a problem that if the user turns on an AT program in one GDM login GUI window, it launches for them all since the boolean keys to trigger this are stored in GConf.  Likewise if one user kills the AT program, it dies on them all.  This is obviously a problem, very confusing behavior, and a serious issue for users with disabilities.

So, I have been working for the past several weeks to fix this problem and I have discovered a few things about how GConf works.  I have been able to figure out how to get this working better via two mechanisms, but both require a change to GConf.  In fact, both of my proposed patches may be sensible for GConf to adopt.

So, to separate each GDM login GUI to a separate GConf directory I create a ~gdm/.gconf.path file with this entry:

xml:readwrite:$(HOME)/$(ENV_GDM_SEAT_ID)/.gconf

Using $HOME/.gconf.path ensures that this readwrite directory gets assigned
before the $HOME/.gconf setting in the /etc/gconf/2/path, so this is used.

Also I make sure that I set the GDM_SEAT_ID environment variable to a unique per-session string for each display and set GCONF_DEFAULT_SOURCE_PATH to "/etc/gconf/path/2".  The GDM slave daemon first launches D-Bus and then launches gnome-session.  I make sure to only set these environment variables before running gnome-session and not when starting D-Bus.  Note that the session D-Bus launches gconfd, so avoiding setting these environment variables when starting D-Bus ensures that these are not set for the gconfd process for each display, but are set for all clients.

If I do this, then things works well, and each login GUI has a separate $HOME/$(ENV_GDM_SEAT_ID)/.gconf directory, and launching or exiting AT programs only affects the display where the user made the request.

However, "/etc/gconf/path/2" is not an exposed interface by GConf.  My first patch adds "gconf_defaultpath" to the pc file, so that GDM can refer to it in its configure script and ensure that it points to the right default path file.  Since this is an exposed interface that users or other modules should be able to reference if desired, I think this is good to expose and a good patch to go upstream.

I notice that things do not work in two cases:

1) If I do not set GCONF_DEFAULT_SOURCE_PATH for the clients.
2) If the D-Bus session bus process is launched with GDM_SEAT_ID set to the
   same value as for the client.

If either case is true, then launching or exiting an AT program on one display causes the AT programs to launch or exit on all displays.  At first this confused me since each login GUI has a separate gconfd process and one would think they would not know about each other's configuration.

Digging into the GConf code (and with Ray Strode's help), I discovered that this is caused because gconfd treats its "default" path special.  Changes get stored in the common $HOME/.gconfd/saved_state file with entries like this:

ADD 117440623 "def" (cryptic stuff)

So, if the change is in the default path, all gconfd daemons pick up the change.
My second patch adds an environment variable trigger GCONF_DISABLE_DEFAULT which turns off gconfd's usage of the saved_state cache.  With this change, it is possible to make GDM work without needing to set GCONF_DEFAULT_SOURCE_PATH at all.  Instead it is just necessary to set this environment variable to a value and things just work.  I think this is a useful feature for corner-cases like this GDM usage and it avoids GDM needing to set GCONF_DEFAULT_SOURCE_PATH to the default path file, which seems a bit weird and seems a cleaner way to fix this issue.

So, I would actually like to propose that both patches go into GConf, though either one will allow GDM to fix this serious accessibility problem.  Can one or both of these patches go upstream so the GDM issue can be fixed?