X Forwarding with indirect rendering fails with newer clients

Question

Posting this question for a colleague after quite a bit of research. He wants to connects to an old Centos 4 server via ssh -X (or -Y) and run some X application there. It used to run fine for years, but recent updates (on both Centos 7 and Ubuntu) to his client PCs now make this impossible. His app just hangs, and trying simply to run glxgears leads to a crash:

X Error of failed request:  BadValue (integer parameter out of range for operation)
Major opcode of failed request:  150 (GLX)
Minor opcode of failed request:  3 (X_GLXCreateContext)
Value in failed request:  0x0
Serial number of failed request:  19
Current serial number in output stream:  21

It's really a problem of version of the client. Reverting to earlier Centos 6 on the client side make it work again. There's nothing in the X11 log on the server side. I ran strace glxgears without noticing anything out of the ordinary. What can I try to diagnose this further ?

EDIT: On any modern Linux the following attempt to force an indirect rendering context will fail:

glxinfo -i
name of display: :0
X Error of failed request:  BadValue (integer parameter out of range for operation)
Major opcode of failed request:  154 (GLX)
Minor opcode of failed request:  24 (X_GLXCreateNewContext)
Value in failed request:  0x0
Serial number of failed request:  39
Current serial number in output stream:  40

I tried the following to re-enable indirect rendering. Unless I'm mistaken, all those have to be done on the client machine:

• in sections Screen or Device of /etc/X11/xorg.conf you add:

  Option "AllowIndirectGLXProtocol" "True"

• in /usr/bin/startx (or wherever startx is located):

  defaultserverargs="+iglx"

• in /usr/share/lightdm/lightdm.conf.d/50-xserver-command.conf you change the line:

  xserver-command=X -core +iglx

• before launching KDE, for instance in .kde/env/igl.sh

  export LIBGL_ALWAYS_INDIRECT=1

None of those work.

Solution

Linux workstation

Perversely, many versions of GDM don't offer a way to pass arguments like +iglx to Xorg. In response, new X.org versions have an IndirectGLX option (see also example xorg.conf text).

In the absence of that option, there is a workaround of wrapping Xorg itself with a shell script:

mv /usr/bin/Xorg /usr/bin/Xorg.original
echo -e '#!/usr/bin/env bash\nexec /usr/bin/Xorg.original "$@" +iglx' > /usr/bin/Xorg
chmod +x /usr/bin/Xorg
chcon --type=bin_t /usr/bin/Xorg

macOS workstation (XQuartz)

Just run

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

and restart XQuartz if it's running. (Beware of typos: there is no error checking on the domain and variable names.) Recent versions use the simpler org.xquartz.X11.

Comments

[dargaud]

I'm pretty sure that the problem stems from newer X servers that disable indirect GLX by default. "glxinfo -i" fails even locally, and none of the workarounds seem to work.

[Lie Ryan]

What desktop manager are you using? lightdm or kdm? You seem to be modifying the setting for lightdm, but are sure you're using lightdm rather than the default desktop manager for KDE which is kdm?

[dargaud]

Good question. I thought it was lightdm, but apparently it's sddm (note that I'm trying to solve this problem on a set of different machines)

[Jamey Sharp]

First, does the app that your colleague actually wants to run need GL? If not, glxgears failures seem like a red herring. Second, your first three workarounds would need to be on the machine running the X server (which is your desktop/laptop), but the fourth needs to be in the environment of the X client in question (which is running on the remote server). X terminology feels backwards, so please be careful with it or we'll all be confused!

[dargaud]

I had noted the tricky terminology and gotten the first 3 correct, but did the last one on the wrong machine. As for glxgears being a red herring, it's entirely possible but the error messages are identical, and since the program he needs to run is a huge unsupported anymore commercial blackbox, it's my best bet so far to run tests.

[dargaud]

We just tested old versions of CentOS (6) and Ubuntu (14.10) with "glxinfo -i", and when they work, his software works. So he's just going to work in an VM with an old OS from now on. I consider the case closed, even if the resolution is nowhere to be found on recent Linuxes.