On 05/11/09 17:33, Brian Cameron wrote: > I am not sure what you mean. By default, ConfigAvailable should be set > to "true" in the GDM defaults configuration file
Well, it is commented out, but I guess that means the default is true, so you are correct.But still nothing happens if you select the configuration option, and enter either password (default user or root). Actually, it seems you can enter anything as password and nothing interestinghappens... > 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. >... > Could this be your problem? No problem running gdmsetup from an xterm. This really isn't a issue for me at all. I only tried doing it from the gdm login because it was there and I mentioned it here because it didn't seem to work. IMO running gdmsetup from there is weird and unintuitive anyway... > 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, Great! The problems I have seen appear to have been fixed in releases after snv103. Obviously time to upgrade... > 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. Could it be there aren't a whole lot of people using OpenSolaris as an X terminal :-), and probably those that do either get there from the command line, or don't have console sessions running. BTW Using xdmcp from Fedora does the same thing - if you deliberately use X :0 -query, any dtsession with :0 will usually die. This is actually a regression, either by dtlogin or gdm, around about the time Fedora Core 9 came out, maybe snv65 or so? I submitted this as a bug (yes, to bugs.opensolaris.org) last year against dtlogin but the bug report vanished. It really isn't a dtlogin bug because the docs suggest that reusing the display numberis a bad idea. > 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. Only to see if it works. As noted, running X -query from the command line is a rather easy workaround... > 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 % grep get_free_display *.c gdmXnestchooser.c:get_free_display (void) gdmXnestchooser.c: display = get_free_display (); without actually looking at the code, this isn't Xnested so maybe regular xdmcp (gdmchooser.c?) isn't calling this? > 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. As noted, it is a problem with snv111a. Never really tried it with earlier versions due to the default no-tcp-listen. The problem is very reproducible, at least with snv103 on the SPARC side and snv111a on the x86 side, so I suspect as noted that either there aren't too many people doing this, or they prefer to run X -query from the console.
