GLXBadWindow in legacy GLX games (LWJGL) and RandR errors in Steam on master

[zukrmn]

Select the version

Git master branch

Describe your issue

When running legacy OpenGL games (such as Minecraft Alpha running on LWJGL 2) or Steam 32-bit wrappers under XLibre, the applications instantly crash during the OpenGL context/window creation.

The crash log for Minecraft specifically points to a GLX extension failure:
org.lwjgl.LWJGLException: X Error - disp: 0x... serial: 62 error: GLXBadWindow request_code: 138 minor_code: 32

Additionally, Steam games fail to launch, reporting display resolution errors (which points to a regression with RandR failing to report or set modes correctly for legacy 32-bit SDL clients).

Troubleshooting already done:

• Tested with Option "TearFree" "false" and Option "Atomic" "off" in the modesetting config. The crash persists.
• Tested completely rootless and without any compositor running (no picom, no xcompmgr). The crash persists.
• Using the exact same system, drivers, and xinitrc, replacing XLibre with the standard xorg-server makes all games (Steam and Minecraft) work flawlessly.
• This confirms there is a deep regression within XLibre's libglx.so or RandR implementation compared to upstream Xorg.

System Information:

• OS: Void Linux (amd64)
• GPU: Intel UHD Graphics 620
• Driver: Built-in modesetting (using Mesa iris and DRI3/DRI2)
• XLibre Build flags: -Dglamor=true -Dudev=true -Dxorg=true

Upstream_Xorg.0.log
XLibre_Xorg.1.log

Steps to reproduce

1. Compile and install XLibre from the git master branch.
2. Start an X session (startx) using the built-in modesetting driver on an Intel GPU.
3. Attempt to launch Steam or a legacy OpenGL game like Minecraft Alpha (using LWJGL 2.9.4).
4. Observe the immediate GLXBadWindow crash upon OpenGL initialization, or RandR resolution switching failures in Steam.

What did you expect?

I expected legacy GLX applications (like Minecraft / LWJGL 2) and 32-bit wrappers (like Steam) to launch successfully with hardware acceleration, exactly as they do on the upstream xorg-server using the identical driver configuration.

Additional Information

Minecraft crash log snippet:

Minecraft has stopped running because it encountered a problem.
...
org.lwjgl.LWJGLException: X Error - disp: 0x7f6d180308a0 serial: 62 error: GLXBadWindow request_code: 138 minor_code: 32
	at org.lwjgl.opengl.LinuxDisplay.globalErrorHandler(LinuxDisplay.java:320)
	at org.lwjgl.opengl.LinuxDisplay.nCreateWindow(Native Method)
	at org.lwjgl.opengl.LinuxDisplay.createWindow(LinuxDisplay.java:495)
...

Extra fields

• I have checked the existing issues
• I have read the Contributing Guidelines
• I'd like to work on this issue

[tseli0s]

Since you're running master, can you git bisect this?

What about the beta or stable versions of XLibre? Is the issue present there?

[zukrmn]

Since you're running master, can you git bisect this?

What about the beta or stable versions of XLibre? Is the issue present there?

The issue isn't present in the latest stable version (xlibre-xserver-25.2.1). I actually just switched my system to track the stable release instead of master, and both Minecraft (LWJGL 2) and Steam are working perfectly again.

Since this machine is my daily driver for gaming, I can't really run a full git bisect on master right now without breaking my setup.

Looking at the recent commit history between 25.2.1 and master, there was a pretty massive refactoring of the GLX and RandR macros (stuff like request_priv.h: some more request parsing macros, rewriting the rpcbuf reply paths in GLX, etc.). Given the crashes are directly tied to GLXBadWindow and RandR failing to set resolutions in legacy clients, it's highly likely the regression snuck in during that specific cleanup wave

[fish4terrisa-MSDSM]

Coule be #3284 related
GLFW is quite weird and did a lot of things wrong so sometimes cleaning obscure code or fix bugs would cause problem with GLFW applications

[tseli0s]

Since this machine is my daily driver for gaming, I can't really run a full git bisect on master right now without breaking my setup.

You can install various versions of XLibre in different prefixes. I install it in /opt for my own patches, and I use the regular stable packages from FreeBSD ports otherwise, for example.

But it's no problem, because I think I know which commit broke things, no need to go through all that. I'll check right away.

[tseli0s]

@zukrmn looks like the bad commit was reverted so can you check if this fixed your issue or not?