Introduction to QNX SCREEN
The QNX SCREEN framework is a software framework for graphics display and window management, developed by QNX, to provide high-performance, reliable graphics display and user interface functions for embedded systems.
The QNX SCREEN framework provides the following main functions:
-
Display management: The SCREEN framework allows applications to manage graphics display devices, including monitors, touch screens, graphics accelerators, and more. It provides a communication interface with hardware devices, enabling applications to obtain and control the properties, resolution, refresh rate, etc. of display devices.
-
Window management: The SCREEN framework supports window management, allowing applications to create, manage and control multiple windows. It provides functions such as window layout, focus management, window stacking order, window moving and resizing to achieve a flexible user interface.
-
Graphics acceleration: The SCREEN framework can provide hardware-accelerated graphics rendering and drawing functions through the integration of graphics accelerator drivers. This improves the performance and efficiency of graphics operations and supports complex graphics effects and animations.
-
Multi-screen support: The SCREEN framework can handle multiple display screens and provide configuration and management functions for multiple screens. It allows applications to create windows on multiple displays and provides the ability to transfer data and work together between displays.
-
Event handling: The SCREEN framework provides an event handling mechanism for handling user input, touch events, window events, etc. It allows applications to register event handlers to respond to various events and update the user interface.
-
Extensibility: The SCREEN framework supports plug-ins and extensions, allowing developers to add custom functions and drivers according to specific needs. This makes the framework adaptable to different hardware platforms and application scenarios.
QNX SCREEN Architecture
SCREEN source code
The source code of screen service is not open source, forget it!
Start of SCREEN
The screen service is generally started by the command: screen -c /lib64/graphics.conf in the QNX system . This action is usually started by the startupmanager. You can find the relevant source code in the source code file: 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,
},
};The screen service initialization depends on the openwfd display framework, so the startup sequence is required to be after the wfd service:
32795 wfd_server -U 70:70,33,21
32797 wfd_be 5
32798 screen -c /lib64/graphics.confIt should be noted that the initialization of the screen does not depend on the GPU, so it can be initialized before the GPU driver, but the normal use of the screen interface must be after the initial completion of the GPU driver (especially GPU-related operations).
SCREEN debug method
/dev/screen directory
After the screen service starts normally, the screen folder will be generated in the /dev/ directory:
# ls /dev/screen/
0 9711657 mtouch
1196133 buffers qvm
487478 gpus requests
495671 input ssplash
766018 life_cycle_man_demo
823370 lpms
#
0: This directory contains the main information of screen configuration, including display configuration information and framebuffer configuration information
# 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: The directory can get the buffer data content displayed on the current screen
$PID: The directory contains information related to the screen used by the process, such as: windows information, buffer information, 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
It is used to set and modify the properties of windows. The amazing thing is that it takes effect in real time, and the effect is the same as modifying the code:
screencmd setiv win-8 SCREEN_PROPERTY_SIZE 400,400
screencmd setiv win-8 SCREEN_PROPERTY_ROTATION 90
screencmd setiv win-4 SCREEN_PROPERTY_ZORDER 1000When using it, you need to know which windows you want to repair. You can find this information in the /dev/screen/$pid/ directory:
# 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 layer information
Execution: echo surfacedump=0xFF > /dev/displaylog
You can get the dumped layer files in the /tmp directory:
# ls /tmp/displog_surface_dump_*
/tmp/displog_surface_dump_8_[00:00:39.085]_1920x1080_argb8888.rgb
This method is actually the debug method of wfd. It can dump the image data displayed on each pipeline. The data output by dump is raw rgb data, which can be opened directly with tools such as yuv player. Of course, the function of displaylog is not limited to this:
# 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
#