QNX SCREEN架构基本介绍

QNX screen使用介绍 第一章 一、screen介绍 QNX screen系统是一个图形框架,提供开发时图像显示功能,抽象对外统一接口,屏蔽底层硬件差异 screen是基于client/server模型,screen进程是server程序,libscreen/libEGL/libGLESv2提供了对外的API函数 screen支持应用程序渲染和硬件加速 screen支持插件,加载特定的硬件模块,例如显示硬件模块,2D/3D加速器(GPU)和输入设备等资源 ... 阅读详情
AI摘要

QNXSCREEN是一个由QNX开发的图形显示和窗口管理框架,适用于嵌入式系统。它提供显示管理、窗口管理、硬件加速、多屏幕支持和事件处理等功能。框架具有可扩展性,支持插件和自定义驱动。QNXSCREEN的启动通常由screen-c/lib64/graphics.conf命令触发,且依赖于openwfd显示框架。调试方面,可以通过/dev/screen目录、screencmd工具以及displaylog进行图层信息的检查和调试。

QNX SCREEN介绍

QNX SCREEN框架是用于图形显示和窗口管理的软件框架,由QNX开发,旨在为嵌入式系统提供高性能、可靠的图形显示和用户界面功能。

QNX SCREEN框架提供了以下主要功能:

  1. 显示管理:SCREEN框架允许应用程序管理图形显示设备,包括显示器、触摸屏、图形加速器等。它提供了与硬件设备的通信接口,使应用程序能够获取和控制显示设备的属性、分辨率、刷新率等。

  2. 窗口管理:SCREEN框架支持窗口管理,允许应用程序创建、管理和控制多个窗口。它提供了窗口的布局、焦点管理、窗口叠放顺序、窗口移动和调整大小等功能,以实现灵活的用户界面。

  3. 图形加速:SCREEN框架通过与图形加速器驱动程序的集成,可以提供硬件加速的图形渲染和绘图功能。这可以提高图形操作的性能和效率,并支持复杂的图形效果和动画。

  4. 多屏幕支持:SCREEN框架可以处理多个显示屏,并提供多屏幕的配置和管理功能。它允许应用程序在多个显示屏上创建窗口,并提供显示屏之间的数据传输和协同工作的能力。

  5. 事件处理:SCREEN框架提供了事件处理机制,用于处理用户输入、触摸事件、窗口事件等。它允许应用程序注册事件处理器,以响应各种事件并更新用户界面。

  6. 可扩展性:SCREEN框架支持插件和扩展,允许开发人员根据特定需求添加自定义功能和驱动程序。这使得框架可以适应不同的硬件平台和应用场景。

QNX SCREEN架构

SCREEN源码

screen服务源码不开源,forget it!

SCREEN的启动

screen服务在QNX系统中一般由命令:screen -c /lib64/graphics.conf启动,这个动作通常由startupmanager带起,你可以在源码文件:filesets/launcher_scripts/disp.c中找到相关源码:

static const char* screen_arg [] = { 
    "screen",
    "-c",
    "/lib64/graphics.conf",
    NULL
};

static const struct aaction screen = { 
    .type = TYPE_CMD,
    .c = { 
        .flags = FLAG_BACKGROUND,
        .path = "screen",
        .arg = screen_arg,
        .secpol_type = "screen_t",
        .uid=SCREEN_UID,
        .gid=SCREEN_GID,
        .rmasks = 0xFE,
    },  
};

screen服务初始化依赖于openwfd显示框架,所以要求启动顺序要在wfd服务之后:

   32795 wfd_server -U 70:70,33,21 
   32797 wfd_be 5 
   32798 screen -c /lib64/graphics.conf

需要注意的是screen的初始化并不依赖于GPU,所以它可以先于GPU驱动先初始化,但是,正常screen接口使用一定要在GPU驱动初始结束之后(特别是与GPU相关的操作).

SCREEN debug方法

/dev/screen目录

screen服务正常启动之后会在/dev/目录下生成screen文件夹:

# ls /dev/screen/
0                         9711657                   mtouch
1196133                   buffers                   qvm
487478                    gpus                      requests
495671                    input                     ssplash
766018                    life_cycle_man_demo
823370                    lpms
# 

0: 这个目录包含了screen配置的主要信息,包括display配置信息,framebuffer配置信息

# ls
blt-1              dpy-2              str-2
blt-2              framebuffer1       str-4
ctx-0              framebuffer2       win-0
dpy-1              globals            win-1
# pwd
/dev/screen/0
# 

buffers:目录可以获取当前屏幕显示的buffer数据内容

$PID: 目录包含该进程使用到screen相关信息,例如:windows信息,buffer信息,screen_ctx

# find ./
./
./ctx-1
./ssn-0
./str-0
./str-0/str-0
./str-0/str-0-1
./win-2
# ls ./str-0/str-0-1/
buf-62         buf-62.bmp     buf-62.data
# pwd
/dev/screen/9711657
# 

screencmd

用于设置修改windows的属性,牛逼的地方在于是实时生效的,效果和修改代码一样:

screencmd setiv win-8 SCREEN_PROPERTY_SIZE 400,400
screencmd setiv win-8 SCREEN_PROPERTY_ROTATION  90
screencmd setiv win-4 SCREEN_PROPERTY_ZORDER 1000

使用的时候,需要知道你想修的windows是哪一个,你可以在/dev/screen/$pid/目录下找到这个信息:

# ls /dev/screen/
0                         9711657                   mtouch
1196133                   buffers                   qvm
487478                    gpus                      requests
495671                    input                     ssplash
766018                    life_cycle_man_demo
823370                    lpms
# ls /dev/screen/9711657/
ctx-1    ssn-0    str-0    win-2
# 

dump图层信息

执行:echo surfacedump=0xFF > /dev/displaylog

可以在/tmp目录下得到dump出来的图层文件:

# ls /tmp/displog_surface_dump_*
/tmp/displog_surface_dump_8_[00:00:39.085]_1920x1080_argb8888.rgb

这个方法其实是wfd的debug方法,可以dump各个pipeline上显示的图像数据,dump输出的数据是raw的rgb数据,可以用yuv player一类的工具直接打开。当然displaylog的功能不仅限于此:

# cat /tmp/displog_help 
Input Commands:
        echo ? > /dev/displaylog --> help
        echo s > /dev/displaylog --> status
        echo ll=n > /dev/displaylog --> change log level (default=0x8A)
                0x00000000 NONE
                0x00000001 API_TYPE
                0x00000002 ERROR_INFO_TYPE
                0x00000004 PROFILE_TYPE
                0x00000008 CRITICAL_ERROR_TYPE
                0x00000010 INFO_TYPE
                0x00000020 KERNEL_TRACK_TYPE
                0x00000040 ISR_ERROR_INFO_TYPE
                0x00000080 CRITICAL_INFO_TYPE
                0x00000100 BACK_TRACE_TYPE
                0X00000200 WARNING_INFO_TYPE
                0x00000400 API_PERF_INFO_TYPE
        echo rd=n [submodule] [submodule ID]> /dev/displaylog --> register dump
                1: MDP
                        [submodule]
                         1: SWI
                         2: CTL
                         3: VIG
                         4: VIG_SSPP
                         5: RGB
                         6: RGB_SSPP
                         7: DMA
                         8: DMA_SSPP
                         9: CURSOR_SSPP
                        10: LAYER_MIXER
                        11: DSPP
                        12: WB
                        13: INTF
                        14: PP
                        15: ENCR_NS
                        16: ENCR_S
                        17: AADC
                        18: CDM
                        19: DSC
                        20: QDSS
                2: DSI0
                3: DSI1
                        [submodule]
                        1: CTRL
                        2: PHYREG
                        3: PHY
                        4: PHYPLL
                4: EDP
                5: DP0
                6: DP1
                        [submodule]
                        0: AHBCLK
                        1: AUXCLK
                        2: LCLK
                        3: PCLK
        echo surfacedump=n [m] > /dev/displaylog --> dump input surfaces to /tmp/*
                1: RGB0   5: VG0   t9:  DMA0   13: CURSOR0
                2: RGB1   6: VG1   t10: DMA1   14: CURSOR1
                3: RGB2   7: VG2   t11: DMA2   15: CURSOR2
                4: RGB3   8: VG3   t12: DMA3   16: CURSOR3
                0xFF: dump valid surfaces attached to all mdp pipes
                [m]: Number of frames to dump for multiframe option
        echo apibtenable=n > /dev/displaylog --> API backtrace enable
                0: disable
                1: enable
        echo apibtdump > /dev/displaylog --> Dump API backtrace to file
        echo smmudump > /dev/displaylog --> dump SMMU info to /tmp/*
        echo md > /dev/displaylog --> dump Mutex info to /tmp/*
        echo wfd ?>/dev/displaylog --> dump wfd help info to /tmp/
        echo forcereset=n > /dev/displaylog --> forcefully reset a display module
                1: PRIMARY
                2: EXTERNAL
                3: WRITEBACK
        echo dpauxread [module] [aux_addr] [len] --> To read the DPCD registers
                module:
                         4: EDP
                         5: DP0
                         6: DP1
                aux_addr: DPCD address
                len: number of DPCD registers to be read
        echo dpTPG [module] [stream] [enable] [pattern]
                module:
                         4: EDP
                         5: DP0 
                         6: DP1
                stream:
                         0: stream 0
                         1: stream 1
                enable:
                         0: disable
                         1: enable
                TPG pattern:
                        0: CHECKERED_RECTANGLE_PATTERN[default]
                        1: BASIC_COLOR_CHANGING_PATTERN
                        2: COLOR_SQUARE
                        3: BLACK_WHITE_VERTICAL_LINES
                        4: GRAYSCALE_RAMP
        echo dsiTPG [module] [enable] [pattern]
                module:
                        2: DSI0
                        3: DSI1
                Enable:
                        0: Disable
                        1: Enable
                pattern:
                        0: CHECKERED_RECTANGLE_PATTERN[default]
                        1: BASIC_COLOR_CHANGING_PATTERN
                        2: COLOR_SQUARE
                        3: BLACK_WHITE_VERTICAL_LINES
                        4: GRAYSCALE_RAMP

Reading Outputs:
        cat /dev/displaylog
# 

qnx 上 screen display最简实例 本文主要介绍如何使用screen 相关接口来进行显示,并提供一个最基本的显示代码实例qnx7.1如下图所示,是 qnx 官方文档对Screen的介绍,其实它就是一个窗口系统(处理显示,输入设备,事件等)单纯的建立一个显示应用的主要的流程如下图所示(针对本文,第7条可以不用关心)qnx 上所有的显示应用都需要通过screen 来和底层对接;screen 是一个窗口系统;screen 对于软件渲染和硬件渲染分别有各自的接口; 阅读详情

相关推荐

qnx 上screen + egl + opengles 最简实例

本文主要介绍如何在QNX 系统上使用egl和opengles 控制GPU渲染一个三角形并显示到屏幕上,是一个最基础的screen + egl + opengles 使用实例qnx7.1egl1.4screen 是 qnx 上的窗口系统(和linux 上的 weston 类似),所有显示相关的应用都是通过它来对接底层的;通过调用screen 相关的接口生成 egl 所需要的窗口参数,opengles 负责具体的渲染;

lh0616的博客 2646

QNX下PCI设备实时驱动的设计

随着实时操作系统在工业领域的深入应用,硬件设备的实时驱动程序已逐渐成为了开发人员关注的焦点。掌握实时驱动的设计方法,能够从一定程度上解决由于设备实时驱动问题给实时应用在产品选型和功能实现等方面带来的不便。介绍了QNX下PCI总线设备的实时驱动的开发流程,并以某PCI设备为例,给出了实时驱动设计中包括定位设备、获取总线信息、地址映射、初始化配置以及伺服中断等功能的具体实现,最后将该驱动应用到某QNX目标机系统中,经过试验验证取得了很好的应用效果。

QNX Screen架构解密:从像素流到触摸响应的系统级观察

本文深入解析QNX Screen架构,从Client/Server模型到GPU加速机制,详细探讨了其在嵌入式系统中的图形显示与触摸响应优化。通过多屏协同、输入事件处理及Wayland集成等关键技术,为汽车仪表盘和工业控制面板提供高效解决方案,提升系统性能与用户体验。

weixin_29266007的博客 374

QNX-Screen笔记

或者,调用img_decode_frame()(或img_load_file()等)的代码可以在调用img_decode_frame()、img_load_file()等之前进行设置,或者您可以依赖库的默认行为,即从系统RAM为图像和/或调色板分配内存(只有在尚未设置IMG_DIRECT、IMG_INDIRECT和IMG_PALETTE标志时,库才会执行此操作)。此行为意味着,对于每个信号量,在处理完信号量后,必须将对sem_open()的调用与对sem_close()的调用相匹配。

weixin_42463517的博客 1980

QNX微内核架构与车载开发实战:从8155到Screen调试

从智能座舱到自动驾驶域控,实时操作系统(RTOS)已成为汽车电子基础软件的核心。QNX作为高可靠微内核的代表,与Linux宏内核在架构设计上有着本质差异。理解其基于消息传递的进程间通信(IPC)机制、优先级继承与抢占式调度,是掌握系统稳定性和实时性的关键。在高通8155平台上,QNX常与Android协同工作,承担仪表盘与安全关键任务,而Screen图形子系统则负责窗口管理、缓冲区分配与GPU渲染配合。在实际开发中,EDL模式下的镜像烧写、sloginfo日志分析、pidin进程查看是绕不开的调试手段。无论

weixin_29698641的博客 260

从零构建QNX Screen图形应用:实战开发指南与避坑手册

本文详细介绍了从零开始构建QNX Screen图形应用的实战开发指南,涵盖核心架构解析、环境搭建、窗口创建、渲染优化等关键步骤。特别针对汽车仪表盘UI开发场景,提供了多窗口管理、缓冲区优化及性能调优的实用技巧,帮助开发者高效利用QNX Screen实现嵌入式图形应用开发。

weixin_29297127的博客 1013

QNX-Screen官方文档理解(Application Development)

官方文档的理解

weixin_40822211的博客 1414

高通HQX双系统黑屏别慌!手把手教你用adb和screencmd抓取关键log(附QNX截图命令)

本文详细解析了高通HQX双系统黑屏问题的排查方法,涵盖从adb到screencmd的全链路分析。针对QNX+Android Hypervisor架构,提供了Android侧和QNX侧的深度调试技巧,包括关键日志抓取、图层分析和显示信号流追踪,帮助工程师快速定位和解决复杂显示问题。

weixin_42519733的博客 208

QNX Screen使用说明书

QNX_SCREEN 实践性强,逻辑复杂,很多API非要体验过一次才能理解,导致包括我在内的初学者感觉晦涩难懂,不明觉厉,因此将自己的理解写下来、整理下来,与君共勉。

weixin_44862952的博客 3695

基于 NXP iMX8QM 与 QNX 的嵌入式图形系统开发实战

本文详细介绍了基于NXP iMX8QM处理器与QNX操作系统的嵌入式图形系统开发实践。重点解析了QNX Screen图形子系统的架构与多屏显示配置,通过实战案例展示了在工业HMI和车载信息娱乐系统(IVI)中如何实现高性能图形渲染与GPU加速,为开发者提供了一套稳定可靠的嵌入式图形解决方案。

f9g0h的博客 622

QNX Screen图形框架实战指南:从零构建嵌入式UI应用

本文详细介绍了QNX Screen图形框架在嵌入式UI开发中的实战应用,涵盖从环境搭建到窗口管理、缓冲区操作及性能优化的全流程。通过具体代码示例和实战经验,帮助开发者高效构建跨硬件平台的嵌入式图形应用,特别适合汽车仪表盘等工业HMI场景开发。

weixin_29271053的博客 779

1.1 【应用开发】应用开发简介

Screen图形子系统基于客户端/服务器模型,其中应用程序是请求图形服务的客户端(Screen)。它包括一个合成窗口系统作为这些服务之一,这意味着所有应用程序渲染都是在离屏缓冲区上执行的,然后可以在稍后用于更新显示。

从0到1,突破自己 491

SA8155上QNX Hypervisor实战:智能座舱多系统隔离方案全解析

在智能座舱向域控集中式架构演进的过程中,如何在单颗SoC上同时运行仪表与中控系统并保证互不干扰,是工程师普遍关注的问题。虚拟化技术通过Hypervisor实现多系统共存与资源隔离,其中Type-1型裸机虚拟化凭借低开销和高确定性,成为车规级功能安全场景的主流选择。以高通SA8155平台为例,QNX Hypervisor方案可有效实现QNX仪表域与Android娱乐域的逻辑隔离和物理资源隔离,涵盖CPU、内存、中断、GPU显示等关键资源的静态分配。从方案选型、资源划分、刷机调试到故障排查,完整链路展示了工程落

weixin_34009794的博客 326

QNX实时操作系统详解及VirtualBox虚拟机安装指南

在嵌入式系统与工业自动化领域,实时操作系统的选型往往决定整个产品的可靠性与安全性。与常见的Linux宏内核不同,微内核架构通过独立进程和消息传递机制实现故障隔离,既能保证单个模块崩溃不影响全局,又能满足功能安全认证的严格要求。QNX正是这样一套拥有四十余年历史、广泛应用于汽车电子、医疗设备和轨道交通的商用实时操作系统,其确定性调度和高可靠性使其成为关键控制任务的首选。理解QNX的微内核设计原理,有助于技术人员把握实时系统与传统操作系统的本质差异。对于个人开发者而言,无需昂贵硬件即可借助VirtualBox虚

weixin_33507732的博客 138

QNX实时操作系统入门:VirtualBox虚拟机安装与Screen开发

实时操作系统(RTOS)的核心目标不是功能多,而是响应时间可预测。微内核架构把调度、IPC、中断和内存管理等基础能力留在内核,文件系统、网络栈、驱动与图形系统则以用户态进程运行,从而获得故障隔离和可恢复性。QNX Neutrino 正是这一路线的代表,凭借微秒级中断响应和组件独立重启能力,广泛用于汽车座舱、ADAS、工业控制与医疗设备。要在低成本的 PC 环境中验证启动流程、驱动模型、网络配置和 QNX Screen 图形框架,VirtualBox 虚拟机提供了可复现的嵌入式目标板模拟方式;围绕 QNX 6

weixin_30846347的博客 195

告别晦涩难懂!手把手教你用QNX Screen API在8295座舱上显示第一个窗口

本文详细介绍了如何使用QNX Screen API在高通8295智能座舱上创建和显示第一个窗口。通过分步指南和实战代码示例,帮助开发者快速掌握QNX Screen图形架构、环境搭建、窗口创建及多屏协同技术,提升车载人机交互开发效率。

weixin_30855099的博客 317

QNX Screen实战:从零开始构建汽车仪表盘UI(附完整代码)

本文是一篇QNX Screen实战指南,详细讲解了如何从零开始构建汽车仪表盘UI。文章深入剖析了QNX Screen API的核心架构,包括上下文、窗口和缓冲区的层级关系,并提供了创建多窗口、设置Z-order与透明度、加载图像、实现指针动画以及性能优化的完整代码方案,帮助开发者快速掌握车载图形界面开发。

weixin_29300241的博客 207

QNX Neutrino入门:VirtualBox安装与镜像制作实战

实时操作系统(RTOS)强调确定性响应与故障隔离,而微内核架构把进程调度、消息传递和中断管理保留在内核,驱动、文件系统、网络协议栈则以独立进程运行。QNX Neutrino 正是这一路线的代表,借助用户态驱动与微秒级可预期延迟,在车载中控、工业网关、医疗设备等安全关键场景支撑高可靠运行。要低门槛上手,可用 VirtualBox 搭建实验环境:先获取 QNX SDP,加载交叉编译环境,再通过 mkqnximage 自制可启动磁盘镜像,并针对 IDE、Intel PRO/1000、VBoxVGA 等硬件参数做兼

weixin_33507732的博客 287
上一篇: 推荐一个关于性能优化的宝藏博客
下一篇: QNX 7.0 SCREEN开发者手册
norlan_jame
博客等级 码龄16年 4568粉丝 63原创
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付:10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值