Frank:

>> 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.

Yes, the comment is showing you the default value.

> 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...

Odd, I just tested this on build 115, and it seems to work for me.

>> 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...

I would be interested to hear if this problem is still happening on
a more recent build.

>> 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.

You say the GDM issue is general and happens on multiple distributions.
If this is the case, then I would recommend filing a bug at
http://bugzilla.gnome.org/.  It is more likely to get fixed if the
issue is raised with the wider GDM community.

It does not surprise me that any dtlogin or dtsession bugs are removed
from defect.opensolaris.org, since dtlogin is not shipped with
OpenSolaris.  To get bugs or enhancement requests addressed in dtlogin,
I think it would be necessary to work with customer support.

>> 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?

Ah yes, sorry.  Looking at the GDM code, in the file 
daemon/gdm-xdmcp-manager.c, it looks like the GDM daemon gets the
"clnt_dspnum" value from the XDMCP "REQUEST" packet.

> 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.

Or it may be an issue with using snv103.  As I mentioned, there
have been some serious bugs fixed in GDM since build 103, including
compiler errors introducing seemingly random bugs into the code.

I would recommend updating to a more recent build, and retesting.  Then
it would be good to file a bug if you are still seeing problems.  If the
problem affects GDM on any distro, then I would recommend filing the bug
on bugzilla.gnome.org.  If the problem is specific to Solaris GDM, then
I would file the bug on defect.opensolaris.org.  As I mention above, you
probably would need to go through normal Solaris support channels to
get any bug or enhancement request for dtlogin/dtsession looked into.

Brian


Reply via email to