fix(ci): enable Wayland in linux Desktop wheel builds

[banteg]

Summary

This PR makes Linux Desktop wheels Wayland-capable by building raylib/GLFW with both Wayland and X11 backends enabled.

It addresses failures like:

GLFW: Error: 65544 Description: X11: Failed to load Xlib
GLFW: Failed to initialize GLFW

on Wayland-only environments that do not have Xlib available.

Root Cause

Current Linux Desktop wheel builds compile raylib with default GLFW options, which effectively produce X11-only Desktop artifacts for our published wheels.

For Linux jobs, we were building with -DPLATFORM=Desktop but without explicitly enabling GLFW_BUILD_WAYLAND.

There is also a builder-image compatibility issue:

• Our ubuntu16-modern manylinux builder has an older wayland-scanner.
• GLFW’s CMake currently uses private-code, which that older scanner does not support.
• Naively enabling Wayland fails in CI unless we handle this compatibility gap.

What Changed

All changes are in the Linux wheel workflow (.github/workflows/build.yml).

1) Linux x86_64 Desktop wheels (build-linux job)

• For raylib-platform == Desktop:
• Install wayland-protocols.
• Apply a compatibility rewrite in bundled GLFW CMake: private-code -> code.
• Pass CMake flags: -DGLFW_BUILD_WAYLAND=ON -DGLFW_BUILD_X11=ON.

2) Linux i686 Desktop wheels (build-linux32 job)

• Same Desktop-only changes as x86_64:
• Install wayland-protocols.
• Apply private-code -> code compatibility rewrite.
• Pass -DGLFW_BUILD_WAYLAND=ON -DGLFW_BUILD_X11=ON.

3) Linux arm64 Desktop wheels (build-linux-arm64 job)

• Add wayland-protocols to apt packages.
• For raylib-platform == Desktop, pass:
  -DGLFW_BUILD_WAYLAND=ON -DGLFW_BUILD_X11=ON.

Scope / Non-Goals

• No Python API changes.
• No runtime behavior changes outside backend availability.
• No changes to SDL/DRM packaging behavior.
• No changes to macOS or Windows wheel logic.

Why This Is Safe

• Desktop Linux wheels still include X11 support.
• We are adding Wayland support, not replacing X11.
• Backend selection remains GLFW runtime behavior, so existing X11 users should continue to work unchanged.

Validation

I validated this in the same legacy builder context used for manylinux Desktop wheels (electronstudio/ubuntu16-modern):

• Without compatibility handling, Wayland-enabled build fails due to old wayland-scanner and private-code.
• With this PR’s compatibility rewrite + flags, build succeeds.
• The resulting wheel’s _raylib_cffi binary contains both symbols:
  • _glfwConnectWayland
  • _glfwConnectX11

This confirms the artifact is dual-backend capable.

Downstream Impact

This should unblock Wayland-only users (including uvx users of downstream apps that depend on raylib) without requiring distro/Nix-specific repackaging workarounds.

Follow-up (optional)

Once the manylinux builder image is modernized, we can remove the temporary private-code compatibility rewrite and keep only explicit GLFW_BUILD_WAYLAND=ON.

[electronstudio]

I believe the official raylib releases don't enable Wayland because it's still considered problematic? I think they tried it and then disabled it again? Anyway I don't think we should change something like this for 5.5. Maybe for 5.6.

[electronstudio]

Yeah official policy still seems to be it's not ready for use. https://github.com/raysan5/raylib/wiki/Working-on-GNU-Linux#wayland

[0xferrous]

I reported the initial bug report when trying out crimson. I confirm this patch does fix the issue.

[banteg]

Thanks for the pointer. I read through the wiki + linked issues/PRs in raylib.

My understanding now is you’re right that upstream intentionally keeps Wayland off by default in current raylib.

Makefile default: raysan5/raylib#4369
CMake default: raysan5/raylib#4432
Rationale thread: raysan5/raylib#4371

So changing defaults in 5.5 is likely not the right move.

For clarity, this seems to be the key maintainer decision point:

"Now it's easier to take a decision on this change and yeah, I agree that #4369 is the way to go for now."
raysan5/raylib#4371 (comment)

And separately, found this on the wiki warning being stale:

"Yes, the Wiki message should be updated, this is 3 years old and afaik behaviour changed."
raysan5/raylib#2666 (comment)

Given that, I’m happy to align with project policy and not force-enable Wayland for 5.5 wheels.

I think at this point we can close this PR and then we can revisit default behavior when upstream policy changes in 5.6+.

[electronstudio]

People seem to still have problems when Wayland is enabled on high dpi displays and when getting mouse coords.

What was the Crimson bug this solves?

Have you tried raylib_sdl, it's generally better than the default glfw?

[electronstudio]

Looks like the solution for Crimson would be "install xwayland" in the instructions?

[banteg]

the crimson bug was: uvx crimsonland@latest on wayland failed at backend init with:

X11: Failed to load Xlib / Failed to initialize GLFW.

so this is an early display/window backend init issue.

i also checked raylib_sdl (5.5.0.4) wheels:

x86_64/i686: still X11-oriented; aarch64: includes wayland markers (WAYLAND_DISPLAY, SDL Wayland video driver, wl_display*)

so recommending raylib_sdl does not currently solve this for most linux desktop users who are on x86_64.

given upstream policy and wayland issues with hidpi and mouse coords, i agree we should not flip defaults in 5.5.

i'll document xwayland + libX11 as the crimson workaround for pypi-wheel installs on my side.