Page History

...

This is a generic library (as of wayland v1.13) that is provided by wayland project and MUST 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

...

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

...

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

...