Last change to non-XCB libX11 breaks KDE

[Alan Coopersmith]

Kean Johnston wrote:
> When KDE starts up and does its weird DCOP madness and creates its
> pipes, it uses XDisplayName(), which returns the value of $DISPLAY,
> pretty much. As some later point after _X11TransConnectDisplay()
> has been called, it again queries the display name, but not using
> the XDisplayName() but rather (I am guessing) internal members of
> the Display structure. The problem with this change is that if
> DISPLAY was set to the (extremely common) ":0", then it gets
> "canonicalized" by this change to "unix:0". Thus at two different
> points in the life of the server you have two differnt strings for
> DISPLAY.
> 
> I am sure this change wasn't arbitrary, so what was the original
> problem trying to solve? I think we need to figure out a way of
> solving it without changing the effective value of DISPLAY mid-stream.

I was porting in code that's been in Solaris for years:

 When opening display, if LOCALCONN fails, fall back to UNIXCONN, then TCPCONN

 Port to X11R7 of Sun bug fix 4061225 by Alex Chen for X11R6 - when failing to
 connect on a named pipe, try a Unix socket first, to better support people who
 replace their X servers with ones that don't support named pipe transport.
    <http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=4061225>

The full change is at:
http://gitweb.freedesktop.org/?p=xorg/lib/libX11.git;a=commit;h=abcc7e1865cdfbd591f6520cfe4257f0b0b1c03e

Does your Xlib support LOCALCONN but your server not?

(And you'll notice this change isn't the first to do this manipulation
 - the code already had the fallback from :0 to hostname:0 before I added
 unix:0 as the intermediate step.)

-- 
	-Alan Coopersmith-           alan.coopersmith at sun.com
	 Sun Microsystems, Inc. - X Window System Engineering