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

Currently RDK OSS does by default opposite of what wayland graphics guys tried to achieve with libwayland-egl.so split. RDK removes the generic libwayland-egl.so provided by Wayland because it expects it to be provided by platform-specific integration. (unless you explicitly use wayland-default-egl.bb recipe) . Should be changed once all SoC support this split mode

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 (access rights are restricted to aml licensees)

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

TO DO insert REFERENCE TO AML Jira TICKET TO INVESTIGATE / FIX this 

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"

on Broadcom

since move to newer brcm wayland backend in RDK6 no issue

libs deps https://github.com/stagingrdkm/lgpub/blob/master/dac/templates/oe_4.0/72126ott_libs.json

on Realtek

issue to be described

libs deps https://github.com/stagingrdkm/lgpub/blob/master/dac/templates/oe_4.0/rtd1319_libs.json

on meta-bolt-distro

distribution and base layer for firebolt native runtimes and apps

libwayland-egl.so should become part of base-layer. It is currently provided by wayland recipe but it is currently not installed in base-layer rootfs because it is removed as part of  following post rootfs image handling https://github.com/rdkcentral/meta-bolt-distro/blob/3c368153f4edb8bf8ae8c95fcec5c3ed995fcacc/meta-bolt-base/classes/base-bolt-image.bbclass#L40

The reason why it is still being removed because when testing we see application is not visible on Amlogic AH212 when using the libwayland-egl.so from wayland in Application container while it works when bind mounting libMali.so as libwayland-egl.so provider. (see Amlogic issue) so when that is fixed  we can move to that

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.