wayland-egl.so usage in RDK-8

libwayland-egl.so is the 'Frontend wayland-egl library' that wayland-egl client applications need to link against. 

This is a generic library (as of wayland v1.13) that is provided by wayland project and SHOULD NOT be a platform/SoC specific library provided by (SoC) vendor layer .

On some SoCs (Amlogic and Realtek?) the libwayland-egl.so in RDKv6/7 is library provided by SoC vendor layer instead generic frontend lib provided by wayland and we need to fix/resolve that in RDK-8

Purpose of libwayland-egl.so

The wayland graphics experts split wayland-egl between a generic wayland-egl.so frontend library for use by wayland-client applications and versioned backend "wayland-egl-backend-h which serves only as interface, not as library, header file that EGL graphics driver implementations can use"

This was designed to separate this wayland-egl library and applications using it from platform/soc specific EGL drivers, to NOT drag in a platform/soc specific link dependency chain into this library and applications/application containers using it.

The wayland-egl-backend.h is NOT part of the public API for application developers and application do not link to it. It is a versioned interface, helper API that EGL graphics drivers can use. 

That split happened in wayland version 1.13.  RDK-8 uses kirkstone which uses wayland version 1.20. 

More details on reasons and history of this split are described in "History and reasons for split" section. 

Here is the wayland source snippet that defines the package config wayland-egl.pc and wayland-egl-backend.pc

wayland-egl.pc leads to the wayland-egl.so library.  Note that wayland-egl-backend.pc does NOT provide .so library, it only serves as header, interface for EGL implementation 

pkgconfig.generate(
	name: 'wayland-egl',
	description: 'Frontend wayland-egl library',
	version: '18.1.0',
	requires: 'wayland-client',
	libraries: wayland_egl
)

pkgconfig.generate(
	name: 'wayland-egl-backend',
	description: 'Backend wayland-egl interface',
	version: '3'
)

Issue and clean up required in RDK-8

On some SoCs (Amlogic and Realtek?) the libwayland-egl.so in RDKv6/7 is library provided by SoC vendor layer instead generic frontend lib provided by wayland and we need to fix/resolve that in RDK-8

RDK OSS

on Amlogic

This is current bitbake recipe used in current AH212 version as provider of virtual/libgles but also as RPROVIDES:${PN} += "libwayland-egl.so" , see 

https://code.rdkcentral.com/r/plugins/gitiles/collaboration/soc/amlogic/yocto_oe/layers/meta-amlogic/+/refs/heads/develop/recipes-graphics/libgles/libgles-eabihf-dvalin-wayland-drm_r44p0.bb

https://code.rdkcentral.com/r/plugins/gitiles/collaboration/soc/amlogic/yocto_oe/layers/meta-amlogic/+/refs/tags/3.7.1/recipes-graphics/libgles/libgles-eabihf-dvalin-wayland-drm_r44p0.bb

currently  SRCREV ?= "${SRCREV_AML_BSP}" refers to "AML_BSP_REL_VERSION_RDK6.1.6"

and hence the precompiled so binary that provides libwayland-egl.so is following

https://code.rdkcentral.com/r/plugins/gitiles/collaboration/soc/amlogic/linux/amlogic/meson_mali/+/refs/tags/AML_BSP_REL_VERSION_RDK6.1.6/lib/arm64/dvalin/r44p0/wayland/drm/libMali_dmaheap.so

Since library is only provided as binary and not as source (access requires ARM approval Mali DDK license) we and RDK-M cannot investigate and action is fully on amlogic

readelf -d libMali.so | grep NEEDED  is https://github.com/stagingrdkm/lgpub/blob/master/dac/templates/oe_4.0/ah212_libs.json#L4899-L4912

            "deps": [
                "/lib/ld-linux-armhf.so.3",
                "/lib/libc.so.6",
                "/lib/libdl.so.2",
                "/lib/libgcc_s.so.1",
                "/lib/libm.so.6",
                "/lib/libpthread.so.0",
                "/lib/librt.so.1",
                "/usr/lib/libdrm.so.2",
                "/usr/lib/libstdc++.so.6",
                "/usr/lib/libwayland-client.so.0",
                "/usr/lib/libwayland-server.so.0"
            ],
            "name": "/usr/lib/libMali.so"

of that libe is 

meta-bolt-distro

History and reasons for split

Historical Context

see also some of historical wayland discussion threads on this subject, like  

• Originally, Wayland-EGL integration was a single library providing both:
• Public API for applications (wl_egl_window_create(), etc.).
• Internal hooks for EGL drivers to manage Wayland surfaces.
• This caused tight coupling between the application-facing API and vendor-specific backend logic, making it hard to:
• Maintain ABI stability.
• Support multiple EGL implementations (Mesa, NVIDIA, proprietary stacks).
• Evolve the backend without breaking apps.

• Before this split:

  • Mesa shipped one wayland-egl, Nvidia shipped another
  • Mali/Imagination/Vivante SoC vendors shipped different incompatible versions
  • Compositors tried to support all variants and failed
  • ABI mismatches caused crashes that were impossible to debug
  • Wayland protocol adoption slowed due to EGL chaos

  After the split:

  • The public API (wl_egl_window_*) became stable
  • Vendor drivers no longer shipped their own conflicting frontend
  • Backend ABI became versioned and controlled
  • Compositors can explicitly declare which backend ABI they implement
  • EGL drivers and compositors can reject incompatible combinations early

Architectural Reason for the Split

1. Frontend (libwayland-egl.so)
   • wl_egl_window_create()
   • wl_egl_window_resize()
   • wl_egl_window_destroy()
• Provides stable, public API for applications:
• Links against libwayland-client and libEGL.
• Purpose: Applications only need this library to create EGL surfaces on Wayland.
2. Backend Interface (wayland-egl-backend.h)
   • struct wl_egl_window with driver_private and callbacks.
   • Functions for resize and destroy callbacks.
• Defines internal hooks and structures for EGL platform implementers:
• Allows EGL drivers to attach private data and implement buffer management (GBM for Mesa, EGLStream for NVIDIA).
• Purpose: Vendors can implement their own backend logic without exposing internals to apps.