Page History

...

On some SoCs (Amlogic and realtekRealtek?) 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

...

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.

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 SoCs support this generic libwayland-egl.so model 

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

However since library is only provided as a prebuild binary and not in source code we cannot see how build recipes work and possibly bring in wrong linking, dependencies and we as RDK-M cannot investigate (access to full source code from Mali requires ARM approval according to Mali DDK license) and as long as RDK-M does not have that arm approval action is fully on amlogic. However Amlogic no longer providing support at the moment! We are stuck.

Info from ARM site : To build a functional OpenGL ES you need access to the full source code of the Mali GPU DDK, which is provided under the standard Arm commercial license to all Mali GPU customers.

https://developer.arm.com/downloads/-/Bifrost%20Mali%203rd%20Gen%20GPU%20Architecture

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

on broadcom it is ok since move to newer brcm wayland backend (WLPL) in RDK6 

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

on Realtek

issue to be described

Same problem as amlogic

Since library is only provided as prebuild binary and as source code we cannot see how build recipes work and possibly bring in wrong linking, dependencies and we as RDK-M cannot investigate.

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

...

1. Frontend (libwayland-egl.so)
Provides stable, public API for applications:
2. • 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.
3. Backend Interface (wayland-egl-backend.h)
Defines internal hooks and structures for EGL platform implementers:
4. • 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.

...