A method and system for optimizing USB display device display output under Linux.

Abstract

This invention discloses a method and system for optimizing USB display device data delivery under Linux. The method includes: during the display driver initialization phase, constructing a queue linked list for storing the data delivery process and a work queue for running the data delivery execution process, and setting a process synchronization mechanism; during the data delivery phase, first checking if there are any unexecuted data delivery processes for the same data delivery content in the queue linked list; if so, merging the data delivery processes; otherwise, creating a new object for the data delivery process and adding it to the queue linked list; during the data delivery execution phase, a kernel thread calls the data delivery execution process, retrieves the data delivery process to be executed from the queue linked list, maps the data delivery content within it, calls the USB display device driver interface to complete the data submission, and releases related resources after the data delivery is completed. This invention can effectively improve the display performance and system operating efficiency of USB display devices under Linux.

Description

Technical Field

[0001] This invention relates to the field of display device output optimization technology, specifically to a method and system for optimizing output of USB display devices under a Linux system. Background Technology

[0002] In Linux systems, graphics servers operate on a single-threaded execution flow. When the operating system submits display data to the display device, it does so sequentially. When a USB display device is plugged into a USB 2.0 port, the display data transmission process may be affected by data transfer bandwidth, leading to congestion and stuttering. This congestion can then block the display data transmission processes of other devices, resulting in a degraded overall system display performance. Without intervention, this can cause stuttering not only on the USB display device but also on other display devices.

[0003] The serial transmission of USB display devices is particularly evident in cloud desktop system usage scenarios. Specifically, in cloud desktop system scenarios, USB devices on the cloud desktop client need to be "mapped" to the remote cloud desktop system (server) via redirection. This means that USB display devices such as handwriting screens and document cameras on the cloud desktop client's host machine will be managed by the cloud desktop system (server). In this case, the cloud desktop system (server) also needs to additionally transmit the display content to the USB display device on the client's host machine via network protocols. When the server's display content refresh rate is high, this generates a large amount of data, further increasing latency and resulting in extremely poor display smoothness.

[0004] To provide users with a high-quality experience when using USB display devices in cloud desktop systems, a new method for displaying USB display devices is urgently needed to reduce network bandwidth and optimize display performance. Summary of the Invention

[0005] The technical problem to be solved by the present invention is to provide a method and system for optimizing the display output of USB display devices under Linux, in order to effectively improve the display performance and system operating efficiency of USB display devices under Linux.

[0006] To solve the above-mentioned technical problems, the technical solution adopted by the present invention is as follows: A method for optimizing display output from a USB display device under a Linux system, including the following steps: S1, During the display driver initialization phase, a queue list damage_queue is constructed to store the display delivery process and a work queue damage_work is constructed to run the display delivery execution process, and a process synchronization mechanism is set. S2, In the display delivery stage, first check whether there is an unexecuted display delivery process for the same display content in the queue chain. If there is, merge the display delivery process; otherwise, create a new object for the display delivery process and add it to the queue chain. S3, during the display delivery execution phase, the kernel thread calls the display delivery execution process, retrieves the display delivery process to be executed from the queue list, maps the display content in it, calls the USB display device driver interface to complete the submission of display data, and releases the relevant resources after the display delivery is completed.

[0007] Furthermore, the information of the display delivery process is described by constructing a structure called damage_work_node, which includes the display content, the display update area, and one or more items in the queue list.

[0008] Further, step S1 includes: The queue list damage_queue is initialized using the linked list initialization macro INIT_LIST_HEAD() provided by the kernel. The spinlock damage_lock is initialized by the spin_lock_init() function to enter the unlocked state, so as to realize the synchronization of the display sending process and the display execution process. The kernel work queue task is initialized using INIT_WORK().

[0009] Further, in step S2, it is first checked whether there are any unexecuted display delivery processes for the same display content in the queue linked list. If so, the display delivery processes are merged, specifically including the following steps: S21, before executing the display sending process, call the spin_lock_irqsave() function to lock the queue list; S22, traverse each sending and displaying process node in the queue linked list and obtain the structure object corresponding to each node; S23, determine whether the content recorded in the structure object is the same as the content corresponding to the current display sending process. If they are the same, then use the udl_damage_merged() function to merge the display update area in the current display sending process with the display update area in the structure object that has not been executed in the display sending process. S24. After the merge is completed, the spin_unlock_irqrestore() function is called to release the synchronization lock and end the current display sending process.

[0010] Further, in step S2, creating a new object for the display delivery process and adding it to the queue list specifically includes the following steps: T21. When no mergeable display delivery process is detected, the kzalloc() function is called to create a new display delivery process object. T22, call the memcpy() function to copy the display update area and display content corresponding to the current display sending process to the newly created display sending process object; T23 calls drm_gem_fb_get_obj() to increment the reference count of the display buffer corresponding to the sent content in order to prevent the display buffer from being released; T24, call the list_add_tail() function to add the new display delivery process object to the tail of the queue linked list to form a queue of display delivery tasks to be executed; T25, call spin_unlock_irqrestore() to release the synchronization lock on the queue list.

[0011] Further, step S3 includes: S31, check if the queue list is empty, and end the current execution flow if the list is empty; S32, when the queue list is not empty, the spin_lock_irqsave() function is called to lock the queue list, and the list_first_entry() function is called to get the first delivery process object in the queue list; S33, the first display sending process object is deleted from the display sending process queue linked list, and the spin_unlock_irqrestore() function is called to release the synchronization lock; S34, determine whether the display content information and display update area information recorded in the first display delivery process object are valid; if both are valid, perform a memory mapping operation on the display content to obtain the corresponding memory address; otherwise, call the DRM log output function to print error information. S35 retrieves the memory address of the content to be displayed, reads the display data, and performs the display sending operation to complete the transfer of display data to the USB display device.

[0012] Further, step S35 includes: Call the drm_gem_fb_vmap() function to perform a memory mapping operation to obtain the memory address of the corresponding display data; Call the display sending function udl_handle_damage() in the USB display device driver to submit the display data of the corresponding display update area in the sent content to the USB display device; After submitting the display data, call the DRM framework function drm_gem_fb_vunmap() to remove the memory mapping relationship of the submitted content; Iterate through the video memory objects corresponding to the content to be displayed, and call the drm_gem_object_put() function to reduce the reference count of each video memory object; Call the drm_framebuffer_put() function to reduce the reference count of the displayed content object; Call the kfree() function to release the display update area information recorded in the display sending and receiving process structure object, and release the memory resources occupied by the display sending and receiving process structure.

[0013] A USB display device display optimization system under a Linux system includes a microprocessor and a memory interconnected, wherein the microprocessor is programmed or configured to execute the steps of a USB display device display optimization method under a Linux system.

[0014] A computer-readable storage medium storing a computer program for being programmed or configured by a microprocessor to perform steps of a method for optimizing USB display device output under a Linux system.

[0015] A computer program product includes a computer program / instructions that are programmed or configured to execute, via a processor, the steps of a method for optimizing the display delivery of a USB display device under a Linux system.

[0016] Compared with the prior art, the advantages of the present invention are as follows: This invention constructs a display delivery queue linked list and a work queue in the display driver, dividing the display delivery process into two stages: display delivery assignment and display delivery execution. This enables asynchronous scheduling and sequential processing of display delivery tasks, preventing the main display driver process from being blocked and improving system efficiency. In the display delivery assignment stage, by detecting and merging unexecuted display delivery requests (i.e., display requests) targeting the same display buffer, duplicate display delivery operations can be effectively reduced, lowering USB transmission bandwidth usage and improving data transmission efficiency. In the display delivery execution stage, a unified queue scheduling mechanism centrally processes display delivery tasks and promptly releases related resources after completion, ensuring the rational utilization of system resources and improving the stability and reliability of the display delivery process. This invention can effectively improve the display performance and system operating efficiency of USB display devices under Linux systems. Attached Figure Description

[0017] Figure 1 This is a flowchart illustrating the optimization method for USB display device output in a Linux system according to an embodiment of the present invention.

[0018] Figure 2 This is a comparison diagram showing the effects of the serial display processing flow and the display optimization method (parallel display processing flow) of the present invention. Detailed Implementation

[0019] To better understand the above technical solutions, the following will provide a detailed explanation of the technical solutions in conjunction with the accompanying drawings and specific implementation methods.

[0020] like Figure 1 As shown in this embodiment, the USB display device display optimization method under the Linux system includes the following steps: S1, During the display driver initialization phase, a queue list damage_queue is constructed to store the display delivery process and a work queue damage_work is constructed to run the display delivery execution process, and a process synchronization mechanism is set. S2, In the display delivery stage, first check whether there is an unexecuted display delivery process for the same display content in the queue chain. If there is, merge the display delivery process; otherwise, create a new object for the display delivery process and add it to the queue chain. S3, during the display delivery execution phase, the kernel thread calls the display delivery execution process, retrieves the display delivery process to be executed from the queue list, maps the display content in it, calls the USB display device driver interface to complete the submission of display data, and releases the relevant resources after the display delivery is completed.

[0021] In this embodiment, the information of the display delivery process is described by constructing a structure called damage_work_node, which includes the display content, the display update area, and one or more items in the queue list.

[0022] In a specific application embodiment, before executing step S1, a display delivery process structure, damage_work_node, is defined to describe the information of a single display delivery process. The specific code is as follows: struct damage_work_node { struct drm_framebuffer *fb; struct drm_rect *clip; struct list_head list; }; The struct drm_framebuffer *fb stores the buffer to be displayed (i.e., the content to be displayed), the struct drm_rect *clip stores the area to be updated (i.e., the display update area), and the struct list_head list describes a queue linked list used for the display work queue processing flow.

[0023] In this embodiment, step S1 includes: The queue list damage_queue is initialized using the linked list initialization macro INIT_LIST_HEAD() provided by the kernel. The spinlock damage_lock is initialized by the spin_lock_init() function to enter the unlocked state, so as to realize the synchronization of the display sending process and the display execution process. The kernel work queue task is initialized using INIT_WORK().

[0024] In a specific application embodiment, step S1 is implemented as follows: During display driver initialization, a `damage_queue` linked list is created to store and maintain each display delivery process, and a `damage_work` work queue is initialized to run the display delivery execution process. Simultaneously, a spinlock is created to synchronize the display delivery and execution processes. The specific code is as follows: INIT_LIST_HEAD(&udl->damage_queue); spin_lock_init(&udl->damage_lock); INIT_WORK(&udl->damage_work, udl_damage_work_func); The above code means that during the display driver initialization phase, a queue linked list for storing display requests (i.e., the display delivery process) is initialized, and the queue linked list is in an empty queue state; a spin lock for implementing concurrent synchronization between the display delivery process and the display execution process is initialized, and it is in an unlocked state; a work queue for executing display tasks is initialized, and the display execution function is registered in the work queue so that the display process can be executed asynchronously by the kernel thread during subsequent scheduling.

[0025] In this embodiment, step S2 first checks whether there are any unexecuted display delivery processes for the same display content in the queue linked list. If so, the display delivery processes are merged, specifically including the following steps: S21, before executing the display sending process, call the spin_lock_irqsave() function to lock the queue list; S22, traverse each sending and displaying process node in the queue linked list and obtain the structure object corresponding to each node; S23, determine whether the content recorded in the structure object is the same as the content corresponding to the current display sending process. If they are the same, then use the udl_damage_merged() function to merge the display update area in the current display sending process with the display update area in the structure object that has not been executed in the display sending process. S24. After the merge is completed, the spin_unlock_irqrestore() function is called to release the synchronization lock and end the current display sending process.

[0026] In a specific application embodiment, the display sending process can be divided into a display sending and distribution process and a display sending and execution process. The display sending and distribution process can be divided into the first half of the display sending and distribution process and the second half of the display sending and distribution process.

[0027] In the first half of the display submission process, the `damage_queue` linked list is traversed to check if there are any pending display submission processes within the same buffer. If so, the submission processes are merged to remove duplicate submissions within the same buffer, thus reducing bandwidth usage. If the merging is complete, the process returns directly without entering the second half of the display submission process. The specific code is as follows: spin_lock_irqsave(&udl->damage_lock, flags); / * Just merge the damage if the same framebuffer damage is alreadyqueued * / list_for_each_safe(entry, tmp,&udl->damage_queue) { struct damage_work_node *dirty_work; dirty_work = list_entry(entry, struct damage_work_node, list); if (dirty_work == NULL) continue? if (dirty_work->fb == fb) { / * Merged clips * / udl_damage_merged(clip, dirty_work->clip); spin_unlock_irqrestore(&udl->damage_lock, flags); return; } } Before performing related operations, the `spin_lock_irqsave` function is called to lock the work queue to achieve synchronization. Then, the `list_for_each_safe()` function is called to traverse the work queue. If there are items with the same `fb` (buffer) in the queue, the `udl_damage_merged()` function is called to merge them.

[0028] The above code means the following: In the display delivery process, the display queue linked list is first locked and the current interrupt state is saved to ensure the atomicity of the queue access process; then, each display delivery process node in the display queue linked list is traversed and the corresponding display delivery process object is obtained; during the traversal, it is determined whether the display buffer (i.e., the display content) recorded in each display delivery process object is the same as the display buffer corresponding to the current display request; when a display request for the same display buffer that has not yet been executed is detected, the display update area of ​​the current display request and the display update area of ​​the unexecuted display request are merged; after merging, the lock is released and the interrupt state is restored, and the current display delivery process ends, thereby avoiding the repeated creation of display tasks for the same display buffer.

[0029] In this embodiment, step S2, which involves creating a new object for the display delivery process and adding it to the queue list, specifically includes the following steps: T21. When no mergeable display delivery process is detected, the kzalloc() function is called to create a new display delivery process object. T22, call the memcpy() function to copy the display update area and display content corresponding to the current display sending process to the newly created display sending process object; T23 calls drm_gem_fb_get_obj() to increment the reference count of the display buffer corresponding to the sent content in order to prevent the display buffer from being released; T24, call the list_add_tail() function to add the new display delivery process object to the tail of the queue linked list to form a queue of display delivery tasks to be executed; T25, call spin_unlock_irqrestore() to release the synchronization lock on the queue list.

[0030] In a specific application embodiment, when no mergeable display delivery process is detected, the process proceeds to the latter half of the display delivery process. A display delivery process object is created, its relevant information is assigned, and `list_add_tail` is called to add it to the `damage_queue` linked list. The specific code is as follows: struct damage_work_node *new_work; struct drm_rect *new_damage; new_work = kzalloc(sizeof(*new_work), GFP_KERNEL); new_damage = kzalloc(sizeof(*new_damage), GFP_KERNEL); memcpy(new_damage, clip, sizeof(*clip)); new_work->fb = fb; new_work->clip = new_damage; drm_framebuffer_get(fb); struct drm_gem_object *obj; unsigned int i; for (i = 0; i <fb->format->num_planes; ++i) { obj = drm_gem_fb_get_obj(fb, i); if (obj) drm_gem_object_get(obj); } / * Queue a new damage request * / list_add_tail(&new_work->list,&udl->damage_queue); spin_unlock_irqrestore(&udl->damage_lock, flags); schedule_work(&udl->damage_work); The code above means the following: First, the `kzalloc()` and `memcpy()` functions are called to create and initialize the display process object. Then, `drm_gem_fb_get_obj()` is called to increment the framebuffer's reference count to prevent other threads from releasing the buffer and causing a parallel exception. Next, `list_add_tail()` is called to add it to the `damage_queue` linked list. After completing the relevant operations, `spin_unlock_irqrestore()` is called to unlock it. Finally, `schedule_work()` is called to add the display request to the kernel work queue.

[0031] In this embodiment, step S3 includes: S31, check if the queue list is empty, and end the current execution flow if the list is empty; S32, when the queue list is not empty, the spin_lock_irqsave() function is called to lock the queue list, and the list_first_entry() function is called to get the first delivery process object in the queue list; S33, the first display sending process object is deleted from the display sending process queue linked list, and the spin_unlock_irqrestore() function is called to release the synchronization lock; S34, determine whether the display content information and display update area information recorded in the first display delivery process object are valid; if both are valid, perform a memory mapping operation on the display content to obtain the corresponding memory address; otherwise, call the DRM log output function to print error information. S35 retrieves the memory address of the content to be displayed, reads the display data, and performs the display sending operation to complete the transfer of display data to the USB display device.

[0032] Step S35 includes: Call the drm_gem_fb_vmap() function to perform a memory mapping operation to obtain the memory address of the corresponding display data; Call the display sending function udl_handle_damage() in the USB display device driver to submit the display data of the corresponding display update area in the sent content to the USB display device; After submitting the display data, call the DRM framework function drm_gem_fb_vunmap() to remove the memory mapping relationship of the submitted content; Iterate through the video memory objects corresponding to the content to be displayed, and call the drm_gem_object_put() function to reduce the reference count of each video memory object; Call the drm_framebuffer_put() function to reduce the reference count of the displayed content object; Call the kfree() function to release the display update area information recorded in the display sending and receiving process structure object, and release the memory resources occupied by the display sending and receiving process structure.

[0033] In a specific application embodiment, the display submission execution process is called by a kernel thread. Within this process, it first checks if the `damage_queue` linked list is empty. If it is empty, it means there are no display submission requests yet, and the process returns directly. If it is not empty, it retrieves the first item of the `damage_queue` linked list, obtains the data to be displayed, and then performs the display submission operation. The specific code is as follows: if (!list_empty(&udl->damage_queue)) { struct damage_work_node *damage; spin_lock_irqsave(&udl->damage_lock, flags); damage = list_first_entry(&udl->damage_queue, struct damage_work_node, list); list_del(&damage->list); spin_unlock_irqrestore(&udl->damage_lock, flags); if (damage->clip&&damage->fb) { struct iosys_map map[DRM_FORMAT_MAX_PLANES]; ret = drm_gem_fb_vmap(damage->fb, map, NULL); if (ret) { DRM_ERROR("vmap damage fb error %d\n", ret); goto free; } / * Specific display operation* / ... } } The above code means that: first, the list_empty() function is called to determine whether the damage_queue linked list is empty. If it is empty, it means that there is no display request yet, and it returns directly. If it is not empty, the list_first_entry() function is called to get the first item of the damage_queue linked list, and then the display operation is performed.

[0034] The specific display submission operation involves calling `drm_gem_fb_vmap()` to map the buffer, then calling the USB display device driver's display submission function `udl_handle_damage()` to complete the submission of display data, and finally performing the release operation of the relevant objects. A code example is shown below: ... udl_handle_damage(damage->fb,&map[0], damage->clip); drm_gem_fb_vunmap(damage->fb, map); for (i = 0; i <damage->fb->format->num_planes; ++i) { obj = drm_gem_fb_get_obj(damage->fb, i); if (obj) drm_gem_object_put(obj); } drm_framebuffer_put(damage->fb); kfree(damage->clip); kfree(damage); The above code means the following: Based on the already mapped display buffer data, the display sending interface of the USB display device driver is called to submit the display data of the corresponding display update area in the display buffer to the USB display device; after the data submission is completed, the memory mapping relationship of the display buffer is released; then, each video memory object corresponding to the display buffer is traversed, and the reference count of each video memory object is reduced in turn; further, the reference count of the display buffer object is released; finally, the display update area information recorded in the display sending process object and the memory resources occupied by the display sending process object itself are released, thereby completing the resource reclamation process of the display sending task.

[0035] like Figure 2 As shown, Figure 2 The upper part is a flowchart of the serial display process. Figure 2 The lower half is a flowchart of the parallel display process. The method in this embodiment separates the time-consuming part of the serial display process (USB display device display delay) and runs it separately, thereby significantly reducing the main thread's latency. Applying this method to a cloud desktop operating system can greatly improve the smoothness of USB display devices running under the cloud desktop system and the response speed of the graphical interface.

[0036] Compared with the prior art, the present invention has the following beneficial effects: This invention splits the USB display device's data delivery process into two parts: a data delivery sending process and a data delivery execution process. The non-blocking part is placed in the data delivery sending process, and the blocking part is placed in the data delivery execution process. The data delivery sending process is further divided into a first half and a second half. When the USB device display driver loads, a work queue is created and initialized, running as a kernel thread to execute the data delivery execution process. In the first half of the data delivery sending process (before display data submission), it iterates for any unsubmitted display data. If any is found, the display data is merged, and the process returns immediately to reduce bandwidth usage. In the second half of the data delivery sending process (when display data is submitted), if merging cannot be performed in the first half, a data delivery operation object is created, submitted to the work queue, and then returned. The data delivery execution process runs independently by the kernel work queue, achieving a non-blocking parallel effect. The parallel non-blocking USB display device display process of the present invention can reduce the display data bandwidth occupation by merging display data, thereby reducing the display latency of the USB display device under the Linux operating system (the display driver of the USB display device under the Linux system is a UDL driver, and this embodiment achieves this by adjusting the UDL driver display process and adding a parallel non-blocking process), reducing the blocking time of the graphics server, and thus improving the display performance of the USB display device under the operating system.

[0037] The present invention further provides a USB display device display optimization system under a Linux system, including a microprocessor and a memory interconnected thereto, wherein the microprocessor is programmed or configured to execute the steps of a USB display device display optimization method under a Linux system.

[0038] The present invention further provides a computer-readable storage medium storing a computer program, the computer program being programmed or configured by a microprocessor to execute the steps of a method for optimizing the display delivery of a USB display device under a Linux system.

[0039] The present invention further provides a computer program product, including a computer program / instructions, which are programmed or configured to execute the steps of a method for optimizing the display delivery of a USB display device under a Linux system via a processor.

[0040] The system, medium, and product of the present invention, corresponding to the methods described above, also have the advantages described above.

[0041] The present invention can implement all or part of the processes in the methods of the above embodiments, or it can be implemented by a computer program instructing related hardware. The computer program can be stored in a computer-readable storage medium. When the computer program is executed by a processor, it can implement the steps of the above method embodiments. The computer program includes computer program code, which can be in the form of source code, object code, executable file, or some intermediate form. Computer-readable media include: any entity or device capable of carrying computer program code, recording media, USB flash drives, portable hard drives, magnetic disks, optical disks, computer memory, read-only memory (ROM), random access memory (RAM), electrical carrier signals, telecommunication signals, and software distribution media, etc. The memory is used to store computer programs and / or modules. The processor implements various functions by running or executing the computer programs and / or modules stored in the memory, and by calling data stored in the memory. The memory may include high-speed random access memory, as well as non-volatile memory, such as hard disks, RAM, plug-in hard disks, smart media cards (SMC), secure digital (SD) cards, flash cards, at least one disk storage device, flash memory device, or other volatile solid-state storage devices.

[0042] The above description is merely a preferred embodiment of the present invention. The scope of protection of the present invention is not limited to the above embodiments. All technical solutions falling within the scope of the present invention's concept are within the scope of protection of the present invention. It should be noted that for those skilled in the art, any improvements and modifications made without departing from the principles of the present invention should also be considered within the scope of protection of the present invention.

Claims

1. A method for optimizing display output from a USB display device under a Linux system, characterized in that, Including the following steps: S1, During the display driver initialization phase, a queue list damage_queue is constructed to store the display delivery process and a work queue damage_work is constructed to run the display delivery execution process, and a process synchronization mechanism is set. S2, In the display delivery stage, first check whether there is an unexecuted display delivery process for the same display content in the queue chain. If there is, merge the display delivery process; otherwise, create a new object for the display delivery process and add it to the queue chain. S3, during the display delivery execution phase, the kernel thread calls the display delivery execution process, retrieves the display delivery process to be executed from the queue list, maps the display content in it, calls the USB display device driver interface to complete the submission of display data, and releases the relevant resources after the display delivery is completed.

2. The method for optimizing USB display device output under Linux system according to claim 1, characterized in that, Information about the display delivery process is described by constructing a structure called damage_work_node, which includes the display content, the display update area, and one or more items from the queue list.

3. The method for optimizing the display of a USB display device under Linux system according to claim 1, characterized in that, Step S1 includes: The queue list damage_queue is initialized using the linked list initialization macro INIT_LIST_HEAD() provided by the kernel. The spinlock damage_lock is initialized by the spin_lock_init() function to enter the unlocked state, so as to realize the synchronization of the display sending process and the display execution process. The kernel work queue task is initialized using INIT_WORK().

4. The method for optimizing the display of a USB display device under Linux system according to claim 1, characterized in that, In step S2, it is first checked whether there are any unexecuted display delivery processes for the same content in the queue linked list. If so, the display delivery processes are merged, which includes the following steps: S21, before executing the display sending process, call the spin_lock_irqsave() function to lock the queue list; S22, traverse each sending and displaying process node in the queue linked list and obtain the structure object corresponding to each node; S23, determine whether the content recorded in the structure object is the same as the content corresponding to the current display sending process. If they are the same, then use the udl_damage_merged() function to merge the display update area in the current display sending process with the display update area in the structure object that has not been executed in the display sending process. S24. After the merge is completed, the spin_unlock_irqrestore() function is called to release the synchronization lock and end the current display sending process.

5. The method for optimizing the display of a USB display device under Linux system according to claim 1, characterized in that, In step S2, a new object is created for the display delivery process and added to the queue list, which specifically includes the following steps: T21. When no mergeable display delivery process is detected, the kzalloc() function is called to create a new display delivery process object. T22, call the memcpy() function to copy the display update area and display content corresponding to the current display sending process to the newly created display sending process object; T23 calls drm_gem_fb_get_obj() to increment the reference count of the display buffer corresponding to the sent content in order to prevent the display buffer from being released; T24, call the list_add_tail() function to add the new display delivery process object to the tail of the queue linked list to form a queue of display delivery tasks to be executed; T25, call spin_unlock_irqrestore() to release the synchronization lock on the queue list.

6. The method for optimizing the display of a USB display device under Linux system according to claim 1, characterized in that, Step S3 includes: S31, check if the queue list is empty, and end the current execution flow if the list is empty; S32, when the queue list is not empty, the spin_lock_irqsave() function is called to lock the queue list, and the list_first_entry() function is called to get the first delivery process object in the queue list; S33, the first display sending process object is deleted from the display sending process queue linked list, and the spin_unlock_irqrestore() function is called to release the synchronization lock; S34, determine whether the display content information and display update area information recorded in the first display delivery process object are valid; if both are valid, perform a memory mapping operation on the display content to obtain the corresponding memory address; otherwise, call the DRM log output function to print error information. S35 retrieves the memory address of the content to be displayed, reads the display data, and performs the display sending operation to complete the transfer of display data to the USB display device.

7. The method for optimizing the sending of display of USB display device under Linux system according to claim 6, characterized in that, Step S35 includes: Call the drm_gem_fb_vmap() function to perform a memory mapping operation to obtain the memory address of the corresponding display data; Call the display sending function udl_handle_damage() in the USB display device driver to submit the display data of the corresponding display update area in the sent content to the USB display device; After submitting the display data, call the DRM framework function drm_gem_fb_vunmap() to remove the memory mapping relationship of the submitted content; Iterate through the video memory objects corresponding to the content to be displayed, and call the drm_gem_object_put() function to reduce the reference count of each video memory object; Call the drm_framebuffer_put() function to reduce the reference count of the displayed content object; Call the kfree() function to release the display update area information recorded in the display sending and receiving process structure object, and release the memory resources occupied by the display sending and receiving process structure.

8. A Linux system USB display device sending display optimization system, comprising a microprocessor and a memory connected to each other, characterized in that, The microprocessor is programmed or configured to perform the steps of the Linux system USB display device display optimization method according to any one of claims 1 to 7.

9. A computer-readable storage medium having stored therein a computer program, characterized in that, The computer program is used to be programmed or configured by a microprocessor to perform the steps of the USB display device display optimization method under Linux system as described in any one of claims 1 to 7.

10. A computer program product comprising a computer program / instructions, characterized in that, The computer program / instructions are programmed or configured to execute the steps of the USB display device display optimization method under Linux system as described in any one of claims 1 to 7 via a processor.

Images