Thomas Petazzoni 4fad6b3c58 package/opengl/libegl: remove BR2_PACKAGE_HAS_LIBEGL_WAYLAND ... Since wayland 1.15 (upstream commit 549a5ea710f4da1a5749587176d39fef1ded4077), libwayland-egl.so is provided by the wayland package, so there is no longer a question of whether libwayland-egl.so is provided by the particular EGL implementation. See the Wayland commit log: wayland-egl: import libwayland-egl.so frontend library from Mesa Currently the client-facing libwayland-egl API is defined by a header file shipped by Wayland, but the implementation is left to each vendor. This can cause collisions when multiple implementations are installed on the same system. Importing the implementation into Wayland with a stable and versioned driver-facing ABI allows multiple drivers to coexist on the same system. Pull the sample implementation from Mesa commit 677edff5cfd ("wayland-egl: rework and simplify wl_egl_window initialization") It has been used by the Mesa open source drivers, NVIDIA and others[1]. v2: Reword commit message, rebase on top of newer Mesa. [1] https://github.com/thayama/wayland-egl Consequently, we remove the BR2_PACKAGE_HAS_LIBEGL_WAYLAND option. Packages that rely on BR2_PACKAGE_HAS_LIBGLES and BR2_PACKAGE_WAYLAND are guaranteed to have libwayland-egl.so. Note that this doesn't solve the problem that libwayland-egl.so will be provided both by wayland itself and by by the implementation (rockchip-mali, sunxi-mali-utgard, ...). Still, there is a dependency from the implementation on wayland so at least it is predictable which one will end up on the target. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com> [Arnout: remove remaining references in sway and sunxi-mali-utgard] Signed-off-by: Arnout Vandecappelle <arnout@mind.be>		2024-07-13 09:30:58 +02:00
..
Config.in
egl.pc
glesv2.pc
sunxi-mali-utgard.hash
sunxi-mali-utgard.mk