Name OHOS_image_native_buffer Name Strings EGL_OHOS_image_native_buffer Contributors Xindong Shi Zheng Li Contact Xindong Shi, Huawei Inc. (shixindong 'at' huawei.com) Zheng Li, Huawei Inc. (lizheng2 'at' huawei.com) Status Complete Version Version 1, Dec. 14, 2021 Number EGL Extension #148 Dependencies EGL 1.2 is required. EGL_KHR_image_base is required. This extension is written against the wording of the EGL 1.2 Specification. Overview This extension enables using a Openharmony native buffer (struct HNativeWindowBuffer) as an EGLImage source. New Types None. New Procedures and Functions None. New Tokens Accepted by the parameter of eglCreateImageKHR: EGL_NATIVE_BUFFER_OHOS 0x34E1 Changes to Chapter 3 of the EGL 1.2 Specification (EGL Functions and Errors) Add to section 2.5.1 "EGLImage Specification" (as defined by the EGL_KHR_image_base specification), in the description of eglCreateImageKHR: "Values accepted for are listed in Table aaa, below. +-------------------------+---------------------------------------------------+ | | Notes | +-------------------------+---------------------------------------------------+ | EGL_NATIVE_BUFFER_OHOS | Used for Openharmony HNativeWindowBuffer objects | +-------------------------+---------------------------------------------------+ Table aaa. Legal values for eglCreateImageKHR parameter ... If is EGL_NATIVE_BUFFER_OHOS, must be a valid display, must be EGL_NO_CONTEXT, must be a pointer to a valid HNativeWindowBuffer object (cast into the type EGLClientBuffer), and attributes other than EGL_IMAGE_PRESERVED_KHR are ignored." Add to the list of error conditions for eglCreateImageKHR: "* If is EGL_NATIVE_BUFFER_OHOS and is not a pointer to a valid HNativeWindowBuffer, the error EGL_BAD_PARAMETER is generated. * If is EGL_NATIVE_BUFFER_OHOS and is not EGL_NO_CONTEXT, the error EGL_BAD_CONTEXT is generated. * If is EGL_NATIVE_BUFFER_OHOS and was created with properties (format, usage, dimensions, etc.) not supported by the EGL implementation, the error EGL_BAD_PARAMETER is generated." Issues 1. Should this extension define what combinations of HNativeWindowBuffer properties implementations are required to support? RESOLVED: No. The requirements have evolved over time and will continue to change with future Openharmony releases. The minimum requirements for a given Openharmony version should be documented by that version. Revision History #1 (Xindong Shi, Zheng Li, Dec. 14, 2021) - Initial draft.