It would be nice to have a way to configure the entire pathname of the local domain socket that the X server is listening to, and of course the same for the socket that Xlib uses to connect to the server. My use case for this is Xvfb-based testing of GUI applications - currently I have to loop over values of /tmp/.X11-unix/X%d to find an available display number, and then race with other people doing the same thing on that host to get the server started. Proposed ideal solution: On the server side, the existing -listen switch is extended to take an argument of the form local:/absolute/pathname; if that pathname references a directory with acceptable permissions, it creates the usual X%d socket in that directory (where %d is the display number as usual); if the last component of that pathname does not exist, it is created as a directory, go to part 1; otherwise server startup fails. On the client side, the DISPLAY variable is extended to take a value of the form local:/absolute/pathname:display.screen (where display and screen are numbers as usual, and may be omitted with the same semantics as currently). The /absolute/pathname replaces /tmp/.X11-unix when looking for the socket. Document that the path should not contain colons in either case. In both cases, you should be able to use "unix" instead of "local". Also, libICE should use /absolute/pathname (or possibly /absolute/pathname/ICE, creating that subdirectory if necessary) instead of /tmp/.ICE-unix if it finds DISPLAY to have this form. If this is not doable for whatever reason, a less ideal but still acceptable option would be to honor the TMPDIR environment variable, on both client and server, when looking for the .X11-unix and .ICE-unix directories. If this is done, client obviously should fall back to /tmp if there is no socket in $TMPDIR/.X11-unix.
We do this for our socket, but it makes sure the pathname is /tmp/launch* ... maybe it would be a good idea to expand this, but it was a PAIN to get support for our approach into xtrans, libxcb, openssh, and a variety of other sources that parse $DISPLAY Why do you need this?
Like I said, I want this for a test harness that runs GUI applications inside Xvfb (for isolation from any actual login session on the same computer); it's currently not possible to start it up in a race-free manner, because all I can do is guess display numbers that aren't currently in use, and if several instances of Xvfb are starting in parallel, they trip over each other.
Well you can address that by giving each parallel set a pool to use =/
I don't think preallocating display numbers would solve my problem -- the number space is, fundamentally, a global resource; any non-cooperating server can stomp on any scheme I come up with.
Well for now you should be able to do this using the same mechanism we use in XQuartz. Create sockets named /tmp/launch-XXXXXXX/org.x:0 and set DISPLAY to that full path name. xtrans should use it. This code may be inside of a HAVE_LAUNCHD or similar block, so you may need to define that to trick xtrans.
> --- Comment #2 from Zack Weinberg <zackw@panix.com> 2011-10-03 08:19:05 PDT --- > Like I said, I want this for a test harness that runs GUI applications inside > Xvfb (for isolation from any actual login session on the same computer); it's > currently not possible to start it up in a race-free manner, because all I can > do is guess display numbers that aren't currently in use, and if several > instances of Xvfb are starting in parallel, they trip over each other. > This can be fixed by making the server allocate the display number itself. See <1294352941-16508-2-git-send-email-ajax@redhat.com>
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/xorg/lib/libxtrans/issues/1.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.