Frank: >> GDM only displays the login configuration program (gdmsetup) in >> the menus if the greeter/SystemMenu and greeter/ConfigAvailable GDM >> options are set to true. > > Evidently not precisely. If you only set SystemMenu=true, you get the > configuration option, but it seems not to work, perhaps because > ConfigAvailable isn't set.
I am not sure what you mean. By default, ConfigAvailable should be set to "true" in the GDM defaults configuration file /usr/share/gdm/defaults.conf. So it should work out of the box once you set SystemMenu=true. If it does not start from the login screen, then I am guessing it also does not start if you try to run it directly from the command line. Note there was a compiler bug that was causing GDM to have some bad behaviors, including not being able to run gdmsetup at all. These bugs started appearing when we switched to the SS12 compiler. Note bugster bug #6781266. This was fixed in build 106 by reducing the compiler optimization from -x04 to -x02, so if you are using a slightly older build than 106, you can expect problems. The compiler bug is #6781229, so we can increase the compiler optimization once we start building with a version of the compiler with that fix. Could this be your problem? > The manual you refer to would seem to > be consistent with this behavior, but unless I'm missing something, > it seems rather pointless (and confusing) to have the option > displayed and ask for a password if it can't actually do anything. That should not be the default behavior. >> Also, you should be able to run gdmsetup if you su as root and just >> run gdmsetup from the command line, or run "pfexec gdmsetup". > > Quite. But it seems that you actually have to have gdm running first, > so it is a bit of a chicken-and-egg process :-) Correct, you do not run gdmsetup to turn on GDM. Instead you start the gdm SMF service. Though you should first turn off the cde-login service before turning on GDM. >> You can read more here: >> >> http://library.gnome.org/admin/gdm/2.20/configuration.html.en > > Thanks. Interesting reading. I don't know if the dual head problems > have been fixed yet, but if they have not, hopefully they will be > soon! We have fixed several Xinerama bugs in build 111 respin 4 (aka 111b). We fixed Xinerama bugs in GTK+ and GDM. Also, a similar bug in metacity was fixed in build 116. I am not sure if these are the bugs you are referring to or not. Refer to doo bug #7783 and #8748. Also bugster bug #6768573, > I didn't find any reference to choosing the display number > to use when using rather than accepting xdmcp though... I am not familiar with the problem you are having. I do not remember anybody reporting this sort of issue with XDMCP before. I think I would need more specific information about what about the XDMCP transaction is failing to help. I assume you are using GDM's gdmchooser program to pick the remote host to login to. This is the host chooser you can start from the main GDM screen. Note that the gdmchooser code (gdm/gui/gdmchooser.c file in source) does have a function called get_free_display(). As the function name suggests, it does try to get the next display number. This must be failing for some reason on your machine. You can review the source code for the gdmchooser.c file by downloading the tarball here: ftp://ftp.gnome.org/pub/gnome/sources/gdm/2.20/gdm-2.20.10.tar.bz2 If this were broken, I would expect many people to complain, so I wonder if this might be another issue caused by the compiler bugs when we first migrated to SS12. If you are running into the SS12 compiler bug mentioned above, then I'd first recommend updating to a version of GDM that isn't being affected by the SS12 bugs that are known to make it behave badly. I'd recommend updating to build 111 or later, though 106 or later would probably be good. Brian
