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 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

Issue on RDK  :

• on some RDK platform (Amlogic, Realtek) the 

It basically comes down to that  “libwayland-egl.so” library is front-end library for use by applications without soc dependent link dependencies and we should hence we should build and add that lib to our base-layer and NOT bind mount that lib from host in our container.

And we need to mandate that drivers in vendor layer use and support the wayland-egl-backend interface version 3 and possibly review/clean up way they build that library now on host.

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)
• Provides stable, public API for applications:
• wl_egl_window_create()
• wl_egl_window_resize()
• wl_egl_window_destroy()
• 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)
• Defines internal hooks and structures for EGL platform implementers:
• struct wl_egl_window with driver_private and callbacks.
• Functions for resize and destroy callbacks.
• 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.