OpenHarmony—4.0图形HDI基础适配及点屏差异分析

这篇具有很好参考价值的文章主要介绍了OpenHarmony—4.0图形HDI基础适配及点屏差异分析。希望对大家有所帮助。如果存在错误或未考虑完全的地方,请大家不吝赐教,您也可以点击"举报违法"按钮提交疑问。

一、进程调用关系变化

graphic_2d_feature_rs_enable_eglimage,服务器,linux,运维,harmonyos,华为,鸿蒙系统,鸿蒙

1.1 进程数量变化

新增加两个uhdf进程。allocator_host进程及composer_host进程。

删除了disp_gralloc_host 进程,并使用allocator_host替换。

uhdf添加进程配置如下:

hdf_config/uhdf/device_info.hcs

display_composer :: host {
    hostName = "composer_host";
    priority = 40;
    processPriority = -8;
    threadPriority = 1;
    caps = ["SYS_NICE"];
    uid = ["composer_host"];
    gid = ["composer_host", "graphics", "vendor_mpp_driver"];
    composer_device :: device {
        device0 :: deviceNode {
            policy = 2;
            priority = 160;
            moduleName = "libdisplay_composer_driver_1.0.z.so";
            serviceName = "display_composer_service";
        }
    }
}
allocator :: host {
    hostName = "allocator_host";
    priority = 40;
    allocator_device :: device {
        device0 :: deviceNode {
            policy = 2;
            priority = 160;
            moduleName = "liballocator_driver_1.0.z.so";
            serviceName = "allocator_service";
        }
    }
}

1.2 拉起关系变化

  • composer

以前版本composer由render_service通过单例拉起,现在通过composer service拉起接口实现层libdisplay_composer_vdi_impl.z.so,对外提供标准的IPC服务.

  • allocator

进程名字由disp_gralloc_host变更成allocator_host。通过allocator_service拉起接口实现层libdisplay_buffer_vdi_impl.z.so,对外提供标准的IPC服务。

二、接口协议更新

2.1 接口更新

结构体定义由原来的.h变为接口描述语言IDL代替,在协议升级过程中,会遇到大量结构体命名空间不一样的冲突,总体解决思路就是去掉原有的.h头文件依赖,增加新的接口头文件即可。

  • allocator_host

头文件更新:由display_type.h 更新成v1_0/display_buffer_type.h。由DisplayBufferType.idl生成在out下

接口协议更新:

由原来的display_gralloc.cpp中提供的接口更换成OHOS::HDI::Display::Buffer::V1_0::IDisplayBufferVdi,并新建接口实现文件:

display_buffer_vdi_impl.cpp/.h。

参考drivers/peripheral/display/hal/default_standard/src/display_gralloc/display_buffer_vdi_impl.cpp中的接口,并按自己的实际情况完成实现。

  • composer_host

头文件更新:由display_type.h 更新成v1_0/display_composer_type.h。由DisplayComposerType.idl生成在out下

由原来的hdi_session.cpp中提供的接口更换成OHOS::HDI::Display::Composer::V1_0::IDisplayComposerVdi,并新建接口实现文件:

display_composer_vdi_impl.cpp/.h

参考drivers/peripheral/display/hal/default_standard/src/display_device/display_composer_vdi_impl.cpp中的接口,并按自己的实际情况完成实现。

2.2 其它头文件更新

  • BufferHandle

新结构体去掉了key,如果代码中有用到,需要让以下定义保持一致:

drivers/hdf_core/interfaces/inner_api/hdi/base/buffer_handle.h
drivers/peripheral/base/buffer_handle.h
foundation/graphic/graphic_2d/frameworks/surface/include/buffer_handle.h
  • 其它头文件:

drivers/peripheral/display/interfaces/include下的头文件与device_type.h有关联。要解耦,不要使用。

三、开机动画

在4.0中,开机动画默认使用的是播放视频,对点屏不友好,建议修改成原图片播放方式,修改方法如下:

frameworks/bootanimation/include/boot_animationconfig.h

@@ -33,7 +33,7 @@ public:
    bool IsBootVideoEnabled();
private:
    BootCustomConfig custConfig_;
-   bool bootVideoEnabled_ = true;
+   bool bootVideoEnabled_ = false; //不使用视频开机动画模式
};
} // namespace OHOS

四、hello_composer编译报错

合入如下修改解决:graphic_2d_feature_rs_enable_eglimage,服务器,linux,运维,harmonyos,华为,鸿蒙系统,鸿蒙

五、CPU渲染

当前4.0切换成CPU渲染是会报错的,提示一些gl.h/egl.h等文件找不到,与GPU文件解耦不足,通过合入以下修改解决:

diff --git a/graphic_config.gni b/graphic_config.gni
index f7b7b3bdb..635197e80 100644
--- a/graphic_config.gni
+++ b/graphic_config.gni
@@ -13,9 +13,9 @@
 
 declare_args() {
   graphic_2d_feature_bootanimation_enable = true
-  graphic_2d_feature_ace_enable_gpu = true
+  graphic_2d_feature_ace_enable_gpu = false
   graphic_2d_feature_color_gamut_enable = false
-  graphic_2d_feature_rs_enable_eglimage = false
+  graphic_2d_feature_rs_enable_eglimage = true
   graphic_2d_feature_rs_enable_uni_render = false
   graphic_2d_feature_wuji_enable = false
   graphic_2d_feature_enable_afbc = false
diff --git a/rosen/modules/effect/skia_effectChain/BUILD.gn b/rosen/modules/effect/skia_effectChain/BUILD.gn
index b4a23f6ca..7e29b369b 100644
--- a/rosen/modules/effect/skia_effectChain/BUILD.gn
+++ b/rosen/modules/effect/skia_effectChain/BUILD.gn
@@ -37,6 +37,7 @@ config("effect_SKeffectChian_public_config") {
     "//foundation/multimedia/image_framework/interfaces/innerkits/include",
     "$graphic_2d_root/utils/log",
     "include",
+    "//third_party/openGLES/api",
   ]
 }
 
@@ -44,6 +45,8 @@ ohos_shared_library("skeffectchain") {
   public_deps = [
     "$graphic_2d_root:libsurface",
     "$graphic_2d_root/rosen/modules/effect/egl:libegl_effect",
+    "//third_party/EGL:libEGL",
+    "//third_party/openGLES:libGLES",
   ]
 
   if (ace_enable_gpu) {
@@ -51,6 +54,7 @@ ohos_shared_library("skeffectchain") {
     public_deps += [ "$graphic_2d_root:libgl" ]
   }
 
+  public_deps += [ "$graphic_2d_root:libgl" ]
   if (defined(use_new_skia) && use_new_skia) {
     public_deps += [ "//third_party/skia:skia_ohos" ]
   } else {
diff --git a/rosen/modules/render_service/BUILD.gn b/rosen/modules/render_service/BUILD.gn
index 77b26ea2f..b27faca7c 100644
--- a/rosen/modules/render_service/BUILD.gn
+++ b/rosen/modules/render_service/BUILD.gn
@@ -183,6 +183,13 @@ ohos_shared_library("librender_service") {
     defines += accessibility_defines
   }
 
+  cflags = [
+    "-Wall",
+    "-Wno-unused-const-variable",
+  ]
+
+  cflags_cc = [ "-Wno-unused-const-variable" ]
+
   part_name = "graphic_2d"
   subsystem_name = "graphic"
 }
diff --git a/rosen/modules/render_service/core/pipeline/rs_base_render_engine.cpp b/rosen/modules/render_service/core/pipeline/rs_base_render_engine.cpp
index c7418e0fb..fac0a162d 100644
--- a/rosen/modules/render_service/core/pipeline/rs_base_render_engine.cpp
+++ b/rosen/modules/render_service/core/pipeline/rs_base_render_engine.cpp
@@ -85,6 +85,7 @@ void RSBaseRenderEngine::Init()
 
 bool RSBaseRenderEngine::NeedForceCPU(const std::vector<LayerInfoPtr>& layers)
 {
+#ifdef RS_ENABLE_GL
     bool forceCPU = false;
     for (const auto& layer: layers) {
         if (layer == nullptr) {
@@ -113,6 +114,9 @@ bool RSBaseRenderEngine::NeedForceCPU(const std::vector<LayerInfoPtr>& layers)
     }
 
     return forceCPU;
+#else
+    return true;
+#endif
 }
 
 #ifndef USE_ROSEN_DRAWING
diff --git a/rosen/modules/render_service_base/src/platform/ohos/BUILD.gn b/rosen/modules/render_service_base/src/platform/ohos/BUILD.gn
index e1bf2eb3b..cfa6676f1 100644
--- a/rosen/modules/render_service_base/src/platform/ohos/BUILD.gn
+++ b/rosen/modules/render_service_base/src/platform/ohos/BUILD.gn
@@ -109,6 +109,7 @@ ohos_source_set("rosen_ohos_sources") {
     "//drivers/peripheral/display/interfaces/include/",
     "$graphic_2d_root/rosen/modules/render_service_client/core",
     "$graphic_2d_root/utils/log",
+    "//third_party/openGLES/api",
   ]
 
   public_deps = [
@@ -116,6 +117,8 @@ ohos_source_set("rosen_ohos_sources") {
     "$graphic_2d_root/rosen/modules/2d_graphics:2d_graphics",
     "$graphic_2d_root/rosen/modules/composer/vsync:libvsync",
     "$graphic_2d_root/utils:sync_fence",
+    "//third_party/EGL:libEGL",
+    "//third_party/openGLES:libGLES",
   ]
   if (defined(use_new_skia) && use_new_skia) {
     public_deps += [ "//third_party/skia:skia_ohos" ]

五、实战经验分享

本次实战主要是把产品从3.2.3-Release升级到4.0-Release。中间看到这些变化,心里有点慌,从而记录下来,并提供给大家参考。框架上遇到的一些问题,前面几节已经给大家说明了,以下是一些升级的步骤及建议。

1、添加接口协议文件、gn编译、hcs配置。

​ 为composer添加display_composer_vdi_impl.cpp/.h

​ 为gralloc添加display_buffer_vdi_impl.cpp/.h。

​ 在gn中添加目标libdisplay_composer_vdi_impl和libdisplay_buffer_vdi_impl。

​ 在device_info.hcs中添加进程配置。

2、编译修改。

​ 这个是工作量比较大的地方。原则上就是去掉drivers/peripheral/display/interfaces/include下的头文件依赖,并添加

​ #include "v1_0/display_composer_type.h"

 #include "v1_0/display_buffer_type.h"

以及命名空间:

​ using namespace OHOS::HDI::Display::Composer::V1_0;

​ using namespace OHOS::HDI::Display::Buffer::V1_0;

​ 当然gn中也要添加相应的依赖。

3、调试。

​ 主要使用hello_composer调试,关注hdi_backend.cpp中Repaint函数执行流程,并在hilog中搜索关键命令字:REQUEST_CMD,一个完整的流程必须包含以下命令:

REQUEST_CMD_PREPARE_DISPAY_LATERS
REQUEST_CMD_SET_DISPLAY_CLIENT_DAMAGE
REQUEST_CMD_SET_DISPLAY_CLENT_BUFFER
REQUEST_CMD_COMMIT

如果so没有正常加载,也可以在以下文件中添加打印:

drivers/peripheral/display/buffer/hdi_service/src/allocator_service.cpp
drivers/peripheral/display/composer/hdi_service/src/display_composer_service.cpp

可以为dlopen添加详细错误信息,默认没有添加:

if (libHandle_ == NULL) {
        error = dlerror();
        DISPLAY_LOGE("composer load path%{public}s, dlopen err=%{public}s", DISPLAY_COMPOSER_VDI_LIBRARY, error);
        return HDF_FAILURE;
    }

本文主要介绍OpenHarmony 4.0图形HDI基础适配及点屏差异。适用于版本升级,新特性了解及问题分析。

想学习更多华为鸿蒙HarmonyOS开发知识,在这里我为大家准备了华为鸿蒙HarmonyOS开发者资料大全,大家可以自行点击链接领取:《做鸿蒙应用开发到底学习些啥?》

graphic_2d_feature_rs_enable_eglimage,服务器,linux,运维,harmonyos,华为,鸿蒙系统,鸿蒙

其次就是考虑到市场上还没有系统性的学习资料,同时我也整理了一份《鸿蒙 (Harmony OS)开发学习手册》特意整理成PDF文档方式,分享给大家参考学习,大家可以根据自身情况进行获取:《鸿蒙开发学习指南》

《鸿蒙 (Harmony OS)开发学习手册》

一、入门必看

1. 应用开发导读(ArkTS)

2. 应用开发导读(Java)

3.......

graphic_2d_feature_rs_enable_eglimage,服务器,linux,运维,harmonyos,华为,鸿蒙系统,鸿蒙

二、HarmonyOS 概念

1. 系统定义

2. 技术架构

3. 技术特性

4. 系统安全

5......

graphic_2d_feature_rs_enable_eglimage,服务器,linux,运维,harmonyos,华为,鸿蒙系统,鸿蒙

三、如何快速入门?《鸿蒙基础入门开发宝典!》

1. 基本概念

2. 构建第一个ArkTS应用

3. 构建第一个JS应用

4. ……

graphic_2d_feature_rs_enable_eglimage,服务器,linux,运维,harmonyos,华为,鸿蒙系统,鸿蒙

四、开发基础知识

1. 应用基础知识

2. 配置文件

3. 应用数据管理

4. 应用安全管理

5. 应用隐私保护

6. 三方应用调用管控机制

7. 资源分类与访问

8. 学习ArkTS语言

9. ……

graphic_2d_feature_rs_enable_eglimage,服务器,linux,运维,harmonyos,华为,鸿蒙系统,鸿蒙

五、基于ArkTS 开发

1. Ability开发

2. UI开发

3. 公共事件与通知

4. 窗口管理

5. 媒体

6. 安全

7. 网络与链接

8. 电话服务

9. 数据管理

10. 后台任务(Background Task)管理

11. 设备管理

12. 设备使用信息统计

13. DFX

14. 国际化开发

15. 折叠屏系列

16. ……

graphic_2d_feature_rs_enable_eglimage,服务器,linux,运维,harmonyos,华为,鸿蒙系统,鸿蒙

更多了解更多鸿蒙开发的相关知识可以参考:《鸿蒙开发学习指南》文章来源地址https://www.toymoban.com/news/detail-834967.html

到了这里,关于OpenHarmony—4.0图形HDI基础适配及点屏差异分析的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处: 如若内容造成侵权/违法违规/事实不符,请点击违法举报进行投诉反馈,一经查实,立即删除!

领支付宝红包 赞助服务器费用

相关文章

  • openharmony开发最新4.0版本----介绍openharmony(基于api10 ,华为dev studio 4.0,分享学习过程中遇到的难题难点),学习笔记,持续更新

            DevEco Studio(OpenHarmony)使用指南:         HUAWEI DevEco Studio For OpenHarmony(以下简称DevEco Studio)是基于IntelliJ IDEA Community开源版本打造,面向OpenHarmony全场景多设备的一站式集成开发环境(IDE),为开发者提供工程模板创建、开发、编译、调试、发布等E2E的Open

    2024年02月03日
    浏览(47)
  • OpenHarmony 4.0 源码编译hb 问题排查记录

    OS:Ubuntu 22.04 x86_64 下载好Openharmony 4.0Beta2 的源码 从错信息看是找到某个目录,hb 是python写的,所以打算看看源码是找个目录出错了,根据出错信息直接看源码文件。 查看python 代码可知报错原因是没找到 build/lite/hb_internal ,在OpenHamony 源码下确实没有发现有 build/lite/hb_internal

    2024年02月09日
    浏览(45)
  • OpenHarmony应用签名 - 系统应用签名(4.0-Release)

    开发环境:Windows 11 DevEco Studio 版本:DevEco Studio 4.0 Release(4.0.0.600) SDK 版本:4.0.10.15(Full SDK) 开发板型号:DAYU 200(RK3568) 系统版本:OpenHarmony-4.0-Release 示例工程:Applications_SystemUI OpenHarmony开源社区提供了标准系统上的部分系统应用,如桌面、SystemUI、设置等,为开发者提

    2024年04月11日
    浏览(41)
  • 【开源鸿蒙】下载 OpenHarmony 4.0 源代码和工具链

    本文介绍了如何下载开源鸿蒙(OpenHarmony)操作系统源码,该方法可以用于下载OpenHarmony最新开发版本(master分支)或者4.0 Release、3.2 Release等发布版本。 本文基于Ubuntu 22.04进行操作,Ubuntu其他版本也同样可行,包括 20.04, 18.04。 OpenHarmony架构图: 本节介绍如何准备命令行工具

    2024年04月13日
    浏览(92)
  • OpenHarmony 4.0 分布式软总线解析:设备发现与传输

    OpenHarmony 的分布式软总线子系统为 OpenHarmony 系统提供的通信相关的能力,包括:WLAN 服务能力、蓝牙服务能力、软总线、进程间通信 RPC(Remote Procedure Call)等通信能力。 其中主要包括: WLAN 服务:为用户提供 WLAN 基础功能、P2P(peer-to-peer)功能和 WLAN 消息通知的相应服务,

    2024年04月23日
    浏览(47)
  • OpenHarmony应用签名 - DevEco Studio 自动签名(4.0-Release)

    开发环境:Windows 11 DevEco Studio 版本:DevEco Studio 4.0 Release(4.0.0.600) SDK 版本:4.0.10.13 开发板型号:DAYU200(RK3568) 系统版本:OpenHarmony-4.0-Release 为了保证  OpenHarmony  应用的完整性和来源可靠,在应用构建时需要对应用进行签名。经过签名的应用才能在设备上安装、运行、和调

    2024年02月03日
    浏览(46)
  • OpenHarmony 4.0 Beta2新版本发布,邀您体验

    2023年8月3日,OpenAtom OpenHarmony(简称“OpenHarmony”)发布了Beta2版本,相较于历史版本我们持续完善ArkUI、文件管理、媒体、窗口、安全等系统能力、提升体验。欢迎开发者了解并升级使用,积极反馈宝贵建议、参与贡献,共同促进4.0版本的成熟。 为了方便社区开发者了解新版

    2024年02月09日
    浏览(41)
  • OpenHarmony应用集成和固件集成中C库差异化分析

    OpenHarmony中,三方库的使用有两种方式: 一、固件集成 三方库经由OpenHarmony构建框架编译出的动态库或静态库,打包到rom中 二、应用集成 三方库经由IDE(通过IDE中的cmake)编译出的动态库或静态库,打包到hap包中 有时候我们想直接使用三方库,省略编译构建这个过程,直接

    2024年04月14日
    浏览(33)
  • 【Openharmony】【4.0R】hello程序之“ohos.gni”模板使用方法

    lite_component.gni虽然好用,但是毕竟是个“轻量-组件”模板。 这里记录下较为常用的“ohos.gni”模板使用方法。 OH版本:4.0Release 内核版本:LiteOS-A 产品版本:qemu_small_system_demo 相比lite_component.gni模板,ohos.gni模板要复杂多了,关于该模板教程也很多。 首先依然是要先import才能

    2024年02月03日
    浏览(61)
  • 开发板如何适配OpenHarmony 3.2

    简介 OpenAtom OpenHarmony(以下简称“OpenHarmony”) 3.2 Beta5版本在OpenHarmony 3.1 Release版本的基础上,有以下改变:性能上有很大的提升、标准系统应用开发框架增强、标准系统分布式能力增强。 本文介绍诚迈科技基于RK3568设计的HCPAD-100开发板以及基于RK3566设计的中控屏HongzPad2022在

    2024年02月07日
    浏览(46)

觉得文章有用就打赏一下文章作者

支付宝扫一扫打赏

博客赞助

微信扫一扫打赏

请作者喝杯咖啡吧~博客赞助

支付宝扫一扫领取红包,优惠每天领

二维码1

领取红包

二维码2

领红包