Wayland window management method and system supporting dynamic switching of displays

Abstract

The application relates to the technical field of Linux graphic display systems and window management, in particular to a Wayland window management method and system supporting dynamic display switching. The Wayland window management method supporting dynamic display switching is based on Weston to load a window management module in the form of a plug-in, establish UNIX domain socket communication and two one-way pipes, and sequentially execute all window management operations in a compositor main thread; a binding is established between a process identifier and a display name, a non-full-screen switching path and a full-screen switching path are distinguished, a view is moved or redrawn according to a target resolution as required; a background layer, a video layer, an application layer, a top layer and an interface layer are preset, hot plug-in is listened to and migration and back migration are performed according to priorities, runtime screen switching, persistent binding and superimposed presentation are realized, and time delay is reduced and stability is improved.

Description

Technical Field

[0001] This invention relates to the field of Linux graphical display systems and window management technology, and in particular to a Wayland window management method and system that supports dynamic switching of displays. Background Technology

[0002] The Wayland-Weston combination has become the mainstream display stack in embedded multi-screen devices. The default desktopshell relies on global coordinate layout, preventing applications from directly specifying the target display during runtime. Hot-swapping or changing the order of displays disrupts the original coordinate mapping, causing window misalignment. Shells like kiosk and ivi often use static configuration files, making them difficult to adjust during runtime and requiring a service restart after modification. QtWayland's QWindowsetScreen is only effective before initial display; once the window is displayed, it cannot be switched, and automatic migration after hot-swapping does not return to the intended position. While Weston supports multiple layers, its default strategy does not provide layer control to ordinary clients, making it difficult to achieve folding of underlying video and top-level UI, and globally pinned windows.

[0003] The aforementioned limitations make it difficult to meet engineering requirements for runtime screen switching and stable layout maintenance in multi-screen scenarios.

[0004] The above content is only used to help understand the technical solution of the present invention and does not represent an admission that the above content is prior art. Summary of the Invention

[0005] The purpose of this invention is to address the shortcomings of existing technologies by providing a window management module implemented as a plug-in on the compositor side. This module establishes a low-latency runtime control channel between an external management process and a private binary protocol (protocol Y) without altering the Wayland protocol. The module uses a process identifier as the core key to bind the client's drawing surface to the target display, distinguishing between full-screen and non-full-screen switching paths, and performing event and geometry updates within the main thread to ensure stability. It also maintains the binding and restoration of hot-plug events and pre-defines five standard layers to support video and UI overlay and on-top windows.

[0006] This invention achieves the above objective through the following technical solution: a Wayland window management method supporting dynamic display switching, comprising the following steps: Module loading steps: During the Weston compositor startup process, the window management module is loaded as a plug-in and the desktop interface's add callback, submit callback, move callback and size change callback are registered to receive the lifecycle events of the client's drawn surface; Communication access steps: Create a communication sub-thread within the window management module, listen for local inter-process communication based on UNIX domain sockets, and establish two unidirectional pipes. The first pipe is used for the sub-thread to send messages to the main thread, and the second pipe is used for the main thread to send instructions to the sub-thread. Register the pipe reading end used by the main thread to receive messages to the Weston event loop, so that window management operations are executed sequentially within the Weston compositor main thread. Identifier binding steps: After receiving a switching request, write the request process identifier and the target display output into the binding table, and in the drawing surface submission callback, read the process identifier of the Wayland client, match the corresponding drawing surface, create or update the view, and establish a binding relationship between the view and the target display output; Switching control steps: When the window is not in full-screen mode, move the view to the origin of the target monitor coordinates, insert the target layer, and trigger geometry update and graphic composition. When the window is in full-screen mode, compare the target monitor resolution with the drawing surface size. If they are inconsistent, send a redraw instruction to the client according to the target resolution and complete the binding in the resubmission callback. If they are consistent, complete the binding directly and update the composition output. Topology restoration steps: Listen for monitor topology change events, restore the binding between the view and the original target monitor after the monitor is hot-plugged according to the binding table, migrate to the alternative monitor according to the preset priority when the target monitor is unavailable, and migrate back after the original target monitor becomes available again.

[0007] Furthermore, the two unidirectional pipes are created by the operating system pipe interface. The read end of the uplink pipe is registered to the Weston event loop for the main thread to asynchronously receive and process window management messages from the communication sub-thread. The downlink pipe is used by the main thread to send back processing results and control instructions to the communication sub-thread to ensure the orderliness of message transfer between threads and the single-thread execution constraint of the main thread. The communication access step uses local binary message frames for interaction. The message frame includes at least a frame header field, a type field, a message identifier field, a timestamp field, a command field or a data field, and a verification field. The verification algorithm of the verification field is CRC-16 / CCITT-FALSE, which is used to accurately correspond requests and responses between the sub-thread and the main thread and to ensure data integrity.

[0008] Furthermore, the communication access step and the identifier binding step also include: The legality determination process is as follows: The management process running in user mode performs cyclic redundancy check, limits the length of the message buffer queue, and discards expired messages. The upper limit of the queue length is a preset value M, the message processing interval is a preset value N, and the expiration threshold is a preset value D. Only messages that pass the determination are forwarded to the window management module for processing. The binding table mentioned in the identification binding step records at least the process identifier, target display name, target layer index, and the timestamp of the most recent submission. This is used to find the corresponding view in the subsequent drawing surface submission callback and maintain a stable correspondence between the window, display, and layer. The process identifier mentioned in the identifier binding step is carried by the Wayland client object. The window management module reads the process identifier in the drawing surface submission callback and matches it one by one with the process identifiers in the binding table, thereby completing the binding of view recognition and target display output. The protocol of the local binary message frame is protocol Y. The message frame types of protocol Y include command frame, data frame, response frame and event frame. The response frame reuses the message identifier field that is consistent with the original request to complete the pairing. The event frame carries an event type field to indicate the window management event. The field lengths of the protocol Y are configured as follows: the message identifier field is four bytes, the timestamp field is four bytes, the data length field is two bytes, the verification field is two bytes, and the maximum length of the additional data field is a preset value L, which is used to carry necessary control information without increasing round-trip delay.

[0009] Furthermore, in the switching control step, for non-full-screen displays, the view coordinates are set to the origin of the target display coordinate system, the view is inserted at the end of the view list of the target layer, and then the view geometry update and graphic composition are triggered to complete the output switching within the same frame. In the switching control steps, for full-screen displays with inconsistent resolutions, the view is temporarily mapped to the visible area of ​​the target display and the current frame is kept on display. An instruction to redraw according to the target resolution is sent to the client. In the callback of the client's resubmission, the size matching and binding with the target display are completed, and the view transformation update and composite output are triggered. In the switching control steps, for the top-pinning request, the window management module moves the corresponding view from the regular application layer to the top-pinning application layer, and updates the overlay relationship in the top-pinning application layer according to the order in which the views were added, so as to ensure the predictability of the top-pinning display.

[0010] Furthermore, in the module loading step, five layers are pre-set in the compositor, from bottom to top: background layer, video layer, regular application layer, top application layer, and user interface layer. The layer order determines the overlay relationship, which is used to support the aliasing display of video and user interface and the global top window. The module loading process establishes three configuration methods for creating a multi-monitor desktop background: solid color background, image background, and pattern tiling background. Among them, the solid color background is directly generated by the window management module, the image background is submitted by the Wayland client in the background and bound to the background layer of the target monitor through the process identifier, and the pattern tiling background is drawn by carrying RGB color block data in the local binary message frame and tiling in the background buffer. In the binding step, the target display is indexed by the display name, which is consistent with the name of the compositor output object. When performing the binding, the window management module locates the target output based on the display name index. After the module loading step is completed, the system default display can be set. The default display is used to specify the initial output target of the newly launched application when no explicit switching request is received, and the changes will take effect immediately on subsequent newly created views when the default display is changed.

[0011] Furthermore, a priority table is used for restoration and migration in the topology restoration step. The priority table includes at least priority 1 for displays with completely matching names, priority 2 for displays with the same type as the original displays, and priority 3 for the displays with the smallest number among the currently available displays. This is used to migrate the original target displays in an orderly manner when they are unavailable and to automatically migrate them back after they are made available again. In the communication access process, the communication sub-thread does not directly call any window management interface. All window management operations are executed sequentially by the main thread in the event loop callback. The communication sub-thread only submits messages through the unidirectional pipe used for uplink and receives instructions or results through the unidirectional pipe used for downlink, so as to ensure single-threaded execution constraints and thread safety. In addition to the UNIX domain socket-based channel, the communication access step also provides a named pipe as a control channel for command-line access. The named pipe supports checking service status, obtaining the number of displays, obtaining the display name, setting the system default display, switching displays by process identifier, and returning execution failure if no result is obtained within the timeout threshold. In the communication access step, a communication timeout threshold T, a message processing interval N, and a queue length limit M are set. When the waiting time exceeds the timeout threshold T, failure is immediately returned and the waiting stops. When the message arrival rate is too high, causing the queue length to reach the limit M, new messages are discarded and audit information is recorded to avoid abnormal traffic affecting the stability of the synthesizer.

[0012] The add callback mentioned in the module loading step is used to create the corresponding view, set the default display output, register the initial layer and coordinates and write them into the binding table when the client draws the surface for the first time; the submit callback is used to determine the target display according to the binding table when the drawing surface is submitted, update the view position to the target display coordinate system, insert the view into the view list of the target layer and trigger geometric transformation and graphic composition; the move callback is used to set the view position to the origin of the target display coordinate system or a specified offset and record the most recent move timestamp when the window position is adjusted, the display is switched or the layout is corrected; the size change callback is used to compare the target display resolution when the buffer size changes, send a redraw instruction to the client according to the target resolution and temporarily keep the current frame display when there is a discrepancy, and check the size matching and complete the target display binding after resubmission. All of the above callbacks are triggered and executed sequentially in the event loop of the Weston compositor main thread to ensure the consistency of single-threaded execution constraints and display behavior.

[0013] A Wayland window management system that supports dynamic display switching includes: The Weston compositor is used to receive and composite client-drawn surfaces and output them to the display. The window management module is loaded into the Weston compositor as a plug-in. It performs window management operations within the compositor's main thread, registers the add callback, submit callback, move callback, and size change callback for the desktop interface, and is used to implement view creation, view update, and output binding within the lifecycle of the drawing surface. The communication sub-thread, set within the window management module, is used to listen for local inter-process communication based on UNIX domain sockets; Two unidirectional pipes are used. The first unidirectional pipe is used for the communication sub-thread to send messages to the synthesizer main thread, and the second unidirectional pipe is used for the synthesizer main thread to send instructions to the communication sub-thread. The pipe reading end used by the main thread to receive is registered to the Weston event loop to ensure that window management operations are executed sequentially within the synthesizer main thread. An external management process is used to perform verification, rate limiting, and forwarding of messages from the application, and to transfer compliant messages to the window management module for processing. The binding table records the process identifier, target display name, target layer index, and timestamp to complete the matching and binding of the view and display output in the commit callback; The layer management structure includes at least a background layer, a video layer, a regular application layer, a pinned application layer, and a user interface layer to support aliasing and pinning. The application-side dynamic link library provides interfaces for querying the number of displays, obtaining the display name, setting the default display, switching displays by process identifier, and setting the target layer. The window management module is configured to set the view coordinates to the origin of the target display coordinate system and trigger a geometric update when switching from a non-full-screen window. When switching from a full-screen window and the resolutions are inconsistent, it sends a redraw instruction to the client according to the target resolution and completes the binding after resubmission. After listening for changes in the display topology, it restores the window to the original target display or migrates it to a backup display according to priority based on the binding table.

[0014] Furthermore, the external management process performs cyclic redundancy check on messages, limits the length of the message cache queue, and discards expired messages. The upper limit of the queue length is a preset value M, the message processing interval is a preset value N, and the expiration threshold is a preset value D. Only messages that pass the check and have not expired are transferred to the window management module for processing. The two unidirectional pipes are created by the operating system pipe interface. The unidirectional pipe for receiving messages from the main thread is registered to the Weston event loop to trigger the main thread to read and process window management messages. The unidirectional pipe for receiving messages from child threads is used by the main thread to send back processing results and control instructions, so as to ensure the orderliness of message transfer between threads and the single-thread execution constraint of the main thread.

[0015] The beneficial effects of this invention are: This solution extends window management capabilities on the compositor side via a plug-in approach. It unifies window management operations within the Weston compositor's main thread and establishes a UNIX domain socket-based communication channel and two unidirectional pipes within the window management module. This securely and with low latency delivers runtime screen-switching control commands to the main thread, which processes them sequentially in the event loop. This allows applications to initiate monitor switching requests at any time during runtime, no longer limited by binding constraints before the first frame is displayed, nor relying on global coordinates to deduce window ownership. This directly addresses the issue of desktop environments only supporting `setScreen` before the first display and the vulnerability of global coordinate layouts. To prevent window misalignment during monitor changes, this solution establishes a binding table using process identifiers as the core key. In the drawing surface submission callback, the process identifier of the actual submitter is used for one-to-one matching to complete the binding between the view and the target output. This ensures that window positioning and the output target originate from the same deterministic decision chain within the main thread, preventing hot-swapping or sequential changes from disrupting the existing layout.

[0016] To address the pain points of static configuration file binding leading to difficulties in runtime adjustments and the need for service restarts, this solution introduces a user-space management process and a local binary message protocol. It provides runtime interfaces such as setting the default display, switching displays by process, and setting the target layer. Parameter changes are processed through message verification, queue length limits, and expired data discarding before entering the main thread for processing. This achieves dynamic adjustments without restarting and suppresses sudden traffic surges with timeout thresholds and processing intervals, ensuring the stability of the control channel. To resolve the uncertainty of window drift and recovery after hot-plugging displays, this solution retains the binding records between windows and outputs during the topology recovery process. Migration and revert decisions are made using a priority table based on exact name matching, consistent type, and the lowest available number. After the original target output is restored, it automatically returns to its designated position, maintaining consistency in multi-screen layout at the system level.

[0017] To address the issues of the default strategy's lack of layer control and inability to achieve aliasing of the underlying video and the top-level user interface, as well as the global pinned window, this solution pre-defines a background layer, a video layer, a regular application layer, a pinned application layer, and a user interface layer during module initialization. The overlay relationship is determined by the layer order and the view insertion order. The application can move the view from the regular application layer to the pinned application layer as needed to achieve a stable global pinned effect. The video layer and the upper-level user interface coexist to achieve a clear aliasing presentation. To reduce screen tearing and distortion during screen switching, this solution distinguishes between non-fullscreen and fullscreen paths. The non-fullscreen path directly moves the view to the origin of the target output coordinate system and triggers geometric updates and compositing, typically completing the switching within the same frame. The fullscreen path first compares the resolution, and if there is a discrepancy, it instructs the client to redraw according to the target resolution. After resubmission, the binding and compositing updates are completed, avoiding interpolation blurring or edge clipping caused by scale mismatch.

[0018] In terms of engineering usability, this solution provides a unified interface through application-side dynamic link libraries and optional named pipes. The Wayland client does not need to modify the protocol or perform complex adaptations; it only needs to initiate queries and switches according to the interface to stably map windows to the specified monitors and layers. Multi-monitor backgrounds can be configured in three ways: solid color, image, and pattern tiling. Image backgrounds are submitted by the backend client and bound to the corresponding output according to the process identifier. The relationship between the background and the window is naturally maintained by the layer management structure, ensuring a consistent desktop appearance even after hot-plugging and switching. Through the above mechanisms, runtime screen switching capabilities, persistent binding capabilities, and multi-layer aliasing capabilities are uniformly implemented within the same main thread's in-order execution framework. This solves engineering problems such as the inability to specify the target monitor during runtime, the need for restarts when switching, difficulty in recovery after hot-plugging, and lack of layer control in multi-screen scenarios. It also achieves a balance between stability and real-time performance, enabling embedded multi-screen devices to maintain predictable display behavior and low response latency in complex scenarios such as task switching, interface partitioning, and global top placement. Attached Figure Description

[0019] Figure 1 This is a system overall framework diagram of the present invention.

[0020] Figure 2 This is a diagram defining the communication protocol (protocol Y) of the present invention.

[0021] Figure 3 This is a schematic diagram illustrating the window switching process (API method) according to an embodiment of the present invention.

[0022] Figure 4 This is a schematic diagram illustrating the window switching process (FIFO mode) according to an embodiment of the present invention.

[0023] Figure 5 This is a schematic diagram illustrating the processing steps in the event callback corresponding to the window switching process in an embodiment of the present invention.

[0024] Figure 6 This is a schematic diagram illustrating the data structure relationship between layers, drawing surfaces, views, and display outputs in an embodiment of the present invention.

[0025] Figure 7 This is a schematic diagram of thread communication processing in the window manager according to an embodiment of the present invention.

[0026] Figure 8 This diagram illustrates the initialization process of the window manager according to an embodiment of the present invention.

[0027] Figure 9 This is a schematic diagram illustrating the external management process communication and message frame processing mechanism in an embodiment of the present invention.

[0028] Figure 10 This diagram illustrates the processing steps in the event callback corresponding to the desktop background configuration in this embodiment of the invention. Detailed Implementation

[0029] The technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings in the embodiments of the present invention.

[0030] In current embedded Linux systems, Wayland / Weston has become a widely used graphics display system framework. Weston's window management functionality relies on different shell module plugins. Different types of shells (such as desktop-shell, ivi-shell, etc.) define window layout methods, interaction logic, and display mapping strategies.

[0031] Desktop shells are typically used to provide a complete desktop environment, including features such as a status bar, window borders, and a taskbar. In multi-monitor environments, desktop shells only support window layout using global coordinates; applications cannot directly specify the target monitor for window display. If the monitor topology changes (e.g., hot-plugging or reordering), the original coordinate mapping can easily become invalid, leading to abnormal window display or misalignment.

[0032] Other shells in Weston (such as kiosk-shell or ivi-shell) simplify the interface elements, but typically only support defining the binding relationship between the application and the display through a fixed configuration file. This binding cannot be dynamically modified after Weston is running; even if the configuration file is adjusted, the Weston service needs to be restarted for the changes to take effect. This mechanism limits the flexible management of running application windows and cannot meet the needs of dynamically switching display output.

[0033] In the Wayland desktop environment, for Qt-based Wayland client applications, the QtWayland plugin allows the application to bind a window to a specified display using QWindow::setScreen() before the window is displayed. However, this method is only effective before the window is displayed; the target display cannot be switched directly after the window is displayed. Furthermore, when a display is hot-plugged, the Qt window is automatically migrated to another available display, and even if the original display is reconnected, the window will not automatically return to its original bound position.

[0034] Furthermore, while the Weston system framework itself supports multiple layer configurations, for security and stability reasons, the default shell window management strategy does not provide clients with direct control interfaces for multiple layers. Regular applications are uniformly assigned to specific layers for display, while other predefined layers are only for internal shell use. This limits the ability of client applications to overlay different layer windows.

[0035] In summary, Weston's existing default window management mechanism still has the following shortcomings in embedded multi-screen display scenarios: It lacks the ability to dynamically switch displays during application runtime; it lacks a flexible application-display binding mechanism, relying on static configuration files to bind displays and unable to dynamically adjust them during system operation; it cannot guarantee the stable maintenance of the application window's display position after hot-plugging or topology changes of the display; and it cannot realize the development requirements of system-level multi-layer overlay display, such as global top placement (e.g., desktop floating window) and underlayer video + top-level UI overlay display.

[0036] Therefore, there is an urgent need for a lightweight and scalable window management module and control mechanism to enable dynamic switching and flexible scheduling management of windows in a multi-screen environment, thereby improving the user experience and operability of embedded systems in multi-monitor scenarios.

[0037] To address the shortcomings of existing Weston window management mechanisms in embedded platforms, such as weak support for dynamic multi-monitor switching and a lack of more refined display management interfaces, this invention proposes a window management module implementation method based on the Weston system framework, achieving the following technical effects: This allows the application to dynamically switch its window display to any monitor while it is running. It supports global configuration of application and display output binding, and the display output binding can be maintained even after the display is hot-swapped; it also supports dynamic configuration of the default display when the application starts. It adopts a plug-in-based lightweight implementation, which results in low system resource consumption; it supports customizable display layer configuration, desktop background configuration, etc. The application layer implements specific functional operations through simplified library interface calls, eliminating the need to directly modify and customize the complex Wayland interface protocol, thus simplifying the adaptation process.

[0038] To achieve the above-mentioned objectives, the present invention adopts the following technical solution: like Figures 1-10 As shown in the figure, this invention provides a Wayland window management method and system that supports dynamic display switching. The overall system composition is as shown in the attached figure. Figure 1 As shown, it includes: Based on the Weston system framework, a window management module (y-shell) is implemented. This module can be loaded and used by the Weston compositor as a plugin. By connecting to the registration interface provided by the libweston-desktop open-source library, the window management module can listen for and process event callbacks in the lifecycle of each drawing surface (weston_surface) submitted by the client window. This is the main interface method for handling the original window management business of Weston.

[0039] The window management module receives window processing requests from the application layer client via IPC communication, enabling low-level control operations for the display output and layer binding of Wayland graphical windows.

[0040] To facilitate efficient communication between system processes and manage processing requests from different applications, IPC communication is uniformly implemented using UNIX domain sockets and a proprietary binary communication protocol (hereinafter referred to as Protocol Y), achieving a unified message frame format definition (as shown in the attached document). Figure 2 ).

[0041] To avoid impacting the stability and security of the window management module, an external management program (hereinafter referred to as the external management process) outside the Weston system framework is implemented on the Linux system. This program performs validity checks and frequency control on window control requests from various applications. Internally, the external management process needs to implement multi-terminal communication and schedule the verification, forwarding, and response of message frames from various client applications.

[0042] Optionally, if the target product system has a relatively simple application scenario and does not require the system to run external third-party applications, the implementation of external management programs can be skipped, and the window management module can be directly connected through protocol Y, making communication management more streamlined and efficient.

[0043] The client application links to the provided dynamic library and uses a unified API function call to handle window requests. Communication between the client API and the external management process also uses protocol Y. In addition to the API interface, the external management process provides some window control nodes via named pipes.

[0044] When handling communication within the window management module, window control operations are guaranteed to be processed in the Weston main thread, while communication processing must be implemented in a sub-thread. The communication sub-thread communicates with the Weston main thread via pipes. The main thread registers a pipe file descriptor with the Weston event loop, allowing it to promptly respond to and process pipe messages from the communication sub-thread. The internal thread pipe communication protocol within the window management module also uniformly adopts protocol Y.

[0045] The window management module primarily handles monitor binding through PID comparison. After submitting a window binding request via protocol Y, the specified monitor's binding information array is appended with the specified PID information. When the client application submits drawing surface data to Weston via the Wayland standard desktop protocol, the event callback corresponding to the `weston_desktop_api` interface registered in the initial phase of the window management module is invoked. At this point, the window management module can obtain the submitted drawing surface object data (hereinafter referred to as `weston_surface`). This allows us to obtain the PID information of the client that submitted the drawing surface, which is stored in wl_client. By comparing these two sets of PID information, we can identify the drawing surface during the process of binding the window corresponding to the specified PID to the specified monitor.

[0046] In handling monitor switching, the window management module compares the resolution of the specified monitor with the resolution of the drawing surface if the drawing surface is in full-screen mode. If they differ, it first maps the view of the drawing surface to the coordinate region of the specified monitor, then notifies the client via protocol Y to redraw and submit the adjusted drawing surface. The resubmitted drawing surface, corresponding to the monitor's resolution, will be bound and displayed on the specified monitor during its submission event callback processing. Finally, the compositor interface will be called to update and redraw the corresponding view to the specified display output. If the drawing surface is not in full-screen mode, during message frame processing, after moving to the zero point of the specified monitor's coordinates, the compositor interface will be directly called to trigger the redrawing of the corresponding view on the specified display output. (See attached...) Figure 3 Example process) In the window management module, five standard layers are pre-defined in the compositor for use by background, video, application, pinned application, and desktop UI. (See attached image.) Figure 6 The layers, from bottom to top, are background, video, normal, top, and ui. These layers are registered and added to the compositor's layer list during the initialization phase in the window management module. When a regular client application submits its drawing surface, the created view (hereinafter referred to as weston_view) is assigned to the application layer (normal) by default. The background layer is used for background views on various monitors, the video layer is used for UI and video overlay displays, the top application layer is used to place the currently top-processed application window view, and the desktop UI layer is used to customize and draw top-level desktop components (such as the system time desktop component). When the program needs to be permanently displayed on top, it requests this via protocol Y, and the window manager removes it from the original application layer (normal) and places it in the top application layer (top). The stacking relationship between layers is determined by the order of the layer's view list; later added views cover earlier ones.

[0047] In the desktop background management of the window manager, during the initialization phase, the compositor monitor list can be traversed to create corresponding drawing surfaces and views by the window management module, which are then assigned to the background layer and bound to the specified monitor. When the window manager receives a desktop background configuration request via protocol Y, it will destroy the original drawing surfaces and views. For solid color / pattern schemes, the drawing surfaces and views will be recreated according to the specified colors or color blocks and bound. For image schemes, the drawing surfaces are submitted by the client, and the window manager, upon receiving them in the event callback handling, will create the corresponding views and assign them to the background layer by comparing their process IDs (PIDs), while simultaneously binding them to the corresponding monitor.

[0048] The beneficial technical effects of this invention are: 1. Enables dynamic display switching of application windows during runtime: This invention introduces a private protocol communication mechanism into the window management module, enabling applications to dynamically switch their windows to any specified monitor while running. Compared to Weston's default window management module, this overcomes the limitations of existing shells that can only rely on static configuration or global coordinate mapping, significantly improving system flexibility and controllability in multi-monitor scenarios.

[0049] 2. Provides persistent monitor binding and flexible configuration capabilities: Through a global application-monitor output binding mechanism, the system can automatically restore the original window layout after hot-plugging the monitor and supports dynamically setting the default monitor for application startup. This mechanism effectively solves the problem of window misalignment caused by changes in display device status, enhancing the stability and consistency of display output.

[0050] 3. Lightweight and highly scalable system architecture: This invention adopts a plug-in architecture and binary communication protocol, which ensures low system resource consumption while realizing refined display management functions such as window pinning, multi-layer customization, and desktop background configuration.

[0051] In real-world testing, compared to the default desktop-shell plugin, using the y-shell plugin reduced CPU usage by approximately 10% per core in non-idle mode on the Weston desktop, and reduced GPU usage by approximately 7%-15% when running more complex OpenGL rendering applications. Regarding screen switching latency, in the same Qt application with the same API call flow, the average latency for screen switching using QWindow was approximately 10ms, while the average latency using the ys-api.so API was 1.5ms (or approximately 0.7ms if only the interface call time is considered and the client resubmits the drawing face is excluded). The latency is significantly lower than using the QWindow API for screen switching. In terms of dynamic screen switching flexibility, Qt's QWindow API only supports switching the display before the application starts and a window is displayed, while the ys-api.so API can switch the display at any point during application runtime.

[0052] 4. Reduced development and adaptation complexity at the application layer: By encapsulating private dynamic libraries and external management process interfaces, the application layer does not need to directly handle complex Wayland protocol customization. Wayland clients based on frameworks such as QtWayland and GStreamer only need to call simple APIs or FIFO nodes to achieve window switching and desktop configuration, greatly reducing development workload and integration risks.

[0053] In summary, this invention, through a systematic design of "external management process + custom shell module + private communication protocol", effectively solves the shortcomings of the existing Weston window management mechanism in terms of dynamic switching, persistent binding and multi-layer overlay, providing a more flexible and stable window management solution for embedded multi-monitor scenarios, and has significant engineering practical value.

[0054] The y-shell window management module and system of this invention are applicable to embedded multi-screen display systems based on the Wayland framework, and are particularly suitable for multi-display device scenarios such as vehicle central control, industrial control terminals, smart home hub screens, and human-machine interaction control consoles. In these scenarios, the system typically has a main display screen, a secondary screen, or an extended display screen, and needs to dynamically adjust the display output according to the application type or task status to achieve information partitioning display, layered interface rendering, and real-time screen switching.

[0055] The implementation details of the relevant functions of this invention are as follows: 1. Example of protocol Y implementation: Appendix Figure 2 The following are examples of message frames defined for Protocol Y and communication transmission / reception: Message frames can be mainly divided into four categories: command frames, data frames, response frames, and event frames; The first three fields (pillow) of each frame are: HEAD|TYPE|MSG-ID, with a uniform length of 8 bytes. The HEAD field is used to identify the management service to which the message belongs, so that when other management service processes are added in the future, y-shell can distinguish messages from different management service processes. The MSG-ID field is the message ID, which is a 4-byte random number used by the server to respond one by one according to the message ID; The TYPE field indicates the message type, which is a predefined message type of 2 bytes. Examples include the following four categories: command (0x00), data (0x01), response (0x02), and event (0x03). 1) Command Frame The frame composition is: HEAD|TYPE|MSG-ID|TS|CMD|PARAM-TYPE|PARAM-CNT|PARAMS|RESERVED|CRC16; The S field contains the message timestamp information and is 4 bytes long; the CMD field contains the command operation type executed by the command frame and is 2 bytes long; the PARAM-TYPE field contains the parameter type description and is 1 byte long; the PARAM-CNT field contains the number of command parameters and is 1 byte long; the PARAM-CNT field contains the command corresponding parameter data and is up to 32 bytes long; the RESERVED field is a reserved field for future custom expansion purposes; and the CRC16 field is the frame check field (the check algorithm uses CRC-16 / CCITT-FALSE) and occupies two bytes.

[0056] 2) Data Frame The frame composition is: HEAD|TYPE|MSG-ID|TS|RES-TYPE|DATA-TYPE|DATA-LEN|DATA-BUFF|RESERVED|CRC16; The S field contains the message timestamp information and is 4 bytes long; the RES-TYPE field contains the resource type information of the data frame and is 1 byte long; the DATA-TYPE field contains the BUFF data type format information and is 1 byte long; the DATA-LEN field contains the data length information and is 2 bytes long; the DATA-BUFF field contains the data and is up to 12288 bytes long; the RESERVED field is a reserved field for future custom expansion purposes and is 2 bytes long; the CRC16 field is the frame check field (the check algorithm uses CRC-16 / CCITT-FALSE) and occupies 2 bytes.

[0057] 3) Response frame / Event frame The frame composition is: HEAD|TYPE|MSG-ID|TS|RESULT|DATA-TYPE|DATA-LEN|EX-DATA|EVENT|CRC16; When the server responds, the MSG-ID of the response frame is the same as the MSG-ID of the corresponding command frame or data frame, thus distinguishing the response results for different messages; the TS field is the message timestamp information, with a length of 4 bytes; the RESULT field is the processing result of the specified message frame, which is meaningless if it is an event frame, and has a length of 2 bytes; the DATA-TYPE field is the data type information attached to the response frame, with a length of 1 byte; the DATA-LEN field is the data length information attached to the response frame, with a length of 1 byte; the EX-DATA field is the data attached to the response frame, with a maximum length of 16 bytes; the EVENT field is the event type corresponding to the event frame. When a specific event is triggered by the y-shell window management module, it will actively send an event frame to the client, with a length of 2 bytes; the CRC16 field is the frame check field (the check algorithm uses CRC-16 / CCITT-FALSE), occupying two bytes.

[0058] 2. Example of application layer adaptation: The application layer is compatible with applications that output using the Wayland protocol, such as Wayland-Client applications based on QtWayland or Gst-WaylandSink. Applications do not need to adapt and implement cumbersome Wayland protocol interface customizations; they can call the interfaces provided by the external management process by linking to a private dynamic library.

[0059] Specifically, the application communicates with the external management process by linking the ys-api.so dynamic library. The underlying communication of the dynamic library uses UNIX domain sockets; see the appendix for details. Figure 3 The protocol is a private protocol (hereinafter referred to as Protocol Y, see Appendix for details). Figure 2 The processing of protocol frames is handled internally by the library and sent without exposing them to client interface functions. It primarily uses highly encapsulated functional interfaces. When communicating with external management processes, a communication timeout period T is set (e.g., 3ms). If this timeout is exceeded, it is considered that there is no response, and the waiting stops.

[0060] The implementation of some functions in ys-api.so can be exemplified as follows: intcheckYsServiceState() checks the current running status of the window management process. If it is running normally, it returns a non-zero value. The `intgetScreenNum()` function retrieves and returns the current number of screens on the system. The `char* getScreenName(int index)` method retrieves and returns the name of the monitor at the specified index. The parameter is the monitor index, which should be less than the number of monitors in the system. intsetDispScreen(constchar*name, pid_tpid) switches the application display to the monitor with the specified name. It returns a non-zero value if successful. int setDefaultScreen(const char *name) sets the default screen for all desktop applications when they start. It returns a non-zero value if successful. The `intsetDispLayerIndex(intindex, pid_tpid)` method toggles the layer displayed in the application window. It returns a non-zero value if successful. The `intsetBackgroundColor(intcolor)` method sets the desktop background to a specified RGB24 color. The lower 24 bits of the parameter are RGB values, and the highest 8 bits are reserved. A typical application usage example is shown below. The following code demonstrates how to switch the current application display to the system's second display screen: if(checkYsServiceState()){ intnum = getScreenNum(); intresult=0; if (num > 1) { result=setDispScreen(getScreenName(1),getpid()); ... } } The FIFO node parameters are explained below via shell command line (node ​​access permissions are limited to 0600): The node is / tmp / ys-cmd. Parameter 1 is the specific command, and parameter 2 is the optional command parameter. Examples of commands supported by parameter 1 are: check_state (check the status of the window management service), get_snum (get the number of system monitors), get_sname (get the name of the monitor at the index specified by parameter 2), and set_screen (set the specified monitor for the system application to display by default, where parameter 2 is the monitor name). The node / tmp / ys-result contains the execution results of the corresponding command via ys-cmd.

[0061] 3. Example of implementing external management processes: The external management process is a standard Linux background daemon that runs automatically after system boot. When the Weston backend is detected to be running normally, this process establishes a communication connection with the y-shell window management module via a private protocol (protocol Y), and performs validity checks and frequency control on client requests to avoid impacting the stability of the Weston synthesizer. Furthermore, the external management process provides a FIFO node, to which the application layer can send commands via the shell terminal to achieve window switching and desktop configuration operations. This ensures dynamic control over window display behavior without modifying the application source code.

[0062] Communication between the external management process and the y-shell window management module is in the form of UNIX domain sockets. After Weston runs, y-shell will create an independent management thread to listen for connection requests on the SocketServer side.

[0063] Regarding the legality and frequency control of application-layer call requests, the appendix... Figure 8 The request processing thread and message processing thread are implemented.

[0064] Appendix Figure 8 In the request processing thread, each message frame is checked according to the CRC field of each frame. Message frames that pass the check are temporarily stored in the message buffer queue. The maximum number of message frames that the queue can hold is M (30 in the example). If the number is greater than M, new requests will be rejected directly.

[0065] Appendix Figure 8 The message processing thread retrieves data from the message buffer queue at specified intervals N (e.g., 0.2ms). If the time difference between the TS field of the message frame and the current time exceeds a specified value D (e.g., 2s), the message frame will be ignored and not processed. The external management process will directly send a response frame to notify the client that the frame processing request timed out. (See attached...) Figure 3 After the message is successfully sent to the y-shell server, the external management process receives the corresponding response frame (processing result) of the message frame, forwards the response frame to the client, and then removes the message frame from the message cache queue.

[0066] 4. Example of implementation of the y-shell window management module: The y-shell window management module is implemented as a Weston plugin, and the system can dynamically choose whether to enable the module when Weston starts. The main functions of this plugin include: module initialization, surface event callback handling, private communication with external management processes, monitor binding management, and desktop background configuration management.

[0067] As attached Figure 1 As shown, in the Wayland communication architecture, the client submits wl_surface window data to Weston via the Wayland protocol. After receiving the data, the Compositor, based on the layer allocation and display binding strategy of the window management module, performs accelerated graphics compositing of multiple surfaces and outputs it to the display device, achieving a multi-window display effect. The Compositor module manages client data by registering the wl_surface_interface interface, and its callbacks include surface creation, destruction, submission, and redrawing. Through a custom implementation of the Weston window management module, the window display logic and management strategy can be flexibly controlled.

[0068] During the initialization process, y-shell loads modules through the wet_shell_init function (as shown in the attached image). Figure 6 This function is called by wet_load_shell during the WestonCompositor initialization process. During initialization, y-shell registers the weston_desktop_api interface to handle event callbacks for adding, removing, committing, moving, and resizing client surfaces (see attached). Figure 5 ).

[0069] To enable communication with external management processes, y-shell creates an independent child thread during initialization to receive message frame requests sent via UnixSocket. Since the Weston main thread is a single-threaded architecture, all window management logic must be executed on the main thread. After the communication child thread is created, two sets of communication pipes are established to enable bidirectional communication between the main thread and the communication thread. The pipe's read end is registered to the Weston main thread's event loop using `wl_event_loop_add_fd`. When the child thread writes data to the pipe, the Weston main thread triggers the corresponding event callback function, achieving cross-thread data forwarding and message synchronization (see attached). Figure 7 ).

[0070] When the client submits wl_surface data to Weston (as shown in the attached document) Figure 5y-shell receives callbacks through the registered weston_desktop_api interface and processes them as weston_surface pointers. In the added callback, y-shell calls weston_view_create to create a weston_view corresponding to the surface and sets its default output device (weston_output). In the committed callback, weston_view_set_position updates the view's display position to the target output device coordinate system, then inserts it into the normal_layer created by y-shell using weston_layer_entry_insert, and finally calls weston_view_update_transform to complete the geometric transformation and rendering update.

[0071] As attached Figure 6 As shown, y-shell creates five Weston layers (weston_layer) during initialization: background_layer: Background layer, used to place the background view corresponding to each output device, corresponding to POSITION_BACKGROUND in the Weston standard layer definition; video_layer: The video layer, used for video preview display, corresponds to POSITION_BOTTOM_UI in the Weston standard layer definition; normal_layer: The normal application layer, which contains the normal application window view, corresponding to POSITION_NORMAL in the Weston standard layer definition; top_layer: Top application layer, where the application window view is placed on top, corresponding to POSITION_UI in the Weston standard layer definition; ui_layer: The top layer of the UI, used to place custom desktop components (such as the system clock display), corresponding to POSITION_UI in the Weston standard layer definition.

[0072] The `video_layer` and `normal_layer` can be used together to achieve an overlay effect of video and UI. By default, all views created by y-shell, except for the background, are placed in the `normal_layer`. The `ys-api.so` interface allows configuration of a specific process (PID) to be bound to a specific layer, thus enabling flexible control over the window display hierarchy.

[0073] When an application requests a display switch, the overall system flow is as follows: Figure 3As shown, the application initiates a switching request by calling the ys-api.so interface: If the current window surface size does not need to be adjusted, then click the attached... Figure 3 The T1->T2->T3->T5 process is executed; If the window size needs to be adjusted, follow the T1->T2->T4->T5 process to switch monitors.

[0074] When switching configurations via named pipes (FIFO) using Linux Shell, the process is as follows: Figure 4 As shown, when the Shell writes a system default monitor switching request, it executes the T1->T2 process; if it writes a specific monitor switching command, it executes the T3->T4 process, ultimately achieving the switching of the display output of the specified process.

[0075] Regarding multi-monitor desktop background management (as shown in the appendix) Figure 10 During initialization, y-shell creates background surfaces and views for each monitor based on default configurations. Clients can dynamically configure the background type via the ys-api.so interface. Solid color background: The surface is generated and its color is set by y-shell directly calling the Weston interface; Image background: The background client program (Waylandclient) is launched by the external management process, submits a surface of the corresponding size, and y-shell identifies it by pid and binds it to the background layer (background_layer) of the target output device; Pattern tiling background: Supports RGB888 color block data with a maximum size of 64×64. The data is sent by the client through the data frame of protocol Y. After receiving it, y-shell will tile the pattern onto the buffer corresponding to the background surface.

[0076] Through the above mechanism, the y-shell module enables flexible and unified management of multiple monitors, multi-layer windows, and desktop backgrounds, and can support complex scenarios with multiple types of display output and dynamic switching.

[0077] 5. Description of the environment and system versions related to instance development and deployment CPU architecture: Dual-core Arm® Cortex®-A76 + Hexa-core Arm® Cortex®-A55; GPU architecture: IMBGXM-4-64MC1; Linux kernel version: 5.15.147aarch64 (verified deployment is 5.15, no specific requirements); File system version: Buildroot 2022.05; Weston version: 9.0.0 and above; Wayland library version requirement: 1.20.0 and above; Westonshell plugin loading configuration example is as follows: Weston configuration file example: / etc / xdg / weston / weston.ini [shell] background-image= / etc / xdg / weston / background.png background-type=scale locking=false [core] idle-time=0 shell=y-shell.so [output] name=DSI-1 transform=rotate-90 [output] name=HDMI-A-1 mode=preferred Example of Weston SysV service startup initialization configuration: / etc / init.d / S40weston #! / bin / sh #StartWeston exportXDG_RUNTIME_DIR=" / tmp / wayland" exportPATH= / usr / local / bin:$PATH exportLD_LIBRARY_PATH= / usr / local / lib:$LD_LIBRARY_PATH mkdir / tmp / wayland chmod0700 / tmp / wayland / mkdir -p / tmp / .X11-unix weston--backend=drm-backend.so--tty=1--socket=wayland-0&.

[0078] Finally, it should be noted that the above description is only a preferred embodiment of the present invention and is not intended to limit the present invention. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art can still modify the technical solutions described in the foregoing embodiments or make equivalent substitutions for some of the technical features. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the protection scope of the present invention.

Claims

1. A Wayland window management method supporting dynamic display switching, characterized in that, Includes the following steps: Module loading steps: During the Weston compositor startup process, the window management module is loaded as a plug-in and the add callback, submit callback, move callback and size change callback of the desktop interface are registered to receive the lifecycle events of the client drawing surface; Communication access steps: Create a communication sub-thread within the window management module, listen for local inter-process communication based on UNIX domain sockets, and establish two unidirectional pipes. The first pipe is used for the sub-thread to send messages to the main thread, and the second pipe is used for the main thread to send instructions to the sub-thread. Register the pipe reading end used by the main thread to receive messages to the Weston event loop, so that window management operations are executed sequentially within the Weston compositor main thread. The communication access step uses local binary message frames for interaction. Each message frame includes at least a frame header field, a type field, a message identifier field, a timestamp field, a command or data field, and a checksum field. The checksum field uses a CRC-16 / CCITT-FALSE algorithm to accurately match requests and responses between the sub-thread and the main thread and ensure data integrity. The local binary message frame uses Protocol Y, which transmits commands, data, responses, and events according to a predetermined message frame format. It distinguishes message frame types based on the type field, establishes a correspondence between command frames or data frames and response frames based on the message identifier field, records message time based on the timestamp field, verifies message frames based on the checksum field, and identifies event types based on the event field. The message frame types of Protocol Y include command frames, data frames, response frames, and event frames. Response frames reuse the same message identifier field as the original request to complete pairing, and event frames carry an event type field to indicate the window management event. Identifier binding steps: After receiving a switching request, write the request process identifier and the target display output into the binding table, and in the drawing surface submission callback, read the process identifier of the Wayland client, match the corresponding drawing surface, create or update the view, and establish a binding relationship between the view and the target display output; Switching control steps: When the window is not in full-screen mode, move the view to the origin of the target monitor's coordinates, insert the target layer, and trigger geometry update and graphics composition. When the window is in full-screen mode, compare the target monitor resolution with the drawing surface size. If they are inconsistent, send a redraw instruction to the client according to the target resolution and complete the binding in the resubmission callback. If they are consistent, complete the binding and update the composition output.

2. The method according to claim 1, characterized in that, The following steps after switching control also include: Topology recovery steps: Listen for display topology change events, and restore the binding between the view and the original target display after the display is hot-plugged, based on the binding table. If the target display is unavailable, migrate to the alternative display according to the preset priority, and migrate back after the original target display becomes available again. The two unidirectional pipes are created by the operating system pipe interface. The read end of the uplink pipe is registered to the Weston event loop for the main thread to asynchronously receive and process window management messages from the communication sub-thread. The downlink pipe is used by the main thread to send back processing results and control instructions to the communication sub-thread to ensure the orderliness of message transfer between threads and the single-thread execution constraint of the main thread.

3. The method according to claim 2, characterized in that, The communication access step and the identifier binding step also include: The legality determination process is as follows: The management process running in user mode performs cyclic redundancy check, limits the length of the message buffer queue, and discards expired messages. The upper limit of the queue length is a preset value M, the message processing interval is a preset value N, and the expiration threshold is a preset value D. Only messages that pass the determination are forwarded to the window management module for processing. The binding table mentioned in the identification binding step records at least the process identifier, target display name, target layer index, and the timestamp of the most recent submission. This is used to find the corresponding view in the subsequent drawing surface submission callback and maintain a stable correspondence between the window, display, and layer. The process identifier mentioned in the identifier binding step is carried by the Wayland client object. The window management module reads the process identifier in the drawing surface submission callback and matches it one by one with the process identifiers in the binding table, thereby completing the binding of view recognition and target display output. The field lengths of the protocol Y are configured as follows: the message identifier field is four bytes, the timestamp field is four bytes, the data length field is two bytes, the verification field is two bytes, and the maximum length of the additional data field is a preset value L, which is used to carry necessary control information without increasing round-trip delay.

4. The method according to claim 3, characterized in that, In the switching control steps, for non-full-screen displays, the view coordinates are set to the origin of the target display coordinate system, the view is inserted at the end of the view list of the target layer, and then the view geometry update and graphic composition are triggered to complete the output switching within the same frame. In the switching control steps, for full-screen displays with inconsistent resolutions, the view is temporarily mapped to the visible area of ​​the target display and the current frame is kept on display. An instruction to redraw according to the target resolution is sent to the client. In the callback of the client's resubmission, the size matching and binding with the target display are completed, and the view transformation update and composite output are triggered. In the switching control steps, for the top-pinning request, the window management module moves the corresponding view from the regular application layer to the top-pinning application layer, and updates the overlay relationship in the top-pinning application layer according to the order in which the views were added, so as to ensure the predictability of the top-pinning display.

5. The method according to claim 4, characterized in that, In the module loading step, five layers are preset in the compositor, from bottom to top: background layer, video layer, regular application layer, top application layer, and user interface layer. The layer order determines the overlay relationship, which is used to support the aliasing display of video and user interface and the global top window. The module loading process establishes three configuration methods for creating a multi-monitor desktop background: solid color background, image background, and pattern tiling background. Among them, the solid color background is directly generated by the window management module, the image background is submitted by the Wayland client in the background and bound to the background layer of the target monitor through the process identifier, and the pattern tiling background is drawn by carrying RGB color block data in the local binary message frame and tiling in the background buffer. In the binding step, the target display is indexed by the display name, which is consistent with the name of the compositor output object. When performing the binding, the window management module locates the target output based on the display name index. After the module loading step is completed, the system default display can be set. The default display is used to specify the initial output target of the newly launched application when no explicit switching request is received, and the changes will take effect immediately on subsequent newly created views when the default display is changed.

6. The method according to claim 5, characterized in that, In the topology restoration step, a priority table is used for restoration and migration. The priority table includes at least priority 1 for displays with completely matching names, priority 2 for displays with the same type as the original displays, and priority 3 for the displays with the smallest number among the currently available displays. This is used to migrate the original target displays in an orderly manner when they are unavailable and to automatically migrate them back after they are made available again. In the communication access process, the communication sub-thread does not directly call any window management interface. All window management operations are executed sequentially by the main thread in the event loop callback. The communication sub-thread only submits messages through the unidirectional pipe used for uplink and receives instructions or results through the unidirectional pipe used for downlink, so as to ensure single-threaded execution constraints and thread safety. In addition to the UNIX domain socket-based channel, the communication access step also provides a named pipe as a control channel for command-line access. The named pipe supports checking service status, obtaining the number of displays, obtaining the display name, setting the system default display, switching displays by process identifier, and returning execution failure if no result is obtained within the timeout threshold. In the communication access step, a communication timeout threshold T, a message processing interval N, and a queue length limit M are set. When the waiting time exceeds the timeout threshold T, failure is immediately returned and the waiting stops. When the message arrival rate is too high, causing the queue length to reach the limit M, new messages are discarded and audit information is recorded to avoid abnormal traffic affecting the stability of the synthesizer.

7. A Wayland window management system that supports dynamic display switching, characterized in that, include: The Weston compositor is used to receive and composite client-drawn surfaces and output them to the display. The window management module is loaded into the Weston compositor as a plug-in. It performs window management operations within the compositor's main thread, registers the add callback, submit callback, move callback, and size change callback for the desktop interface, and is used to implement view creation, view update, and output binding within the lifecycle of the drawing surface. A communication sub-thread, set within the window management module, is used to listen for local inter-process communication based on UNIX domain sockets; Two unidirectional pipes are used. The first unidirectional pipe is used for the communication sub-thread to send messages to the synthesizer main thread, and the second unidirectional pipe is used for the synthesizer main thread to send instructions to the communication sub-thread. The pipe reading end used by the main thread to receive is registered to the Weston event loop to ensure that window management operations are executed sequentially within the synthesizer main thread. An external management process is used to perform verification, rate limiting, and forwarding of messages from the application, and to transfer compliant messages to the window management module for processing. The binding table records the process identifier, target display name, target layer index, and timestamp to complete the matching and binding of the view and display output in the commit callback; The layer management structure includes at least a background layer, a video layer, a regular application layer, a pinned application layer, and a user interface layer to support aliasing and pinning. The application-side dynamic link library provides interfaces for querying the number of displays, obtaining the display name, setting the default display, switching displays by process identifier, and setting the target layer. The window management module is configured to set the view coordinates to the origin of the target display coordinate system and trigger a geometric update when switching from a non-full-screen window. When switching from a full-screen window and the resolutions are inconsistent, it sends a redraw instruction to the client according to the target resolution and completes the binding after resubmission. After listening for changes in the display topology, it restores the window to the original target display or migrates it to a backup display according to priority based on the binding table.

8. The system according to claim 7, characterized in that, The external management process performs cyclic redundancy check on messages, limits the length of the message cache queue, and discards expired messages. The maximum queue length is a preset value M, the message processing interval is a preset value N, and the expiration threshold is a preset value D. Only messages that pass the check and have not expired are transferred to the window management module for processing. The two unidirectional pipes are created by the operating system pipe interface. The unidirectional pipe for receiving messages from the main thread is registered to the Weston event loop to trigger the main thread to read and process window management messages. The unidirectional pipe for receiving messages from child threads is used by the main thread to send back processing results and control instructions, so as to ensure the orderliness of message transfer between threads and the single-thread execution constraint of the main thread.

9. The system according to claim 8, characterized in that, The communication sub-thread interacts with the external management process using a local binary message protocol. The message frame of the message protocol includes at least a frame header field, a type field, a message identifier field, a timestamp field, a command field or a data field, and a verification field. The verification algorithm of the verification field is CRC-16 / CCITT-FALSE, which is used to achieve a one-to-one correspondence between requests and responses and to verify data integrity. The layer management structure has the following coverage relationship from bottom to top: background layer, video layer, regular application layer, pinned application layer, and user interface layer. When the window management module receives a pinned request, it moves the corresponding view from the regular application layer to the pinned application layer and updates the coverage relationship in the pinned application layer according to the order in which the views were added. The binding table establishes a mapping based on the monitor name as an index. The monitor name is consistent with the name of the compositor output object. When performing view binding, the window management module locates the target output object based on the monitor name index and completes the binding.

10. The system according to claim 9, characterized in that, The window management module provides three configuration methods for desktop backgrounds on multiple monitors: solid color background, image background, and pattern tiling background. The solid color background is directly generated by the window management module, the image background is submitted by the Wayland client in the background and bound to the background layer of the target monitor through the process identifier, and the pattern tiling background is drawn by carrying RGB color block data in the background buffer using the local binary message protocol. The application-side dynamic link library provides named pipes as a control channel for command-line access. The named pipes support checking service status, obtaining the number of displays, obtaining the display name, setting the system default display, switching displays by process identifier, and returning execution failure if no result is obtained within the timeout threshold. After detecting a change in the display topology, the window management module restores and migrates the display according to a priority table. The priority table includes at least priority 1 for displays with completely matching names, priority 2 for displays of the same type as the original display, and priority 3 for the display with the smallest number among the currently available displays. After the original target display is restored to usability, the window management module migrates back to the original target display.

Images