Re-enabling INdirect GLX on your X server

As of December, 2014, X.org has advised a change in the default behavior of X servers to no longer be launched/started with INdirect GLX rendering enabled. The feature is still available but the default X server is typically started with it disabled.

INdirect GLX rendering is required to run GLX enabled tools like VisIt, ParaView, GlVis, etc. on remote resources and have them display back to your local desktop, via X. There is some discussion about this among HPC Chemistry community here.

The reason cited by X.org for disabling INdirect GLX is the potential for security issues. However, remember that a majority of our user base is in the habit of forwarding X connections over ssh, a secure connection. IGLX security issues are likely to be a potential issue for you only if you are in the habit of by-passing ssh X forwarding by manually re-setting your DISPLAY enviornment variable on the remote host and disabling host authentication on your X server (e.g. xhost +).

Note that for VisIt, as well as possibly other tools, a common and recommended work-around for missing INdirect GLX rendering functionality in your X server is to use VisIt in client-server mode. In client-server mode, you start VisIt locally, on your desktop/laptop and then use VisIt to log into and launch VisIt's metadata server and engine components on remote resources.

Although client-server is the preferred way of using VisIt in general to access remote resources and although it also works around disabled INdirect GLX rendering in your local X server, there are many reasons users may still want to run VisIt entirely remotely and display back to their desktop via X. These include just plain convenience, additional firewall issues client-server may tickle, the need for having host profiles available as well as the ease with which interactive parallel node reservations can be acquired and re-used throughout a VisIt session.

What follows on this page is some explanation for how to re-enable INdirect GLX rendering on your X server

Updates for LLNL Users

As of June 17, 2016, system adminstrators have patched the Linux X server to enable +iglx. Simply reboot your Linux desktop. That should pull in the patched X server and you should be back to normal operation again. We are working on similar solution for OS X users with a patch to XQuartz. We have yet to develop a plan and solution for Windows users. However, most Windows X servers are relatively old and, in all likelihood, have not been modified to disable IGLX.

OS X 10.11 and later

Its possible the following command may be sufficient for OSX users...

defaults write org.macosforge.xquartz.X11 enable_iglx -bool true

Try it. Then if you are already running an X server, kill and/or otherwise restart it. Then log into a remote system and try running a glx enabled application like glxgears. If the above command does not result in the glxgears displaying an animation of rotating red, green and blue cogs (gears) such as the one pictured to the right, then please read on.

Output window from glxgears command

Note: The utlimate solution is to add the "+iglx" argument to the arguments used to start the X server. The discussion here is lengthy because I did not have administrator privileges on my Mac to affect the changes in /usr that are needed.

Apparently, XQuartz 2.7.8 was the last release of XQuartz where iglx rendering is enabled by default. So, one option may be to simply go ahead and install that. Also, it would appear that the ReadMe file in XQuartz 2.7.10 installer has support for enabling IGLX as part of the installation process.

Here are the steps I took to re-enable INdirect GLX rendering on OS X 10.11 on a machine for which I had no privileges to modify files in /usr.

  1. Make a copy of /opt/X11/bin/startx to some place you can edit it
  2. Edit startx by changing the first line from #!/bin/sh to #!/bin/sh -x
    • This is so you can see the commands its executing
  3. Next, find a line near the top of the form, defaultserverargs="" and change that line to read, defaultserverargs="+iglx"
  4. Save your changes to startx and exit your editer
  5. Exit all your X related applications
  6. Kill any of your current xinit/startx process (or Force Quit XQuartz)
  7. Remove any /tmp/.Xi-lock files (where i=0,1,2...)
  8. Start the new X server with INdirect GLX enabled using the command, ./startx -- /opt/X11/bin/Xquartz
    • You may encounter syntax error(s) with expr match expressions. If so, edit startx and change those to expr : expressions
  9. When you run startx, it will emit a bunch of output echoing all the commands the script is executing. At the end, you should see a line of the form
    • eval /opt/X11/bin/xinit "/opt/X11/lib/X11/xinit/xinitrc" -- "/opt/X11/bin/Xquartz" :2 +iglx -auth '/Users/miller86/.serverauth.50752'
    • Note the :2 in this line. That is the display number. In my case, I nelgected to remove the /tmp/.X0-lock and /tmp/.X1-lock files. So, it picked display # 2.
  10. Test the X server you just started locally by trying to run an xterm like so...
    • env DISPLAY=:i xterm where the i is the integer display number (2 in the example above)
  11. That should start an X term. If that works, exit the X term and try to log into your remote system
    • env DISPLAY=:i ssh -C -X -Y <remote-system-name> where the i is the integer display number (2 in the example above)
  12. Once logged into the remote system try the command
    • glxinfo or glxgears
  13. If the above runs successfully, you have confirmed your new X server has INdirect GLX enabled.

Presumably, a similar set of steps on variants of Linux should work to re-enable iglx on those systems. There are, of course, more permanent ways of doing this but those require ability to edit files that typically only system administrators have privileges to modify.