View source for Re-enabling INdirect GLX on your X server

[https://www.x.org/wiki/Development/Security/Advisory-2014-12-09/ As of December, 2014, X.org has advised a change in the default behavior of X servers to no longer be launched/started with '''IN'''direct GLX rendering enabled]. The feature is still available but the default X server is typically started with it disabled.

'''IN'''direct 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 [https://www.phoronix.com/scan.php?page=news_item&px=Xorg-IGLX-Potential-Bye-Bye here].

The reason cited by X.org for disabling '''IN'''direct 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 '''IN'''direct GLX rendering functionality in your X server is to use VisIt in [http://www.visitusers.org/index.php?title=Running_client-server client-server] mode. In [http://www.visitusers.org/index.php?title=Running_client-server 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 [http://www.visitusers.org/index.php?title=Running_client-server client-server] is the preferred way of using VisIt in general to access remote resources and although it also works around disabled '''IN'''direct 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 [http://www.visitusers.org/index.php?title=Running_client-server 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 '''IN'''direct 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.

[[Image:Glxgears-pic.jpg|thumb|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, [https://www.xquartz.org/releases/XQuartz-2.7.8.html 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 [https://www.xquartz.org/releases/XQuartz-2.7.10.html 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 '''IN'''direct GLX rendering on OS X 10.11 on a machine for which I had no privileges to modify files in /usr.

# Make a copy of /opt/X11/bin/startx to some place you can edit it
# Edit startx by changing the first line from <nowiki>#!/bin/sh</nowiki> to <nowiki>#!/bin/sh -x</nowiki>
#* This is so you can see the commands its executing
# Next, find a line near the top of the form, <nowiki>defaultserverargs=""</nowiki> and change that line to read, <nowiki>defaultserverargs="+iglx"</nowiki>
# Save your changes to startx and exit your editer
# Exit all your X related applications
# Kill any of your current xinit/startx process (or Force Quit XQuartz)
# Remove any /tmp/.Xi-lock files (where i=0,1,2...)
# Start the new X server with '''IN'''direct GLX enabled using the command, <nowiki>./startx -- /opt/X11/bin/Xquartz</nowiki>
#* You may encounter syntax error(s) with <nowiki>expr match</nowiki> expressions. If so, edit startx and change those to <nowiki>expr :</nowiki> expressions
# 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
#* <nowiki>eval /opt/X11/bin/xinit "/opt/X11/lib/X11/xinit/xinitrc"  -- "/opt/X11/bin/Xquartz" :2  +iglx  -auth '/Users/miller86/.serverauth.50752'
</nowiki>
#* 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.
# Test the X server you just started locally by trying to run an xterm like so...
#* <nowiki>env DISPLAY=:i xterm</nowiki> where the i is the integer display number (2 in the example above)
# That should start an X term. If that works, exit the X term and try to log into your remote system
#* <nowiki>env DISPLAY=:i ssh -C -X -Y <remote-system-name></nowiki> where the i is the integer display number (2 in the example above)
# Once logged into the remote system try the command
#* <nowiki>glxinfo</nowiki> or <nowiki>glxgears</nowiki>
# If the above runs successfully, you have confirmed your new X server has '''IN'''direct 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.