Skip to content

Prefer GLFW X11 backend when no Wayland display is set - #11

Merged
lgulich merged 2 commits into
mainfrom
lgulich/glfw-prefer-x11-without-wayland
Oct 7, 2026
Merged

lgulich merged 2 commits into
mainfrom
lgulich/glfw-prefer-x11-without-wayland

Conversation

@lgulich

@lgulich lgulich commented Oct 7, 2026 •

Copy link
Copy Markdown
Collaborator

Summary

Inside Docker, ros2_control_node prints a spurious error twice at startup:

[MujocoSimulation]: Initializing simulation...
error: XDG_RUNTIME_DIR is invalid or not set in the environment.      # viewer glfwInit()
...
error: XDG_RUNTIME_DIR is invalid or not set in the environment.      # CameraPlugin glfwInit()
[MujocoSystemInterface]: Auto-registered plugin: mujoco_ros2_control_plugins/CameraPlugin

GLFW >= 3.4 built with both Wayland and X11 (e.g. Bazel builds using BCR glfw 3.4.0) falls back to probing platforms in order when XDG_SESSION_TYPE is unset, and Wayland comes first. libwayland prints the error, then GLFW falls back to X11 and everything works.

The core library and libmujoco_ros2_control_plugins_impl.so can each carry their own statically linked GLFW, so the init hint must be set from both:

+mujoco_ros2_control_plugins/glfw_platform.hpp
+  static inline prefer_x11_without_wayland_display()
+    if GLFW >= 3.4 && !WAYLAND_DISPLAY && X11 supported
+      glfwInitHint(GLFW_PLATFORM, GLFW_PLATFORM_X11)

 MujocoSimulation::initialize
+  prefer_x11_without_wayland_display()
   GlfwAdapter -> glfwInit()              # viewer
 CameraPlugin::init
+  prefer_x11_without_wayland_display()
   glfw_init_fn()                         # cameras

Compiled out on GLFW < 3.4 (Ubuntu's system libglfw3 3.3 is X11-only anyway).

Evidence

Bazel build of unitree_g1_bringup unitree_g1_controller_manager.launch.py hardware_type:=mujoco initial_controller_group:=agile_velocity, env stripped like a container (env -u XDG_RUNTIME_DIR -u XDG_SESSION_TYPE -u WAYLAND_DISPLAY), real X display:

  • Before: grep -c 'XDG_RUNTIME_DIR is invalid' → 2 (viewer + camera plugin)
    After: grep -c 'XDG_RUNTIME_DIR is invalid' → 0; viewer starts, camera rendering loop starts, controllers switch successfully.

Also verified in a release-2026.09 isaac-ros activate container (Ubuntu 24.04, ROS_DISTRO=lyrical, no XDG_RUNTIME_DIR/XDG_SESSION_TYPE/WAYLAND_DISPLAY) with ros-lyrical-unitree-g1-bringup installed from the release snapshot, running the tutorial launch command:

  • Before (released ros-lyrical-mujoco-ros2-control{,-plugins}): XDG_RUNTIME_DIR is invalid → 2
    After (same packages rebuilt with this change): → 0; controllers switch successfully in both runs.

pre-commit passes.

Merge Danger

Door: two-way

Blast Radius: small

Only affects GLFW platform selection when WAYLAND_DISPLAY is unset. Real Wayland sessions (which set WAYLAND_DISPLAY) keep GLFW's default auto-detection.

🤖 Generated with Claude Code

lgulich and others added 2 commits October 7, 2026 19:21
GLFW >= 3.4 built with both Wayland and X11 probes Wayland first when
XDG_SESSION_TYPE is unset. Inside Docker this makes libwayland print
"error: XDG_RUNTIME_DIR is invalid or not set in the environment."
before GLFW falls back to X11. Hint the X11 platform before glfwInit()
when WAYLAND_DISPLAY is unset so the probe is skipped.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The core library and libmujoco_ros2_control_plugins_impl.so can each
carry their own statically linked GLFW (e.g. Bazel builds against
BCR glfw 3.4), so the init hint set in MujocoSimulation does not reach
the camera plugin's glfwInit() and the XDG_RUNTIME_DIR error is printed
a second time. Move the helper into a shared header and call it before
both glfwInit() sites.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
@lgulich
lgulich merged commit 0c75738 into main Oct 7, 2026
3 of 8 checks passed
lgulich added a commit that referenced this pull request Oct 7, 2026
…pedance

Prefer GLFW X11 backend when no Wayland display is set (cherry-pick #11)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant