A multi-display terminal capable of real-time screen switching and a method thereof.
The multi-display terminal facilitates real-time screen switching in vehicles by managing screen properties through a software framework, addressing inefficiencies and safety risks in existing technologies, ensuring smooth transitions and adaptive information display.
Patent Information
- Application Number
- JP2026019619
- Authority / Receiving Office
- JP · JP
- Patent Type
- Applications
- Current Assignee / Owner
- Priority Date
- 2025-02-14
- Filing Date
- 2026-02-09
- Publication Date
- 2026-08-26
AI Technical Summary
Existing display technologies in vehicles are limited by fixed pipelines that restrict information display to specific screens, leading to inefficiencies and potential safety risks during real-time screen switching, especially when drivers need diverse information depending on driving conditions.
A multi-display terminal with a framework application that manages properties of multiple screens, allowing seamless real-time screen switching by exchanging properties of pipelines via a software-based method, eliminating the need for hardware switchers and reducing computational complexity.
Enables real-time, smooth screen transitions without delays or flickering, enhancing driver convenience and safety by allowing dynamic information display adaptation to driving environments.
Smart Images

Figure 2026137078000001_ABST
Abstract
Description
Technical Field
[0006]
[0001] The present invention relates to a multi-display terminal capable of real-time screen switching and a method thereof.
Background Art
[0002] Pipeline change is a sophisticated operation that requires close communication and coordination between hardware (H / W) and software (S / W) in a display terminal that outputs display data.
[0003] DRM (Direct Rendering Manager) is a hardware interface that connects a display device and graphic data, and each pipeline is fixedly assigned to a specific display device. That is, the existing DRM design is designed such that the image data generated by each application is output only to a specific display device. To change this, the components of DRM, namely, plane, CRTC (Cathode Ray Tube Controller), encoder, connector, etc. must be reconfigured.
[0004] For such reconfiguration, the state of the existing pipeline must be released, and new settings must be generated and applied. However, display delay or interruption may occur during this process.
[0005] When a pipeline change request occurs in real time, the kernel must immediately process the change, which may cause problems of high computational complexity and hardware resource collision.
[0006] On the other hand, the number of display devices inside vehicles is increasing, and the amount of information that can be displayed is becoming more diverse. As a result, drivers can obtain a variety of information such as speed, destination information, AV (Audio / Video), and air conditioning information through the multiple display devices.
[0007] However, even with a variety of display screens, drivers can acquire information when the vehicle is stopped or in restricted situations, and the display screens they can actually see while driving are limited. Therefore, the screens that drivers need while driving vary depending on the driving environment, such as when the vehicle is stopped, and consequently, the information displayed on the screen closest to the driver's field of view can also be diverse.
[0008] However, as mentioned earlier, conventional technology has the limitation that an application can only utilize one pipeline, and therefore image data can only be displayed on a designated display device. [Overview of the project] [Problems that the invention aims to solve]
[0009] This disclosure provides a multi-display terminal capable of real-time screen switching and a method for doing so. [Means for solving the problem]
[0010] According to one feature, the method for operating a multi-display terminal equipped with multiple screens includes the steps of: executing a pipeline switch that utilizes the properties of the target screen to exchange some of the properties of each screen when a screen switching request occurs via user input; and applying the property change information of the switched pipeline to the target screen.
[0011] The execution step described above can change the properties of the kernel's CRTC (Cathode Ray Tube Controller) and connector for the first screen to the properties of the CRTC and connector for the second screen, and change the properties of the CRTC and connector for the second screen to the properties of the CRTC and connector for the first screen.
[0012] Prior to the execution step, the step may further include collecting and storing properties for each pipeline screen from multiple display applications connected by separate pipelines to the multiple screens.
[0013] The execution and storage steps may be performed by a framework application located between the multiple display applications and the kernel.
[0014] In the execution step, the framework application, in response to a request from the pipeline switching application that has detected the screen switching request, provides the properties of the pipeline to be switched to the pipeline switching application, receives each property processed by the pipeline switching application, and can perform the pipeline switching based on the processed properties.
[0015] According to other features, the multi-display terminal includes one or more display devices that output multiple screens, a memory that stores instruction words, and a processor that executes the instruction words. By executing the instruction words, the processor is configured to realize a kernel that processes image data to be output to the multiple screens, multiple display applications that are connected to the multiple screens by separate pipelines and generate properties, which are display settings for each screen, and output them to the kernel, and a framework application that is located between the kernel and the multiple display applications. When a screen switching request occurs due to user input, the framework application can execute a pipeline switch that uses the properties for the screen to be switched to exchange some of the properties of each screen, and can apply the property change information of the switched pipeline to each of the screens.
[0016] The processor is configured to detect the screen switching request, receive and process the properties of the pipeline to be switched from the framework application, and further implement a pipeline switching application that transmits the processed properties to the framework application, and the framework application can perform the switching of the pipeline based on the processed properties received from the pipeline switching application.
[0017] The framework application can collect and store screen properties for each pipeline from the multiple display applications at predetermined intervals, and manage each pipeline in a centralized manner.
[0018] The framework application may be a daemon application that operates independently of the kernel.
[0019] The framework application can change the kernel's CRTC (Cathode Ray Tube Controller) and Connector properties for the first screen to the CRTC and Connector properties for the second screen, and change the CRTC and Connector properties for the second screen to the CRTC and Connector properties for the first screen.
[0020] The kernel includes a Direct Rendering Manager (DRM), which is a hardware interface that links the image data of the multiple display applications with the multiple screens. The DRM may include a Plane, which is a basic unit for managing image data; a CRTC, which converts the image data of the Plane into pixel data and outputs it to a display device; an Encoder, which encodes the pixel data generated by the CRTC; a Bridge, which converts the encoded pixel data into a hardware display interface; and a Connector, which is a display output port connected to the display device.
[0021] The processor is configured to further implement back-end modules for each display application that perform processing for transmitting image data from the multiple display applications to the DRM, and each back-end module for each display application can be shared by the GUI (Graphical User Interface) module of each display application. [Effects of the Invention]
[0022] According to this disclosure, a multiplex display device that outputs image data for multiple applications can be switched in real time.
[0023] In addition, the multi-display terminal installed in the vehicle can increase the convenience of the driver by switching the screen in real time so that the driver can obtain the desired information even during driving.
[0024] Furthermore, it is possible to solve the hardware constraint problems and cost problems due to existing screen switching.
Brief Description of the Drawings
[0025] [Figure 1] It is a configuration diagram of a multi-display terminal according to an embodiment. [Figure 2] The switching operation of the pipeline for screen switching in FIG. 1 will be described. [Figure 3] It is an exemplary diagram for switching the screen in a multi-display terminal installed in a vehicle according to an embodiment. [Figure 4] It is a flowchart for explaining the screen switching operation of a multi-display terminal according to an embodiment.
Modes for Carrying Out the Invention
[0026] Hereinafter, referring to the attached drawings, embodiments of the present invention will be described in detail so that those having ordinary knowledge in the technical field to which the present invention pertains can easily implement them. However, the present invention can be realized in various different forms and is not limited to the embodiments described here. And, in order to clearly explain the present invention in the drawings, parts that are unnecessary for the explanation are omitted, and similar parts throughout the specification are denoted with similar reference numerals.
[0027] In the description, when a certain part "includes" a certain component, this means that, unless otherwise stated to the contrary, it does not exclude other components but can further include other components.
[0028] Furthermore, terms such as "...part," "...device," and "...module" used in the specification refer to a unit that processes at least one function or operation, which can be achieved through hardware, software, or a combination of hardware and software.
[0029] In this explanation, the reference numerals and names in the drawings are provided for the convenience of explanation, and the device is not necessarily strictly limited to the reference numerals and names in the drawings.
[0030] In this specification, “transmission or provision” may include not only direct transmission or provision, but also indirect transmission or provision via other devices or by utilizing alternative routes.
[0031] In this specification, expressions written in the singular can be interpreted as singular or plural unless explicitly stated otherwise, such as "one" or "single."
[0032] In this specification, regardless of the drawing, the same drawing number refers to the same component, and "and / or" includes each of the components mentioned and all combinations of one or more of them.
[0033] In this specification, ordinal terms such as "First," "Second," etc., may be used to describe a variety of components, but the components are not limited by such terms. The terms are used solely for the purpose of distinguishing one component from another. For example, to the extent that it does not exceed the scope of the rights of this disclosure, the first component may be named the second component, and similarly, the second component may also be named the first component.
[0034] In the flowcharts described herein with reference to the drawings, the order of operations can be changed, various operations may be merged, certain operations may be divided, and certain operations may not be performed.
[0035] The apparatus of this disclosure is a computing apparatus configured and coupled so that at least one processor can perform the operations of this disclosure by executing instructions. A computer program includes instructions written to cause a processor to perform the operations of this disclosure and can be stored on a non-transitory computer-readable storage medium. The computer program may be downloaded over a network or sold in product form.
[0036] Figure 1 is a configuration diagram of a multi-display terminal according to one embodiment, Figure 2 illustrates the switching operation of the pipeline for screen switching in Figure 1, and Figure 3 is an example diagram of screen switching in a multi-display terminal mounted on a vehicle according to one embodiment.
[0037] A multi-display terminal is a terminal equipped with multiple displays, that is, multiple screens.
[0038] A multi-display terminal may include multiple display devices that output individual screens. In this case, each display device is connected to multiple different applications via independent pipelines.
[0039] The pipeline is configured to graphically process the application's content data and output it to the screen.
[0040] A multi-display terminal may include a single multi-display device that outputs multiple screens. In this case, the overall screen of the single multi-display device is divided into multiple sections, and each divided screen is connected to multiple different applications in independent pipelines.
[0041] A multi-display terminal may include one or more display devices that output individual screens, and one or more multi-display devices that output multiple divided screens.
[0042] In the following examples, for the sake of explanation, a multiplex display terminal equipped with multiple display devices that output individual screens will be described as an example, and such a configuration is applicable to all of the various forms of multiplex display terminals described above.
[0043] Referring to Figure 1, the multi-display terminal 100 may be configured in a hierarchy that includes hardware 110, a kernel 120, and a user space 130.
[0044] Hardware 110 generally includes memory for storing instruction words, a processor for executing the instruction words in memory, input devices, display devices, etc. However, for the sake of explanation, the drawings do not show the processor, memory, storage, and input devices, and only the multiplex display devices 111, 112, and 113 are shown.
[0045] Here, the memory of hardware 110 stores the kernel 120 and the DRM libraries 131, modules 133, 134, and applications 132, 135, 136, 137, and 138 of user space 130. The processor of hardware 110 executes the kernel 120 and the DRM libraries 131, modules 133, 134, and applications 132, 135, 136, 137, and 138 of user space 130 that are stored in memory.
[0046] The kernel 120 directly controls the hardware 110, while multiple applications 135, 136, and 137 in user space 130 can indirectly access the hardware 110 through the kernel 120.
[0047] Display devices 111, 112, and 113 each output image data through their individual screens. Display devices 111, 112, and 113 may include display functions and input detection functions. Display devices 111, 112, and 113 may also be in the form of touchscreens.
[0048] Kernel 120 is the memory space where the operating system kernel (core code) is executed, and it manages hardware and system resources. Kernel 120 directly interacts with hardware 110 and controls the CPU (Central Processing Unit), memory, I / O devices, etc.
[0049] Display devices 111, 112, and 113 each output image data through their individual screens. Display devices 111, 112, and 113 may include display functions and input detection functions. Display devices 111, 112, and 113 may also be in the form of touchscreens.
[0050] Kernel 120 is the memory space where the operating system kernel (core code) is executed, and it manages hardware and system resources. Kernel 120 directly interacts with hardware 110 and controls the CPU (Central Processing Unit), memory, I / O devices, etc.
[0051] Kernel 120 has all privileges, is isolated and protected from userspace 130, and handles program requests (system calls) from userspace 130.
[0052] The kernel 120 processes the image data to be output to the display devices 111, 112, and 113, respectively.
[0053] The kernel 120 may include a DRM (Direct Rendering Manager) 121 and an input processing driver 127.
[0054] DRM121 is a hardware interface that connects multiple display applications, image data 135, 136, and 137, with display devices 111, 112, and 113.
[0055] The DRM121 may include a plane 122, a CRTC (Cathode Ray Tube Controller) 123, an encoder 124, a bridge 125, and a connector 126.
[0056] Plane 122 is the basic unit for managing image data (or graphic data) output to the screens of the display devices 111, 112, and 113, and processes various image layers (e.g., UI (User Interface), video). Plane 122 is coupled to a specific memory buffer to provide image data.
[0057] Plane 122 includes a Primary Plane, an Overlay Plane, and a Cursor Plane. The Primary Plane handles basic display content. The Overlay Plane handles additional layers (e.g., video, graphics). The Cursor Plane handles UI elements such as the mouse cursor.
[0058] CRTC123 converts the data from plane 122 into pixel data and outputs it to display devices 111, 112, and 113. CRTC123 controls the display timing (e.g., refresh rate).
[0059] The CRTC123 constructs its screen by combining multiple planes.
[0060] The CRTC123 configures the display mode (resolution, refresh rate, etc.) and connects to the screen output path.
[0061] Encoder 124 converts the pixel data generated by CRTC 123 into a signal suitable for display devices 111, 112, and 113. Encoder 124 works in cooperation with Bridge 125 to transmit the signal, supporting various display output ports and setting the signal format (digital, analog, etc.). For example, encoder 124 can support HDMI (High Definition Multimedia Interface), DisplayPort, VGA (Video Graphics Array), and others.
[0062] Bridge 125 converts display data to a hardware display interface, performs signal conversion at the final stage of display output, and transmits the display signal, providing compatibility with specific display devices 111, 112, and 113. For example, the hardware display interface may include HDMI, LVDS (Low-Voltage Differential Signaling), DSI (Display Serial Interface), etc.
[0063] Connector 126 is connected to the display devices (including monitors, panels, etc., 111, 112, and 113) and manages the status of the display devices 111, 112, and 113. Here, the status of the display devices 111, 112, and 113 includes whether or not they are connected, and whether EDID (Extended Display Identification Data) has been read.
[0064] Connector 126 is an actual display output port and may include a plug-and-play function, which is an automatic recognition function when a display is connected.
[0065] The input processing driver 127 transmits the screen switching event generated by user input to the pipeline switching application 138.
[0066] User space 130 is an area where multiple applications 135, 136, 137, and 138 are executed, and it is a memory space that can be accessed by general user processes.
[0067] Userspace 130 is where application programs (e.g., web browsers, text editors) run, protected by the operating system to prevent direct access to system resources, and uses system calls to communicate with kernel 120.
[0068] Userspace 130 includes the DRM library (libdrm) 131, the framework application 132, the back-end module 133, the GUI (Graphic User Interface) module 134, and multiple applications 135, 136, 137, and 138.
[0069] The DRM library (libdrm) 131 provides a user-space library for multiple display applications 135, 136, and 137 to access DRM 121 in operating systems that support the IOCTL (Input / Output control) interface.
[0070] Framework application 132 monitors each pipeline and handles its properties.
[0071] One pipeline connects individual display applications 135, 136, 137, GUI module 134, backend module 133, framework application 132, DRM library 131, DRM components, namely plane 122, CRTC 123, encoder 124, bridge 125, connector 126, and individual display devices 111, 112, 113.
[0072] The properties are used to manage display components such as plane 122, CRTC 123, encoder 124, bridge 125, and connector 126. Their main functions include content position / size setting, display mode control, linked display information management, color correction, and power management.
[0073] The framework application 132 is located between the kernel 120 and several display applications 135, 136, and 137.
[0074] The framework application 132 collects and stores properties for each pipeline's display device 111, 112, and 113 from multiple display applications 135, 136, and 137 at predetermined intervals, and centrally manages each pipeline.
[0075] The framework application 132 can store and manage property information for each pipeline in the Resource Manager at predetermined times or intervals. Here, the predetermined time or interval can include at least one of a user-defined interval, 10-20ms, or 16.6ms.
[0076] The framework application 132 may be a daemon application that operates independently of the kernel 120. Therefore, it can be implemented in a structure that can operate regardless of the kernel 120 and has extremely reduced complexity.
[0077] When a screen switching request occurs via user input, the framework application 132 executes a pipeline switch that utilizes the properties of the target screen to exchange some of the properties of each screen, and applies the property change information of the switched pipeline to the display devices 111, 112, and 113 corresponding to each screen.
[0078] According to one embodiment, the use of properties can include actions that are taken when a screen switching request occurs.
[0079] Framework application 132 is a DRM driver extension kernel module code that can perform utilization operations using utilization code for the main components of DRM121. The utilization code can be implemented as shown in Table 1.
[0080] [Table 1]
[0081] The use of properties can include the framework application 132 utilizing frace to track DRM function calls and collect necessary information, monitoring real-time display information using the debugfs interface, and implementing a DRM event listener to detect changes in the display state.
[0082] In other embodiments, the utilization of properties may include storing properties in a lookup table (LUT) and retrieving those properties from the lookup table (LUT) when a screen switching request occurs. The lookup table (LUT) may store properties for each pipeline at regular intervals.
[0083] Furthermore, according to other embodiments, the utilization of properties may include temporarily storing the properties in flash memory or similar when the vehicle is started, and then calling up and using the temporarily stored properties when a screen switching request occurs. The flash memory may store properties for each pipeline at regular intervals. The properties stored in the flash memory are deleted when the vehicle is turned off.
[0084] The property information used by framework application 132 is obtained from the resource manager that manages the properties within framework application 132.
[0085] The framework application 132 performs pipeline switching based on the processed properties received from the pipeline switching application 138.
[0086] When the framework application 132 receives a screen switching request from the pipeline switching application 138, it performs pipeline switching, which involves exchanging some of the pipeline properties of each screen between the screens to be switched. The framework application 132 identifies the display devices 111, 112, and 113 that output the screens to be switched. The framework application 132 uses the pipeline properties of the identified display devices 111, 112, and 113 to perform pipeline switching. In other words, the framework application 132 changes some of the properties of display device A (111) that outputs the screen A to be switched to the properties of display device B (112) that outputs the screen B to be switched to, and changes some of the properties of display device B (112) to the properties of display device A (111).
[0087] The properties to be changed are those of CRTC123 and connector 126, while plane 122 remains unchanged.
[0088] The framework application 132 transmits the utilized properties to the pipeline switching application 138 and receives the properties processed by the pipeline switching application 138. Based on the received processed properties, the framework application 132 performs a pipeline switch. In other words, the framework application 132 performs a pipeline switch that changes the properties of the kernel's CRTC123 and connector 126 for the first screen to the properties of the CRTC123 and connector 126 for the second screen, and changes the properties of the CRTC123 and connector 126 for the second screen to the properties of the CRTC123 and connector 126 for the first screen.
[0089] Since modifying the pipeline requires permissions to use the resources of kernel 120, framework application 132 acts as a manager to appropriately distribute permissions among multiple applications 135, 136, 137, and 138.
[0090] Framework application 132 dynamically manages and modifies all display settings (Properties). Because property monitoring and utilization are handled by a single engine via framework application 132, screen switching can be easily performed.
[0091] The back-end module 133 is a DRM-back-end module that performs processing to transmit image data from multiple display applications 135, 136, and 137 to the DRM 121. The back-end module 133 is linked to each of the display applications 135, 136, and 137 and is attached to the framework application 132.
[0092] Traditionally, the backend module was configured to exclusively use the DRM for the GUI alone. However, the backend module 133 of this disclosure enhances drm-backend.so (an already constructed DRM backend module) to support the simultaneous use of DRM 121 by other display applications 135, 136, and 137. In other words, the backend module 133 is shared by the GUI modules 134 of each of the display applications 135, 136, and 137.
[0093] The GUI module 134 composites images requested by multiple display applications 135, 136, and 137 into a single image. For example, the GUI module 134 may include a Weston module.
[0094] Multiple applications 135, 136, 137, and 138 include multiple display applications 135, 136, and 137 and a pipeline switching application 138.
[0095] Multiple display applications 135, 136, and 137 are connected to the multi-display device via their own independent pipelines, generating properties (display settings) for each individual screen and outputting them to the kernel 120.
[0096] If the multi-display terminal 100 is a terminal installed in a vehicle, the multiple display applications 135, 136, and 137 may be, for example, a cluster application 135, an in-vehicle infotainment (IVI) application 136, and a camera application 137.
[0097] The cluster application 135 can display cluster information within the vehicle, that is, basic vehicle information such as RPM (revolutions per minute), speed, and warnings, as well as autonomous driving operation information such as distance between vehicles, lane recognition display, vehicle proximity warning, and pedestrian warning.
[0098] IVI application 136 can perform GPS (Global Positioning System) navigation, multimedia entertainment, various user-downloadable applications, voice recognition, safety diagnostic functions, and more.
[0099] The camera application 137 can process images taken of the interior and exterior of the vehicle in conjunction with cameras installed at various locations within the vehicle.
[0100] Pipeline switching application 138 is an application that allows you to know the current display status and switch pipelines.
[0101] When the pipeline switching application 138 receives a screen switching request event from the input processing driver 127, it requests the framework application 132 to switch screens. The pipeline switching application 138 receives and processes the properties of the pipeline to be switched from the framework application 132, and transmits the processed properties back to the framework application 132.
[0102] Here, applications connected to the display devices 111, 112, and 113 by pipelines are referred to as display applications 135, 136, and 137, and are classified separately from the pipeline switching application 138.
[0103] Each display application 135, 136, and 137 writes content to the desired image layer 122, and each display application 135, 136, and 137 performs display configuration work by selecting the desired display mode and display device 111, 112, and 113.
[0104] Display modes can include settings such as Resolution and Refresh Rate.
[0105] The display configuration process is generated using text-based properties, and these properties constitute information transmitted to the display devices 111, 112, and 113 in a single pipeline.
[0106] The framework application 132 monitors and stores all properties. When a screen switching event occurs, the pipeline switching application 138 processes the properties used by the framework application 132 to modify the pipeline and provides them to the framework application 132.
[0107] The framework application 132 transmits the processed properties to the kernel 120 all at once via the DRM library 131. The kernel 120 performs pipeline modifications based on the transmitted properties and outputs the content of each display application 135, 136, and 137 to the switched display devices 111, 112, and 113.
[0108] Referring to Figure 3, with display devices 111, 112, and 113 arranged in a row, the user can switch between adjacent screens.
[0109] For example, when a user input occurs to switch from display device A (111) to display device B (112), the CRTC123 in the properties of cluster application 135, which is pipelined to display device A (111), is changed to the CRTC123 in the properties of IVI application 136, which is pipelined to display device B (112). Therefore, the pipeline of cluster application 135 is changed to display components 122, 123, 124, 125, and 126, which are pipelined to display device B (112). In other words, as shown in Figure 2, the pipeline for cluster application 135 consists of "cluster application 135 - GUI module 134 - backend module 133 - framework application 132 - DRM library 131 - plane 122 connected to display device A (111) - crtc 123 connected to display device B (112) - encoder 124 connected to display device B (112) - bridge 125 connected to display device B (112) - connector 126 connected to display device B (112) - display device B (112)".
[0110] When user input occurs to switch from display device B(112) to display device C(113), the CRTC123 in the properties of the IVI application 136, which is pipelined to display device B(112), is changed to the CRTC123 in the properties of the camera application 137, which is pipelined to display device C(113). Consequently, the pipeline of the IVI application 136 is changed to the display components 122, 123, 124, 125, and 126, which are pipelined to display device C(113). In other words, as shown in Figure 2, the pipeline for IVI application 136 consists of "IVI application 136 - GUI module 134 - Backend module 133 - Framework application 132 - DRM library 131 - plane 122 connected to display device B (112) - crtc 123 connected to display device C (113) - encoder 124 connected to display device C (113) - bridge 125 connected to display device C (113) - connector 126 connected to display device C (113) - display device C (113)".
[0111] When user input occurs to switch from display device C(113) to display device A(111), the CRTC123 in the properties of camera application 137, which is pipelined to display device C(113), is changed to the CRTC123 in the properties of cluster application 135, which is pipelined to display device A(111). Consequently, the pipeline of camera application 137 is changed to display components 122, 123, 124, 125, and 126, which are pipelined to display device A(111). In other words, as shown in Figure 2, the pipeline for camera application 137 consists of "camera application 137 - GUI module 134 - backend module 133 - framework application 132 - DRM library 131 - plane 122 connected to display device C (113) - crtc 123 connected to display device A (111) - encoder 124 connected to display device A (111) - bridge 125 connected to display device A (111) - connector 126 connected to display device A (111) - display device A (111)".
[0112] At this time, even if the screen is switched, the plane 122 of each pipeline remains the same as before the switch. In other words, the pipelines of each display application 135, 136, and 137 have the same plane connected to the display device before the switch, and are switched from the CRTC to the display devices 111, 112, and 113 that are being switched.
[0113] As described above, the multi-display terminal 100 monitors the properties of the display applications 135, 136, and 137, and when a screen switching event occurs, it modifies the pipeline connected to the screen to be switched, allowing the content to be switched and output through the switched display screen.
[0114] Modifying the pipeline in existing systems can cause problems such as screen delays, blackouts, and flickering due to conflicts with screen update timing. This can be distracting in a vehicle display environment used while driving and may pose a safety risk. However, the pipeline modification method described in this disclosure allows for smooth screen transitions without screen delays or flickering, ensuring driver safety.
[0115] Furthermore, real-time screen switching is possible via a framework application without the need for hardware such as a monitor switcher, allowing the driver to obtain information through their desired screen while driving, and the passenger to switch their desired screen to their preferred position. For example, while driving, the cluster screen can be primarily placed in the driver's field of view, and the infotainment screen can be temporarily placed in the driver's field of view when the vehicle is stopped or when necessary, before being returned to its original position.
[0116] According to this disclosure, a software-based solution that replaces hardware-based screen switchers (e.g., monitor switchers) is commercially viable and can be offered to vehicle manufacturers and automotive software developers as a cost-saving solution. Furthermore, it is possible to develop vehicle software that allows the driver and front passenger to individually switch screens and configure information settings.
[0117] Based on the configuration described above, the operation of the multi-display terminal 100 will now be explained. In this explanation, the same reference numerals will be used for descriptions relating to the same configuration.
[0118] Figure 4 is a flowchart illustrating the screen switching operation of a multi-display terminal according to one embodiment.
[0119] In this case, the display devices to be switched are exemplified by display device A (111) and display device B (112).
[0120] Referring to Figure 4, the framework application 132 stores properties for each pipeline at regular intervals (S101). In other words, the framework application 132 can collect and store properties for the screens output by the display devices 111, 112, and 113 of each pipeline from multiple display applications 135, 136, and 137, which are connected by separate pipelines independent of the display devices 111, 112, and 113 that output individual screens.
[0121] When the input processing driver 127 receives a screen switching request based on user input (S102), it generates an event requesting a screen switching and transmits it to the pipeline switching application 138 (S103).
[0122] The pipeline switching application 138 transmits the screen switching request to the framework application 132 (S104).
[0123] The framework application 132 checks the number of pipelines currently running (S105) and determines whether the number of pipelines is two or more (S106).
[0124] The framework application 132 transmits a screen switching failure notification to the pipeline switching application 138 if the number of pipelines is not two or more (S107).
[0125] If the number of pipelines is two or more, the framework application 132 identifies the screen to be switched based on the screen switching request (S108).
[0126] The framework application 132 utilizes the properties of the identified screens to perform a pipeline switch, exchanging some of the properties of each screen (S109). In S109, the framework application 132 transmits the utilized properties to the pipeline switching application 138, receives the processed properties from the pipeline switching application 138, and performs a pipeline switch based on these properties.
[0127] The framework application 132 checks the display device to be switched in response to the screen switching request and waits (S110).
[0128] The framework application 132 transmits property change information of the switched pipeline information to the kernel 120 (S111).
[0129] The kernel 120 applies the switched pipeline information (property change information) to each pipeline, i.e., the DRM 121 (S112). In other words, as described in the explanation of Figure 2, the pipelines are switched by the CRTC 123 and connector 126 whose properties have been switched, except for the plane 122.
[0130] Kernel 120 transmits pipeline information from display device B to display device A (111), and transmits pipeline information from display device A to display device B (112) (S113, S114). In other words, the pipelines between display device A (111) and display device B (112) are swapped according to the property change information.
[0131] In S113, the pipeline for IVI application 136 is changed to DRM components 123, 124, 125, and 126 connected to display device A (111), and in S114, the pipeline for cluster application 135 is changed to DRM components 123, 124, 125, and 126 connected to display device B (112).
[0132] Once the pipeline switching operation is complete, kernel 120 transmits a screen switching notification to framework application 132 (S115).
[0133] The framework application 132 transmits a screen switching notification to the pipeline switching application 138 (S116).
[0134] As an example, the pipeline switching application 138 can pop up a screen switching success message on the screens of the switched display devices 111 and 112.
[0135] The embodiments of the present invention described above may not be realized solely by apparatus and methods, but may also be realized via a program that implements functions corresponding to the configuration of the embodiments of the present invention, or via a recording medium on which such a program is recorded.
[0136] Although embodiments of the present invention have been described in detail above, the scope of the present invention is not limited thereto. Various modifications and improvements made by those skilled in the art, utilizing the basic concepts of the present invention as defined in the following claims, also fall within the scope of the present invention.
Claims
1. A method for operating a multi-display terminal equipped with multiple screens, When a screen switching request is made via user input, the process involves a stage where a pipeline switch is executed, utilizing the properties of the target screen to exchange some of the properties of each screen. The stage of applying the property change information of the switched pipeline to the screen to be switched. Methods that include...
2. The aforementioned execution step is, The method according to claim 1, wherein the properties of the kernel for the first screen's CRTC (Cathode Ray Tube Controller) and connector are changed to the properties of the CRTC and connector for the second screen, and the properties of the CRTC and connector for the second screen are changed to the properties of the CRTC and connector for the first screen.
3. Before the aforementioned execution step, This step involves collecting and storing properties for each screen in a pipeline from multiple display applications connected by separate pipelines, each independent of the aforementioned multiple screens. The method according to claim 2, further comprising:
4. The execution step and the storage step are, The method according to claim 3, which is performed by a framework application located between the plurality of display applications and the kernel.
5. The aforementioned execution step is, The method according to claim 4, wherein the framework application, in response to a request from the pipeline switching application that has detected the screen switching request, provides the properties of the pipeline to be switched to the pipeline switching application, receives each of the properties processed by the pipeline switching application, and performs the switching of the pipeline based on the processed properties.
6. One or more display devices that output multiple screens, Memory for storing instruction words, A processor that executes the aforementioned instruction word, By executing the aforementioned instruction, the processor A kernel that processes the image data to be output to the aforementioned multiple screens, Multiple display applications are connected to the aforementioned multiple screens by their own independent pipelines, and each generates properties (display settings) for each screen and outputs them to the kernel. A framework application located between the kernel and the plurality of display applications is configured to realize The aforementioned framework application is A multi-display terminal that, upon receiving a screen switching request via user input, executes a pipeline switch by utilizing the properties of the target screen to exchange some of the properties of each screen, and applies the property change information of the switched pipeline to each of the aforementioned screens.
7. The aforementioned processor, The system is configured to further implement a pipeline switching application that detects the aforementioned screen switching request, receives and processes the properties of the pipeline to be switched from the framework application, and transmits the processed properties back to the framework application. The aforementioned framework application is A multiplex display terminal according to claim 6, which performs pipeline switching based on processed properties received from the pipeline switching application.
8. The aforementioned framework application is The multiple display terminal according to claim 7, which collects and stores screen properties for each pipeline from the multiple display applications at predetermined intervals and centrally manages each pipeline.
9. The aforementioned framework application is The multi-display terminal according to claim 8, which is a daemon application that operates independently of the kernel.
10. The aforementioned framework application is A multiplex display terminal according to claim 7, wherein the kernel properties for the CRTC (Cathode Ray Tube Controller) and connector for the first screen are changed to the properties for the CRTC and connector for the second screen, and the properties for the CRTC and connector for the second screen are changed to the properties for the CRTC and connector for the first screen.
11. The kernel mentioned above is It includes a DRM (Direct Rendering Manager), which is a hardware interface that links the image data of the multiple display applications with the multiple screens, The aforementioned DRM is A plane is the basic unit for managing image data, The CRTC converts the image data of the plane into pixel data and outputs it to a display device, An encoder for encoding the pixel data generated by the CRTC, A bridge that converts the encoded pixel data into a hardware display interface, The connector is a display output port connected to the display device. A multi-display terminal according to claim 10, including the above.
12. The aforementioned processor, The system is configured to further implement a backend module for each display application that performs processing for transmitting the image data of the multiple display applications to the DRM, The backend module for each of the aforementioned display applications is: A multi-display terminal according to claim 11, shared by the GUI (Graphic User Interface) module of each display application.