Screen driving method, device and storage medium based on industrial equipment

By obtaining screen interface type information, allocating video memory, establishing memory maps, generating frame data and sending display instructions, and using the kernel DMA controller to control screen hardware updates, the problems of low efficiency and high latency in traditional screen driving methods are solved, and efficient and accurate screen refresh is achieved.

CN120255836BActive Publication Date: 2025-08-22KINGWAY FOSHAN ELECTRONICS TECH CO LTD
View PDF 3 Cites 0 Cited by

Patent Information

Application Number
CN202510732582.0
Authority / Receiving Office
CN · China
Patent Type
Patents(China)
Current Assignee / Owner
Filing Date
2025-06-04
Publication Date
2025-08-22
Estimated Expiration
2045-06-04

AI Technical Summary

Technical Problem

Traditional industrial equipment screen driving methods lead to low data transmission efficiency, waste of resources and performance losses, and it is difficult to accurately identify dynamic changes in screen content.

Method used

By obtaining screen interface type information, configuring display parameters, allocating video memory and establishing memory mapping, generating frame data and sending display instructions, using the kernel DMA controller to control screen hardware updates, combining intelligent dirty rectangle detection and adaptive frame rate control, the screen refresh process is optimized.

Benefits of technology

It significantly improves the data transmission efficiency and performance of screen display, ensures response speed, reduces resource waste and delay, and achieves accurate screen updates.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN120255836B_ABST
    Figure CN120255836B_ABST
Patent Text Reader

Abstract

The present invention discloses a screen driving method, device, and storage medium based on industrial equipment, belonging to the field of data processing technology. The method comprises the following steps: S1: obtaining screen interface type information, and the kernel layer configuring display parameters according to the screen interface type information, wherein the display parameters include resolution; S2: allocating video memory and establishing memory mapping through the application layer; S3: the application layer generating frame data according to the resolution and writing it to the video memory through memory mapping; S4: determining the screen update area; S5: the application layer sending display instructions to the video memory through memory mapping; S6: reading the frame data and display instructions in the video memory through the kernel layer, and controlling the screen hardware to update the screen update area according to the display parameters, frame data, and display instructions. The screen driving method based on industrial equipment solves the problem of low data transmission efficiency of current screen drivers, which leads to high screen display delay.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] The present invention relates to the field of data processing technology, and in particular to a screen driving method, device and storage medium based on industrial equipment. Background Art

[0002] Intelligent display control systems for industrial equipment face a series of complex technical challenges in achieving efficient screen updates and optimizing display performance. Traditional full-screen refresh methods result in a large amount of unnecessary data transmission and processing, resulting in resource waste and performance loss. Updating only the changed areas requires precise identification of dynamic changes in screen content, which requires complex image analysis algorithms. Furthermore, from a hardware and software resource coordination perspective, each step, such as video memory allocation and memory mapping, can become a performance bottleneck. Consequently, current screen driver data transmission efficiency is low, leading to high display latency. Summary of the Invention

[0003] In order to overcome the defects of the prior art, the present invention provides a screen driving method, device and storage medium based on industrial equipment to solve the above problems.

[0004] The technical solution adopted by the present invention to solve the technical problem is: a screen driving method based on industrial equipment, comprising the following steps:

[0005] S1: Obtain screen interface type information, and the kernel layer configures display parameters according to the screen interface type information, where the display parameters include resolution;

[0006] S2: allocates video memory and establishes memory mapping through the application layer;

[0007] S3: The application layer generates frame data based on the resolution and writes it to the video memory through memory mapping;

[0008] S4: Determine the screen update area;

[0009] S5: The application layer sends display instructions to the video memory through memory mapping;

[0010] S6: Read the frame data and display instructions in the video memory through the kernel layer, and control the screen hardware to update the screen update area according to the display parameters, frame data and display instructions.

[0011] Preferably, in step S1, screen interface type information is obtained through the application layer; the application layer sends the screen interface type information to the kernel layer, and the DRM interface and KMS interface of the kernel layer configure display parameters according to the screen interface type information.

[0012] It is worth noting that in step S2, the video memory is allocated at the application layer through the GEM and TTM mechanisms, and a dual-channel memory mapping is established; the dual-channel memory mapping includes a primary channel and an auxiliary channel, display parameters and frame data are transmitted through the primary channel, and display instructions are transmitted through the auxiliary channel;

[0013] The driver applies for video memory resources through the DRM interface and KMS interface to allocate video memory size;

[0014] Both the primary channel and the secondary channel map the video memory to the user process address space through mmap; the area corresponding to the user process address space used by the primary channel is different from the area corresponding to the user process address space used by the secondary channel.

[0015] Specifically, in step S3, the application layer generates frame data through a graphics engine; and then updates the frame data in the video memory.

[0016] Optionally, in step S4, the screen change area is determined by comparing pixel differences between frame data of two frames, using an intelligent dirty rectangle detection algorithm.

[0017] It is worth noting that, in the step S5, corresponding update data is generated according to the screen change area; the generation process of the update data is to extract pixel information within the dirty rectangular area;

[0018] The display driver converts the update data into display instructions.

[0019] Specifically, the display parameters also include an initial refresh rate; in the step S6, the frame data and display instructions in the video memory are read through the DMA controller of the kernel layer;

[0020] The adaptive frame rate control module dynamically adjusts the VSync signal to generate a target refresh rate so that the target refresh rate does not exceed the initial refresh rate in the display parameters;

[0021] According to the target refresh rate, frame data and display instructions, the screen hardware is controlled to update the screen update area.

[0022] Preferably, after step S6, step S7 is further included, and step S7 includes:

[0023] The performance monitoring module obtains the frame rate data and delay data during the screen display process as the current display performance status;

[0024] If the frame rate data is lower than a first preset threshold or the delay data is higher than a second preset threshold, adjusting the rendering strategy by reducing the resolution and updating the resolution in the display parameters;

[0025] Using the adjusted rendering strategy, step S3 is executed to update the frame data generated by the graphics engine.

[0026] A computer device includes a memory and a processor. The memory stores a computer program. When the processor executes the computer program, the screen driving method based on industrial equipment is implemented.

[0027] A computer-readable storage medium stores a computer program, which, when executed by a processor, implements a screen driving method based on industrial equipment.

[0028] The beneficial effects of the present invention are as follows: in the screen driving method based on industrial equipment, efficient generation and writing of frame data are achieved by allocating video memory and establishing memory mapping. The present invention precisely controls screen software updates by determining the screen change area and converting the update data into display instructions through the display driver. At the same time, the present invention utilizes the kernel DMA controller to directly read video memory data and control the screen hardware to update the screen update area based on display parameters, frame data, and display instructions, thereby achieving precise control of screen refresh display. This screen driving method significantly improves the display data transmission efficiency and performance, ensuring the responsiveness of the screen display. BRIEF DESCRIPTION OF THE DRAWINGS

[0029] Figure 1 is a flow chart of a screen driving method based on industrial equipment in one embodiment of the present invention;

[0030] Figure 2 FIG. 1 is a flow chart of step S7 in one embodiment of the present invention. DETAILED DESCRIPTION

[0031] The following is a further description of specific embodiments of the present invention in conjunction with the accompanying drawings. It should be noted that the description of these embodiments is intended to facilitate understanding of the present invention and does not constitute a limitation of the present invention. In addition, the technical features involved in the various embodiments of the present invention described below may be combined with each other as long as they do not conflict with each other.

[0032] like Figure 1 and 2 As shown, a screen driving method based on industrial equipment includes the following steps:

[0033] S1: Obtain screen interface type information, and the kernel layer configures display parameters according to the screen interface type information, where the display parameters include initial refresh rate and resolution;

[0034] S2: allocates video memory and establishes memory mapping through the application layer;

[0035] S3: The application layer generates frame data based on the resolution and writes it to the video memory through memory mapping; it implements zero-copy rendering at the kernel layer;

[0036] S4: Determine the screen update area;

[0037] S5: The application layer sends display instructions to the video memory through memory mapping;

[0038] S6: Read the frame data and display instructions in the video memory through the kernel layer, and control the screen hardware to update the screen update area according to the display parameters, frame data and display instructions.

[0039] In the industrial equipment-based screen driving method, efficient frame data generation and writing are achieved by allocating video memory and establishing a memory mapping. This method precisely controls screen software updates by determining the screen change area and converting the update data into display instructions via the display driver. Furthermore, the present invention utilizes a kernel DMA controller to directly read video memory data and control the screen hardware to update the screen update area based on display parameters, frame data, and display instructions, achieving precise control of screen refresh display. This screen driving method significantly improves display data transmission efficiency and performance, ensuring the responsiveness of the screen display.

[0040] In this solution, the core driver logic resides in the application layer, while the kernel layer retains only minimally necessary modules (such as the DRM interface and KMS infrastructure). During OTA updates of the screen driver, only application-layer components are replaced, reducing the risk of device bricking. A rollback mechanism is also included, allowing for a quick rollback to the previous version if an OTA update fails.

[0041] It is worth noting that in step S1, the screen interface type information is obtained through the application layer; the application layer sends the screen interface type information to the kernel layer, and the DRM interface and KMS interface of the kernel layer configure display parameters according to the screen interface type information.

[0042] When obtaining screen interface type information at the application layer, the first step is to identify the screen interface type. Common options include TTL, LVDS, and MIPI. The TTL interface is a parallel interface, typically used for low-resolution screens. It has a low data transmission rate but is simple to implement. The LVDS interface is a differential signal interface, suitable for high-resolution screens, featuring strong anti-interference capabilities and long transmission distances. The MIPI interface is a serial interface widely used in mobile devices, offering the advantages of high bandwidth and low power consumption. The application layer obtains the interface type information of the current screen by calling a system API or reading a device configuration file. For example, in an embedded system, the application layer can obtain the screen interface type by reading the screen configuration node in the device tree. The application layer sends the obtained screen interface type information to the kernel layer, typically through a system call or kernel module interface.

[0043] The kernel layer's DRM and KMS interfaces are responsible for managing the configuration and status of display devices. DRM (Direct Rendering Manager) is a subsystem in the Linux kernel used to manage graphics hardware, while KMS (Kernel Mode Setting) is responsible for setting the display mode, including resolution, refresh rate, and other settings. After receiving information about the screen interface type, the kernel layer selects an appropriate initial refresh rate based on the interface type. For example, for a TTL interface, the initial refresh rate might be set to 60Hz due to its low transmission rate; for a MIPI interface, the initial refresh rate might be set to 120Hz due to its high bandwidth. When configuring the initial refresh rate based on the screen interface type information, the kernel layer's DRM and KMS interfaces take into account hardware performance and display requirements.

[0044] The refresh rate refers to the number of times the screen refreshes per second, directly affecting the display quality and user experience. A higher refresh rate provides a smoother display, but also increases the hardware burden. Therefore, the kernel layer needs to select an appropriate initial refresh rate based on the screen interface type and hardware capabilities. For example, in industrial control equipment, the TTL interface may only support a lower refresh rate. The kernel layer may set the initial refresh rate to 50Hz or 60Hz to ensure stability and compatibility.

[0045] The application layer obtains screen interface type information and sends it to the kernel layer. The kernel layer's DRM and KMS interfaces use this information to configure the initial refresh rate. This process ensures correct initialization and optimized configuration of the display device. This automatically selects the appropriate refresh rate based on the screen interface type and hardware capabilities, avoiding display issues or performance waste caused by improper configuration. For example, automatically selecting a high refresh rate on high-performance devices can improve the user experience, while selecting a lower refresh rate on low-power devices can extend battery life. This automated configuration process reduces manual tuning and improves system stability and compatibility.

[0046] Preferably, in step S2, video memory is allocated at the application layer through GEM and TTM mechanisms, and a dual-channel memory mapping is established; the dual-channel memory mapping includes a primary channel and an auxiliary channel, display parameters and frame data are transmitted through the primary channel, and display instructions are transmitted through the auxiliary channel;

[0047] When panel_init() is called at the application layer, the driver applies for video memory resources through the DRM interface and KMS interface to allocate video memory size;

[0048] The code for user space to apply for video memory resources is as follows:

[0049] struct drm_mode_create_dumb create = {0};

[0050] create.width = screenwidth;

[0051] create.height = screen height x3; / / Two pages for double buffering, one page for auxiliary channel

[0052] create.bpp = bits per pixel; / / such as 32

[0053] ioctl(fd, DRM_IOCTL_MODE_CREATE_DUMB,&create);

[0054] In the DRM (Direct Rendering Manager) framework, the create parameter is a struct drm_mode_create_dumb type structure, which is used to pass parameters to the kernel. The structure includes: width, height, and bpp;

[0055] When calling ioctl(fd, DRM_IOCTL_MODE_CREATE_DUMB,&create), the kernel will allocate video memory according to these parameters;

[0056] For example, a 1080p resolution screen is allocated a 1920x1080x4 byte contiguous video memory block and the video memory handle is returned to user space via ioctl. At this point, the video memory has not yet been mapped to user space; physical allocation is only done in the kernel. The GEM and TTM mechanisms for video memory allocation: GEM (Graphics Execution Manager) and TTM (Translation Table Maps) are the core mechanisms for managing video memory in the Linux kernel. GEM is responsible for the creation and lifecycle management of video memory objects, while TTM handles address translation and migration between video memory and system memory. The panel_init() function communicates with the kernel via the system call ioctl (input / output control). panel_init() writes the screen type and gpio parameters to the auxiliary channel and calls ioctl to notify the kernel to initialize.

[0057] Both the primary channel and the secondary channel use mmap to map the video memory to the user process address space. The area of ​​the user process address space used by the primary channel is different from the area of ​​the user process address space used by the secondary channel. mmap (Memory Map) is a memory mapping mechanism that allows part of a file or device to be mapped to the virtual memory space of a process. By using mmap, the process can directly access the contents of the mapped object.

[0058] For the primary channel, for example, an allocated 8MB of video memory is mapped to the process virtual address starting at 0x7f000000. During mapping, the page table attributes must be configured to WC (Write-Combining) mode to prevent CPU cache interference with frame data writes. Data is written directly to the mapped area using memcpy or SIMD instructions. For example, 1080p RGB data at 60 frames per second is written at a bandwidth of 128MB / s without requiring kernel mode switching. This zero-copy design reduces latency, with actual measurements showing that frame submission time has been reduced from 3ms with traditional solutions to 0.5ms.

[0059] The auxiliary channel uses a separate memory-mapped area, typically a 4KB ring buffer, to store display commands generated by panel_setcmd(). For example, the command "0x01 0x02" sets the brightness to 50%. An ioctl interrupt triggers a driver read request. The auxiliary channel is physically isolated from the primary channel but shares the same video memory address space. After the driver parses the command, it sends it to the display controller via the MIPI DSI bus.

[0060] The dual-channel separation design prevents frame data and instructions from competing for bandwidth. Actual measurements show that the instruction response delay is reduced from 10ms to 2ms. Dual-channel synchronization and consistency are guaranteed. When the main channel writes frame data, it must be synchronized with the auxiliary channel instructions. For example, a memory barrier instruction is used to ensure that the "brightness adjustment" instruction takes effect in the next frame. The kernel maintains the fence mechanism of the video memory object. When the user layer calls commit(), the driver checks the completion status of the two channels. If there are unprocessed instructions on the auxiliary channel, the VSYNC signal is delayed. By setting up a dual-channel mechanism, 99.9% of tearing phenomena can be avoided, while the tearing probability of the traditional single-channel solution is 5%.

[0061] Optionally, in step S3, the application layer generates frame data through the graphics engine, and then updates the frame data in the video memory. Specifically, when the application layer generates frame data through the graphics engine, it first needs to extract geometric information, texture data, lighting parameters, etc. from the scene. These data are usually provided by the logic module of the application layer, such as the scene manager or the layout calculation module in the UI framework. The graphics engine organizes this data into a format suitable for rendering, such as a vertex buffer and an index buffer. The core of this process is to convert the logical data into rendering instructions that can be processed by the GPU, preparing for the subsequent rendering stage.

[0062] The graphics engine parses application-level drawing instructions (such as OpenGL / Vulkan calls) to convert vector graphics, texture maps, and other elements into pixel matrices. For example, when rendering a 1080p UI, the engine first calculates the geometric coordinates of each control, then uses rasterization to convert the triangle mesh into a pixel array with a 24-bit color depth, ultimately outputting a frame of data sized 1920 × 1080 × 3 bytes. This process leverages the GPU's parallel computing capabilities, distributing tasks such as vertex shading and fragment shading to stream processors to improve generation efficiency. The zero-copy pipeline implementation mechanism: The application layer maps video memory to the process address space using mmap, and the graphics engine writes frame data directly to the mapped area. For example, in Android SurfaceFlinger, rendering results are shared with the display driver via the ION memory pool, avoiding data copying from user mode to kernel mode.

[0063] Specifically, in step S4, the intelligent dirty rectangle detection algorithm compares the pixel differences between the frame data of the previous and next frames to determine the screen change area. The intelligent dirty rectangle detection algorithm determines the screen change area by comparing the pixel differences between the previous and next frames. For example, if it is detected that only the 100x200 pixel area in the upper left corner of a page layout has changed (such as the appearance of a pop-up window), the algorithm will mark this rectangular area as a dirty rectangle area, i.e., the screen change area. The core of this is to use differential buffering technology to compare the blocks whose RGB value differences exceed the threshold pixel by pixel, and merge adjacent changed pixels to form a minimum bounding rectangle. This differential buffering technology can reduce the amount of invalid data transmission by more than 90%.

[0064] It is worth noting that in step S5, corresponding update data is generated based on the screen change area; the update data generation process is to extract the pixel information within the dirty rectangular area, convert it into a format suitable for transmission, and package it into an update data packet. For example, when displaying a moving icon, the system will extract the pixel data of the area where the icon is located and package it into an update data packet. In addition, the system will also optimize the update data based on the characteristics of the display hardware. For example, if the display hardware supports a specific color format, the system will convert the update data into that format to reduce the overhead of subsequent processing.

[0065] The display driver calls the panel_setcmd() function to convert the update data into display commands. The panel_setcmd() function is a key interface within the display driver, responsible for converting update data into display commands that the hardware can understand. For example, when updating a dirty rectangular area (a changing screen area), the panel_setcmd function generates a series of display commands, including setting the display area's starting coordinates, transmitting the update data, and triggering a screen refresh. These display commands are sent to the display hardware, ultimately completing the screen content update. To improve efficiency, the panel_setcmd function uses batch processing, consolidating multiple display commands into a single command packet to reduce communication overhead. Furthermore, the panel_setcmd function optimizes the command generation process based on the characteristics of the display hardware. For example, if the display hardware supports partial refresh, the panel_setcmd function generates the corresponding commands to refresh only the dirty rectangular area (changing screen area) rather than the entire screen, further reducing power consumption and latency. The panel_setcmd() function communicates with the kernel through the system call ioctl (input / outputcontrol); panel_setcmd() writes the instructions to be executed, such as setting the backlight and mipi screen instructions (such as sleep and wake-up) into the auxiliary channel, and calls ioctl to notify the kernel to execute the corresponding instructions.

[0066] Preferably, in step S6, the frame data and display instructions in the video memory are read through the DMA controller of the kernel layer; the core of this step is the direct memory access capability of the DMA controller. The DMA controller can read data directly from the video memory without occupying CPU resources, thereby improving system efficiency. For example, in the display update phase, the DMA controller transfers the frame data in the video memory to the display hardware in a high-bandwidth and low-latency manner to ensure the real-time nature of the screen update. The DMA controller can complete data transmission at a speed of hundreds of megabytes per second to avoid screen freezes or tearing.

[0067] The adaptive frame rate control module dynamically adjusts the VSync signal to generate a target refresh rate, ensuring that the target refresh rate does not exceed the initial refresh rate specified in the display parameters. The adaptive frame rate control module uses the display parameters to dynamically adjust the VSync signal to generate the target refresh rate. The VSync signal is the synchronization signal for screen refresh, and its frequency determines the screen refresh rate. The adaptive frame rate control module dynamically adjusts the VSync signal frequency by monitoring system performance (such as frame rate, latency, and power consumption) in real time. For example, in low-load scenarios, the module may reduce the refresh rate from 60Hz to 30Hz to reduce power consumption; in high-load scenarios, the module may increase the refresh rate to 90Hz or 120Hz to provide a smoother visual experience. This dynamic adjustment not only optimizes system performance but also extends device battery life. Furthermore, the initial refresh rate is used as a reference, limiting the target refresh rate to a range less than or equal to the initial refresh rate to prevent the target refresh rate from exceeding the initial refresh rate and becoming incompatible with the current screen interface.

[0068] Based on the target refresh rate, frame data, and display instructions, the display hardware is controlled to update the screen update area. Based on the target refresh rate, frame data, and display instructions, the display hardware is controlled to update the screen update area. The core of this step lies in the precise control of the display hardware. Based on the received frame data and display instructions, the display hardware only updates the areas that need to be refreshed, rather than the entire screen. For example, supported by an intelligent dirty rectangle detection algorithm, the system can identify changed areas in the image and transmit the data for these areas to the display hardware for updating. This local refresh mechanism significantly reduces data transmission volume and power consumption, making it particularly suitable for scenarios with a large amount of static content. The dynamic adjustment strategy of the adaptive frame rate control module also considers the balance between system power consumption and performance. For example, in mobile devices, the module can intelligently adjust the refresh rate based on the remaining battery power and current application requirements. When the battery power is low, the module will reduce the refresh rate to the lowest acceptable level to extend device usage. This strategy not only improves device energy efficiency but also enhances the user experience. Controlling the display hardware updates also involves the precise execution of display instructions. For example, through the panel_setcmd() function, the display driver can generate specific display instructions, such as brightness adjustment and color mode switching. These display commands work together with frame data and refresh rate to ensure the accuracy and consistency of the screen display. For example, in night mode, the display driver can send commands to reduce the screen brightness and adjust the color temperature to reduce irritation to the user's eyes while maintaining the clarity and smoothness of the picture.

[0069] Optionally, after step S6, step S7 is further included, and step S7 includes:

[0070] The performance monitoring module collects frame rate and latency data during screen display as the current display performance status. It evaluates current display performance by collecting key metrics during screen rendering, such as frame rate and latency, in real time. Frame rate refers to the number of frames displayed per second, typically measured in FPS. Latency refers to the time difference between the graphics engine generating frame data and its actual display on the screen. For example, when running industrial software, the performance monitoring module can detect a frame rate of 30 FPS and a latency of 50 milliseconds in real time. This data reflects the system's rendering capabilities and responsiveness, providing a foundation for subsequent performance optimization.

[0071] If the frame rate data is lower than a first preset threshold or the latency data is higher than a second preset threshold, the rendering strategy is adjusted by reducing the resolution and the resolution in the display parameters is updated. By comparing the collected frame rate data and latency data with the first and second preset thresholds, respectively, it can be determined whether the current display performance meets the requirements. For example, if the first preset threshold is 60 FPS and the monitored frame rate is 30 FPS, it indicates that the current display performance status is lower than the preset threshold and a performance bottleneck exists. For another example, if the second preset threshold is 30 milliseconds and the monitored latency is 50 milliseconds, it indicates that the current display performance status is lower than the preset threshold and a performance bottleneck exists. When it is determined that the current display performance status does not meet the requirements, the system automatically adjusts the rendering strategy to improve performance. For example, performance can be optimized by reducing the rendering resolution, reducing the rendering complexity, or enabling dynamic resolution scaling. For example, when the frame rate is lower than 60 FPS, the system can reduce the rendering resolution from 1080P to 720P, thereby reducing the GPU load and increasing the frame rate. This dynamic adjustment strategy can significantly improve display performance without affecting the user experience.

[0072] Using the adjusted rendering strategy, step S3 is executed to update the frame data generated by the graphics engine. That is, after adjusting the rendering strategy, the graphics engine generates new frame data based on the updated resolution. For example, after lowering the rendering resolution, the graphics engine generates frame data at a lower resolution. This updating method can effectively reduce data transmission and processing overhead, thereby improving display performance.

[0073] A computer device includes a memory and a processor. The memory stores a computer program. When the processor executes the computer program, the screen driving method based on industrial equipment is implemented.

[0074] A computer-readable storage medium stores a computer program, which, when executed by a processor, implements a screen driving method based on industrial equipment.

[0075] The embodiments of the present invention are described in detail above with reference to the accompanying drawings, but the present invention is not limited to the described embodiments. It is apparent to those skilled in the art that various changes, modifications, substitutions, and variations to these embodiments may be made without departing from the principles and spirit of the present invention, and these changes and modifications still fall within the scope of protection of the present invention.

Claims

1. A screen driving method based on industrial equipment, characterized in that: The following steps are involved: S1: Obtain screen interface type information. The kernel layer configures display parameters based on the screen interface type information, including resolution and initial refresh rate. The kernel layer's DRM interface and KMS interface configure the initial refresh rate based on this information, selecting the appropriate refresh rate based on different screen interface types and hardware capabilities. S2: allocates video memory and establishes memory mapping through the application layer; Allocate video memory at the application layer through the GEM and TTM mechanisms and establish a dual-channel memory mapping; the dual-channel memory mapping includes a primary channel and an auxiliary channel, display parameters and frame data are transmitted through the primary channel, and display instructions are transmitted through the auxiliary channel; The driver applies for video memory resources through the DRM interface and KMS interface to allocate video memory size; Both the primary channel and the secondary channel map the video memory to the user process address space through mmap; the area corresponding to the user process address space used by the primary channel is different from the area corresponding to the user process address space used by the secondary channel; S3: The application layer generates frame data based on the resolution and writes it to the video memory through memory mapping; S4: Determine the screen update area; S5: The application layer sends display instructions to the video memory through memory mapping; S6: Read the frame data and display instructions in the video memory through the kernel layer, and control the screen hardware to update the screen update area according to the display parameters, frame data and display instructions; S7: Obtain the frame rate data and delay data during the screen display process through the performance monitoring module as the current display performance status; if the frame rate data is lower than the first preset threshold or the delay data is higher than the second preset threshold, adjust the rendering strategy by reducing the resolution and update the resolution in the display parameters; through the adjusted rendering strategy, execute step S3 to update the frame data generated by the graphics engine.

2. The screen driving method based on industrial equipment according to claim 1, characterized in that: In step S1, screen interface type information is obtained through the application layer; the application layer sends the screen interface type information to the kernel layer, and the DRM interface and KMS interface of the kernel layer configure display parameters according to the screen interface type information.

3. The screen driving method based on industrial equipment according to claim 1, characterized in that: In step S3, the application layer generates frame data through a graphics engine; and then updates the frame data in the video memory.

4. The screen driving method based on industrial equipment according to claim 1, characterized in that: In step S4, the screen change area is determined by comparing the pixel differences between the frame data of the previous and next frames using an intelligent dirty rectangle detection algorithm.

5. The screen driving method based on industrial equipment according to claim 4, characterized in that: In step S5, corresponding update data is generated according to the screen change area; the generation process of the update data is to extract pixel information within the dirty rectangular area; The display driver converts the update data into display instructions.

6. The screen driving method based on industrial equipment according to claim 1, characterized in that: In step S6, the frame data and display instructions in the video memory are read through the DMA controller of the kernel layer; The adaptive frame rate control module dynamically adjusts the VSync signal to generate a target refresh rate so that the target refresh rate does not exceed the initial refresh rate in the display parameters; According to the target refresh rate, frame data and display instructions, the screen hardware is controlled to update the screen update area.

7. A computer device comprising a memory and a processor, wherein the memory stores a computer program, wherein: When the processor executes the computer program, the screen driving method based on industrial equipment according to any one of claims 1 to 6 is implemented.

8. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the computer program is executed by a processor, a screen driving method based on industrial equipment according to any one of claims 1 to 6 is implemented.

Citation Information

Patent Citations

  • Android terminal-based system and method for automatically regulating resolutions according to different interfaces

    CN106126141A

  • Watermark updating method, device and system and storage medium

    CN114647467A

  • Rendering display method and device, equipment and storage medium

    CN117170883A