Add wayland and kmsdrm support to manylinux wheels

[ankith26]

Continuation of upstream pygame/pygame#3482

[Starbuck5]

Could you explain what this PR does and how it does it?

[ankith26]

So basically, we compile wayland and friends (libdecor, protocols) so that SDL-compilation step finds it at compile time. These are not bundled in the wheels, and just like X11, is dynamically loaded on the users system if available.

I'm also adding mesa (and its deps) because it is needed for proper wayland support as I understand it (though in the long run someone more experienced than me will probably find more usecases for something like mesa being bundled in pygame wheels)

To test this PR, a linux user who has wayland can use SDL_VIDEODRIVER=wayland and run any pygame app (note that this would error previously if you are using a CI made wheel; locally made wheels are a different story)

[Starbuck5]

Thanks for the clarification.

If the deps aren't bundled, what's the point of building it ourselves? Can't we get libwayland-devel our whatever through apt?

Also does this stuff build on mac too? It seems like it shouldn't.

[robertpfeiffer]

If the deps aren't bundled, what's the point of building it ourselves? Can't we get libwayland-devel our whatever through apt?

Back when I filed pygame/pygame#2529, official pygame wheels would only use X11 on wayland (xwayland), but compiling on my own would fix this.

[ankith26]

Can't we get libwayland-devel our whatever through apt?

The base image we use (manylinux2014) is old, wayland likely doesn't exist on those old centos repos, and even if it somehow did, would be quite outdated and SDL needs a new-ish wayland

Also does this stuff build on mac too? It seems like it shouldn't.

It doesn't build on macs, only manylinux

[MyreMylar]

LGTM - from a scan through the scripts.

I think the only way we are going to be certain that this works is if we get in merged, get the wheels building and then get somebody with wayland & kmsdrm to test them out. That person will not be me as I do not have that hardware.

[Starbuck5]

Shouldn't we be building against the oldest wayland stuff that still works? Because it will need to be linked at runtime on users systems, and that only happens if runtime available version >= compiled version? Looking at versions, I see we're building Mesa 23.0.0, which came out less than a month ago. So wouldn't that fail to link on anyone's system not on bleeding edge Mesa?

[MyreMylar]

Linked to: #1301

[pmp-p]

Shouldn't we be building against the oldest wayland stuff that still work

Nobody would use that, (old) wayland/pulseaudio/systemd are alpha prototypes stage that were (are) experimented on "live".

Wayland support allow for integration of pygame-ce in GNU/Linux rolling releases distributions.
Mesa should be always up to date or hardware drivers could fail.

[Starbuck5]

But we don’t ship “Wayland”, we rely on what’s on the user’s system right? This is dynamic linking?

I don’t understand how we can compile against the latest and then have it work against not the latest. That’s not how libc works, famously. The PyInstaller docs say that you have to compile against the oldest libc you plan on supporting, why would this be different?

[ankith26]

Some updates on this

1. Building against the latest wayland+libdecor isn't problematic (as wayland negotiates the correct protocol version)
2. the mesa stuff is apparently not being bundled in the wheels at all, which is a good thing because now it seems like it's going to pick whatever is on the users system (AKA retain same behaviour as before this PR)

[oddbookworm]

LGTM!

[oddbookworm]

Holding off on merge because I want @Starbuck5 to have the chance to voice any reservations he may still have after the most recent updates

[Starbuck5]

I feel like with dependency updates like these the only way to really anticipate what happens is to see what happens, so lets merge this in.